Sunday, December 29, 2013

Good Readings

During the past months I received, throught my blog, requests on what to read during winter Holidays. I decided to publish a little list on some of the books (yes, I wrote "some" and  not "all" ) that have been really useful for my carrer which I would totally suggest to everybody interested on such a field.

The following list is:  incomplete (by meaning I had to choose some of my favorite books due to time limit in post writing),"time depending" (by meaning that in few years from now the current titles could be changed due to new editions and/or the book might be outdated), and totally subjective (by meaning that I did not read all the "Sec Readings" out there, so there could be amazing books that I am not aware of). 

  1. Modern Operation Systems (Andrew S. Tanenbaum). This book will give you an entire vision on the complexity behind Operative Systems. It will give you practical examples on how to program them and how to build structured systems from "Ring 0 to Ring 3".  This is the basic reading to everybody interested on computer security.
  2. Computer Security: Art and Science (Matt Bishop). This book is considered as a milestone in Computer Security. Matt Bishop explains the basic security concepts and approaches (from definitions to criptography walking through security mechanisms) of computer security. This is the second step to everybody interested on such a field.
  3. Principles Of Concurrent And Distributed Programming (M. Ben-Ari). Understanding the cuncorrent and distribute programming could be quite  hard, but M.Ben-Ari , in my opinion, make it easy and very accessible. Nowadays many vulnerabilities are caused by poor implementation of concurrent principles. Understanding them would make you a better "security man".
  4. Penetration Testing and Network Defense (Whiteker and Newman). It might sound a little outdated (2005). But it really is not. Well, actually it is, if you consider the penetration testing "technicalities" they suggest, but from this book you wont take "technicalities" (technical details) you want to take the "method" they use. The approach they introduce in this book is still very actual.
  5. OSSTMM by ISECOM. This is one of the most famous methodologies used to perform security testing (no, I have not written penetration testing). If you feel the need to learn more about methodologies (why you will need methodologies ? You will need them once you will eventually called to manage a "Security/Hacking Team" ) you might find on my book ( "A design methodology for computer security testing" ) a good guide.
  1. The Web Application Hackers Handbook (Stuttard Pinto). This book covers a vaste area of web applications pen-test. It provides a "bite" of almost everything you might find on the web. It's a great starting point giving you all the weapons you need to get out firing. You will need further studies to become a real web tester pro.
  2. The Tangled Web (Zalewski). This book is most focused on web programmers, it covers many good practices and explains lots of basic concepts behind the web. If you need to write a Web App you want probably to have a quick look to it. If interested, have a look to my full review.
  3. Programming From the Ground Up (J. Barlett). Super boring, but really important. I personally have tried to read it as a book, but I failed. Indeed I used it as a manual from time to time.
  4. IDA PRO (Chris Eagle).  From 0 to whatever you need to know about Reversing Engineering. This would be a "cutting edge" book if you already have foundamentals on your "sholders".
  5. The Shellcoder's Handbook: Discovering and Exploiting Security Holes (C. Anley). Almost what you need to know to modern exploitation techniques. This book will give you all the sugar you need to be effective in the art of exploitation. 
  6. A Bug Hunter's Diary: A Guided Tour Through the Wilds of Software Security (T. Klain).  A really good reading. It provides a lot of real examples of how Tobias discovered some pretty nasty vulnerabilities. If interested, have a look to my full review.
  7. Metasploit: The pentration Tester's Guide (D. Kennedy). When you need automatisms and you cannot afford a manual and specific testing this book provides a great detailed view on how to use one of the "de-facto standard" penetration tester tools.
  8. Practical Cryptography (Niels Ferguson and Bruce Schneier ). I did add to my list only one book on cryptography. I decided that one because it explains cryptography as  Engineer discipline and not as Mathematical science. This is foundamental for us who need to work in the hard real world rather then in mathematical abstractions.
