Sunday, November 27, 2011

POP POP RET: SEH Exploiting process

This morning I want to talk a little bit about Structured Exception Handling (SEH) exploitation. Some readers, during a Skype meeting early last week, pointed me out that I never wrote about it, se lets talk a little bit about it.

First of all SEH is a piece of code written in the application with the purpose of dealing with exceptions. Each exception is a special event that interrupts the "normal" program behavior, and it mostly happens during errors and/or unexpected behaviors. Writing exception handlers are  one of the "best practice" in software engineering. Each exception handler, once compiled from the favorite language,  is mapped into the stack in 8 Bytes divided into 2 pointers.
  1. Pointer to the next "exception registration" structure. This pointer is only used in case of the current handler is not able to catch the exception.
  2. Pointer to the actual code. This pointer points to the actual code of the current handler which tries to handle the happened exception.
The following image (click on it to make it bigger) shows how the structured chain is build over the stack

Image from Corelan

Obviously from the attacker point of view, overwriting SEH pointers could mean hijacking control flow and/or executing arbitrary instructions. So the first question to be answered is: where is place the SEH chain in the stack layout ?  The following image (click on it to make it bigger) shows where SEH chain is placed.

Image From openrce

As you can note in (%EBP - 12) is placed the SEH Handler while in (%EBP - 16) is placed the Next SEH Frame. It seems pretty easy so far right ? But in the reality there are a couple of protections that must be investigated:
  • XOR. Before the exception handler is called all the register are cleaned (xored each other) 
  • DEP and Stack Cookies Stack Cookies or Canary words are setup. DEP or NX bit set to 0 (non executable area) 
  • SafeSEH Saves and checks the original value of SEH. If it has been overwritten SafeSEH brings it back to the original value. 
 Those actions make difficult the exploiting process to SEH chains. I am not going to talk about DEP, I've been widely discussed about it in these posts, so lets see what we have so far:
Firstly we cannot jump to the stack, the registers are "XORed", so we cannot use the JMP to Register technique to point to our shellcode or to our PAYLOAD. BUT, we can overwrite SE Handler address. The OS knows the exception handling routing so it will pass the control flow to the next SEH record. We need to make the pointer to "next SEH" bringing us to the injected Shellcode.

In other words, the injected PAYLOAD should follow these steps: 
  1. Cause an exception. Without exception the SEH handler won’t start. 
  2. Overwrite the pointer to the next SEH with some jumpcode (to make it jump to the shell code).
  3. Overwrite the SE handler with a pointer to an instruction that brings the control back to next SEH executing the jumpcode. (The shellcode should be directly placed after the overwritten SE Handler)

The following image (click on it to make it bigger) shows how to implement the SEH Exploiting process (from this image you can understand the post title)

Again, the attacker needs to force an exception (by injecting the PAYLOAD). The exception causes the execution of the current SEHandler. The current SEHandler has been replaced by the attacker to make a short jump ( If DEP then Gadget to POP POP RET) to the pointer to the next SEHandler which point to the injected Shellcode. In the previous image it has been assumed an active DEP protection and for that the Current SEHandler points to a POP POP RET gadget which increments %SP and returns to the next SEhandler pointer which it points to the injected Shellcode. Before ending up I want to thank you corelan team which provides to me a lot of great material such as: images, ideas and from time to time good suggestions ! Thank you Corelan, you are doing a great job !

That's all for today.

Sunday, November 20, 2011

ruCTF2011 - ESP(CardGame) Exploiting Process-

During the past ruCTF I found particularly interesting the ESP (CardGame) exercise. ESP is a java implemented client-server  card game, in which you have to find the correct ascending sequence of the displayed cards. 

As usually happens during the exploiting process the attacker needs to understand how the software correctly works. So lets try to play some games and lets find out where the game provides us the flags we need to win the challenge. The flags are provided only when you correctly order all the 54 cards in the deck. 

