Hello everyone, and thank you for joining this course.
My name is Natalie and we are going to explore software exploitation in from one hand a very simple
way and on the other hand, very advanced uh, concepts that we are going to talk about and actually
experience firsthand.
So my goal would be to take you through a journey that covers very sophisticated topics in a very simplified,
easy to understand way, using illustrations and examples from the real world.
So really, thank you for joining and let's jump right in.
So first, who am I?
Um, I started early with computer science.
Uh, but the only connection I had to computers was that I really liked playing FIFA.
Um, and that somehow brought me to a bachelor's degree in computer science when I was 14, and that
paved the way to unit 8200, the Israeli intelligence forces, where I gained a hacker's perspective
practicing cyber security there, which led me to my professional experience in the industry, where
I really was a vulnerability researcher, finding zero day vulnerabilities in Linux kernel and Android
devices.
But more importantly, designed exploitations to actually take advantage of those vulnerabilities to
extract intelligence, which led me to co-founding sternum, which developed a runtime security solution
that can prevent the exploitation stages of different attacks and software attacks.
We use techniques like memory protection, runtime application self-protection and those sorts of things.
And worked on the most advanced devices you can imagine, from medical devices to military drones to
machine vision devices that used our technology to be protected.
And what I want to do here today is to actually simplify very complex topics and talk about how exploitation
really looks like, not just the part of finding a vulnerability or patching a CVE, but what really
happens behind the scenes.
This will give you the tools to understand hands on.
What are attack vectors?
Where should I look for sweet spots in the code that I'm generating, or the product that I'm bringing
to market, and how hackers are actually bypassing different security mitigation Mitigations that I
think I put on my device.
All of these will be explored, and we're going to have a lot of fun actually developing exploitations.
But first, starting from the very beginning, defining vulnerabilities and exploitation.
So what are vulnerabilities in computer security?
A vulnerability is a weakness which can be exploited by a threat actor, such as an attacker, to perform
unauthorized actions within a computer system.
I would say here that not all vulnerabilities can be exploited.
And we are seeing in the field vulnerabilities that can't really be exploited but are still addressed
by military or by companies patching them.
But the key point here is that vulnerability is an option for a malicious user to use a system flow
to gain control of the system, or to use it in a way the developer did not Intend.
Keyword here is an option.
Just the fact that we have a vulnerability does not mean we got attacked or something happened.
And it also doesn't necessarily mean it's exploitable.
So what is exploitation?
To exploit a vulnerability, an attacker must have at least one applicable tool or technique that can
connect to a system weakness.
So what we understand here is that an exploit is actually connected to a very specific vulnerability.
We cannot create a generic exploit.
Each exploit is connected to the vulnerability that we are attempting to exploit.
And the exploit is actually where we take advantage of the vulnerability that we have found to cause
the unintended behavior.
So an exploit from the English verb to exploit, meaning to use something to one's own advantage is
a piece of software, actually a chunk of data or a sequence of commands that takes advantage of a bug
or vulnerability to cause unintended or unanticipated behavior.
And this is also a key part here, because if our exploitation cannot really cause the system to behave
unexpectedly on or unintendedly, then we didn't exploit anything, right?
If the system continues to behave as it was intended by the developers, we didn't really exploit the
system.
So a key part of actually exploiting is causing this unexpected or unintended behavior.
Let's take an example for the real life to just cover those two topics.
Let's say I left the door open in my house.
So the vulnerability in that scenario is leaving the door open.
An attacker scouting out can find that you actually tend to leave your door open, or that you actually
live in the door open every once in a while, and that this is a vulnerability to enter your house.
But now I need to plan the exploitation.
Just knowing that you tend to leave the door open doesn't help me that much.
So at planning, the attack requires.
Basically, let's think about a few things I need to know first.
Making sure that the door is actually open at the time of exploitation.
When I plan to enter your house, that the vulnerability exists.
Second, maybe I want to become familiar with your schedule to know if you're home or not, because
I also need you to be out of the house to exploit it.
Understand your alarm mechanism to know how to bypass it if needed, and so on.
So planning the Planning.
The exploitation is actually very much the same in software as well.
We need to plan and arrange the environment so that we can actually leverage the vulnerability that
we found.
The execution is actually taking this planned exploitation that connects to the specific vulnerability
that we found the door open and actually performing the exploit entering the house while I'm not there,
bypassing the alarm mechanism or anything else that I needed to account for.
So let's talk about the general types of vulnerabilities, because not all vulnerabilities are the same.
And when you choose a security tool to implement in your company or when you are starting to search
for vulnerability, if you are a security researcher, you need to know that, uh, we don't treat all
vulnerabilities the same.
And this is my kind of categories of vulnerabilities.
You might see other things online.
But as I view, uh, most of the world, we have first bucket, uh, of configuration vulnerabilities.
Those actually arise from incorrect system settings, insecure defaults and so on.
Examples could be open ports or services.
Exposing an S3 server to the, uh, to the internet.
Default credentials, weak permissions, uh, and so on and so forth.
So these are vulnerabilities in how we configure our systems across the board.
The second type I call them logical vulnerabilities, which is actually the software designed from the
get go or by intention, not in a secure manner.
This could be, for example, uh, not encrypting data or having a very weak admin password that, uh,
someone can kind of, uh, guess or business logic errors.
This could mean that you actually allow a certain sensitive operation to happen without requiring permissions.
So this is like you didn't design the software in a way that is secure.
And this is why I call them logical vulnerabilities.
The third part are code vulnerabilities.
These are flaws in the actual source code or memory handling, often due to easy to miss programming
bugs.
This could be something that you'll easily miss and static analysis tools sometimes companies use can
only track around 50% of those bugs, and we're still left with 50% that goes out there, uh, into
the field.
Examples are, of course, the most famous one.
Stack overflows.
Buffer overflows in general format.
String vulnerabilities, command injections, basically everything that is within how you handle code.
Not necessarily, uh, application logic.
Our focus will be on code vulnerabilities.
Why?
Because this actually requires advanced exploitations.
Most of the zero days out there that are being exploited are code vulnerabilities, especially if we're
talking about military grade exploits.
IoT exploits that, uh, are more prone to code vulnerabilities and so on.
So this is the most interesting part.
We have a lot of tools to cover this part.
And logical vulnerabilities are something that, uh, at least in advanced systems, MPs are also a
more easy to track, at least the more the important ones.
We're still seeing a lot of system that has these logical vulnerabilities, but in that case, the exploitation
is pretty simple, right?
If you find just a business logic that is not well written, you just need to go in and use that business
logic.
You don't need to really craft a sophisticated exploitation.
So this is where we are going to focus.
Just as a Glimpse Micro actually published every year, the most, uh, the top ten vulnerabilities
that are most common out there.
And you can see that each type of vulnerability has an ID, a CWA, basically.
And what we are going to cover is the number two, uh, which is memory corruption out of bound.
Right.
So this is the second most popular vulnerability out there out of about read use after free.
and we are also going to cover vulnerabilities that are not within that list.
In future courses, we probably going to cover command injections, missing authorization and those
type of things.
Now let's talk about attack vectors, which are really potential paths to exploitable vulnerabilities.
Mark the word exploitable.
It's not just paths to vulnerability.
Sometimes you can have a vulnerability but no path to trigger the vulnerability.
So attack vectors are crafting together, knowing the path to trigger a vulnerability so it becomes
exploitable.
Attack vectors are target dependent.
We don't have a general attack vectors in mind.
Different systems expose different pathways for exploitation.
The interface matters a lot.
How a system connects to the outside world Sidewall determines its vulnerable points.
If we have more interfaces, Wi-Fi, Bluetooth connectivity to different servers, parsing different
types of information coming in and out from our system, these are all attack vectors because those
are interfaces that create communication between our system and the outside world.
Since the attacker is present in the outside world and not in our system, attacker actually relies
on his ways to communicate with our system.
So every time you need to map an attack vector, think about this.
What are all the options that an outside world player can talk, communicate, or influence my system?
This will probably give you a good start of attack vectors.
In this section, we're actually going to briefly review an IoT Example, where we map the various attack
vectors that are present in a.
In a simple IoT device.
So simple breakdown of IoT attack vectors.
Let's say we have a device.
And what you can see here is an illustration of a chip.
And let's talk about the five elements we see here.
The first one is parsing vulnerabilities when dealing with user input.
This is uh basically all the communication channels where we need to break down the packets received.
Received.
Sorry.
And we are not dealing well with the user input or checking sizes, those type of things, and creating
overflows in the memory or other types of vulnerabilities.
The second is communicating with insecure source.
This is something we see a lot.
Our system communicates with a server or a smartphone application, and we trust that the information
coming from this source is legitimate, but we can't really trust it.
What if someone took over the server, or pretending to be the server, and is sending commands to our
IoT device, and our IoT device is just performing the commands?
This is an example of a logical vulnerability securing a trust in a source without legitimate reasons
to trust it.
The third thing is third party libraries in every system, including IoT device.
We actually implement a lot of third party code libraries.
Even the operating system is a type of a third party.
Every vulnerability in this third party code is another attack vector for the attackers.
They can actually find a third party vulnerability and then exploit it in all systems that leveraging
this third party.
We will see an example of it in just a second.
The fourth is encryption and authentication misuses.
This is a very common attack vector for IoT devices.
And fifth is chip level vulnerabilities.
Even the chip set used for Wi-Fi and Bluetooth communication comes with software.
Inside.
That software is responsible for the first layer of analysis of the incoming communication, which means
you can also overflow that, uh, piece of, uh, of input that is being parsed to at least gain control
over the chip and then, uh, find your way into other places.
We don't have to really understand that deeply right now.
But the most important thing to remember here is that everything that has software in it.
Even the smallest chip in your device could be an attack vector.
What is the attack chain?
Um, so we have actually between 4 to 3 stages.
Between 3 and 4 would be a better way to say it.
Uh, of attacking a device.
The first one is a vulnerability.
We need to find a flaw in the system.
The second one is exploit.
We actually weaponized, uh, a code that manipulates the system behavior by leveraging the vulnerability
from stage one.
Now that we were able to do that, we can, uh, inject a shell code that is the first, uh, malicious
code running in the system that is actually opening the gate or installing the malware, which is the
last stage, which is the malicious software that actually, uh, continuously, uh, spying the system
or causing a certain damage.
In some cases, stage three and four are being connected together, and you actually goes from exploit
to a malware.
But if you are looking for more, I would say persistent malware that is present.
Many times you'll go through a shellcode that is then responsible for, uh, safely installing the malware
without being recognized.
Now an example.
Heartbleed, a critical security third party, uh, vulnerability and exploitation.
You probably noticed and heard about it a lot, but just to give you, uh, a glimpse into how it connects
to what we discussed, OpenSSL is a widely used cryptographic library that is actually supposed to protect
sensitive data.
Ironically, it's a software, and it's a software that powers information coming from the outside.
So it had a flow, a code vulnerability.
So while the logical behavior of open SSL is to protect us within the implementation of the library,
there is a simple code vulnerability.
The interface that was exposed is the mechanism called Heartbleed which should basically say, hey,
I'm here, I'm good, and it is exposed to the outside world via https.
The type of vulnerability is out of bound read.
Uh, the critical flow came from improper input validation in the Heartbleed uh extension.
This is actually a third party library vulnerability.
What that means is that every system that is using this version of OpenSSL is exposed to the vulnerability
and to the same exploitation.
So thinking about it from the hacker's perspective here, I can find one vulnerability in a third party
and apply it, uh, almost generically across systems.
This is very powerful attack scenario is attackers crafting packets requesting more data than actually
provided OpenSSL returns basically the memory containing the adjacent memory containing, for example,
passwords and keys and private data, because it starts sending, uh, memory from places that the attacker
should not have any visibility to.
And the impact is is well known.
But let's see the Heartbleed attack chain timeline, as we saw earlier, uh, about the attack chain.
So the vulnerability is out of bounds.
Read the exploitation is the malicious heartbeat request actually requesting larger payload size than
actually provided, which triggers this out of bounds read.
Shellcode in that case was not used.
Uh, using this, uh, malicious packet, we were able to directly extract memory and read this sensitive
information with no, uh, shellcode needed.
The malware or the impact in that case is the sensitive data being exposed.
So this pretty much covers how a real attack is actually reflected in the timeline we discussed earlier.
What is the vulnerability, how the exploitation actually looks like?
What is the attack vector, which is the Https interface that is exposed to the outside world?
To basically wrap up the concepts we talked about with a real example.
What's next?
So we are going to cover stack Overflow's security mitigations like how systems today protect against
code vulnerability exploitations, how attackers handle that with ROP, return oriented programming
to bypass those security mitigations.
And we are going to have a very cool hands on lab where you will actually develop your own exploitations
later in the course.
We will also cover advanced techniques like heap, feng shui and other cool stuff.
So I hope you enjoy.
This was just an introduction, but next in line are going to be really code examples, exploitations
and diving deep into how actually softwares are being exploited and how to design and exploit.
Thank you.