Managing a Security/Hacking group:
  1. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (Frederick P. Brooks Jr). When you will need to manage a group of super skilled people (Security Team/Hacking team), this book will be a great starting point.
  2. The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt, David Thomas).This is the so called "ever green" book. Everybody should read it if you are a manager or not.
  3. Agile Software Development, Principles, Patterns, and Practices (Robert C. Marting). Even if in your practical life you will be using Extreme Programming as your main "testing" and/or "development" methodology, you should know how to guide a group of people into the Agile Software Development methodology, this book shows you well how to follow this way.
  4. Getting Things Done: The Art of Stress-Free Productivity (David Allen). Another best seller. No description need for the great book of David Allen.
  5. Impro: Improvisation and the Theatre (keith johnstone). When you will start to focus on people managing rather then machines you will learn that humans are way more complex then "stack pointers" or "spray the heap", you will need to do one thing you wont do as a "pragmatic programmer", you will need to improvise !
Do those books describe everything you need to know in order to be a great hacker/Security Engineer ? Unfortunately no, not at all. Those books are only a small part of what you will need to learn. But don't warry, you do not need to read more books .. what it makes the difference is the experience. So get out here and start to get practice.

Monday, October 21, 2013

Hacking through images

It's long time I don't write on my own blog (more then two months) and if you look at the history bar on your right you will probably figure out  I am slowing down my blog posts a bit if compared to the past years. This happens due the amount of work my security team and I are involved on.

Many different and really important facts happened during the past months, from astonishing NSA revelations to huge BUGs and new Malware kit ready to be purchased. Even if there would be lots to say about all these  I will not dig into them. 

Since "things" went public today I want to share a little and dirty python script which embeds javascript code into bmp images letting those images still valid images, ready to be processed from your favorite browser. 

The following  HTML page wants to parse a bmp file and a javascript file which happen to be the same file: 2.bmp. Theoretically the file should be or a bitmap file or a javascript file. Could it be a javacript and an image file at the same time ? The answer should be NO. It couldn't. But let's see what we have.

 Executing this file you'll find out this result:

As you can see, both tags succesfully executed. The Image tag is showing the red Bitmap file and the script tag is doing its job by executing a JavaScript. How is it possible ? How did you write such a file ? The following images show more details about the dirty code who generates these beautiful bitmap files.

The creation procedure.

The  substitution procedure.

This is not magic at all. This is just my implementation of the BMP parsing bug many libraries have. The idea behind this python code is to create a valid BMP header within \x2F\x2A (aka \*) and then close up the end of the image through a \x2A\x2F (aka *\). To be a valid JavaScript file, you need to use the --not used-- header (\x42\x4D) as a variable and/or as a part of the code. This is why before the payload you might inject a simple expression like "=1;" or more commonly used "=a;" The following image shows the first part of a forget BMP header to exploit this eakness.

BTW if you want to downloade the entire code, grab it  here (pasteBIN). 

Run-it as: -i image.bmp "alert(\"test\");"

Running Example

Don't forget, you might want to use obfuscators to better hide your javascript like the following example:

python -i 2.bmp "var _0x9c4c=[\"\x48\x65\x6C\x6C\x6F\x20\x57\x6F\x72\x6C\x64\x21\",\"\x0A\",\"\x4F\x4B\"];var a=_0x9c4c[0];function MsgBox(_0xccb4x3){alert(_0xccb4x3+_0x9c4c[1]+a);} ;MsgBox(_0x9c4c[2]);"

Running a more complex Example

Enjoy your new hackish tool !

Friday, August 16, 2013

BUG in WinCalc.exe

Today I'd like to share another "funny BUG" (yep, believe me this is quite funny) through this summer time quick'n dirty post. The involved hunter is Nuzhny (no contacts provided to me, more infos here) who disclosed a Stack Overflow in Windows Calculator last week. You would think: "A BOF in Windows Calc.exe ? You're kidding me... One of the oldest executable on the Earth is still hiding BUGS on it ?". The sad answers is: "yes", windows CALC still has undisclosed BUGs at least on the following machine (in where I was able to test it).

Machine Settings:

Windows 7 Ultimate SP1 x86-64, English.

