Tuesday, December 27, 2011

Yes, it still happens: FreeBSD Telnet BOF

Buffer Overflows has been one of the major cause of exploiting during the past years, many remote exploits, malware and viruses took advantage from this technique to keep the control of a target machine. I am not going to write about Buffer Overflows, I've been widely discussing this topics in several past posts ( just take a look here) but here I want to discuss how this vulnerability still infects many softwares including amazing project like the FreeBSD Operative System.

The telnet's bug is place into the file encrypt.c which defining a key_info struct with a fixed length buffer of 64 bytes to hold the key id passed by the telnet client, does copy the passed data into the key_info struct using memcpy without any restriction on the length specified by MAXKEYLEN. Following the bugged code:


This code is almost 20 years old and it is pretty interesting that nobody discovered it until the 2011 Christmas's eve. And yes... Apple is vulnerable too (take a look here). The simple but well written exploit made by PainSec is available here. Attackers used a "/bin/sh execve() shellcode " as shown following:


And filled the buffer in the most classic way:


Again another BOF example to show to everybody thinks that Safe Libraries, NX/DEP, ASLR, StackGuard and Canaries resolved the security Buffer Overflow problem. I do not believe it will be easy to solve in a permeant way this problem that afflicts security since the beginning of such a field.

To have more details of the telnet code go here.

Wednesday, December 21, 2011

IDA FindCrypt

Finally a great IDA Plugin for Cryptography. Often we'd like to know what kind of cryptographic algorithm has been used in the binary we are analyzing: FindCrypt comes to help us ! The idea behind this Plugin is pretty simple: since almost all cryptographic algorithms use magic constants placed inside the binary, FindCrypt just looks for these constants in the program body.
"This approach will fail if the S-boxes have been altered but in most cases they are untouched (can you admit that you understand all consequences of modifying an S-box, say, in AES?)"
 The plugin supports the following crypto algorithms:

  • Blowfish
  • Camellia 
  • CAST 
  • CAST256 
  • CRC32 
  • DES 
  • GOST 
  • HAVAL
  • MARS 
  • MD2
  • MD4 
  • MD5
  • PKCS_MD2 (byte sequence used in PKCS envelope) 
  • PKCS_MD5 (byte sequence used in PKCS envelope)
  • PKCS_RIPEMD160 (byte sequence used in PKCS envelope)
  • PKCS_SHA256 (byte sequence used in PKCS envelope) 
  • PKCS_SHA384 (byte sequence used in PKCS envelope) 
  • PKCS_SHA512 (byte sequence used in PKCS envelope) 
  • PKCS_Tiger (byte sequence used in PKCS envelope) 
  • RawDES 
  • RC2 
  • RC5
  • RC6 
  • Rijndael 
  • SAFER 
  • SHA-1 
  • SHA-256 
  • SHA-512 
  • SHARK 
  • SKIPJACK 
  • Square 
  • Tiger 
  • Twofish 
  • WAKE 
  • Whirlpool 
  • zlib
The Plugin is very simple to be used just select it from the Plugin menu and it will do its job ending up with the following window:


It will also rename the constant arrays and it will put them in the marked location list. I definitely suggest this great Plugin to everybody who's working in reversing engineering. Good joob Guilfanov ! Download it directly from here.

Monday, December 19, 2011

Book Review: A Bug Hunter's Diary

It has been asking my personal revision on the Tobias Klein's english version of "A Bug Hunter's Diary" book. As the title suggests "A Bug Hunter's Diary" is not a normal book, it's not a manual or a guide to exploiting it's a new way to interpret the bug hunting teaching process. It follows the "blog paradigm" where the author seems to talk to his personal diary, just for personal memories and not for relating or for writing a book. Each chapter begins with the "Dear Diary" sentence , the language is technical but simple, the text is essential: no additional adjectives or related stories to support to the main concepts.  The writer style is very clear, everybody should be able to understand what Tobias is talking about, the text form follows a standard path, after a couple of chapters the reader enjoys it because he  will known exactly where "he is" and where the text "is going to take him".


The First chapter (Bug Hunting), is the weakest section of the book. It is a small chapter introducing the bug hunting process as well as some basic security concepts such as the necessary tools, well know hunting  techniques, and best practices. Under my personal point of view this chapter should be much more elaborated then the current one by going deeper into the details giving to the reader much more background for better understand the following chapters.

