For the folks who are on the screen, are we on the record?
Is the transcription running?
Here's the thing with the transcription, you know that this is new this year
and I think it's been very, very cool.
And I've had a lot of questions about how it's working because it
is so darn effective.
So the way that that's actually happening is there
is a live participant of Party Track that is not here.
They are off site and it is a court reporting service.
So ponder that, okay?
When I'm not at DEF CON, I'm an attorney back home.
And court reporters obviously sit there and transcribe court proceedings
and depositions and very bland and boring types of materials.
So, there is a team of court reporters that has now gotten
to transcribe this for all of us and type
the words that have been coming out of all these speakers' mouths
like Dongs, pumpkin poop, booze, okay?
So it may be one of the more interesting types
of projects that they've ever been assigned to.
So my question to our court reporter is: What do
you think?
You are an interesting group.
By far the funnest group I have worked with.
(applause) So how about just one more time
for our court reporter here in Party Track,
let's make applause show up on that screen.
(applause) Awesome stuff.
I will be taking off pretty soon.
You guys have been good.
Party Track totally rocks and I will probably see you all next year.
Without further ado, we are going to learn something
about exploit detection systems now.
Have a good time, everybody.
(applause) AMR THABET: Hello, guys.
Hello, girls, also.
Girls mainly.
Today I will talk about exploit detection system.
First, I am Amr Thabet.
I'm from Egypt.
I am work for Q CERT in Qatar.
I work on open source projects like SRDF and Pokas Emulator.
I wrote about Stuxnet and that's it.
This is my first team here at DEF CON.
(applause).
AMR THABET: Thank you.
Okay.
Let's begin.
As you all know, been testing right now or hacking right
now has become different from the security compliance.
They are not attacking the servers right now.
They are not trying to use Metasploit and attacking
the server.
Right now most of the attacks are advanced
resistance threats.
They are attacking from the client side.
This are using phishing.
They are attacking ways from (inaudible).
From their clients, from their machines, they are attacking the servers.
They can bypass most of the security compliance applications,
firewalls, antivirus prevention systems.
They can bypass everything.
They use some undetectable malwares affecting their clients,
using HTTP connections.
So they are bypassing everything.
They are bypassing the antiviruses and all the security tools right now
become useless.
So what's the solution?
There is a new technology, a new era.
That's what we are talking today.
The latest security technology is from my point of view
the exploitation detection system.
We now need to secure the client like we are securing the server.
We need to secure from the client side attacks
and exploits.
We need to stop the successful exploitation and stop
the using of 0days and make it harder.
Actually, when the security begins, they begin with antivirus
as a technology.
And after a time, it was bypassed and there was other attacks.
They created the firewalls and become very, very vulnerable.
And after a time, bypass the detection systems and now
they are bypassed.
So what is the next?
The next is the exploitation detection system.
That's the era of exploitation detection system.
Today I will talk about the exploit detection system,
a new technology, as a new concept.
That's what I already talked about.
I talk about also my exploit detection system tool, how it can stop
the attacks, how it can mitigate the attacks.
I will also talk about the development, still in the middle.
But I will talk about what we are doing now.
And I have a little bit of advertisement
for my open source (inaudible).
I will talk about it also.
How many people here know about assembly exploits,
understand all that?
Good.
Not too much.
But I will explain everything for you.
No problem.
First, we'll talk about why it is the goals of this tool,
how I created all this.
Then I will talk about the design of this tool and
the mitigations that's used to stop all the attack vectors and I
will talk about the attack vectors, explaining them in detail, in brief,
not huge details, for everyone to understand.
And I will talk about the monitoring system that's also
inside the EDS and then the development and my future point
of view for EDS.
Let's begin.
Simply, as I said, it's created mainly to stop the exploitation.
As I see most of the attacks are using social
engineering and client side attacks on all of this.
That's what I created this tool for.
It's to stop the memory corruption exploits.
Maybe you don't know about memory corruption.
I will describe it right now.
It detects the compromised processes.
If you have a malicious wire running it, it also exploited your process so it tried
to take this process compromised through an unknown behavior
or it has some corruption in its memory and stops that.
It prevents or alerts someone in the company, in the I.T.
administrators or the security team, about there is a machine or there
is a client that has been hacked.
Simply, memory corruption is about if you have a piece
of memory and there is a buffer created, there is verification with username
and password, imagine your name will be 200 characters.
No one has a name longer than this, so it creates a buffer for it.
Take your username, copy all your username inside this buffer,
and you don't check on the size of your username, and then run.
Actually, if I send an username with 1,000 bytes or so,
1,000 character length, he will right on the 200 bytes of his buffer
and then he will overwrite some other place in memory.
These places in memory could be if you are could be a pointer
to this memory, could make some corruption.
Could be a pointer in a code, in the stack, something
in the stack has a pointer named return address.
The processor or the CPU after a time executes, goes
through this pointer and executes the code that this pointer points to.
So if I overwrite this pointer, I can make the CPU go
to another place in your application.
So if it is something that shaked the password,
I can overwrite this pointer and make it return that you win
or you passed or something like this or your username and password are
correct so I can change the behavior of your process using some
modification in your memory.
And that's what's named memory corruption.
You can know about it more in corlan.be.
Corlan team is a very, very good team.
Talking about memory corruption and how to use it, how people use it.
And as you see in these pictures, I show you that there is an overwrite
he overwritten the return address you can see so I can
now modify the behavior of this process.
Okay.
Some people ask, okay, it is good point but what's
the difference between the exploit detection system
and antivirus.
Simply, EDS is not signature based, is not mainly behavior based;
it's simply searching the memory for any corruption.
If there is unknown corruption or unknown overwrite,
you can detect that.
It doesn't detect malware.
To detect there is a new virus or something.
It is just search for exploitation.
So is this something new?
No.
There is combined solutions and the combined solutions was created
by Microsoft like GS cookie.
They had a cookie before the return address that we saw
in the previous slides to check if it was verified or not,
something like this.
But the combined solutions has
a problem that force everyone to recombine the application
to add this feature.
So always there is an exception.
There will be someone, a developer, who will not compile
with the new technology so I can bypass also.
There is other runtime solutions.
One of them was EMET, who talked about his great tool
from two presentations and there's others.
Actually, from my interview, I see it is like enough mitigation.
This action is a malware or there is an exploit or that's not an exploit.
I need something more flexible.
It's one layer of mitigation, one layer of defense.
It can't know it was bypassed or not.
I will talk about this.
Okay.
So what we have what new things we have?
We have cooperative mitigations.
We will talk about this.
We have a scoring assistant.
We have something more flexible to detect exploitation and so on.
We have an additional layer of monitoring system
and this monitoring system, we'll talk about it.
It detects if there is something bypassed
all mitigations and there is an attack already working.
So it's another additional layer to secure.
Simply, the design that there is payload detection, we will talk
about what is shared code and what's chain.
They have shared code detector.
We have chain detect.
We have attack vector detector.
We have security mitigations for the stack and with heap.
Actually, the stack as we saw in the two slides, it's
a place that includes some return addresses.
And this return address, if it was overwritten, it
will create a problem.
It can change the behavior of the application.
The heap has something similar named V table.
V table actually it has some pointers, some functions.
In a time, the processor can execute one of them.
And if they are also overwritten, it will create a problem.
After that, we have the scoring system and
the monitoring system.
Okay.
The scoring system is based on three things.
Based on payload detection, placed on share code, what you see
in your input, if you sent a code or something like this,
if you send a ROP chain or a return address.
Also, it includes it detects the exploitation attack vector.
If there's an attack, there is something suspicious, tries
to stop this.
Also, it scans on something suspicious related
to this process.
It renames a suspicious action so it gives more
score or high score for this attack or this input.
There is something more suspicious.
The monitoring system searches for evidence of exploitation.
Detectors bypassed mitigations.
This promise was compromised, it would include unknown delays.
There is some functions hacked or something like this.
There is something unknown running at this process.
We will talk about it in details.
First, what's (inaudible)?
Simply, as I told you, I can send username 1,000 bytes.
But I can overwrite a return address.
And I can also modify this return address to return to my user input,
to return to my username.
So the processor will execute my username
as it's a code.
shared code is simply a bunch of bytes I can send as an username
and actually it's an assembly code in bytes so I can when I can do
the return address, I can make the processor execute my username
or execute the bytes this bunch of bytes and this bunch of bytes do
an action for myself so I can control
your process.
I can send you a code and this code will get executed.
And I'm like I'm inside your PC.
The shared code simply it gets its place in memory.
That's the first thing it do because it is running in unknown space.
It is just username copied in unknown buffers.
Try to take it the way it is.
And then getting the Windows functions to execute
like I need to execute a new application.
I need to create (inaudible).
I need to connect their Internet so it gets the Windows functions to do
all of this.
And then attack.
There is a good article about this code project.
Is there any problem until now?
Actually, some shared codes are forced to not have any null byte or zero.
Why?
Because when I send an username, the username always is just a string
or a (inaudible).
(inaudible) finishes with mall byte or zero byte.
That means your username was finished.
So the shared codes should not have null bytes.
That's a point or most of them.
They are sometimes encrypted.
If you see Metasploit how many people here use Metasploit?
A lot.
Actually, Metasploit, when you choose the payload,
choose a shared code, you can encode it
to bypass antiviruses and all signature based ways so sometimes
shared codes are encrypted and there will be, like, a loop
to grab it byte by byte.
So there will be a loop, some code execute in, like, a cycle.
And some shared codes are forced to be in ASCII
like they are characters A, B, C and so on because some applications
the username includes some unknown bytes.
That's it.
So we need to detect that this username this
person's name includes some shared code, includes some code inside it.
And you dry to modify the application behavior
to run this share code.
So I created a share code detection tool.
My goal in this tool is to be very fast
because this sample will be sent in small time an action will happen
after that, so I don't need to have
a memory consult any time used.
I need it to be very hard to bypass and to be very strong and I have some
false positives but low as I can.
So I added static share code detection.
Static shared code means maximum disassemble or just checks the bytes.
It doesn't try to when it detects a shared code, it doesn't run it.
That's the mean of static.
It doesn't run the shared code.
It just disassembles it and convert it to assembly and try
to understand this assembly code or just a bunch of bytes.
And we divide this shared code detector into three phases.
The first phase, we research this username.
There is an indication that there is a code, a working code.
And we'll detect how we can do this like we detect that there is a loop,
a working loop inside.
There is something, if I disassemble all the instructions, I jump to one
of the instructions and the code simply is working.
That's the first indication of possible shared codes.
The second, I filter all of the instructions that are invalid
or some set of instructions that are corrupted
or not used in the normal process.
And then I do some flow analysis on all of this shared code.
This code will work fine or it will not work.
It is just a bunch of bytes.
(applause).
Yeah!
AMR THABET: Thank you.
(laughter) Why did you stop speaking?
AMR THABET: Let's take a break.
(laughter).
All right.
You know the drill.
What are we called?
No, it is not fuck this speaker.
(laughter) Shot the n00b.
What are you doing?
All right.
Oh, and we need who's first time Jesus.
(laughter).
I think the guy here in front actually got there first.
All right.
Here you are, sir.
Wait, wait, wait.
I want to interview him.
Yeah, we have to interview him, first.
What's your name?
Orbo.
Where are you from?
Utah.
Why did you come to DEF CON?
Why are you drinking?
Because I'm not Mormon.
Why are you in Utah?
(laughter) Cheers.
All right, cheers to everybody first time at DEF CON.
(applause) How's he doing?
Should we invite him back next year?
(applause) You have five minutes.
We're taking this.
AMR THABET: I will take it.
Is this yours?
AMR THABET: No, no, no, it is not mine.
I'm just joking.
That's awesome.
I don't know.
But we'll just leave it there for the next speakers.
Thank you.
AMR THABET: Thank you.
Thank you, guys.
(applause).
What we said?
(laughter) That's the shared code detection.
(laughter).
Okay.
We search for indication of shared code.
First, we search for a working loop.
How it works, actually the assembly code for X86,
each instruction has variable size, like instruction has three bytes
and instruction has five bytes and so on.
So what we are doing is we assembled from a place
to a research jump to something previous and disassemble
between all of them.
If the assembly code works fine, the last instruction ends
before the jump, so it means that it is something it is a real loop.
So the jump is here, pointing to an instruction and
all of this instruction were running and it will return to this jump and so on.
We search for something like this.
It seems that it's a working loop.
It seems it is a shared code that's just an indication.
We check for in some shared codes, they call to something
to address in previous.
Why?
To try to using a simple way to get whoever they are in the memory.
I don't know I don't need to enter details.
But we can detect there is a call to something previous and disassemble
between the call and between the destination so we can
know it seems a working loop or something like this.
Which also in some loop instructions
inside the X86, that's the first way to indicate there
is a shared code or something.
If we didn't find the loop, we search for high rate
of unknown instruction and push.
Usually it was used in all shared codes.
It must can ASCII, it must be three characters, A, B, C,
something like this.
And we detect there is a high rate of these pushes.
And after that, usually the shared code that include pushes,
it pushes instruction value inside the stack.
So if you have a hundred pushes and then call to the stack,
it simply it could be an encryption way or
a shared code encrypted and will describe all the shared code
in the stack and then (inaudible) it so we can detect something like this.
Also, we have an instruction, an assembly instruction.
But it is used very much with shared codes
because it detects where there are the shared codes.
So with all of these three ways, we can see that it seems
the shared code here, this assembly or this person name is suspicious.
Then we skip some invalid instructions, some of these instructions in and
out and all of this are related to devices and used in kernel, used
by device drivers, not used by normal applications.
Some instructions has unknown behavior, some crazy things
into assembly.
But we skip all of the instructions if we found them, so the shared code
if we found the shared code has this instruction,
it seems corrupted or something.
And then we do some flow analysis.
Simply if you have a loop, the loop should have
if it saves something in the stack, it should give the value that it saves
in the stack because stack is like it is like a cup of water.
You add to it and then you take from it.
So you can't fill it until it overflows.
You just you need to add to it and then take what you added.
So if you have a loop, you should have push
and pull you should have something added
in the stack and another instruction take
from the stack so we check on this.
We check on, compare jumps, and we check for malware bytes.
After I designed this shared code and after I wrote it,
I tested some false positives and some real shared codes
in Metasploit.
For the false positives, I detect that 4% of the shared codes,
4% of junk data, it detected as a shared code.
It's not a very high level of false positives, but not few.
It detects all Metasploit shared codes.
It can detect the (inaudible) for shared codes.
But actually manual elevation is still possible.
ROP chain, it is simply return oriented programming,
and as you can see, it is simply when there is some,
mitigation windows in execution prevention, to prevent
the users from prevent any data sent as username or something like this
to be executed, so some people try to return in side
the application itself and try to find very few instructions
after these instructions are return instruction and to make a call return
or return some instructions.
And then the return to other instructions
inside the shared code section in the application and another
and another and collects these small pieces to create
a working shared code from the code of the application.
So it can bypass an execution detection and it can have
a working shared code.
We detect all of them easily.
We check if the address is we check if the address
is in the executable module.
We check the return address, the return of the call or not, and
all of this.
Okay.
For the stack mitigations, we detect we have a mitigation
in (inaudible) switching and it is simply we detect that there
is a return to a Windows API, the Windows functions or Windows API
are some functions created by Windows tool to do some stuff
like creating a new process or something like this.
We will check if there is a call to it or if it is a return to this call.
If there is a return to this CAPI, it seems return oriented programming
or it seems an attack.
We talk about return robot attack.
Most of this type of attack vector, what they do to bypass
the exploit detection system, they create some pieces of robot text
or ROP objects.
These piece of code call to virtual protected API.
Virtual protects can make the stack executable so
they can use the ROP objects to make the username that I entered
as a shared code or the shared code
inside my username become executable so I can return
to the shared code and bypass the execution prevention.
So what we do is we hook the calls to the system.
There is a kernel mode that includes the Windows device drivers.
And the process the process connects
to the Windows kernel mode using an instruction system enter.
We are working here and do stack back tracing, check every caller to this
to system, check the caller to system and the caller
to the caller until we reach if there is a call from the application
to this API or if there is no callers or if it is return oriented programming.
Actually, in Windows 62, this is dehooking.
But in Win64, we don't we can't create device drivers
that unhook this dehooking.
So we hook the Windows emulator, we can hook any function calling
to the kernel mode, system enter and something like this.
We hooking virtual protect and all of this protection APIs and
the creating process should execute an application.
So I can connect the (inaudible).
We hook the functions that will create a socket connected
to the Internet.
What we do exactly after we do the backtracing and reach the call
to this application, call to this API in the application, we check this call
is really a call to this API or if it is a fake return address created
by the attacker.
We do some checks like we check if there is a call to the API or not.
We check the parameters.
The program remembers are created by this API caller.
Application called the API with this prompter or not.
We will see this again.
We check if the application itself as a call to the function that calls
to the API.
We check other things.
And after that, we give a score to the API.
Yeah, that's a call to the API or not.
We check on different types of calls to see if there is really a call to the API.
We check the parameters.
If there is a reconnaissance prompter, the process give it to the CPI.
It gives the name of the process.
Create process it has a create process API and it gives create
process API a parameter, a specific application and attacker try
to use this part of the code and try to give it another parameter.
We can detect something like this.
Let's see the demo.
Anyone see anything?
Simply we begin by we have FireFox API,
FireFox application and we try to we try to hook this API and hook
the FireFox and check if we run an application using FireFox, if there
is a real call to this API or not.
Is it really FireFox who runs this application or if it
is a fake call or something?
We first hooked the application, and then we here clicked
on an application on FireFox.
So we forced FireFox to execute an application or create a process.
And then we check on the parameters of this.
I don't see the video but no problem.
We check the parameters.
We check on the (inaudible).
We do some stack back tracing and check on the call stack
and check on the parameters.
We check the score.
And we saw the score is 2, so it's a normal call.
And then I don't think see anything.
Okay.
I made a vulnerable application, small vulnerable application which not
call to shell execute.
It gives an input and return to shell execute.
So I tested it.
I run the application and it's vulnerable.
It gives the message in the call in the code.
And then it should return to shell execute which executes
a function.
So we'll check this.
And it detected there is no call.
And it detects there is an attack and gives a high score,
so it can stop this attack.
And then we have a (inaudible) mitigation.
We simply check instruction exception handle something working fine.
And then we have some mitigations for heap.
We detect a heap overflow, heap spray, abuser.
We hook the global look the function that looks in the heap,
runs all of this.
And we defect that we add some cookies in h located buffer and try
to detect if there is an overflow to this buffer in the heap or not.
And for heap spray, we try to detect there
is a large memory location in a very small time
from the same module and try to stop this heap spray or risk
for ROP chain.
If we find the shared code and ROP chain inside, it
is simply heap spray.
We detect there is a (inaudible).
If there is a class including some pointers
or creating something in the V table, we try to make this buffer freed
after we delay it.
So we can stop any use of the free.
And then we have the scoring system.
We described the scoring system.
We stop all types of attack using our scoring system
which I check the payload and the attacking vector and all of this.
And then if we didn't find it's a real attack, we can at least mark it
as suspicious and give it to the bad news trader.
We have the monitoring system.
The monitoring system will check if all of our mitigations were bypassed.
We check the memory.
Check if there is executable place in the stack, if there
is an executable place in heap, if there is an execute place
in memory (inaudible) or something suspicious.
We search for ROP chains in the memory and shared codes and
all of this stuff.
We check if there is a threat running
outside running outside the memory and all of this.
What we are planning for, we are planning
to create any company to have a central server which gets
all the looks from the exploit detection system
applications inside the clients inside the company so
they can get information from all of this detect, if this
is a suspicious action that happens on all of their clients.
Also correlating all this information
with the intrusion detection system and all of the tools,
they can create a timeline of an attack.
They can detect there is an attack and contain it.
That's the future work.
Development, it is based on security session development.
It is a development (inaudible) I already created.
Until now, it is in three contributors.
It simply is in C++, it is for Windows right now.
And we couldn't include the version Linux and version bison.
(inaudible) for writing security tools.
This development framework includes a bunch of security tools inside it.
It includes BE and (inaudible), including Android BRSA.
It includes for static analysis a full assembler and disassembler
engine and the (inaudible) server.
It includes some wildcard standing.
It has dynamic scanning, full process analysis, debugger,
full debugger and later it includes full behavior dehooking and all of this.
Simply, you can build your application using it.
It will you will not waste your time if you have an idea and you need
to implement it.
You will not waste your time.
You can use the SRDF and don't waste your time
in creating and reinventing the wheel and creating all of the tools.
We have packet capturing decision analysis and all of this.
I will talk about it in details in virus bulletin.
Just join us.
That's the GitHub version.
Join SRDF or use it.
You can reach us for exploit detection system
if you want to support this idea, if you have feedback,
if you have any questions.
If you have anything, just email me or send me on Twitter or anything.
That's it.
EDS, exploit detection system, in my opinion, it is a new era.
All people should jump into something like this.
That's the new technology which can stop the (inaudible) attacks.
Join us.
Thank you.
(applause) AMR THABET: We can talk outside.
Thank you.