Sony Bravia Remote Code Execution Disclosure

Sony Bravia Overview

Sony’s BRAVIA Signage (1) is an application to deliver video and still images to Pro BRAVIAs and manage the information displayed across a network. Features include management of displays, power schedule management, content playlists, scheduled delivery management, content interrupt, and more.

NOTE – there is an accompanying video for this post located here.

Previous Vulnerability Disclosure

During our initial analysis, we observed that the Bravia software had the capability to upload arbitrary files onto the file system. This issue had been previously disclosed online as an unauthenticated Remote File Inclusion (RFI) with an advisory ID of ZSL-2020-5612 (2). The proof of concept can be found on exploit-DB (3). This vulnerability is mostly concerned with the ability to upload arbitrary content, with the risk being an exploitation of client-side dynamic scripts to achieve an exploit such as Cross-Site Scripting (XSS).

Disclosure Timeline

9/16/2022: Submitted vulnerability through Sony’s HackerOne submission page
9/19/2022: Submitted additional details on the vulnerability
11/1/2022: Sony team confirmed the issue
4/12/2023: Sony informed White Oak Security an update has been issued to remediate the vulnerability
5/10/2023: White Oak Security publicly discloses the finding after approval was received from communication with Sony via HackerOne

Sony Bravia File Upload

When observing the Bravia application, we realized that while the main application was deployed as a NodeJS server, the content library was actually serving content via Apache. The application allows users the ability to upload content that would be projected onto BRAVIA displays. Digging into the settings functionality of the application, the “content-library” upload directory is allowed to be configured by the end user as shown below.

Sony Bravia contents library in settings screenshot by White Oak Security

Privilege Determination

Since the user could configure the location in which files were to be uploaded on the system, we wanted to determine what privileges this application was being run under. We performed uploads to directories that only privileged accounts could access which include:

C:\Windows\System32\*

With the knowledge that the application is running with privileged access, as an administrative user, we begin to determine the best course of achieving code execution.

Multiple Ways To Achieve Code Execution

Auto-runs windows file (Waiting for privileged user session)

A common folder to look for when having privileged access to a Windows system is the all users startup folder. It is located at the following path:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Essentially, anything placed within this folder will be executed when a user logs into the system. In this case, since it’s not an average user’s workstation there might be a chance a privileged account is logging into the system. If someone wasn’t trying to be opsec safe and went this route you could upload a .bat (batch) file to create a new user account (local or domain account).

Code Execution through Node.js application modifications

The Node.js application was not deployed with “hot-deployments”, meaning that any code change, such as an additional file upload that overwrites an existing Node.js function, would have needed the Node.js service to be restarted in order for a malicious payload to execute. While this was possible, we wanted to push further to achieve an instant code execution path.

Code Execution through Apache CGI-Bin

The Apache cgi-bin directory could be a viable solution for execution. We quickly created a simple Perl script, uploaded it to the Apache Directory, and attempted to navigate to this file. However, instead of a successful hello world, we were presented with a 500 error.

Document Root changed to cgi-bin:

here in the screenshot by White Oak Security is the contents library doc root going to apache

Hello-world.pl file uploaded through BRAVIA:

the upload was complete in Sony Bravia in this screenshot by White Oak Security (hello-world)

Validating that the hello-world.pl file was uploaded to cgi-bin directory

this screenshot by White Oak Security shows where you can look in the cgi-bin directory for the file

500 error when navigating to the file

this screenshot by White Oak Security shows the internal server error while trying to access hello world

The good news is that this 500 error confirms that the file was accessible, we just needed to figure out a way to have the script run. Reading through the RFC for the CGI Interface (RFC-3875 (4)), we realized that any script has the ability to execute arbitrary programs as a built-in functionality of the RFC. Therefore, the most likely conclusion is that Perl is just not installed by default on the Windows Server machine.

this screenshot by White Oak Security shows the 3.4 execution script

To test our theory about the RFC, we simply changed the Perl script Shebang to point to calc.exe instead of the Perl executable (example below).

windows/systems/calc.exe screenshot by White Oak Security

Uploading and navigating to this endpoint in the browser resulted in calc.exe being executed (shown in the task manager below) and now we have a valid path for remote code execution.

task manager screenshot by White Oak Security showing it being executed

In our production environment, we knew we were going to be fighting against an advanced Endpoint Detection and Response (EDR) solution. To complete our exploit, we could either upload a single binary (C2 implant) to bypass endpoint detection, or we could attempt to use the NodeJS server to execute our reverse shell. While the former did work, we also opted for the latter approach as it’s a bit more interesting and can help with evasion when application whitelisting is in place.

First, we created a simple NodeJS reverse shell script which establishes a TCP connection once the script is executed with the Bravia Signage Node process.

function code screenshot by White Oak Security

Next, we uploaded this file to the server to an arbitrary directory, such as C:/Windows/Temp

now we upload shell.js to sony bravia in this screenshot by White Oak Security

Then, we crafted our Apache CGI script, which calls the node process installed by the Bravia Signage application pointing to our reverse shell script.

code shows the apache cgi script in this screenshot by White Oak Security

We uploaded this script to the Apache CGI-Bin directory (C:\Apache24\cgi-bin\). Before execution, we spawned a Netcat listener (nc -lvp 9999) on the host receiving the connection.

Finally, we navigated to our Apache script in the browser and observed the reverse shell executing, establishing a session on the server.

shell exec internal server error screenshot by White Oak Security

power shell code screenshot by White Oak Security

Overall, we were able to take an original proof of concept exploit for a Remote File Inclusion (RFI) vulnerability and chain it into a full unauthenticated Remote Command Execution (RCE) exploit without having to have any additional user interaction on the server.

More From The White Oak Security Team

White Oak Security is a highly skilled and knowledgeable cyber security testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion.