Microsoft patch Tuesday, May (2019) comes with a patch for critical RDP RCE Vulnerability, CVE-2019-0708 Remote Code Execution Vulnerability exists in Remote Desktop Services (RDP) pre-authentication and requires no user interaction Microsoft described it as “Wormable” so we could see new Wannacry hit the world! unfortunately, the world as we know it is not safe as we think and the threats are bigger than public ips within known internet scanners like shodan.io , censys.io etc

I think the threat is more than that number! we have RDP services running over other ports, as well the number itself is not kinda live number, however from my own internet scanner “Falcon-Claw” data comes from crawlers in last 24h shows that 8057271 RDP Host is online on last 24h however it’s not blog about is my scanner is better then shodan or not.

so the attack scope is really huge and the world as we know kinda in risk since there’s a lot of critical environments their vulnerable system exposed to the internet so however let’s get in and understanding the bug! in this blog we will analysis the patch and diff some dlls and try to understand what’s going on !

as most security researchers I have been trying some stuff with RDP since it’s good money! for example zerodium pay around 1m$ for an exploit like this ! so it’s really good money, however, I will go with normal patch analysis process but in fact, I already skipped a lot of stuff since I already know what I am looking for

BTW we will find soon some threat hunting guys catch the exploit in the next few weeks! if they didn’t already!

Microsoft delivers updates in 2 formats

• exe format for XP/2K3 Systems
• msu (standalone update) format for Windows 7 +

however, I will pick “Windows 7 for x64-based Systems Service Pack 1” update for analysis since I will talk about how we can extract patched dlls, exe, and drivers from the downloaded update from Microsoft

KB4499175 which is I am going to analysis it, we will extract the files and we will kinda pick up only interesting stuff since the update patches other bugs as well, and we’re just interested in RDP stuff as well maybe network drivers and Dlls if there’s any

it would be mess if you tried to extract it with expand.exe so however, I will suggest a PowerShell Tool for extract the patch files however I have been using this tool for a while since the output is really good organized PatchExtract125.ps1 you can pass the msu file via -Patch , and try to do it in empty folder !

./PatchExtract125.ps1 -Patch downloaded_update.msu

Get-ChildItem -Recurse -Filter *.dll|Export-Csv -Path all_dlls.csv
Get-ChildItem -Recurse -Filter *.sys|Export-Csv -Path all_sys.csv
Get-ChildItem -Recurse -Filter *.exe|Export-Csv -Path all_exe.csv

Our scope is RDP – Pre Auth we will take look on drivers first maybe we will start from there so starting taking notes about each driver functions and how it’s work and trying to put interesting drivers on the list to perform diff however I don’t know if there’s a list to know about drivers functionality etc all what I see on the internet is just websites telling you hey do you hate blue screen ? so just google the driver name won’t gain you anything but you can try this one for example

peauth.sys site:microsoft.com

keep your research only in Microsoft blogs etc you will get useful information also keep try harder cuz maybe when you’re trying to understand a bug or a patch maybe you can get another one!

So the scope kinda huge but we still need to hunt for a quick thing to save the time, I already saw blogs written in Chinese about diffing termdd.sys and they found kinda good stuff! but I wasn’t sure and I still not sure if the exploit can land there! but

sending simple unauthenticated RDP network packet , it will land in 2 places, termdd.sys and ICAAPI.dll, but ICAAPI.dll not touched on this patch… it’s just “DLL Interface to TermDD Device Driver”

Limited Choices

so now we’re front of tremdd.sys so as I think this how the normal RDP Packet Landing on the endpoint

tremdd.sys probably got the vulnerable function

before we even think about diff tremdd.sys since once you diff it won’t take too much to spot the vulnerability but it will take too much time to hit a breakpoint within or near the vulnerable function so it’s a good idea I think to reverse ICAAPI.dll and understand the execution flaw it would be much easy for you to write the exploit!

the dll begin called by “svchost.exe” I am not sure if this one is the latest version of that dll but 22 kb won’t take too much time to reverse, but keep it away now and let’s diff the driver because that’s all what we got in the patch so let’s give it a priority

Using diaphora and IDA Pro, I started to take look inside termdd.sys

My first thoughts came to _ReconnectStack Function since I saw video coming from “somewhere” exploiting the bug and seems like the attacker made kinda reconnect operation after executing the exploit script and just popped up a shell on next connect

on the right side is the patched code ! so once you call _ReconnectStack and go with the condition will just call “IcaRebindVirtualChannels” instead of going throw find the channel and “_IcaBindChannel” so let’s take this function in our count as well, I mean they did it for a reason! maybe it’s exploitable also, but I found other interesting patched function calling IcaBindChannel

Before we look at the vulnerable function we’re going to look at the patched one that will give us an idea about what we’re looking for

Patched Channel number controlled

The patch trying to set channel number to 31, but if the channel name is equal “MS_T120” then it will set it to something else, and always highlight controlled parameters by the program if you’re looking in the patched side because once you’re front of vulnerable code you will know what you’re looking for so that’s why I highlighted channel number and you will understand more when you see the vulnerable code .

r8d reg should be 31

testing eax and set r8d to rbp offet -2 which is probably a default integer coming from the (char_p – 1) and that’s if channel name is not equal MS_T120 ,

simply means that this parameter would be 31 or other int coming from (char_p – 1) ‘rbp-2’ so it’s kinda controlled parameter now, it’s time to take look into the vulnerable function

patching a critical bug like this one with stricmp i don’t think it’s a good idea in general maybe it’s secure!

pass channel number directly

r8d reg is the channel number

So now we know our controlled parameter it’s time to check _IcaBindChannel Looking for memory corruption or something to exploit