Now that we've covered the basics of what a CVE is,
what a vulnerability is, and the CVE and National Vulnerability
database, let's look at some examples to help
understand a little more.
We're going to look at Heartbleed, EternalBlue,
and Log4J.
We'll start with Heartbleed.
Now, I'm going to bring you over to the CVE page for Heartbleed,
and here it talks about it being TLS and DTLS implementation
of OpenSSL 1.0.1 through 1.0.1g.
Now, TLS-- and we'll get it to this in a little example--
will encrypt data in transmission.
Now, OpenSSL is the software that allows for that encryption
and for private-public key infrastructure that then
leads to a shared private key.
And it's in that utilization where we see what
they're talking about here.
There is a heartbeat extension for the packets,
and it allows remote attackers to obtain sensitive information
from process memory via crafted packets
that trigger a buffer over read as demonstrated
by reading private keys.
That might not make a lot of sense,
and I'll dig into exactly how it works
and how you would take advantage of it,
how you would exploit, it in a minute.
But let's continue to look at what research
we have on this vulnerability.
Now, National Vulnerability database--
it's a lot of the same information.
You can see evaluator impact.
This is new.
This is helpful, and you got to take into account
the nature of the data being protected
according to the organization's risk acceptance.
That's exactly what we talked about before
in risk management.
This vulnerability, though, it's got a high rank, 7.5.
Organizations will have to determine what
they're going to do with it.
It does not allow unrestricted access to memory,
but it does leak information from memory.
That could include cryptographic keys and passwords.
If you have the cryptographic keys and passwords,
well, passwords are pretty straightforward,
but the cryptographic keys mean that you could un-encrypt
all the traffic, which TLS is meant
to prevent the eavesdropping and reading of data in transport.
So that's not a good thing.
We don't want that.
Impact depends on sensitivity of the data and function
of the system.
There's a bunch of references.
A lot of references, and includes
some exploits and proof of concepts on how to use this.
We'll actually look at a few of those,
and then you have weakness enumeration,
improper restriction of operations within bounds
of memory buffer, and you could dive
into exactly what that means.
But here's the known effect of its software configurations,
and it's just different versions of OpenSSL.
Looks like some implementations in other software.
And so that's worthwhile to look at and identify
are we using any of the software that
is using that outdated version of SSL.
We'll see this again in Log4J.
It's an underlying system that other software might use.
So has long reach and a lot of potential impact.
Now, we can scan for this.
You can find out what version of SSL
is being utilized with this Nmap script that will show which
enum ciphers are being used.
And there's an example down here.
If we were to do our service scan
and then with the script ssl-enum-ciphers,
we've looked at this in enumeration.
And so if you're not used to using a script with Nmap,
go back and take a look at those videos and review those labs.
In this situation, it's going to be port 443
because that's HTTPS.
There's other-- again, other utilizations of TLS.
This is just one of them.
This would be an example of, hey, you found something.
Let's see if this applies and see
if we can find a vulnerability.
In here, there is TLS version 1, and that's not
terribly helpful.
It all depended on which version of SSL or OpenSSL
was being utilized.
So we can go even deeper.
There's a specific script for SSL Heartbleed,
and you can detect if a server is vulnerable to the Heartbleed
bug.
Again, it's going to look for TLS 1.0, 1.1, and 1.2.
Let's look at it down here.
What we see is when it runs a scan, it comes back with, hey,
this is vulnerable.
It tells you a little bit about Heartbleed,
says it's vulnerable, high risk factor, and the description.
It's using OpenSSL version 1.01 and 1.02 beta.
So we can scan for that exact vulnerability
to see if it's on network, and you don't necessarily
have to pick just one port.
If you found a whole bunch of open ports
and you know several of them are using
a secured encrypted protocol, then you
might want to run the scan against all of them.
You could run against all of them.
If it doesn't apply, it'll skip it.
Nmap scripts are usually pretty helpful that way.
What we have here is Exploit DB, the exploit database.
You can see it's run by Offensive Security.
It's a great tool they put out for the community,
and I've searched just for Heartbleed.
Normally, on Exploit DB, this is the first implementation here.
It's just a large database.
If you take a look down there, 44,000 entries, and it
gets updated fairly regularly-- these last three
in the last week of this recording.
It can be fairly straightforward to search for things.
If I just type "Heartbleed," we come across a few proof
concepts, and here's what they look like.
This one is a Python script.
It looks like it's Python 2 or I think 2.7.
Don't look like Python 3.
You don't necessarily need to know what
all this code is doing yet.
It'll be nice if you get there, but you
could look at these proof of concepts
and get an idea of, oh, OK.
So if I run that scan, what is it doing?
Because that's what this code is doing.
It is just checking to see if it is vulnerable.
It's not exploiting it.
It's just saying is this vulnerable or not.
So you could see what it returns.
If it receives an alert and it is vulnerable,
then we should see this warning.
Warning.
Server returned more data than it should.
Server is vulnerable.
Now, you may be wondering what all that means.
Why is it returning more data than it should?
Now let's return to our example.
So we've looked at some of the data.
If you came across a service that was utilizing encryption,
then you might want to run some of those Nmap scans.
You might want to run the Metasploit
module that enumerates that.
You might want to run Nessus scan.
All those things can find whether it's vulnerable or not.
Now, what does it mean?
What does it look like when it is vulnerable?
So you can run your Nmap scan.
Check for services.
If you come across something that uses encryption,
it might utilize that OpenSSL 1.0.1 to 1.0.1f, fox,
and then you could utilize an actual proof of concept and run
the vulnerability, exploit the code,
exploit that vulnerability, and this is what it would look
like.
The way TLS normally happens is we send a packet
as part of the TLS handshake.
So there's the TCP handshake.
It sets up the connection, and then the next layer above that
is the encryption connection.
As part of that, there's going to be public and private keys
for either side that are going to encrypt a shared
private key that is symmetric.
What's important there is as part of the TLS handshake
the client tells the server this is the password,
and the password is this length.
And then the server itself is going
to respond with confirmed, this is the password.
And that confirmation, what it's sending back is based on--
I'll go back-- that password length.
Now, someone found that if you sent here's the password,
and the password length is in this case 52 instead of 12.
Then you could get back, hey, this is the password,
then in memory whatever the next 40 characters are as well.
And all that would come back, and you'd
have to take a look at it.
It's going to be in the packets.
It's not necessarily going to be obvious.
And the way that you craft packets to find this,
you could use Scapy.
You could use Python.
There's Metasploit modules that take advantage of this
and exploits in the Metasploit framework
that you can gather back the information you want.
It can go all the way up to 64,000 characters
so that you could pull pages of data.
Thus, if someone were to find this vulnerability,
then they could just keep asking for more information.
And as the server processes information,
it doesn't always go to the same location.
It's a buffer over-read, and so depending
on where in memory that variable that is part of the handshake
gets stored, it's then going to read Linux stuff.
So it can be quite dangerous.
You can get pages and pages of information
from the memory of the server.
And if the server is compromised and the client
was utilizing a vulnerable version of OpenSSL,
it could actually go the other way.
So that's why even as attackers or practitioners
we need to keep our systems up to date.
And in this situation, it sends back information,
and I cut it off after a certain point
with some dot, dot, dot 64,000 characters.
It's going to fill up the page way too much.
And so that's how Heartbleed works.
That's how it's utilized and understanding that you probably
won't--
hopefully, you won't see it in the wild on a pen test.
But if you were to run something similar,
now you know how to look for it in the National Vulnerability
Database and then on ExploitDB see
if there's proof of concepts, see
if there's Nmap scans that can enumerate specific lead
that vulnerability.
And that's crucial.
We're going to see that again in the next vulnerability
with EternalBlue.
EternalBlue is a very well known vulnerability
because it was part of a WannaCry ransomware attack,
and it affected hospitals, organizations, governments all
across the world for quite a time period in 2017.
The basis of it--
there was a zero-day exploit that
took advantage of SMB and SMB version 1 and a buffer overflow
situation.
It was alleged that the United States National Security
Agency had known about this vulnerability,
had created an exploit for it, and when
there was insider threat and release
of confidential information, their toolkit
including EternalBlue was released and then exploited
by APTs as part of the WannaCry ransomware.
And that affected so much of the world
and seemed almost impossible to stop.
Fortunately, a young researcher, Marcus Hutchins,
found out what was the kill code, essentially,
for the WannaCry virus.
Because of the way that this vulnerability acts,
it can easily spread throughout a whole ecosystem,
especially since if one machine is vulnerable,
other machines might also be vulnerable.
Why?
Why might they also be vulnerable?
Let's jump in.
So CVE-2017-0143.
It's SMB version 1 server and Vista service
pack two, server 2018 service pack two and service pack one.
Windows 7 service pack one, Windows 8.1, Windows Server
2012.
Almost all operating systems being
used at the time that weren't patched,
and Microsoft didn't know until it got released because the US
government didn't tell them.
So it had to be found in the wild
as part of that leaked toolkit from the NSA,
and people just didn't update their service packs.
It wasn't too hard to switch from Windows 7
service pack one to Windows 7 service pack two, which
mitigated this SMB version 1, but it's quite a vulnerability.
Microsoft Corporation was the assigning CNA.
Once they were informed of it, they shared the vulnerability
with the community, and you can see
some more white paper, some exploits, and proof of concepts
to.
Take advantage of it.
On the National Vulnerability Database, same information
we see and fairly high score.
Now there's solutions, tools, proof of concepts,
and the weakness enumeration improper input validation
for SMB version 1, and then affected software
configurations.
And there are versions of Windows 10, Windows 7, Windows
8 servers.
This was part of Windows implementation, Microsoft's
implementation of SMB.
Now, you could say it was the operating system.
It was a service that was built and baked in the operating
system and required a service pack, a patch, or an update
to the OS itself.
It wasn't patched software that may or may not be running.
If the operating system itself wasn't patched,
then it was vulnerable.
And it's such a ubiquitous vulnerability
that it had far-ranging consequences.
There is a specific Nmap scan for the script
to look for, ms17-010.
The ms17-010 comes from Microsoft's internal bug
numbering system, and it's how a lot of exploits
are talked about.
ms08-067 is another older one.
You might see it in some courseware
because the net API also relies on SMB, essentially,
that same protocol suite, if you will.
And a very similar problem, very similar
exploit, very similar vulnerability, and very far
reaching.
Again, part of the operating system,
but also if you want to explain how
these vulnerabilities work, 60% of the time,
it works every time.
So if you create a lab and you want
it to work for your students every time,
ms08-067 ms17-010 are really high up there for entry level.
Hey.
I just want to show you something,
and it's going to work.
What this one looks like-- it will test and see
if it's vulnerable.
It'll test that SMB connection, see if it gets back,
what it expects to get back if it was vulnerable,
and it will tell you that it's vulnerable in CVE-2017-0143.
Again, looking at exploit database--
in this case for ms17-010--
there's some proof of concepts.
There's some pretty good ones.
There's some Metasploit code in here.
This one right here says Metasploit.
Let's take a look.
It's the execution scanner.
It's an auxiliary module.
Sorry.
This is Ruby.
You're not expected to know how to read Ruby, but a lot of it's
just plain English.
And if you've worked with Metasploit at all,
there's a whole course that [? Alexei ?]
has made that goes into how Metasploit,
the framework, and the modules all work together.
The basis for Metasploit framework is Ruby,
and so you should read through this code
and see things that make a lot of sense-- name, description,
all the references.
If you were to run info on a module,
you're going to get this.
It's going to pull it out of the Ruby
and present it in the console.
But looking through this code, we
can see what works, what doesn't work.
And if for some odd reason, maybe during a pen test
they don't want you to use Metasploit for some odd reason.
You could see what is going on in the exploit module
or in the auxiliary module-- this is a scanner--
and then perhaps recreate that in Python
or another language that's rather advanced.
That's not going to be a requirement any time soon
in this courseware.
Just wanted to give you an example of similar code.
All right.
Now, again, going to spell this out exactly how EternalBlue
works.
It's scary simple.
So you scan your victim, and if it is Windows
7 service pack one, if it's running
SMB, if it is server 2012--
any of those vulnerable operating systems--
then it's worthwhile to run that ms17-010 script from Nmap.
You might want to check to make sure it's a safe script
because the exploit EternalBlue can shut down SMB.
And depending on what that system
is used for in the network, shutting down SMB
could be very bad.
There's implications there, so understanding
what those implications when you are exploiting a vulnerability
is really huge as a pen tester.
But we find out that it is SMB version 1
and it is vulnerable to EternalBlue.
So then what do we send?
If you use the Metasploit exploits for it,
it's going to send an SMB packet with a malicious payload.
What it does is it takes advantage of a buffer overflow
inside of the SMB version, and then it
can allow remote code execution.
In that payload, there's going to be probably,
most likely, a reverse shell.
That's what you're going to put in your payload
more often than not.
What that will do is tell the server tell your victim machine
to call back to you and give you a shell,
give you command line interaction with that system.
And that's really straightforward.
It's very, very dangerous.
Now, you don't necessarily need full command line access.
You can run any sort of code.
So if you have a virus, a worm that installs itself, installs
ransomware, encrypts the whole system,
and puts up a splash page of this
is now encrypted for ransom, and then also finds other systems
on the network that also are vulnerable,
and then sends the exploit to them.
That's not very difficult code to write,
and it will just propagate and keep doing the same thing
over and over and over again.
That's what happened, and that's why it was so bad because
if one system on a network--
and it was a flat network--
got hit, if there weren't the right things to place,
it spread across whole hospitals and spread
across whole communities and quite a bad vulnerability.
One that we still want to check for if you see old operating
systems.
Old operating system exists in operational technology
in your ICS or SCADA environments,
often because they've worked and perhaps
the software to run a system hasn't needed to update.
It works.
It pumps the oil out of the ground,
and so it does that day in and day out.
We don't need Windows 10 running the software that does it.
It worked perfectly fine on Windows XP, and that's fine,
but there needs to then be some segmentation and a lot
of mitigation in there to keep something
that you know is very vulnerable on your network
because operational technology and information technology
do touch.
They touch quite often, and it's often overlooked,
so that's something that we don't want to forget.
Now Log4J.
It's a library that's used for logging in Java,
and let's take a look at the CVE page
to kind of understand the jargony way of explaining it.
It says Apache Log4J 2.0-beta 9 through other versions of JNDI
features used in configuration log messages and parameters do
not protect against controlled LDAP and other JNDI-related
endpoints.
I will break down what all that means.
It is very confusing, but essentially an attacker
who can control log messages or log message parameters
can execute arbitrary code loaded on LDAP servers
when message lookup substitution is enabled.
I'll break that down a little bit.
There's references to white papers, explanations.
This is quite a big reason of vulnerability.
So much of the world, so much of gaming,
so many web apps run off of Java that far-reaching impacts
or possible impacts.
We've already looked at this National Vulnerability database
page in the past lesson.
There's a lot of information, a lot of affected configurations,
and a very high criticality at this point just because
without authenticating only having access.
If the old version of Log4J is being implemented,
all you have to do is run a very simple command
and set up an LDAP server, which isn't that hard,
and you could put malicious code onto the server.
And depending on how the Java service is being run,
you might have very high privileges
when you exploit the system.
And there's not too many ways to protect against it.
Since it is so new, the Nmap script for it
is still being developed.
Many developers will come up with these things
and then suggest them or propose them to Nmap
in most cases or Metasploit, often
put them up on Exploit DB, which we'll take a look at,
though there isn't much out there yet.
You've got to be wary about using scripts
that you don't understand.
You could read through some of this code
if it makes sense to you.
The NSE scripts are fairly straightforward.
It's not that difficult to understand.
Difficult to write.
Just like any programming language, I can read through it
and know what a lot of it is saying
if they made good variables and explain, have good outputs.
Writing it, that's another lesson
for another course, another pathway, but in this situation
you can see the usage.
What it would return in this situation--
it's doing the Log4J Log4Shell dot NSC script, some arguments,
call back to a server--
a remote LDAP server in this situation--
on that port.
So it's going to test.
It has this payload, this dollar sign, curly brackets JNDI colon
LDAP colon, an IP address, a port, and then a file.
In this situation, we had an HTTP proxy service running
on port 8080, and it's going to send some get requests and see
what it returns.
And you would have to take a look back
at the callback server to see if it was actually vulnerable,
but that's what it's going to attempt to run.
Let's try to make sense of this vulnerability
because if you don't know Java, like me a week ago,
it could possibly be very confusing.
84% of Java applications use Log4J for logging.
You would log your application.
It could be messages.
It could be bugs.
It could be commands that are input,
wanting to store those for debugging later
if there is an issue.
If it's a web app, you might want to gather information
to see usage data.
There's many, many reasons to log.
It's a crucial thing for developers,
and Log4J is the library that you
utilize for doing that with Java, and that's very common.
On the slide here, we run our Nmap scan
and we get a door service enumeration.
What you return back varies.
It varies so much.
There's so much software that's utilizing Java
that there's no way of honing down and saying
it is SMB version 1, it is these operating systems.
Some things to look for are vulnerable web apps.
It's Apache, so Apache Tomcat.
Web apps run frequently on Apache Tomcat.
You would see that in the service scan.
It would say Apache Tomcat.
There's also Jetty, Apache TomEE, or GlassFish.
These are other services used for web app serving.
The web app could also utilize Java
and be configured on standard PHP website that's
served up via Apache or Nginx.
Nginx.
So you find a vulnerable web app or a vulnerable desktop
application, truthfully.
There's a lot of games that run on Java.
There's a lot of desktop apps, just normal everyday apps
that users use that are created with Java,
and they have logging.
And depending on how the system is
used, that logging and usage of Log4J
could make the end server where those logs
are being kept vulnerable.
It could make the machine being used vulnerable
a little bit-- if it is a desktop app,
then you would already have to exploit that machine
to take advantage of the Log4J exploit
and then exploit that system.
So that's something to take into account,
but we find an input field.
This is how it works.
Java and Log4J takes information from an input field.
It can be a name.
It could be username, password.
It can be information that you send.
For Minecraft, it was server chat.
Someone stands up a Minecraft server,
and there's the chat functionality.
What was sent in chat gets logged onto the server hosting
the Minecraft server.
Now, this command gets sent, and rather
than the server parsing it as text and just logging it,
it actually evaluates the code.
And because of how this is crafted, it's injection,
it's going to get evaluated.
Now, a dollar sign make something a variable, and then
this dollar sign, squiggly line, and then
JNDI, JNDI being the Java Naming and Directory Interface.
It's going to then reach out for more code.
This is useful for Java developers
because you often want to make your web app
or your desktop app as small as possible.
Now, if you can keep code elsewhere and then reference it
only if it's really needed, it keeps your software
small, agile, and less processor,
less things that need to be loaded into memory,
less file storage space for storing your program
because it's going to utilize a server if it
needs additional functionality.
That's what JNDI and LDAP--
LDAP being the Lightweight Directory Application Protocol.
That's the protocol used for interacting
with a remote database.
In this situation, it's going to tell it, hey, reach out to--
oh, this should have been like malicious dot INE on port 1389.
That's going to be our LDAP server.
It sees that variable.
It does the lookup that says, hey, go look elsewhere.
So we've got demo dot INE down there,
and it is an LDAP server that's served up on port 1389.
Now when they connect, they're going
to look for a file called "mycode,"
and that's going to have a Java class in it.
Java class is just Java code that is in another file.
When it gets pulled over, it's going to get executed.
So simple string in an input field
made the server reach out and find more Java code.
A good example of this is here.
It's Java.
There's a lot that doesn't make sense to me.
I mean, you can try to figure it out by reading it,
but I would not write it.
But if you get down in here, there's string and a command.
This might be small to read, but it says the command is bin/sh
[? -c ?] and then echo PWNED redirected into /tmp/pwned.
So what this code is doing-- it's fairly benign,
but it's going to run in Bash execute
code of echo the word "pwned" and put it
into a file temp pwned.
And temp is rolled writable, so no matter
what service is utilizing this, they'll
be able to write to that file or create the file and write to it
if it doesn't already exist.
So Linux understanding that.
If that doesn't make sense to you,
go back and watch the videos and do the content on Linux.
But we don't really need to understand too terribly much,
just seeing that this is going to get pulled into the Java
application and get executed.
That's what this class is.
It's Java code that's pulled from somewhere else.
Object-oriented programming scripting utilizes classes
and instantiates them.
We'll get into that in a more advanced class, I'm sure.
Actually, that understanding of object-oriented programming
should be covered in the fundamentals course,
so hopefully that makes sense.
If it doesn't, go back and watch that.
So it gets executed, and whatever
code is there is going to be run by that server.
In this situation, it's benign--
copy something into a file--
but it could be a remote shell.
A reverse shell, if you will.
It could be almost anything, so it's terribly, terribly
dangerous potentially to run code on another system
unauthorized just from inputting one simple command
into an input field and then having something
ready on an LDAP server.
And after creating some proof of concepts,
it's not difficult to make a malicious LDAP server.
This is very simple exploit that works really well.
Looking at the vulnerabilities and understanding
what's behind them, how they apply, and then trying to think
how would you utilize this playing
the path of an attacker, being a penetration tester,
being a red teamer, hopefully this all made sense to you.
If you're taking this course but you
don't see yourself as a pen tester,
you don't see yourself becoming a pen tester,
you just want an understanding of cybersecurity,
I hope this helped understand why these vulnerabilities are
important, and start thinking about some of the mitigations.
Even as pen testers, we need to think
about the mitigation for these vulnerabilities
because that's going to go in a report,
and that again is what is valuable and useful
to the client.
With that, we're going to get into some labs.