Once understood the game we are ready to decompile our code. Using JAD and handily parsing the decompiled JAR files we want to focalize our attention on two classes: 
  1. CardGameClient.jar -> org.ructf.cardgame.client -> CardGameClient.class
  2. CardGameServer.jar -> -> CardGameProtocol.class
The first interesting class "CardGameClient.class" is called by the CardGameClientApp for initialize the game an it's called each time the user clicks on a given card for picking up a card. The following image (click on it to make it bigger) describes the starting game procedure. I used 3 colors in order to distinguish between:

  1. Bytes sent (RED color)
  2. Bytes received (GREEN color)
  3. Bytes processed (BLUE color)
The first action performed by the startGame() function is to send to the CardGame Server the byte representation of the "reset" string.  After sending the "reset" string, the application sends the byte representation of "PLAY" and gets back a stream of bytes that calls deck1. Immediately after, the application uses an internal function called shuffle() to (try to guess :) ) shuffle the received deck, it creates a key vector of 20 randomly generated bytes (chars lower and upper case, no number nor symbols) it encodes the received deck (deck1) and it sends to the CardGameServer the encoded deck1.

CardGameClient waits for another incoming stream of bytes that calls deck2. It decodes deck2 by re-using the "single key" generated randomly in during previous deck (deck1). Now it generates a new key vector by randomly generate 20 bytes for each card (54 is the size of the deck) like in the previous key vector generation. It now encodes the second deck (deck2) using the new key vector and sends it to the CardGameServer. Finally it decodes the deck2 and keeps it clearly into the memory for later. 

This was the initialization of the game. Now lets see the main game function: playgame(). 
The following picture shows the game procedure playgame().

The palyGame procedure sends to the CardGameServer the byte representation of the "PICK"  string followed by:  a number, representing  the picked card,  and 20 byte representing the key to be used to decode the card symbol. If the picked up card, decoded through the given  key,  matches to the one in the server, the server sends back to the CardGameClient application the string "LUCK" (number 3, in the previous picture). If the user picks up all the 54 cards in the deck in the right order the server sends back to the CardGame Client the string "WIN" followed by the Flags we need. This is easy understandable from the CardGameServer.jar -> -> CardGameProtocol.class.

Now we know how the game works. What we need is to find a way to cheat the CardGameServer in the way we always reach the state "WIN". There are plenty of ways to cheat this CardGameServer, but my favorite one is based on the key generation procedure. In few words...  both of the key vectors, but most important the second one, is randomly generated in the client procedure ( code lines number: 4 and 7 in the starGame procedure ) what if we generate a static string that encodes and decodes each card ? If you do like that you are breaking the assumption of picking up the card in the right order.  Since the key vector is associated to a specific card order, and each entry of the key vector is randomly generated, if you put to each key a fixed 20 bytes sequence it doesn't matter what card you choose because every card has been encoded with the static 20 bytes sequence. In other words whatever you choose will always be decoded in the server side, and it will result as good as if you really picked up the right card.  Following my exploit.

I decided to implement a small CardGameClient using Java technology. I decided to use Java because I was able to reuse all the libraries and the decompiled code without write it from scratch. The following image shows my startGame() procedure

I used a fixed single key "ciao" to exchange the first deck. I later on used a single 20 bytes string ( "aaaaaaaaaaaaaaaaaaaa" ) to populate the key vector . I finally implemented a loop over the 54 cards (DECK_SIZE) to get 53 "LUCK" strings reaching the "WIN" state and getting from the server side the Flags.