Trigger the bug:
  1. Start |-> run Calc.exe
  2. Press "Alt-2" to go to tjhe "Scientific" calculator mode ("Programmer mode" should also work)
  3. Type "1/255" and press Enter.
  4. Now press button "F-E"
Problem Signature:
Problem Event Name: APPCRASH
Application Name: calc.EXE
Application Version: 6.1.7600.16385
Application Timestamp: 4a5bc9d4
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.17725
Fault Module Timestamp: 4ec4aa8e
Exception Code: c00000fd
Exception Offset: 0000000000053560
OS Version: 6.1.7601.

The exception is unhandled at address:  0xC00000FD.

The screen-shot:
Crash after F-E representation needed.

Debugger on BUG
I'm not sure on how this bug could be exploited in the real life - right now -,   maybe it wouldn't become a vulnerability at all but what it's important to all this "story" is that no safe software in a real world exist. Even wincalc.exe, one of the most simple and most tested software of the entire software history might hide bugs and vulnerabilities. Are you still wondering why a "security source code review" is essential out there ?

Saturday, July 20, 2013

Malware Evasion Chart

Plenty of documents are describing how Malwares implement "Escape" techniques in order to evade Malware analysis. I did write posts on several of the most interesting evasion techniques ( available here and here)  adding information on my side as well.  Today I want to share a personal MAP that I made to correlate evasion techniques to detection techniques. It helped me a lot during some of my past talks as well as during my (research) malware writing nights.

Aims of the following MAP is to correlate evasion techniques to detection techniques without preteding to be "cool/graphically appealing" or "complete". It wants to be  "remind me what happens there".

Malware Evasion Chart 101 (Download PDF)
The "soul" of the entire chart is stright int the center. Highlighted in blue shape the Analysis techniques. Highlighted in red shape the corresponding evasion techniques. In separate colored boxes significant examples of evasion techniques (again, there are many many many other ways to perform debugging traps/Red Pills/etc../etc... this wants to be only a "remind").

A glimpse of content:
All the detection techniques could be clustered into two big groups: "Static Analisys" and "Dynamic Analysis". The Static analysis could be divided into "Signature" based techniques and "Decompiling" based techniques. The first set of techniques are based on signature matching. A signature is a set of bytes (not adjacent). The second set of techniques, look into binaries trying to understand behavior without running the binary on its own. These techniques are quite useful on pieces of data junk or not executable data. On the other side "dynamic analysis" where the analyst run the Malware. These techniques could be divided into "System Centric" and "Program Centric". The main difference between such techniques is the perspective. If you analyse the binary from inside you are "Program Centric" and so you might debug the bnary and/or look for internal API calls. If you are analyzing the binary from outside you are "System Centric" and you probably are sandboxing the binary.

In the example boxes you find significative pieces of code and/or softwares that are used to achieve the evasion technique. For instance in the green box named "Code not run" PEditor shows how to modify the OEP (Original Entry Point) of a program to run unaligned code. In the box named "Breaking/watching/Catching point handlers" one of the most famous signal handlers have been shown and so forth and so on.

If you find the MAP usefull, please leave a comment, if you'd like to expand it please send me an email I'd like to receive help in expanding it.

Hope you'll enjoy.

Monday, June 24, 2013

Hash Detector Tool

Since 2009 when I wrote: "The string Decoding Process" (published by hakin9 magazine) I use crafted tools to automatically decode strings (some of them have been published on this blog). Decoding strings results pretty hard especially nowadays where many encoding algorithms are commonly used over planty "daily life tools". Understanding what encoding we are facing becomes really important if we are analyzing Hashing. Let's assume we 've just got a file including hundreds of different hash strings, how to identify what kind of hashing algorithm have been used ? Having a list o hashes, that potentially could "hide" passwords or important data, having  the power of a bruteforce machine and the right tools to attack the hash list without knowing what algorithm have been used could be pretty nesty for attackers. Indeed attackers might have difficult time in attacking hashes without knowing what is the generation algorithm. 

