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.
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).
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
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.
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:
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.
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\StartUpEssentially, 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).
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.
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:
Hello-world.pl file uploaded through BRAVIA:
Validating that the hello-world.pl file was uploaded to cgi-bin directory
500 error when navigating to the file
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.
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).
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.
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.
Next, we uploaded this file to the server to an arbitrary directory, such as C:/Windows/Temp
Then, we crafted our Apache CGI script, which calls the node process installed by the Bravia Signage application pointing to our reverse shell script.
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.
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.
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.
Read more from White Oak Security’s pentesting team.