This little CardGame Client was always winning. How to fix it up ? Well, the right way should be to invert the paradigm of the key generation. Instead of letting the client to decide the key vector the programmer should let the server to shuffle and to generate the key vector. I am not going deeper in this, since the post is already pretty big and probably everybody is getting bored :( . I'll post my impression on ruCTF later in another post.

Monday, November 14, 2011

Thread Injection

Today I suggest this short but intensive ( :D ) reading. It's a simple tutorial for thread injection in x86 systems. I believe it is useful for everybody likes thread hijacking . It shortly describes 7 simple steps to attack a generic running process  by showing code examples to make the reading even faster.
Here the seven main steps:
  1. Detect the target process
  2. Identify the main thread
  3. Suspend the main thread
  4. Obtain the thread content
  5. Create the "code-cave" (the code to be injected)
  6. Spoof the %IP and hijacking control flow
  7. Resume the thread, continue execution and free the memory

Friday, November 4, 2011

Global Offset Table Injection Procedure

Have you ever thought about how a program can call external functions ? Lets say we have a classic printf() which is imported from "libc" how does the program know where exactly printf() is located into the memory ? Well the answer in the Global Offset Table. The following sketch sows how the calls between external function work:

In other words the Global Offset Table redirects a position independent address calculations to an absolute location and is located in the .got section of an ELF executable or shared object. It stores the final (absolute) location of a function calls symbol, used in dynamically linked code. When a program requests to use printf() for instance, after the rtld locates the symbol, the location is then relocated in the GOT and allows for the executable via the Procedure Linkage Table, to directly access the symbols location. For a complete resource about ELF and its sections I suggest to take a look here, you want find many useful references such as: blog posts, articles,  books and papers. But this post is not about describing ELF, GOT or PLT it's about describing a procedure to redirect control flow by injection code into the GOT table.

Lets assume to have the following function (click on the image to make it bigger) in a give program. The program copies one input parameter to a support buffer following a given offset. The execution string looks like: program.o 4 30 AAAA. Basically 4 is the number of bytes to be copied into the destination buffer (size [256]) 30 is the offset from the beginning of the destination buffer and AAAA  is the data to copy on it.

The external function that we want to follow is the "puts()" function. The  GOT table will be "filled" dynamically during the execution so lets see what happens by running the system. Breaking on main():

Disassembly the "main()".

The puts() function is reached by the "callq  0x100000e8a ".  Following 0x100000e8a address we see the PLT pointing to the GOT table. Lets see the dynamic pointer *0x1b2(%rip) . PLT table is on 100000ea8.

The program itself prints out to the buffer address in which the data should be copied. (0x66f37a60). A little bit of hexadecimal math: just remember we got the memory address in which we want to inject our data (AAAA) placed into 0x100000e8a and we have the buffer address in 0x66f37a60. And here we go !  A nice and easy segmentation fault ;D !!

This post shows a quick'n dirty procedure on how attackers could manipulate programs control flows by injecting address/code into the GOT table. Don't take it as a tutorial or a guide but as simple and fast way to sum up the entire procedure. 

Tuesday, November 1, 2011

Does AV really increase security ?

From a user point of view any AV increases the security of his system since it's a defense mechanism able to detect and to block most of the known viruses affecting Internet. But let think the other way around, what is an AV from a ROP expert ? Since every AV is at least one running processes within loaded libraries and imported functions it is an additional component where to look for Gadgets. During the past days I've been installing some of the most used AV (trial commercial versions only) and I investigated the distribution of the Gadgets that such AVs introduce into a running Windows XP system.

The above picture (click on it to make it bigger) shows the gadgets distribution ordered by gadget's length. The smallest gadget found is composed by one operation (RETN) while the biggest one is composed by 15 operations. The analyzed AVs (Avast, AVG, Avira, kaspersky, ThreatFire and TrendMicro), as shown in picture, share the same distribution even if in different quantity. The picture also shows how similar the analyzed AVs are from the attacker (ROP expert) point of view. The attacker assuming the AV presence might ignore what kind of AV is (except for TrendMcro which provides lot of help to the attacker, letting he to choose between a wide amount of gadgets). These are only few preliminary results of what I really found. I'll be back with more details on that in next few months (I have to analyze tons of data and to figure out similarities and differences ).