Wednesday, March 27, 2013

Vulnerability Classification

During the past few days I had the opportunity to talk about security for entire days with amazing and passionate guys. I had a great feeling about the group in which I was, and a great feeling about every single person belonging to that group. During our discussions some folks asked to me very complex questions that I was not able to properly answer because the complexity. So I decided to write a quick'n dirty blog post for every question I think I let opened or partially opened.

Today I 'm going to dig a little bit into Vulnerability Classification.
Historically vulnerabilities have been classified in broad super set such as: buffer overflows, format string vulnerabilities, and integer type range errors (including integer overflows). These broad categories have two major failings, however. First, it is not always possible to assign a vulnerability to a single category. Second, the distinctions are too general to be useful in any detailed engineering analysis.

Quoting an example from: "A structured Approach to Classifying Security Vulnerabilities" (Cert 2005) the following function contains two vulnerabilities.
Len1 or Len2, could be negative -- bypassing the logic of the program -- and both the functions strncpy(..,..,..,) and strncat(..., ..., ...) suffer of buffer overflow. The question raises natural : is this function classificable as an "integer range check" vulnerability or as a "buffer overflows" vulnerability? Can the function be classifcated as both of them ( integer range check vuln and buffer overflow vuln) ? In this last case, do we need to provide "ranges and indicators" to exactly point to the vulnerability offset in order to distinguish the two vulnerability sets? Is this the best approach ? Generally speaking when the "science" classifies something it never split the "classified object" into primitive subst of objects, but contrary it collects as many proprieties as it can from the "classified object" in order to build an unique "signature" able to identify it. 

For example if we consider the science of systematics it does not classify a cat into multiple cathegories because has a tail, 4 legs and 2 eyes, but it classifies the cat because his biological composition. Indeed the alligator has a tail 4 legs and 2 eyes but it's obviously different from a cat!

What we need is to switch to taxonomies to be able to classify vulnerabilities in a way to be useful for engineers and enough general to wrap all the known vulns. The Program Analysis (PA) study is one of the first taxonomies approach applied to vulnerabilities classification. Following the RISOS study Matt Bishop in his report: "A Taxonomy of UNIX System and Network Vulnerabilities" described six vulnerabilities classification schemes .
Those graphs show the frequencies of flaws in each of the six classification schemes used in Matt's paper. CERT did a great job in vulnerability taxonomies as well as Anil Bazaz and James D. Arthur did in their paper titled "Towards A Taxonomy of Vulnerabilities". The following image shows a subset of the CERT taxonomy:
According to the CERT taxonomy, four are the main root causes of vulnerabilities: Design errors, Implementation errors, User interface and Other problems. In this picture only a subset of the implementation errors is showed. "Design errors" might relay to absence of designed patterns, "user interface" might relay on weak protection and "other problems" might relay on physical protections and so on..
Vulnerability classification is not an easy "field". It's not enough to say "buffer overflow", " format string" and "integer overflow" anymore -- -- -- to properly classify vulnerabilities. We need to keep in mind that researchers made great taxonomies to make class of vulnerabilities and to help engineers to recognize all the possible available solutions. 

Sunday, March 17, 2013

Nozzle and BuBBLE: a trick to JUMP them!

It is a busy time for me and as you see I rarely find time to write on my own blog, but as promised in the past I'll keep on posting some of my notes. Today, for example, I want to stare a nice trick to bypass Noozle and (theoretically) Bubble; two of the most used anti heap spray techniques. Both of the techniques aim to block the "Heap Spray payload delivering". While Noozle recognizes a sprayed payload and block it, Bubble blocks the execution of the payload by messying up the memory.

Lets start to keep a quick and dirty look into the "Heap Spray Payload Delivery Technique". The following image shows how the payload is delivered through the "spray" technique.
Payload Delivering technique: Heap Spray (From Microsot Noozle paper)