The Second chapter (Back to the '90s) shows the abilities of the writer in going straight into the core arguments with no unnecessary words or sentences. Every section is well written with the less possible words letting an avid reader going directly into the main aspect of the problem without being distracted from additional contexts. This chapter walks through the first vulnerability of the book: VLC TiVo demuxed stack overflow.

The Third chapter (Escape from the WWW Zone) explains the entire process to exploit the Sun Solaris IOCTL Kernel NULL pointer dereference. In my personal opinion, this chapter is the most valuable one since it describes with meticulous details (but always without unnecessary words or sections) a quite rare exploit. Sun solaris resources are pretty rare and difficult to be documented since the referenced platform is not well known as Microsoft or Linux are.

The Fourth chapter (NULL Pointer FTW) walks through the famous FFmpeg type conversion vulnerability. While the chapter and the vulnerability, under some aspects, could be compared to the first chapter, I believe that this is one of the most didactic chapters of the book. The writer shows a mature writing in describing his steps, in particular I am referring to the steps 2 and 3 where the author with extremely mastery explains firstly how is made the  srtk chunk layout and secondly how to manipulate it.

The Fifth chapter (Browse and You're Owned) shows the WebEx meeting manager activeX stack overflow.  Probably the easiest to read chapter. I personally don't get why the author preferred the use of WinDbG rather then Immunity debugger which has a lot of scripts and plugins ready to be used which might help a lot the reader.

The Sixth chapter (On Kernel to Rule Them all) walks to the Avast! kernel memory corruption vulnerability disclosed here. This is one of my favorite chapters. The author shows his confidence in finding vulnerabilities in IOCTL handlers. Probably the most complete, technical and difficult to follow chapter.

The Seventh  chapter (A Bug Older Than 4.4BSD) shows another really interesting Kernel vulnerability  against XNU

The Eight chapter (The Ringtone Massacre) is the last book's chapter. The author ends up in the mobile world walking through a classic buffer overflow found in IOS (from 1 to 3.2.1) AudioToolbox library.  The beauty of this chapter is in the way the stack buffer overflow is applied to the mobile world and for this reason I consider it as "innovative chapter" perfect to be the conclusive chapter of this book.

The book presents three didactic appendixes titled: Hints For Hunting, Debugging, Mitigation.


Conclusions:
I did enjoy reading  this book. I did enjoy the way the book is written, it's pretty different from the books I' am used to read and I think this new way to report, pretty close to a blog, is immediate and effective. The book amazingly describes the way the author hunts the bugs and take them into vulnerabilities. I would definitely suggest this book to everyone is interested on "touch with hands" the real words exploiting processes.


Thursday, December 15, 2011

Testing ASLR on Linux Kernel 2.6.38 and Lion

This morning I'd like to share some results on two Asynchronous Space Layout Randomization implementations: in particular on Linux Kernel 2.6.38 and on Darwin 11.2.0 Lion. I am not getting into the details about ASLR, I've been writing a lot in past blog posts and journal articles  about this topic ( for example here ), but I want to share a little study of their randomization. The goal of this early morning hour is to build a simple but relevant randomization statistic about these kernels, proving their differences.

I started by writing a simple program like the following one:

#include
int main(int argc, char **argv)
{

unsigned int ebp;
asm("movl %%ebp, %0\n":"=r" (ebp));
printf("Current ebp: 0x%x \n", ebp);
return 0;

}

It takes %ebp and prints it out. I run it one Million of times putting the results into a .txt file ready to be processed through my favorite spreadsheet. Here the results . More then one Million of tests only few duplicates, and very high entropy functions as shown following.





Wednesday, December 14, 2011

From ROP to JOP

Researchers from North Carolina State University and National University of Singapore presented an interesting paper to ASIACCS11 titled: "Jump-Oriented Programming: A New Class of Code-Reuse Attack".


The previous image (click on it to make bigger), taken from the original paper, shows the differences between the well known Return Oriented Programming and the new Jump Oriented Programming. As in ROP, a jump-oriented program consists of a set of gadget ad- dresses and data values loaded into memory, with the gadget addresses being analogous to opcodes within a new jump- oriented machine. In ROP, this data is stored in the stack, so the stack pointer esp serves as the “program counter” in a return-oriented program. JOP is not limited to using esp to reference its gadget addresses, and control flow is not driven by the ret instruction. Instead, JOP uses a dispatch table to hold gadget addresses and data. The “program counter” is any register that points into the dispatch table. Control flow is driven by a special dispatcher gadget that executes the sequence of gadgets. At each invocation, the dispatcher advances the virtual program counter, and launches the as- sociated gadget.

This new way to see reusable code exploitation makes the use of  three main actors: (1) the dispatcher, which has to hijack the control flow by jumping to different entries on the dispatch table, (2) the dispatch table which has to wrap out gadgets addresses and data/padding, and finally (3) the gadget catalog, which contains the effective code to be executed. Gadgets are not terminating with RET as we were accustomed, but with JMP to the dispatcher. A dispatcher example could be:

add %ecx, 4
jmp %[ecx]

Each time it is executed it jumps to the next gadget  (+4 bytes) through the dispatch table (base address on %ecx).  Each time an addressed gadget is executed it ends with a jump to the dispatcher, in this way a jumping chain is built.  The paper follows on describing a MOC example and providing algorithms to find JOP gadgets. 

I did like this reading and I do suggest it to all the interested security guys that are reading my post,  but I have some issues on believing the real implementation of the dispatcher. As you might see the dispatcher increases the jump offset by a fixed step, this assumes that the respective gadgets don't use data or  at least use a fixed number of data (variables). This is highly impractical in a real exploitation scenario in which the attacker needs many different gadgets which use respectively different quantity of data. I have made here a simple explanation to what I mean.

Sunday, December 11, 2011

ETTERCAP is still alive

As many of you might know, Ettercap has been one of the most important tools during the past decade. It was one of the most powerful, fast and easy to use "man-in-the-middle" attacks tools. When it reached it first "NG" version during 2004 it was able to automatically decrypt WEP packets, to perform ICMP, DHCP and DNS attacks and it was able to sniff many of the most used protocols grabbing credential, certificates and symmetric encryption keys.


It has been six year since Ettercap developers released the last update.  But in these days 11-12-04 a new version of Ettercap (0.7.4 - Lazarus) became available. This version fixed a lot of Buffer Overflows bugs and made Ettercap compatible with mac OS X Lion and 64bit architectures.

I think Ettercap developer team is not anymore the same of six year ago, but I totally encourage these new guys to bring it to a new life implementing new features such as HTTPS stripping, WPA 3-handshake sniffing, etc. Keep up the good work guys.

Saturday, December 3, 2011

iCTF2011 experience

Yesterday I participated once again to the iCTF organized by UCSB. For everybody who does not know what this event is about:

The Capture The Flag contest is multi-site, multi-team hacking contest in which a number of teams compete independently against each other.
In traditional editions of the iCTF (2003-2007), the goal of each team was to maintain a set of services such that they remain available and uncompromised throughout the contest phase. Each team also has to attempt to compromise the other teams' services. Since all the teams received an identical copy of the virtual host containing the vulnerable services, each team has to find vulnerabilities in their copy of the hosts and possibly fix the vulnerabilities without disrupting the services. At the same time, the teams have to leverage their knowledge about the vulnerabilities they found to compromise the servers run by other teams. Compromising a service allows a team to bypass the service's security mechanisms and to "capture the flag" associated with the service.
For the past three years (2008, 2009, and 2010), new competition designs have been introduced. More precisely, in 2008 we created a separate virtual network for each team. The goal was to attack a terrorist network and defuse a bomb after compromising a number of hosts. In 2009, the participants had to compromise the browsers of a large group of simulated users, steal their money, and create a botnet. In 2010, the participants had to attack the rogue nation of Litya, ruled by the evil Lisvoy Bironulesk. A new design forced the team to attack the services supporting Litya's infrastructure only at specific times, when certain activities were in progress. In addition, an intrusion detection system would temporarily firewall out the teams whose attacks were detected.  (from here)

iCTF namely: "international Capture The Flag" is only one of the many capture the flags (FTC) happening over the year. Here you might find some of the most famous ones. This year iCTF was organized in a amazing way, plenty challenges (to get money), and plenty services to exploit (to get flags in order to convert money into points). Finally the winners were We_0wn_Y0u while a brand new team named "More Smoked Leet Chicken" got the second place.


I've been involved in iCTF competition for several years, and this time it has been a very good organized one, but as you might see, especially if you have participated to some of them over the past years,  current iCTFs tend to go more and more far away from the original concept of hacking school. At the beginning CTFs were organized as simple challenges, in which participants should solve different kind of problems in order to get the flag. For example teams should solve problems like: forensic, reverse engineering, trivial questions, patching bugged code, etc. All these problems were very close to what is the global concept of cracking.  Some years later the so called "offline CTFs" became what we call nowadays the "online CTFs" where hacking teams fight each other by pawning the attacked team's online services in order to get the flags. This kind of challenges are pretty close to what people call hacking. 

Yesterday, everything was much more complicated. "Offline challenges" to get money (the "cracking" side of the hacking competition). "Online attacks" to convert money into points (the hacking part of the hacking competition) and a linear function that modified the value of the money depending on several parameters. In other words, if you got 100 dollars and you want to change them, the value of the change from dollars to points was different depending on the current value of the given function. So, if you got a lot of money but if you don't submit them in "the right way", you are going to loose them. This was more like a linear problem solving. The result was that pretty good hacking teams, pretty good to solve challenges and pretty good to attack services got high amount of money, but since not prepared to solve dynamic linear programming problems got very very low scores. The result has been that pretty good hacking teams not reached hight score, this happened because some of the good teams were not prepared to solve linear programing problems during the runtime competition.

In my personal point of view (which of course it could be wrong) CTFs are getting harder and harder but not in the direction of hacking, in the direction of multi-disciplinarity. In other words, rather then making more and more difficult  "cracking" challenges or "hacking" services, CTFs are increasing  the difficulty by increasing the number of "things to do" during the competition. So CTFs are not working to increase the quality of hacking but are working to increase the quantity of taksI am not saying that this is bad. Not really.... don't write me emails about that. After all CTFs have been made to teach people security,  and more different people CTFs can involve more reached is the original scope. But again, following this way, the risk is to promote the quantity (of thins to do, of people, of tasks, etc..)  rather then the quality (of hacking). Since many of the participants will be hired from companies in order to solve security related jobs, assuring the quality is an important goal.

This has been a great Capture the flag challenge, Good job UCSB security team !!