This blog post highlights bugs found in installed software while doing vulnerability research. The process for this publication is aligned with the Improsec Responsible Disclosure Policy.
CVE registered
CVE: CVE-2020-12431
What is Splashtop Streamer
Splashtop Streamer is a remote desktop application that allows users to share their desktop and remotely control workstations. The affected component is the Splashtop Updater that is bundled with Splashtop Streamer, as well as certain other Splashtop products.
Timeline
13/2-2020 – Improsec identified the vulnerability.
21/2-2020 – Contact to Splashtop reached, a vulnerability disclosed to the software vendor.
24/2-2020 – The software vendor acknowledged the vulnerability report.
13/3-2020 – Software vendor releases an internal software update for testing.
19/3-2020 – Improsec reviewed the update and acknowledge that the vulnerability was fixed.
6/4-2020 – Improsec contacts vendor again about another vulnerability in the same update function.
7/4-2020 – The software vendor acknowledged the vulnerability report.
14/4-2020 – Software vendor releases an internal software update for testing.
15/4-2020 – Improsec reviewed the update and acknowledge that the vulnerability was fixed.
25/4-2020 – Software vendor releases patched software packages.
19/5-2020 – Public disclosure of the vulnerability.
We want to thank Splashtop Inc. for an effective and professional response.
Walkthrough
Using SysInternals AccessEnum showed that all members of the group "Users" had read and write access to "C:\ProgramData\Splashtop".
Various Splashtop products come bundled with a "Splashtop Updater" package. This package deploys various files, amongst these an executable(sits in taskbar tray) and another executable, "SSUService.exe" that runs as a service in the context of "NT Authority/System".
Performing a manual update from the tray-application would call “SRUpdate.exe” that would call “SSUService.exe” through a named pipe and start an update process.
Monitoring the update process with ProcMon showed, that the service executable read an INI-file from "C:\ProgramData\Splashtop\Splashtop Software Updater\Tracking\".
Loading the service executable into Ghidra and searching for functions that load INI-files showed the below function(here manually renamed to "parse_ini"). The function showed the different possible variables that could be set in the INI-file, amongst these "Platform" which would be set as a filename used to name a logfile.
To test the function I created an INI-file with the "Platform" variable set.
Calling the update function showed that a CSV-file would be created if not already existing. The file would be created in the same directory as the INI-file and would have “Platform_” appended to the beginning of the defined filename.
After the CSV-file had been created, “SetSecurityFile” was called to set read and write rights to “Anyone” for the file.
Setting the "Platform"-variable with a path traversing filename showed, that it was possible to write the CSV-file to any place on the file system. This would also bypass the added “Platform_” to the filename.
While running the update function the "SRUpdate.exe" executable, which ran in the context of "NT Authority/System", would try to load several non-existing DLL-files from the directory "C:\Program Files(x86)\Splasthop\Splashtop Remote\Server\". Amongst these were the DLL-file called "SRUpdateENU.dll".
Since the "SSUService.exe" service, when creating new logfiles, would append a ".csv" to the defined "Platform"-variable and since parent directory rights prevented me from just renaming my CSV-file into f.x. "SRUpdateENU.dll", I had to find a way to prevent the application from appending ".csv" to the filename.
To do this I used the Alternative Data Streams(ADS) function in NTFS. When defining a filename parted with a colon, the last part will be used for the alternative Data Streams. By setting the "Platform"-variable to f.x. "TEST:" the “CreateFile”-function would automatically append ".csv" as an ADS and TEST would be the full filename.
Using this technique allowed me to write an empty file to "C:\Program Files(x86)\Splasthop\Splashtop Remote\Server\SRUpdateENU.dll". Every user on the system would be able to write new data to the file.
Compiling a malicious DLL-file which would execute a reverse shell.
Using "type" to write the content of my malicious DLL-file into the empty "SRUpdateENU.dll", and thereafter calling the update function.
This would execute my reverse shell as "NT Authority/System" and a privilege escalation would be achieved.
Splashtop Software Updater 1.5.6.16 was released which fixes this problem.
Further research into another privilege escalation vulnerability
I did some further research into the Splashtop Update mechanism after the above vulnerability had been patched. I found that the two programs “SRUpdate.exe” and “SSUServer.exe”, were communicating via the already mentioned named pipe called “SSU_IPC_NAMED_PIPE_0” created by “SSUServer.exe”. When an update call was executed “SRUpdate.exe” would connect to the named pipe and send a 560 bytes long payload. This payload contains the filename of the file that “SSUServer.exe” creates in “C:\ProgramData\Splashtop\Splashtop Software Updater\Tracking\”. The filename is appended the file extension “.ini” by “SSUServer.exe”.
Wiretapping the named pipe with ioNinja showed the payload sent upon an update call from “SRUpdate.exe” to “SSUServer.exe”.
Checking permissions on the named pipe showed that all users were allowed to read/write to the pipe.
When the “.ini”-file had been created and written to, a call to “SetSecurityFile” was performed to set the permissions for the file to READ/WRITE for all users.
By sending a custom payload which performed directory traversal to directories(and perform the trick described in the first part of the write-up) and write “.ini” to Alternative Data Streams, the “SSUServer.exe” program was forced into writing data to the directory’s ADS and set the permissions for the directory to READ/WRITE for all users. Afterwards a malicious DLL-file like the above “SRUpdateENU.dll” could be placed in the now writable directory and executed as “NT Authority/System”.
Payload data sent from exploit to named pipe.
Permissions on “C:\Program Files (x86)\Splashtop\Splashtop Remote\Server” was set to READ/WRITE for everyone. Thereby giving the possibility to perform privileged escalation with DLL-hijacking.
Proof-of-concept exploits to perform privileged escalation. “main.dll” copied to “SRUpdateENU.dll” executes a reverse shell.
Splashtop Streamer version 3.3.8.0 comes bundled with Splashtop Updater that fixes this vulnerability.