Surfing on this "painful wave" I decided to share a pretty python code that helped me out in solving this specific problem. The script can be downloaded here (pastebin). The following image shows how simple the script is, and how could be really easy to update it within new hashing algorithms. If you are planning to add new features to the script, please give me the diff file, so that we can create a more generic tool able to detect as many different hashing algorithms as possible. (click to enlarge)

The script is quite modular and easy to update. What you need to to is to add your new hashing function within its own identifier into the "algorithms" array (lets see the following image).

Algorithms array list: easy to expand (click to enlarge)

After having filled up the "algorithms" array, you need to add the new function which finds out if the string you are processing might be generated (or not) from the hash algorithm you 've just "declared" in the "algorithms" array. The following image shows to you some examples already implemented.

Function that perform the detection (click to enlarge)

Finally, in a very quick'n dirty way you want to process the input string by adding the generated function to the main flow. 

Adding functions to control flow (click to enlarge)

Hope it could be useful to everybody, enjoy your new hash detector tool !

Sunday, June 16, 2013

ZeuS Evolution: it's time for P2P and RSA.

Today another "Hack Note" on my blog to point you out to a great analysis of ZeuS evolutions. I definitely suggest the reading titled "ZeuS-P2P" by Cert Polska because, in my personal opinion, it describes one of the most important evolutions of a "bot kit" happened so far: the distribution of the Command aNd Control (CNC) module. As you might remember the CNC modules evolved from single access point (such as IRC, Twitter, FaceBook, and so on) to multiple access points (often by implementing a Domain Generation Algorithm, DGA), in where attackers had a bounch (~1000)  of domains to generate and/or to compromise in order to spread commands to the infected hosts. The last ZeuS versions have been using a nice alternative: the P2P protocol. Specifically ZeuS bot-kit has been using a P2P protocol very close (in term of code) to Kademlia (xor map based). The following image taken from the aforementioned document written by Cert Polska, nicely illustrates the flow between the attacker and the attacked user.
The paper follows on describing interesting detatils about the new "ZeuS generation malware" including (decompiled) source code and highlighting interesting sections such as:PROXY_SERVER_HOST string replacement, DDoS module, HTTP DDoS variant module, DhTUdp DDos, Digital Signature verification (another great improvements respect to the "OLD versions"), and so on. Aditionally fully reversed-engineered P2P protocol can be found on a dedicated chapter. Have a nice reading !

Sunday, May 12, 2013

Firmware Hacking: The Samsung smart TV turn

Tooday I want to share a little experiece I had in reversing Samsung Smat TV's Firmware. I am not going to explain every step in details but I just want to give an idea on how it's possible to perform a reverse engineering process starting from a firmware self-installable.
Let's assume you receive a request on Saturday asking to reverse T-GAP8DEUC_1028.0.exe, how would you approach it ?

As normally everybody does, the first step is to find out the firmware you want. Google is the master in finding stuff. Just few clicks and you get what you need.

The file you've just downloaded is a PE executable, as I wrote many previous posts ExeInfoPE or PEiD is your first gate. You want to learn if it has been encrypted, obfuscated or which security procedures has been taken to increase the security bar. ExeinfoPE tells you compression is playing a big role into the executable, so what you need is to discover what kind of compression is placed. There are many ways to discover the compression used algorithm, for example the most easy one is to search for common headers. In this specific scenario, I used Immunity debugger just because I performed more reverse actions over this executable which I am not going to explain in this blog post. As the following image suggests winRAR libraryes have been used.

Ok, no specific encryptors have been used over the data section, let's walk through the binary and see if we discover where the RAR archive is placed. BinWalk is an amazing tool, it scans any binary looking for know header patterns. Once known header is found it gives you additional information regarding its status. The following image shows the walk of the entire executable threaten as a junk of byte.
Here we go ! Right now, we know there are 6 LZMA compressed data junk and a Big RAR archive ! I don't know why, but I feel to try to see what is inside the big RAR archive. So let's extract it !

