top of page

BLUEKEEP: đŸ”„ Analysis of CVE-2019-0708 đŸ”„

⚡ Cyber Morans,

In January 2022, I started delving into Malware analysis 🧐. I learnt this using GHIDRA, Assembly Language basics, Youtube (LiveOverflow, JohnHammond, MalwareTech...etc) and started reverse engineering simple malwares i had built (Keyloggers, trojans and viruses with python and shell). Then i started a collection of the biggest baddest malware samples from the world. Am talking the devastating weapons grade stuff that has been used to conduct attacks around the world in the last 5 years đŸ˜Č. Stuff like EternalRocks, eternalRomance, Wannacry, Petya family, Allaple family... etc.


These attacks were based and took advantage of some of the biggest system vulnerabilities to be discovered in recent history. Vulnerabilities like eternalBlue(2017), Bluekeep (2019), Log4shell (2021)... etc


I with-held this post for a while until I had tried and created multiple proofs of concept (PoC). Now, there are multiple DoS PoCs on github and even a metasploit module, I’m posting this analysis.

 


BlueKeep is a security vulnerability that was discovered in Microsoft's Remote Desktop Protocol implementation, which allows for the possibility of remote code execution. On 13 August 2019, related BlueKeep security vulnerabilities, collectively named DejaBlue, were reported to affect newer Windows versions, including Windows 7 and all recent versions up to Windows 10 of the operating system, as well as the older Windows versions đŸ˜Č

On 6 September 2019, a Metasploit exploit of the wormable BlueKeep security vulnerability was announced to have been released into the public realm đŸ˜Č. This makes this vulnerability exploited by anyone with no cybersecurity background (but a good knowledge of metasploit) đŸ€Œ Ladies and Gentlemen, this vulnerability is still being exploited today and has a lot of exposed targets. Infact, you may be a target if you are reading this from a PC you havent updated in like forever 😁.


So, Lets get right into the weeds đŸ’Ș



 

BinaryDIFFing

Using binDiff 6+ (because you can use it with/in GHIDRA), Most of the changes turned out to be pretty mundane, except for “_IcaBindVirtualChannels” and “_IcaRebindVirtualChannels”. Both highlighted above, both functions contained the same change, so I decided to mess with the first one.


_IcaBindVirtualChannels

original👆 patched👆


A new logic has been added (In the patch), changing how _IcaBindChannel is called. If the compared string is equal to “MS_T120”, then 3rd parameter of _IcaBindChannel is set to 31.

Based on the fact the change only takes place if v4+88 is “MS_T120”, we can assume that to trigger the bug this condition must be true. So, 1st question is: What the HELL “v4+88”?


Looking at the logic inside IcaFindChannelByName, I think i may have found the answer👇

See 👆, and even more, IcaFindChannelByName finds a channel, by its name (using our advanced knowledge of our colonial language). The function seems to iterate the channel table, looking for a specific channel. On line 17 there is a string comparison between a3 and v6+88, which returns v6 if both strings are equal. Therefore, we can assume a3 is the channel name to find, v6 is the channel structure, and v6+88 is the channel name within the channel structure.


GREAT! but now i had no idea how to move forward.

So i started snooping deeper, I was in over my head, my palms were getting sweaty, my neck got hot, anxiety set in. Then a few deep breaths;


Found a file 🧐; MCSInitialize. I figured Initialization code is always a good place to start, no?

so a thread is created for the completion port, and the entrypoint is IoThreadFunc. Let’s look there 👇


GetQueuedCompletionStatus is used to retrieve data sent to a completion port (i.e. the channel). If data is successfully received, it’s passed to MCSPortData.


To confirm my understanding 😁, I got a basic RDP client (from github; there are tons) with the ability to sending data on RDP channels, opened the MS_T120 channel, using the method previously explained. Once opened, I set a breakpoint on MCSPortData; then, I sent the string “MalwareTech” to the channel.

AAAAAND, YES! I can read and write to the MS_T120 channel.


PS: I use hackers-arise and MalwareTech to learn Malware stuff ie building, reverse engineering, mitigation techniques etc. In this case I got this from a blog by Marcus Hutchins and used his exact technique to do this. (Thus the 'Malwaretech' easter egg)


Ok, the best way out of a hole is to keep digging (quoted from brooklyn 99 tv show) so lets keep going.

let’s look at what MCSPortData does with the channel data 👇;

The ReadFile tells us the data buffer starts at channel_ptr+116. Near the top of the function is a check performed on chanel_ptr+120 (offset 4 into the data buffer). If the dword is set to 2, then the function calls HandleDisconnectProviderIndication and MCSCloseChannel.


Hmm, I see, I see...


The code looks like some type of handler dealing with channel connects and disconnect events. Looking into what would normally trigger this function (3hrs of googling and 18 blogs later), I realized MS_T120 is an internal channel and not normally/shouldn't exposed externally.

Oops, I don’t think we’re supposed to be hereâ€ŠđŸ”„


Internally, it would seem the system creates the MS_T120 channel and binds it to ID 31. However, when it is bound using the vulnerable IcaBindVirtualChannels code, it is bound with a different id.

When one reference is used to close the channel, the reference is deleted, so is the channel; however, the other reference stays up (known as a use-after-free). With the remaining reference, it is now possible to write kernel memory which Does NOT belong to us. This is what is referred to as Use-after-free vulnerability exploit.


PS: đŸ”„The use-after-free vulnerability exploits a mistake made by the original author of a software and can result in devastating effects that range from remote code execution to the leaking of sensitive datađŸ”„


 

conclusion

Here we decyphered in deep how the bluekeep vulnerability manifests itself and how the patch attempts to fix this. Subscribe to receive notifications of similar posts where we will be reverse engineering malware and the technical aspect of vulnerabilities as well as how an attacker may use this vulnerability as an attack vector.


Thank you for your time, Like and leave a comment/review and as always, stay awesome! 👊 đŸ’Ș


10 views0 comments

Recent Posts

See All
Post: Blog2_Post
bottom of page