Minimize your digital risk by detecting data loss, securing your online brand, and reducing your attack surface.
A powerful, easy-to-use search engine that combines structured technical data with content from the open, deep, and dark web.
Digital Risk Protection
Research Team Finds 50% Increase in Exposed Data in One Year
New report recognizes Digital Shadows for strongest current offering, strategy, and market presence of 14 vendors profiled
Read Full Report
Over the last week we have all been tuning into our news feeds and listening to the security folks chatting about the next super vulnerability, CVE-2019-0708. There’s no shortage of coverage over the issue and the potential impact once a working proof of concept or full-blown exploit hits the shelves in a repository near you.
Amid all of this, I want to outline what it actually means for your organization, and what can you do to reduce the risk.
Let’s get to grips with the basics.
RDP, or Remote Desktop Protocol, is a service which commonly runs on TCP port 3389 on Windows workstations and servers, and is used to administer them remotely. The service is prevalent within mid-sized and large networks, where an administrator (or user) needs to access multiple computers without having to keep jumping between desks and server rooms.
BlueKeep is the name given to the vulnerability, which was reported to Microsoft by the UK’s National Cyber Security Centre. Microsoft’s May cumulative update contains many security updates, including a critical update for a vulnerability in the RDP service, where a crafted series of requests to the service could be used to perform remote code execution or crash the service causing a denial of service.
The name BlueKeep was later given to the vulnerability which is technically referenced by the Common Vulnerabilities and Exposures ID (CVE-2019-0708).
The following is a list of the reportedly affected Microsoft Windows releases:
Keep in mind that both Windows Server 2003 and Windows XP are both legacy and out of support, meaning that, in theory, they should never receive updates. However, like with the vulnerability exploited by ETERNALBLUE (CVE-2017-0144) back in 2017, they have both received updates addressing BlueKeep – indicating how seriously Microsoft is taking this issue.
As of yet, there are no publicly available working proof of concepts or full exploits for BlueKeep, however it will most certainly arrive soon. Just today, MalwareTech released a video claiming to have developed a working POC, although he has stated he will not release the code. Furthermore, there are multiple cybersecurity research outfits that claim to have reversed the Microsoft patch and developed working exploits, such as Zerodium, McAfee, and Qihoo360.
Almost 2 years ago, the WannaCry outbreak caused significant damage to organizations around the world, causing losses of up to £100,000,000 for the UK NHS alone.
Well, why the WannaCry comparison? The WannaCry malware was built around an exploit known commonly as ETERNALBLUE, an exploit that targeted several vulnerabilities in SMB servers, most notably CVE-2017-0143. Once a vulnerable service was identified, the malware would exploit the weakness to establish a foothold and then use that to relaunch itself to another target, moving through the network like a worm.
While EternalBlue exploited SMB services, BlueKeep is a vulnerability in RDP (Remote Desktop Protocol). The information disclosed so far indicates that once BlueKeep is exploited successfully it may either be used to:
Remote code execution would provide an attacker with full unrestricted access to the target. With full access to the system, it’s anyone’s guess what an attacker might use it for. Ransomware and/or data collection are two possible options, and a large scale campaign ransomware could be an effective money-maker.
WannaCry’s worm-like lateral movement meant that it would gain a foothold on one system and then look for other vulnerable targets on the network, and so on. A piece of malware able to exploit BlueKeep would easily be able to achieve similar results.
WannaCry initially identified hosts running SMB services on the internet and then used this to burrow into the internal network where it continued to spread and scan for other targets internally and externally. If there weren’t so many publicly-exposed SMB services without any form of access controls in place, we may not have seen such a wide spread of the issue. The level of exposure for RDP is also unnervingly high, with an excess of 2.3million RDP services being identified on Shodan (see below). This is, of course, just an approximate figure and does not indicate how many may be vulnerable.
Figure 1 – Shodan – port:3389 “Remote Desktop Protocol”
There is always a lot of hype about certain vulnerabilities – especially the branded ones. Of course, fancy websites and logos do not always mean that the research behind them is not fascinating, there certainly have been a few branded vulnerabilities that have deserved the hype. The issue comes when people start to become numb to the announcements and, as a result, become less reactive.
I fully agree we should be cautious before getting our system and infrastructure administrators in from their holidays or out of their beds at 2am. We must be careful and make sure we look at all the elements and how it may affect your organization, before blowing the horn three times.
When assessing the risk of any vulnerabilities, you need to think about:
In these situations, asset inventories become your best friend, knowing what servers you have, where, what they are running, who manages them, when were they last updated, and a strong process to be able to track assets by services and software versions. The easier said than done solution of patching is recommended, as is network-based access controls, ensuring only the specific source addresses have access, and that the systems that do have access are fully patched and have access controls themselves, to avoid any lateral movement attempts from WannaCry-like malware.
Enabling Network Level Authentication on all of your RDP services will add an additional layer to reduce the risk of attackers exploiting this vulnerability without any credentials. This is made possible by requiring authentication before the session is fully established and at a point where the service is exploitable.
Figure 2 – Windows 7 RDP NLA
Let’s not forget the most effective barriers you can put in place for most services. Access controls such source IP address filtering can often be easily deployed through most firewall and network solutions, allowing an individual or organization to be able to explicitly define the IP address of any connecting clients. This will mean that an unauthorized connection attempt will be blocked due to being from an unexpected source address.
While you may not have the luxury of an internal red team, you should consider performing sweeps of your environments looking for potentially vulnerable systems. A simple Nmap scan for TCP port 3389 would give you a good view of a potential attack surface for this issue. You can then assess if those systems are running a Windows version reported to be vulnerable, and when was the last patch on those systems.
There have been a lot of fake exploits and proof of concepts out there for BlueKeep, all of which, have either just been trolling people, or trying to crash the target. However, there have been a few legitimate attempts to help, including a Ruby script designed to identify vulnerable unpatched machines. We decided to take a look at one of these scripts in a controlled environment, due to the possible adverse effects of malicious scripts. The testing started against an unpatched Windows 7 X64 virtual machine, and then once again with the latest patch distributed by Microsoft.
The script was then executed in an isolated environment, against the Virtual Machine, which identified it as being vulnerable.
Figure 3 – Kali VM running the Ruby script
Figure 4 – May patch applied
The Virtual Machine was then patched with all the latest updates, and the script run once again.
Figure 5 – Windows 7 x64 successfully patched against BlueKeep
The script used for the testing above is available on GitHub, we would highly recommend that your own controlled testing is performed before using any scripts or tools from unknown or untrusted sources against a production network. While there were no suspicious activities from the script at the time of our testing, the code can be changed, and additions made.
Tracking vulnerabilities and understanding how the hype maps to your organization can be tricky. Hopefully, some of the tips in this blog help to this end. I’ll finish by outlining two critical considerations for mitigating the impact.