11.12.2019

Local privilege escalation in EA Windows Origin Client (CVE-2019-19247 & CVE-2019-19248)

Introduction

I send my greetings to everyone who has decided to read my new article with vulnerability analysis. Last time, in a small three-article cycle, I told about the vulnerabilities in Steam Client (1, 2, 3). In this article, I shown the vulnerabilities of a similar product – Origin Client – which is also a game launcher. The vulnerabilities were identified as CVE-2019-19247 and CVE-2019-19248.

There will not be any «lock/unlock account» games this time – the communication history with the Electronic Arts Inc. security department was originally on a professional level. When I made a first contact, I was given a registration number; all the reports were thoroughly examined and confirmed. None of my e-mails was ignored; even for a little discussion, the team organized a conference call. It was very easy for me to guide a project, special thanks to Adrian Stone, Elise Murphy and other EA employees who were also working with my reports.

Now, let us back to the vulnerabilities. I have found two «escalation of privilege» vulnerabilities (lpe – local privilege escalation and eop – escalation of privileges) in Origin Windows client. These vulnerabilities allow any OS Windows user to obtain additional rights, which was not supposed to be given by default. In this case, we are talking about two “typical” escalation – from any user to «NT AUTHORITY/SYSTEM» (an account that has maximum permissions in the OS). The first vulnerability is rather boring, so I briefly described it in the next section. The second one was quite interesting, so I have shown in details how I have been finding it out.

CVE-2019-19248

The vulnerability consists of two parts:

1) Arbitrary directory creation (with ACL «Everyone-Full control»);

2) Obtain NT AUTHORITY\SYSTEM via 1 part.

Explanation of the first part.

Prepare the environment

Terminate Origin client and stop «Origin Client Service» service (in fact, the service shutdowns itself after the program, so it is mentioned just in case).

Directory «C:\ProgramData\Origin» has explicit rights «Everyone-Full control». This allows us to clear that folder.

Making links

Let us make some links. The first link is NTFS Reparse Point (NTFS Mount Point) — this kind of links redirect one folder to another: «C:\ProgramData\Origin» <-> «\RPC Control». Reparse points creation does not require administrator rights. There are two requirements – the folder must be empty and the folder must be writable by a user (the folder was flushed on the previous step and rights were checked too). «\RPC Control» — is not an ordinary folder, this is a special type of folders — an object directory. It cannot be viewed in the explorer, but the directory can be a target of the reparse point (it seems to be so, due to the common abstractions in the underlying Windows internals).

Now we create a symbolic link like «\RPC Control\CatalogCache» <-> «C:\Path\To\Target\Folder». Creating file-to-file symlinks requires administrator rights, but symlinks from object directory do not have such restriction. Therefore, any user can create it. Via a combination of the links, any access to «C:\ProgramData\Origin\CatalogCache» will be redirected to «C:\Path\To\Target\Folder».

Read more details about such links here. In addition, this repo contains binaries for many tools.

Run

Therefore, we run the Origin client. The client starts «Origin Client Service» service. The one detects an absence of the directory «C:\ProgramData\Origin\CatalogCache» and tries to create it. Service creates «C:\Path\To\ Target\Folder», due to redirections. Moreover, it grants ACL «Everyone-Full control» for the folder.

From here, an arbitrary folder was created as we wished. Let us move on the next point.

Exploitation of arbitrary directory creation

There are some methods of doing so. Let me mention some of them.

Easy and reliable method — create directory «C:\Windows\system32\LogonUI.exe.local». «LogonUI.exe» (a program running as «NT AUTHORITY\SYSTEM», used by Windows for lockscreen and user selection screen), will load a library from path «C:\Windows\system32\LogonUI.exe.local \amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.648_none_fb45a0e93062a6d2\comctl32.dll» due to special dll loading mechanism «.local-redirection» («dotlocal redirection»). In fact, this is a widespread mechanism, so there are many available targets.

