In this blogpost I would like to introduce you to Sentinel, an anti-exploit tool, and share two demos with you.

Sentinel is a 32-bit anti-exploit tool that I have been developing for some time which I presented in "Ekoparty" security conference at the end of September 2013. The slides of the presentation can be found here.

Today the first public version will be published here.

I would like to show you some details. First of all, Sentinel is in beta version, so there may be some bugs, if you find one, please send me an email to "neconomou@coresecurity.com".


How does it work ?

    The user decides which process or group of processes to protect and which protection level to set.

In the command line, we can see:
    "use: sentinel <-p pid|-e executable|-pn process_name|-pl filename> [module_to_protect [module_to_protect [...]]]"

When "sentinel.exe" is executed, it injects "sentinel.dll" in the process to be protected.
When the DLL is initialized, it establishes a TCP connection between the Sentinel kernel and the UI.
After that, and depending on the parameters set by the user, Sentinel analyses the program and the modules to be protected in RUNTIME.
When the analysis finishes, Sentinel starts to modify in RUNTIME the program and the modules chosen by the user.
When the protections are added, Sentinel is activated and it starts to check CALLs done by the program to the PROTECTED FUNCTIONS.

If Sentinel detects some modification in the regular behavior of the program, Sentinel freezes all the program's threads and launches a window asking the user if the program should continue.

Note: I know that to give options to users is a little dangerous but in a beta version I would prefer to be more flexible.)


Analysis and Protections:


Default protection:

    It's the option by default (no parameters), it only checks calls to exploit "targeted" functions.

For now, the "protected" functions are:

  • CreateFileMappingA
  • CreateFileMappingW
  • CreateProcessA
  • CreateProcessW
  • LoadLibraryA
  • LoadLibraryW
  • LoadLibraryExA
  • LoadLibraryExW
  • MapViewOfFile
  • MapViewOfFileEx
  • VirtualAlloc
  • VirtualAllocEx
  • VirtualProtect
  • VirtualProtectEx
  • WinExec
  • ZwCreateSection
  • ZwCreateProcess
  • ZwCreateProcessEx
  • ZwProtectVirtualMemory
  • ZwSetInformationProcess

This function list may not be complete, but for now, I would say that there are more than enough to get started.


P
rogram and module protection:

    Besides setting the protection level, this option allows Sentinel to add protections to the program and modules (DLLs) loaded in the process memory space.

Essentially, Sentinel uses its own analyzer to detect which functions belong to each module to be able to protect all possible functions.
The analysis of the modules is taken from the memory, not from the files located in the drive.
This is to detect possible modifications in the program memory for example EMET, Adobe Sandbox, AntiViruses, Viruses, etc ...

In contrast, when an executable or module is analyzed completely, this analysis mode produces an important overhead time (OR NOT ) because the analysis is taken each time. So, I recommend you to use this option only if the program is launched few times.

It's important to clarify that "protected" function means that its PROLOGUE and its EPILOGUE were modified by Sentinel to detect changes in the program execution.

Changes in the program execution could be considered:

  • Execute a function EPILOGUE without executing a function PROLOGUE (usually ROP behavior ).
  • Differences in values of RETURN ADDRESS, STACK POINTER, BASE POINTER between the PROLOGUE and the EPILOGUE.
  • Stack pointer out of range (Stack Pivoting).
  • Caller instructions are not CALL instructions (Invalid Caller )
  • Stack execution or stack returning


Demo Time:

Demo1: "A simple Stack Overflow - Jumping to 0x41414141"

    In this demo we will see a classic example of stack overflow remote exploitation.
In this simple example, we will use the "exploitme.exe" program.
This program accepts TCP connections in the 65535 port and it only answers to some specific requests.
As the "exploitme.exe" doesn't check the length of the TCP packets that will be received, if a TCP packet is greater than 1024 bytes a stack overflow will be produced and the RETURN ADDRESS of the VULNERABLE FUNCTION will be overwritten.

In the demo we can see two different behaviors:

Attack a:

  1. We execute the "exploitme.exe" program from the Windows debugger ( "ntsd exploitme.exe" command ).
  2. We attack the "exploitme.exe" program by launching an exploit that sends a crafted packet to the 65536 TCP port.
  3. A stack overflow is produced and the RETURN ADDRESS is modified with the value 0x41414141.
  4. The final result is the redirection of the program execution to the address 0x41414141.

Attack b:

  1. We execute the "exploitme.exe" program from Sentinel ( "sentinel -e exploitme.exe exploitme.exe" command ).   As a detail, "exploitme.exe" is repeated 2 times because we want to protect the program too, we don't want the basic level protection only.
  2. We attack the "exploitme.exe" program by launching an exploit that sends a crafted packet to the 65536 TCP port.
  3. A stack overflow is produced and the RETURN ADDRESS is modified with the value 0x41414141.
  4. The final result is Sentinel intercepting the stack overflow and stopping the exploit, then it asks the user if the program should continue.

From the attacker’s point of view, the difference between the 2 attacks is that the first one was SUCCESSFUL because the program execution could be redirected but, in the second attack was NOT !

In the "attack b", Sentinel's success is because all PROLOGUES and EPILOGUES of the DETECTED FUNCTIONS are hooked by it and it's easy to detect modifications in RETURN ADDRESSES.

It's important to note that Sentinel doesn't need the program’s source code to protect it, because it takes an analysis of the binary program in runtime.
On the other hand, it's necessary to understand that the analysis is not perfect and sometimes Sentinel may not identify some program functions and leave them unprotected.

Watch part 1 of the demo.
http://youtu.be/8YjQB1Nvznk


Demo2:
"A Very Real Attack - Adobe Reader ToolButton Use-After-Free (CVE-2013-3346 + CVE-2013-5065)"

    In November 2013, a crafted PDF file with a double-exploit attack was found in the wild.

This crafted PDF file exploited a fixed vulnerability in Adobe Reader 9.x to 11.x (http://www.adobe.com/support/security/bulletins/apsb13-15.html).
As a second stage, to bypass the Reader sandbox, this double-exploit exploited a second vulnerability located in Windows kernel ("Kernel NDProxy Privilege Escalation Vulnerability" - CVE-2013-5065).
At that time, the "NDProxy" vulnerability was unknown.

Microsoft decided to publish a fix for this bug this month (https://technet.microsoft.com/en-us/security/bulletin/ms14-002).

In this video we can see how Sentinel stops the "Adobe Reader ToolButton Use-After-Free" (CVE-2013-3346) exploit.

The exploit is detected when it starts to take control of the Adobe Reader program through ROP by jumping to the "kernel32.CreateFileMappingA" function.
During the attack, the exploit heaps spray the program memory to fill this with predictable data.
Once the data is mapped in the HEAP of the process, the exploit changes the stack pointer pointing to the heap (Stack Pivoting).
Sentinel's key to stopping this exploit is when the "kernel32.CreateFileMappingA" function is called.
Sentinel checks if the memory range where the stack pointer is pointing is VALID.

In this case, the stack pointer is pointing to 0x0c0c0c18 ... obviously out of range !

If you want to see more details about this double-exploit, you can see here.

Watch part 2 of the demo.
http://youtu.be/mbiWPHkbtxM


Final notes:

    In general terms, we can say that many binary exploits working in the wild could be stopped by using some exploit mitigation tool.

Because of that, it´s important to mention that control checks implemented by mitigation tools are not impossible to bypass and attackers with good expertise level could exploit applications even if they are protected.

If you are interested in another exploit mitigation tool, you can see EMET by Microsoft (http://technet.microsoft.com/en-us/security/jj653751).

Nicolas Economou