The attacker delivers to the target machine a significant number of payloads composed by a NOP sequence (white in the picture) and a final Shellcode (red in the picture). In order to guarantee high performances the kernel allocates memory randomly (ASLR) BUT in organized and atomic blocks.  Dependining on the memory blocks size it happens to have contiguous payloads.  Once the payloads have loaded into the memory the attacker needs to "fire" one of them by pointing EIP to the top-level addressese (NOP) which will eventually take the CPU to execute the desired Shellcode. 

A full attack scenario follows three main steps:
  1. Spray the Heap. Dinamic memory allocation. Fiilling memory with NOP+Shellcode
  2. Trigger the bug. Firing UP the bug to get a pointer.
  3. Control \xEIP to point to the Heap. Making the pointer "pointing" to the memory heap.
One of the most classic way to Spray the heap is to use scripting laguage such as: javascript for spraying browsers or  PDF readers, VBA macros for spraying Microsoft Office suite, ActionsScriptins for spraying Adobe Flash, etc...  One of the most famous (IE6/IE7) script used by attacker all around the world is the following one (I don't know who the author is)

Spray Heap commonly used scripts, from spray2.html (exploitdb)

The anonymous script will produce a heap layout like the one showed in the next picture where  the big yellow section (in the bottom of the memory graphic visualization)  represents the contiguous payload (NOP+Shellcode) just allocated in the memory  (memory array variable in the script):


 
An example of how to trigger the payload generated by the anonymous script, using SEH chain  could be the following:
Example of Payload using SEH chain technique. Add NOPs in the first JUNK section to have more chances to get it.

 A wrong access to the RET address  (\xff\xff\xff\xff) raises the SEHandler which points directly to the memory heap (which is randomized but always on top of the stack ... top = lower addresses...) where is located the payload. From the attacker prespective it is enough to find out a NOP in the memory heap. The NOP sleed will take the CPU to execute the desired payload.
 
According to the paper: "Noozle: A Defense Against Heap-spraying Code Injection Attacks" by Paruj Ratanaworabhan et Al. it possible to exploits the pattern used by memory heap sprayers against themeselves. Common "sprayers" (like the script above) allocte high memory content, one close to the other, filled by NOPs and Sellcodes.

Noozle system architecture, From Noozle paper by Microsoft
The previous image represents the Nozzle architecture. Noozle parses and detects memory alloctions before letting them free in the Browser heap. This security layer introduced in IE8 does not reduce the overall process speed and it's totally transparent to the user. If the Noozle's detectors find a payload according to the described pattern, the running script execution is blocked. Contrary if not patterns have detected the content is freely available to the application heap.
 
Another gret example of how to prevent  memory heap spraying implemented on Mozilla Firefox is called BuBBLE. Introduced by Francesco Gadelata et Al in 2010 it changes the way javascript writes strings in the memory. The following image shows what a delivered payloads becomes after BuBBLE messed up with it

BuBBLE memory transformation (From Bubble Paper, ACM)

 
 
Aim of this contromeasure is to change the way javascript strings are dinamically allocated in the memory. As the image shows it gets hard from the attacker to address the exact point in the heap since NOP chain is interrupted by BuBBLE.

Both of these techniques are very effective in modern browsers, but what if do we introduce smaller payloads within further jump instructions? In other words; what if do we add a "jump to a further small payload" in addition to the NOPs chain ?
 
The following image shows an example of this trick. The delivered payload -- which uses a ROP chain to bypass DEP/Nx protection-- bypasses Nozzle detectors since the NOPs chain is reduced and jump statements have used. I decided to introduce ROP chain in this example just to let you know the techniques are componible and can be used toghether. For more information about ROP here.
 
Example of possible delivered payload to bypass Noozle
 
 
 This technique is about reducing the payload size and the number of NOPs in memory. Splitting the payload into multiple smaller payloads chained together through a forward JUMP. Statistically speaking the most probable address in which to JUMP is on \0x0c0c0c0c. Why this is the most "probable" address is not scope of this post. I might have time to describe the most probable addresses (\0x06060606, \0x08080808, \0x09090909) in future posts.
 
In this post another great example on how "security" follows "hacking" and on how security following hacking failed and will fail again. I do believe that Security should prevent hacking and not following it; more research on how to prevent Heap Spraying Technique is needed.