Interesting and exotic method — reading the hash of administrator’s password via unusual behavior of some functions. More read here.

Result

The vulnerability was easy to exploit. The major problems are to find a target program and write the dll. By the way, Matt Nelson reported the same vulnerability, read his writeup.

CVE-2019-19247

This is my favorite vulnerability. It shows why it is hard to proper use of cryptography.

All started when I install one game on Origin. The process was so good and smooth, so it was very suspicious. Some clicks, waited for download finished and game was ready to start. Suddenly I realize reason of my disturbance: game installed to «C:\Program Files\GameName», but Origin did not ask any UAC-question while installing. I checked ACL of «C:\Program Files» – anything was normal: non-writeable for ordinal users. Some more investigations and I figured out that game was not installed by Origin client, service with name «Origin Client Service» installed it.

I made some assumptions about communications between service and client, so I decided to make checks for vulnerabilities.

Service and client communicated via named pipes. I figured that out from logs of Origin. There was plaintext messages in log files, said that pipe with name «OriginClientService» received commands to work with files and directories.

Open IDA, load client.

*works at IDA: 1*

I quickly found out that commands goes to pipe in plaintext. Somewhere near code of communication there was a list of available commands. I straightforward sent command «copy “C:\test\payload.dll” “C:\Windows\pwn.dll”» to the pipe. Opened «C:\Windows» and… saw nothing new. But there was something new in logs — something about that pipe client signature failed to validate.

Open IDA, load service.

*works at IDA: 2*

It turned out that not everyone could send commands. When client connected to the pipe, service check it. Service obtain the pid of process from pipe connection, than get path to program from pid, than check signature of the program (correct and belongs to EA).

This looked good, but not enough. I could took original legal «Origin.exe» (binary file of client), and copied it to my folder. In that folder I placed dll from «Origin.exe»’s import list. Version.dll for example. I called that action «reverse dll-injection»: in ordinary dll- injection we copied dll to exe-file, but now it vice versa. Wrote code for proxy-dll of version.dll, added code for communication with the pipe and run my «Origin.exe». And… Payload still not copied. Read logs — «WTF!? What does it mean “unable to decrypt command”». So, I overlooked the encryption.

Open IDA, load client.

*works at IDA: 3, signature bypass: 1*

If client sent encrypted command, so I can too. Looked here, looked there… Result: crypt algorithm AES, IV was constant, key read from file. Copied that part from IDA, compiled and tested. No luck. But logs helped us again — using of path altered from Program Files was prohibited.

Open IDA, load service.

*works at IDA: 4, signature bypass: 1, cipher bypass: 1*

So, that was true – there were some additional checks for target path. In fact our path did not fit the requirements and path traversal did not work. So looked for other commands.

Works with registry — there were other restrictions. However, executing of files looked promising. At least it contained not so many checks. Wrote code, sent command «ExecuteProcess “C:\test\payload.exe”». You knows… Nothing.

Logs said about wrong signature one more time. Oh, once I beated that. I changed payload to copied «Origin.exe», and our dll loaded one more time, but now as «NT AUTHORITY\SYSTEM». Added code for spawning cmd. Run test and finally «NT AUTHORITY\SYSTEM» cmd appeared.

*works at IDA: 4, signature bypass: 2, cipher bypass: 1*

Rebooted for final test. And nothing was working. WTF? It worked a minute ago.

Diagnosis showed that service «Origin Client Service» was not running, so I started it. But it was not starting. No, it started, but immediately shutdowned. Run Origin client and service started normally. Magic. After that exploit worked. I was able to stop here, but this is not my way — I wanted to create fully worked exploit.

Open IDA, load service.

*works at IDA: 5, signature bypass: 2, cipher bypass: 1*

It turned out that service checked its run-parameters. There are nothing interesting. Base64 from encrypted pid of the process (that started service) and check signature of that process program. May be it sounds complicated, but all of this already bypassed. Added some code and exploit completed!