Exploiting the Windows CVE-2019-0708 RDP
vulnerability, also known as BlueKeep.
So now that we have got an understanding of how
we can exploit RDP via a brute force attack
in order to identify legitimate credentials that we can use
to authenticate with the target system via RDP, let's
take a look at an inherent vulnerability within RDP
that can allow us to obtain a Meterpreter
session or a reverse shell.
Before we get started with the actual exploitation,
let's get an understanding of this vulnerability
because it is quite a severe vulnerability,
and the actual exploitation process can be quite confusing
or can be quite tedious.
So BlueKeep, also known as CVE-2019-0708
is the name given to an RDP vulnerability in Windows that
could potentially allow attackers to remotely execute
arbitrary code and gain access to a Windows system
and consequently the network that the target system is
a part of.
Now, a BlueKeep vulnerability was
made public by Microsoft in May 2019, so keep that in mind.
It was not discovered by a hacker group or anything
like that.
The Microsoft security research labs or rather one of them
was able to identify this particular vulnerability,
and Microsoft made it public alongside a patch
that companies can essentially utilize to patch these systems.
And, of course, there are various types
of mitigations that can be used as well,
and we'll get to that in a second.
So the BlueKeep exploit takes advantage
of a vulnerability in the Windows RDP protocol
that allows attackers to gain access
to a chunk of kernel memory, consequently allowing them
to remotely execute arbitrary code at the system level
without authentication.
So the key area that you need to focus on there
is the kernel memory side of things.
So, again, this particular vulnerability essentially
utilizes or allows attackers to gain access
to a chunk of kernel memory through the vulnerability
within RDP, and, of course, this is part of the vulnerability.
So the chunk, that particular chunk of kernel memory,
is where the malicious code or arbitrary code
is executed by the attackers.
And, of course, as we already know,
the kernel is privileged, which means
anything that's executed in the kernel space
will be privileged.
So if we execute a payload-- a Meterpreter payload,
for example--
we will obtain a Meterpreter session
with elevated privileges.
However, as we'll see in a few seconds,
playing around or executing code at the kernel level
will most likely cause system crashes.
So you need to be very cognizant of that.
All right, so in terms of the vulnerability and the patching
and the affected versions of Windows,
Microsoft released a patch for this vulnerability on May 14,
2019 and has urged companies to patch
these vulnerabilities as--
this particular vulnerability as soon as possible.
At the time of discovery, about 1 million systems worldwide
were found to be vulnerable.
And, of course, that has steadily decreased over time
because, as of recording this video, we're currently in 2021,
and that number has reduced drastically.
However, there are still various systems out there
that have been proven to be vulnerable,
and those are external systems or systems
that are exposed to the internet,
not taking into consideration the thousands of systems
on internal networks that have not been patched yet.
Now, in terms of the versions of Windows affected
by this vulnerability, this particular vulnerability
affects the following versions; so Windows versions,
anywhere from XP to Windows Server 2008 and Windows Server
2008 R2.
So these are the versions of Windows
where this particular exploit has been tested successfully,
and it has actually been verified
that you can execute arbitrary code
or obtain a shell on these particular versions of Windows.
And, of course, a prerequisite for this exploit
is that RDP needs to be enabled on the Windows target.
And furthermore, if network level authentication
is enabled, then this particular vulnerability
will most likely fail.
So that's one of the mitigation techniques
that Microsoft has actually recommended over time.
So do keep that in mind.
As for the exploit, the BlueKeep vulnerability
has various illegitimate proof of concepts
and exploit code that could be malicious in nature.
Right now the reason for that is primarily
because of how this vulnerability was disclosed.
So it was disclosed by Microsoft,
which means they did not provide any proof of concept code
or exploit code that the public could use to exploit
this particular vulnerability because if they did that, that
would exacerbate the issue and make companies even more
vulnerable.
However, many security researchers
have actually come up with various proof of concepts
without exploit payloads attached
to them, which means that instead of actually obtaining
a reverse shell, the proof of concept
exploit code or scripts essentially demonstrate
that a target is vulnerable by executing a specific command
or by actually creating a file on the target system's file
system, therefore proving that an attacker could use
this to execute malicious code.
And the very important thing to note
about this particular vulnerability
or this particular exploit in comparison
with EternalBlue is this particular vulnerability
or exploit has seen a lot of illegitimate proof of concepts
being uploaded to GitHub or any other mirrors.
And when I say illegitimate, what do I mean about this?
Well, what I mean is that they don't work as intended
or as they state they should work.
So we've seen a lot of proof of concepts that don't actually
work and instead may be malicious
when executed on a target system and could perform
a plethora of other tasks or functionality not associated
with this particular exploit or this particular vulnerability.
It is therefore recommended to only utilize
verified exploit code and modules for exploitation.
And, in this case, we will be utilizing the Metasploit
framework auxiliary and exploit modules
to demonstrate how this vulnerability can be exploited.
So the BlueKeep exploit has an MSF auxiliary module
that can be used to check if a target system is
vulnerable to the exploit and also has
an exploit module that can be used
to exploit the vulnerability on unpatched systems.
So the BlueKeep exploit module is fantastic.
However, it does need tweaking in regards
to the target operating system or the version
of Windows that you are targeting,
as well as the actual groom or the memory chunk size
that this particular exploit requires in order
to execute malicious code, and, of course,
we'll take a look at that.
So the exploit module can be used
to obtain a standard command shell as well as a Meterpreter
session on the target system.
Now, as I mentioned in the previous slide, targeting
kernel space memory and applications
can cause or will cause system crashes,
and you'll actually see that as I'll
demonstrate this particular exploitation
process on a Windows 7 system.
You'll actually see what I'm talking about.
So, in this case, this particular video
does not have a lab attached to it, for obvious reasons.
And I'm going to be performing all of the techniques
or I'm going to be highlighting the exploitation methodology
and techniques on my own home lab.
So my penetration testing distribution of choice
is Kali Linux, and the target that I'm going to be exploiting
is a virtual machine running Windows 7 build--
or rather Service Pack 1.
And again, if you want to replicate this, then
you can download that exact virtual machine
or that version of Windows and try it out for yourself.
So I'm going to jump into Kali Linux,
and we can get started with the actual exploitation process.
All right, so I'm back in my Kali VM.
And the first step, of course, will
involve performing a port scan on the target system
in order to verify that RDP is indeed running on the target.
So we'll say sudo nmap.
And we don't need to perform service version detection.
We can just limit the actual port scan to port 3389.
And the target IP in this case is 10.10.10.7.
And, of course, in your case, it's going to be different.
So I'll just hit Enter.
And you can see port 3389 is indeed open,
and that is running RDP.
So we can now utilize the Metasploit auxiliary module
to actually verify whether this particular target is
vulnerable.
So I'll start up MSF console.
And, of course, I'll give that a couple of seconds.
MSF console usually takes a couple of seconds.
So there we are starting the Metasploit framework console,
and we can then search for the actual module.
So we can say search for BlueKeep.
That will bring up the two modules.
One of them is an auxiliary module,
and the other one is the exploit module.
And the exploit module will also run the auxiliary module
during the exploitation process, but I just
want to show you how this works.
So I can say use module 0, and I'm
using the actual identifier or the module ID here.
So I'll say show options.
And, in this case, the only option
we need to configure really is the target IP,
and that can be done by setting the RHOSTS option
or by configuring the RHOSTS option.
You also have the ability to change the RPORT option
if RDP is running on another port,
if it's not been configured to run on the default port.
So, in this case, I'll just say set RHOSTS to 10.10.10.7,
and I can then hit Run.
There we are.
You can see it tells us that target is vulnerable,
and that means we can actually move on
with the actual exploitation process.
So I'll say search for BlueKeep.
And what I'll do is I'll say use module 1 because this
is the exploit module.
It's going to default to the Windows x64 Meterpreter
payload.
And, of course, this is a staged payload.
So, again, this particular module-- and it's something
that I didn't mention previously--
this particular module will only work
on 64-bit versions of Windows.
So again, if I clear the screen and show the options here,
you can see that you have your module options, which
essentially will involve you configuring the target IP
and the target port that has RDP running.
And then you have your payload options,
which you will actually need to configure.
In this case, it's already done for me.
So it'll set my LHOST option to my Kali Linux VMIP,
and then the LPORT option is set to the default, which is 4444,
and I'm going to leave it on that particular port.
So we'll say set RHOSTS, and we're going to say 10.10.10.7.
And, of course, at this point, we can simply type in exploit.
Well, not really, but let's see what happens.
So I'll say exploit, all right, and you'll
see that it'll run the auxiliary module to check
whether it's vulnerable.
Indeed, it is vulnerable, and it's
going to say, "Exploit aborted due to failure,
bad configuration, set the most appropriate target manually."
So the great thing with this module
is you have the ability to actually specify
the target configuration.
What this means is that you will need to manually
configure or set the version of Windows that you're targeting.
So if I say show targets, these are the versions of Windows
that I can target.
In this case, we are targeting Windows 7 Service Pack 1.
And this is a 64-bit version of Windows 7, and this, of course,
is running on Virtualbox 6, which
is the latest version of Virtualbox
as of recording this video.
So to set a target, we can say set target to 2,
and we can pretty much hit Exploit.
And let's see what happens here.
We might get lucky during our first attempt,
but I heavily doubt that.
So the exploitation process will start off
by saying using the CHUNK grooming strategy.
And the default memory or allocated group size
is set to 250 megabytes.
And again, this is something that we
may need to modify based on the amount of RAM that's been
allocated to the target system.
And if this is allocated too high,
this might cause the target system to crash.
So, again, if I will just give this a couple of seconds.
And, in this case, it looks like this will indeed fail
or this will cause the target Windows system to crash.
So as you can see, entering the danger zone here,
it's going to start surfing the channels and lobbing the eggs.
So let's see whether this is successful.
If it fails, then we'll need to modify the actual groom
size, which is perfectly fine.
And that's something that you need
to be cognizant of beforehand because, again, as I said,
I'm doing this within my own local lab,
so I can afford to actually crash systems.
When you're working within an actual company or enterprise
environment, you want to be extremely careful with kernel
exploits because they can crash a system and cause data loss.
So this is not an exploit that I really recommend running.
As I said, I'm doing this for the purposes of demonstration.
So, again, let's see whether this works.
There we are it looks.
Like it worked during its first attempt, which is great.
So it sends the stage to the target,
and we get a Meterpreter session.
So if I say sysinfo, there we are.
You can see it is Windows 7, and this
is Service Pack 1 build 7601, get user
ID, NT AUTHORITY SYSTEM.
So we've been able to gain access to the target system
by exploiting the RDP protocol.
However, we've not targeted or performed a brute force attack
in order to obtain legitimate credentials.
We have just exploited an inherent vulnerability
within Windows.
And again, this particular exploit is great
and it's very similar to EternalBlue in
that it provides us with an elevated Meterpreter session
so that we don't need to elevate our privileges,
which, again, in a typical penetration test,
this is pretty much the gold mine.
This is something that you want right off the bat--
to have administrative privileges on the target system
that you're exploiting.
However, we'll also be exploring various privilege escalation
techniques you can perform on Windows to elevate
your privileges if you've been able to gain access
through another attack vector that did not provide you
with a privilege session.
All right, so that is going to conclude
the practical demonstration side of this video.
In the next video, we will be exploring
the process of exploiting the WinRM protocol on Windows.
WinRM stands for the Windows remote management protocol.
And it's an extremely useful protocol
for system administrators, and we're
going to be taking a look at how we can exploit it.
So I'll see you in the next video.