dd if=T-GAP8DEUC_1028.0.exe bs=1 skip=99840 of=T-GAP8DEUC_1028.0.RAR; unrar T-GAP8DEUC_1028.0.RAR

What we observe is an entire image folder wrapping severlal big image files and many small binary files.

rocommon.img, rwcommon.img and emanual.img seems to be the most interesting files to dig in. But before digging into them let's see what is the real version we are reversing.

And most important, lets take a look to the partition table ;)

Super! We have many different images and many different informations we whant to learn from the them, but let's going on our path and maybe comming back later to other partitions. So far, we have 4 different bootloaders, on "bml" devices. We have 2 different kernel images on bml as well, we have an emanual image and 2 common partitions. Let's investigate the biggest partitions first (why the biggest first ? Because, statistically speaking, where there is more data you might find more interesting data !). Lets start by ignoring the emanual partition, actually I don't care about manuals, and the name of that image makes me think I will find only "user manuals" on it. I do like to focalize on the "common" things, common usually means that it's used all around the environment so we'll could find interesting sharing points. rocommon would be our first target since it would be ReadOnly. Maybe common applications are in there ! It's a squash file system, pretty common embedded devices. BackTrack owns a nice unsquashFS script, it's what we need.

Let's open it and see what we have. The following image shows the content of the rocommon image file. "Advertisement" (is Samsung planning to advertise on smat TV apps ? Isn't enough adv on television sof ar ? .. anyway...) , A_Store (Application Store ?)". I think this is what we were looking for !

Ok we have one file system, but each file extension is "cmk", if we try to open any file it's encrypted... this is a classic scenario in which you might end up. But if you remember, Samsung released a development kit in order to develop applcations for smart TV. Well... what if I want to develop applications for smart TV and I don't own a smart TV ? No worries Samsung offers to you a samrt TV emulator ! Cool... the emulator must be able to decrypt smart TV firmware otherwise how it can be run over multiple smart tv firmwares ? Here we go, I am not going to show how I obtained the key to decrypt the firmware (which appened to be:  k: B1D5F122E75D757C79F48886D42F8E1A and iv: BFE932F9273DC2A0DFC93F0B8E7AC7C2 :) It is another "reverse story". So.. Let's decrypt the firmware ! The following image shows a little script which iterates over all the rocommon folder tree and decrypts each encrypted file.

Super cool, now we are free do open each file we want to. We might find out some proprietary code ... (comments are still in Japanese)

We might find out some future development scenarios, such as new input parameters ....

What else we might find digging into rocommon... Oh, almost forgot, we migh find some Private Keys !

Do you think to certificats as well ? Ok, I am not going to publish them.. But you might be interested on debugging the frame menu or any default application included in the firmware as well.

As shown in the partition table there are many other images that you want to mount and to dig into. The actual entire firmware is quite a big. Now you have all the infos you need, certs, private keys and tools. Each file named *.sec is a combination of AES and XOR encryption, you will find many forums talking about those files and many python tols have been released to automate the descryption process as well, just keep the one you like ;). Once you decide to dig into the rootfile system you'll not learn really amazing things beside the root account of-course, as shown in the next image.

On the other side if you decide to dig into the exe partition you'll find more interesting applications. If you are a vulnerability hunter this is the place where you want to start your job. The following image shows the root folder of the exe image.

Summing up, in this post I decided to show a full reverse engineering path, starting from a self-executable PE file to real informations such as: root acount, certificates, proprietary code, used applications, private RSA keys and so on. Not all the required steps have been covered, this is not an hacking manual is more like a "this is the way to follow". Hope you might enjoy it.

Saturday, May 4, 2013

Finding path to known functions through IDA-Pro

Dear folks,
as you probably have noticed my blog-post frequence went down a little bit during the past 4 to 6 months, since I am super busy... I am still alive though :). Today I want to share an interesting IDA Pro plugin that I 've been testing for awhile called idapathfinder. Once you installed it ( $ ./ /path/to/ida/install/directory ) you'll se a brand new sub-menu in the "view Graphs" menu named "Find all path to...".

