Skip to main content

CVE-2020-16602 - Remote File Execution on Razer Chroma SDK Server (<= v3.12.17)

Introduction

This writeup is about a remote file execution vulnerability I found on the Razer Chroma SDK Server that comes with Razer Synapse. It chains several issues to enable me to remotely execute a file on the user’s system.

This issue is still present in the latest version which is 3.12.17.


Issue 1

The Chroma Server listens binds on all network interfaces and listens on port 54236. The server also does a hostname check to make sure that it is being accessed as https://chromasdk.io/ instead of an IP address. External clients can modify their hosts file to alias an IP address to chromasdk.io in order to access a remote Chroma Server.

Issue 2

When the server receives a call to register an app (via a REST call), it will create a folder in C:\ProgramData\Razer Chroma SDK\Apps\<appname> and write 3 files, ChromaAppInfo.xml, appname.exe and a DLL. When these files are created, they are only modifiable by admin.

The server will then execute the appname.exe file.

However, the C:\ProgramData\Razer Chroma SDK\Apps\ folder is user writable. If a user process creates an app folder (eg “testapp”) and creates the file, testapp.exe, in it before calling the register endpoint, the server will overwrite the file with its precanned data, but will not reset the permissions before executing the executable file.


Figure 1 CopyFile(): https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-copyfile


Thus, there is a small sliver of time where an external user process can change this file before the server executes it. As the server is executing it using CreateProcessAsUser using the current user token, there is no privilege escalation.

Video of PoC


https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16602 

 

Comments

Lumin said…
Hi, I am doing a Uni project and our group of 2 have decided to use your exploit to present to the class if its ok with you can i ask you a few questions about this ^.^

Popular posts from this blog

How to Get Libraries to Load in Fixed Addresses

Problem I was using DynamoRIO to do instruction tracing to troubleshoot the runtime execution stability of my program and a DLL it was loading and realised that I could not easily diff the files as the addresses were always different. Figure 1. Sample DynamoRIO trace The output shown in Figure 1 illustrates a trace. My program starts to execute at line 83. The address — 0x20XXXX would be where my program was being loaded in. On modern Windows systems, this would be different whenever my program ran due to ASLR. Disabling ASLR The quick fix to this would have been: “use Windows 7 duh”. However, I didn’t think it was a future proof solution and just merely postponed the inevitable, so I decided to see if I could do that on a fully patched Windows 10. The first recourse was to use Google: “Windows 10 disable alsr”. Sadly though, none of it worked. (Sadly, the “MoveImages” registry key only seems to work on Windows 7.) I tried turning off Exploit Guard, but to no avail too. Luckily, disabl