Immediatly after your selection a new window form will ask you what target function you want to look for. From the original graph the plugin will highlight the the path to the function you've just selecteed. The following image (from idapathfinder documentation) shows the path to strcpy.
idapathfinder is a great plugin, pretty useful for vulnerability hunting. However I would like to see something a little bit more automated such as: a procedure to look for the path to known vulnerable functions, a procedure to look for path to null pointers and a procedure to look for path to wrong input checking functions.. and so forth.

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.  

Friday, February 8, 2013

2013 and the "Ping of Death"

It's been a while since I am in the computer security discipline and I remember the old Ping Of Death attack. How cool was it  ?! At that time breaking the stack was as simpe as breaking the modelling assumptions, for example breaking the stack in 1997 was as simple as sending to the target stack a unexpected lenght in the ICMP packet ! And, yes, I do remember the time being where a malformed source and destination address caused the smurf attack.  After those implementation mistakes, developers, engineers and the developing frameworks became more and more sophisticated, became more and more complete in term of security checking.

It is a long time since I saw another mistake like thise ! ... Untill today ! Today I've read a post talking about another implementation bug in the TCP/IP stack made by Intel enginners. The writer shows how the Intel card ( 82574L ) shouts down if a specific value (0x32) is placed into a specific address ( 0x47F). Which basically means if the ASCII "2" is into a specific address in the sent stream.

Let's take a closer look to the bytesteram:

Image From here

Shutting down an ethernet card could be pretty annoying for a system, in fact you need to reboot your entire machine before getting the card workgin bback. Further analysis showed that different values placed into the same address, change the card behavior.

So hard to find so easy to test. When you play with networks captures and/or with networks crafters the big amount of data let the bug hunter's work be pretty difficult and annoying. Contrary a lot of tools have been developed for testing the network behavior so once you found the bug to reproduce it would be pretty easy as simple as:  "ping -p 32 -s 1110 x.x.x.x"

Another fun story to tell, another good example showing why there is the need of security evangelists to increse the security awareness, another good example showing that bugs and eventually vulnerabilities are always "behind the corner" :D. It is worthy to remember.

Saturday, February 2, 2013

SCADA (in)Security

During the last weeks I've been involved in some SCADA systems testing. It has been quite a new world for me, no memory overflows or ROP, no specific deobfuscator  techniques;  just plain text analysis, sometimes even too easy old web style (in)security.

Sometimes the difficulty of the intrusion was just a matter of few minutes. For example in the following scenario the web server protection was based on .htaccess file holding a really insecure password (3 minutes of bruteforcing). The following images represent a supervisor (and controller) of an entire farm. Attackers could easily stop water services, power supplies and heaters.

Sometimes the entire system relizes on unsecure protocol (Telnet) and the bruteforce is just a metter of hours. In the specific case just 1.5h

Even more dangerous when you enter in a system able to control the electric power supply of a huge building and you discover that you were not the first one !!

Who put evil.exe there ?? This specific case was even not password protected ! WoW. (I feel a little bit lame at this moment...) And the list is just huge.

There are some "smarter" systems who calculates passwords on unescaped javascript:
Systems which lets open logs and open control panel because "hidden", and so secured enough ! (0_o!)

Or even who check the presence of a cookie to authorize to configure an entire Power Cell !

At this stage seems that SCADA security is at the very beginning of its history. Unfortunately SCADA systems are really important and might affect thousands, hundred thousands of people. I wont immage a nuclear station managed according to these security standards! It would be just scarry.

Since I am totally newbie on SCADA security, I started some research on my own and I found some interesting resources that shows more advance attacks techniques such as the following:

PLCScan: how to find out PLC and how to deal with them:  

Metasploit MOdule WinVNC Harvester:

How to recover S7 PLC/TIA portal password

 Hope this BLOG-POST helps to encrease security awareness on SCADA systems. They are huge, important and they can affect the real life of many citizens. Each water station, electric station, nuclear station, but also each airport, each industry owns a SCADA system to monitor and (sometime) to control machineries.