Marco Ramilli's Blog

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

2013-06-16T10:08:00.003-07:00

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 !

Firmware Hacking: The Samsung smart TV turn

2013-05-12T23:04:00.001-07:00

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.

Finding path to known functions through IDA-Pro

2013-05-04T10:50:00.000-07:00

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 ( $ ./install.py /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.

Vulnerability Classification

2013-03-27T11:39:00.003-07:00

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.

Nozzle and BuBBLE: a trick to JUMP them!

2013-03-17T14:31:00.001-07:00

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:

Spray the Heap. Dinamic memory allocation. Fiilling memory with NOP+Shellcode
Trigger the bug. Firing UP the bug to get a pointer.
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.

2013 and the "Ping of Death"

2013-02-08T01:30:00.002-08:00

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.

SCADA (in)Security

2013-02-02T10:56:00.000-08:00

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.

BUSY,BUSY,BUSY and Java Vulnerability

2013-01-15T13:25:00.002-08:00

Hi Folks,

it's a very BUSY working time for me, my apologies for the few blog-posts during the past months !

Even today I am writing in the middle of the night and I don't have enough energies to write a detailed post, BUT I do want to remember this incredible vulnerability found on Java 7, during the past few days. The Java bug is still not well described in the CVE-2013-0422 , Oracle did not publish further details so far.

It seems the only suggestion from the security community is to disable Java from Browsers. Take a look here and to the Vulerability Source Code.

BlackHole, as well as many other exploit packs might have it since 2010 [Unconfirmed information, given from private source] !

[update]

My quick and dirty explanation (remember what I wrote on line 4):

The com.sun.jmx.mbeanserver.MBeanInstantiator.findClass method has a bug that allows users to retrieve Class references of any package. In fact findClass calls another method called loadClass(ClassName) which loads the given Class. Unfortunately the findClass method is private and not accessible from external users. However looking at the Call Hierarchy we see there is a public method that calls the contractors. The method is: com.sun.jmx.mbeanserver.JmxMBeanServer. The JmxMBeanServer constructor implementation shows the MBeanInstantiator is stored in the instantiator attribute. Such a class has a method called getMBeanInstantiator which returns what we need (findClass).

The exploit's code looks like the following one:

Actually the entire exploit is way more complex then the one represented up here; it uses Recursive Reflection Vulnerability ( CVE-2012-5088). Following the main steps of the exploit.

The exploits' teps are the following(taken from immunityinc):

Using the previously described vulnerability, it gets two classes from a restricted package.
Using a simple public Lookup instance it uses reflection on the Lookup class to get a MethodHandle for the findConstructor method.
Invokes the findConstructor MethodHandle on the public Lookup instance passing clazz1 as parameter to get a MethodHandle for sun.org.mozilla.javascript.internal.Context constructor.
Invoke the constructor and create a sun.org.mozilla.javascript.internal.Context instance.

For more information here.

How Malware survives to Malware detection mechanisms

2012-11-08T00:01:00.001-08:00

Today I'd like to share some basic techniques that Malware(s) use to protect themselves from being detected. Some of the most used approaches to detect Maware could be described as follows:

Virtualize the environment in where Malware(s) run.
Attach a debugger to Malware processes and
Sandbox the execution of the analyzed Malware.

It comes straight forward that Malware writers need new techniques to detect the detectors :D. In other words they need tools to figure out if the Malware is being analyzed or not. There are tons of ways to perform these checks, here I just want to sketch same of them for future researches.

Detecting Virtual Machines.

Virtual environments have virtual devices such as virtual interfaces, virtual hard dirves and virtual graphics. Malware(s) by using a widly known techniques against "Malware" (ie. the signature checking technique) can detect the environement where they are running.

For example, a network interface for VMware Workstation has a MAC address starting with 00:50:56: or 00:0C:29. A wise Malware could decide how to behave depending on its environment. For example if it runs on a virtual environment it might decide to not perform malicious actions on the other hand if it runs on a real environment it might decide to perform malicious actions. Another used technique to understand the presence of a VM is to check for GUIDs. For example:

MD5: 0151c5afde070a7b194f492d26e9b3ef (Trojan.Agent-124243 by ClamAV).

The previous picture represents the function checking for the presence of: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProductId 76487-644-3177037-23510. The presence of such a key proves the CWSandbox environment is running on the host platform. Or again, the Malware(s) could check for specific Hard Drives, Video Drivers and even Mouse Drivers. Some classical examples follow:

Hard drive driver (VMware):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskVMware_Virtual_IDE_Hard_Drive___________00000001\3030303030303030303030303030303030303130\FriendlyName VMware Virtual IDE Hard Drive

Video driver (VMware):

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\DriverDesc VMware SVGA II

Mouse driver (VMware):

%WINDIR%\system32\drivers\vmmouse.sys

Detecting hardware signatures is not the only solution for malware writers, there are many other differences between Virtual Environments and Real Environments. One of the biggest is the inconsistency of "Table Registers". We have only one Interrupt Descriptor Table Register (IDTR), one Global Descriptor Table Register (GDTR) and only one Local Descriptor Table Register (LDTR) for each processor on the platform. But since in a virtual environment we have at least two operation systems running symultaneosly, the virtual machine needs to dynamically adjust each "Table Registers" in order to avoid conflicts. The process creates inconsistency between the native "Table Registers" and the virtual ones. A Malware can detect these inconsistencies by using assembly level instructions to read those values. SIDT, SGDT and SLDT might been used to read the original values of "Table Registers". The following is an example of such a difference.

MD5: b27d73bfcbaec49a95f23b45e9cf9310 (W32.Virut-54 by ClamAV)

The IDT is at:

0x80ffffff in Windows

0xe8XXXXXX in Virtual PC

0xffXXXXXX in VMware

Again, this is not all the malware writers have. Some Virtual machines, such as VMware use backdoors as a communication media between the hosting machine and virtual machines. For example port 0x5658 (ASCII:"VX") is used in VMware virtual environments. Malware might be able to detect the name of the communication port and behave on consequence.

Detecting Debuggers.

Debugging is not per-se a virtualization, however this technique is widely used by reverse engineers in order to understand what the process is doing. Virtualizaion is the first and easiest way to perform Malware Analysis since you get the results out of the box by simply running the executable. Debugging is way more complicated but you have a deep understanding of what the process does in the host machine. Detecting debuggers is another important techniques that Malware writers have to consider during the Malware creation. The following code (taken from here) shows a simple function checking for the presence of an attached debugger on Windows machine.

The above funciton checks the presence of an atacched debugger by asking to IsDebuggerPresent from kernel32.dll. The next function looks for files such as: SyserDbgMsg, SyserBoot and SICE, NTICE. Those files holds the informations, and the history of a debugged process (taken from here).

Another way to detect debuggers is the NtGlobalFlags check:

mov eax, dword ptr [fs:30h]

add eax, 68h

mov eax, dword ptr [ds:eax]

cmp eax, 70h

if the value in %eax register is equals to 70h, a debugger is attachecd to the process. If the process is not debugged the value of the flag is null (there is no such a flag). If you are implementing this check, remember null pointer exceptions...

Another way to detect Debuggers is throught timing out. Debuggers can put break points in the code, and can therefore stop program execution. A program can detect this, by monitoring the system clock. If too much time has elapsed between instructions, it can be determined that the program is being stopped and analyzed.

These techniques are only some of the numerous techniques that Malware writers might use. If you'd like to check them visit the OpenRCE dedicated page here.

Sanbox Environments.

A sandbox is a tightly secured environment where the analyst can run and analyze the behavior of a given application. It's quite useful since once the execution (of the selectede software) ends everything is automatically restored to the previous state in which the machine was before the run. Being able to restore a "previous state" of an entire OS means to be able to record everything the software does. For such a reason sandbox environemtns are so usefull to analyze M0alware(s).

So usefull but so predictables as well. Pretty much each sandbox has an unique way to be detected. Anubis for example can be recognized based on its product ID (which happens to be: 76487-337-8429955-22614) located at HKMLSoftwareMicrosoftWindows NTCurrentVersion. Following a code snipped able to detect Anubis sandBox (via aspfree):

private static bool AntiAnubis2() {

RegistryKey regProductID = Registry.LocalMachine.OpenSubKey("SOFTWAREMicrosoftWindows"
                           +"NTCurrentVersion", false);
object pid = regProductID.GetValue("ProductId");
string id = "76487-337-8429955-22614";
if ((string) pid == id)
  return true;

return false;
}

Using the same code is possible to detect JoeBox and CWSandbox as well (just checking for 55274-640-2673064-23950 and 76487-644-3177037-23510 registry keys). Sandboxie and ThreatExpert do not use fixed Registry keys as the previous sanbox solutions do, so it is not possible to detect them using the aforementioned code. However they do load specific DLLs in the sandboxed environment in order to control the executed software. So why not just checking for such DLLs ? sbiedll.dll and dbghelp.dll are respectively the two used DLLs.

More ways to evade current security solutions are out there, in this post I summed up some of the most used and some of the most implemented techniques. If you are doing reverse engineering please keep in mind that things are becoming complex since malware writers use those techniques quite frequently. Don't stop your analysis on a sandbox, don't run the suspected malware only in virtual environments and keep in mind debugger-traps whle you are using your favorite debugger.

IDAscope a great SwissKnife for reversers

2012-10-25T06:17:00.000-07:00

Hi Folks,

today I'd like to introduce a great tool made by Daniel Plohmann and Alexander Hanel from University of Bonn and Fraunhofer FKIE called IDAscope. IDAscope is an IDAPro extension for easier (malware) reverse engineering: it offers three main functionalities:


From Hacklu slides (click to make it bigger).

Function Inspection. This function implements the ability to tag specific series of called API. The tracked API could be selected and modified into a specific config file (config.json). IDAscope will alert you when specific API patterns will occur. The function inspection functionality enables another super feature called: basic bloc coloring. Having colored blocks in IDAPro is really useful to quick understand what is the purpose of the analyzed pieace of code. What it's common to do, right now, is to collapse blocks by giving high level names. IDAscope offers the possibility to automatically coloring blocks making you way more efficient in recognize useless blocks. Code to Function convertion and automatic rename of wrapper functions are additional usefull functionalities as well.
WinAPI Browsing. Obviously for windows reversers is incredibly useful having Windows API reference manual. Here, by using IDAscope the API reference is next to your eyes for quick and smart lookup. The following image shows both: Blocks Coloring and WinAPI browsing.

From Haclu slides (click to make it bigger).

Crypto Identification. Maybe the most useufl functionality to all the reversers that are used to struggle with multiple tools to figure out what encryption algorithm has been used on the code. IDAscope detects the used algorithm basing its analysis on the ratio of arithmetic / logic instructions to all instructions in a basic block. More details on how it works here (by Juan Caballero).

For sure a great tool helping out reverse engineers and a great example to everybody who is going to finish his/her PhD on how to "pack" all (or most of) the reseaches done in the past years.

A personal suggestion to push the project to the next step.

What about improving the tagging function to reach out the "behavior analisys" ? You already have implemented some of the basic functions to be able to understand the behavior of the analyzed binary; for instance you already have implemented the lookup function and the tagging function. What about shipping out the extension within configuration files representing some of the most used malicious behaviors ? There are tons of researches on this field that can be easily implemented in your estension with relatively few effort.

Leading a security team

2012-09-26T05:55:00.001-07:00

Today I want to start from this sentence written by Frederick P. Brooks, JR. The Mithical Man-Month:

Software systems are perhaps the most intricate and complex (in terms of number of distinct kinds of parts) of the things humanity makes

Being the most complex systems the man can build, software systems are addicted to numerous mistakes either conceptually either technicals. Each mistake hides a bug, and some specific bugs ( the one that could affect the normal security model of the designed system) could become a vulnerability. This is the "why" we still find and we will find vulnerabilities in softwares ... This is the "why" we will need security experts to handle crisis generated by such a vulnerabilities. In this post I'd like to review some of the basic concepts of "team leadership processes" and apply them into red teaming. This is not going to be an exhaustive review of the most used leading concepts but rather a different point of view (from a security perspective) in classic team leadership patterns.

The craft of "securing". Even if many people can argue that security is becoming a science, I do believe we still are in the "craft" time frame. We can't say it is an Art, because we have methodologies, guideline, policies, and even designed patterns. We can't say it's science, since we can't reproduce the same results (aka the same security level) in every environment. We still have no idea on how to measure "security"! So it is correct to call the "security discipline" a craft. If it is a craft we won't be able to predict the precise cost of "securing" a system. We won't be able to know how many 'penetration testing hours' are needed to secure a whole system, we need experience to be able to give an accurate estimation.
The joy of understanding. While Frederick P. Brooks in his famous book pointed out that the "craft of programming" gratifies developers because they are making things, we cannot say the same for security engineers. We had not the joy of making things.. Developers make things, we broke things for testing their security properties. So what is the spirit of a security engineer? The joy of understanding how things are done. A great security engineer is the one who loves to disassemble, to learn, to discover how other people did such a thing. The necessity in understanding, in learning, in disassembly things take the security engineer in a position to know what is strong and what is not. After some experience the security engineer is the one able to compare two different systems and to judge their models and their designs with respect to security features.
Good cooking takes time... Security process such as the penetration testing process needs time, it cannot be hurried without spoiling the result.
Partitioning a task among multiple engineers occasions extra communication effort, that it doesn't come for free. Partitioning is often a great solution but is not always the best solution. Adding people at the end of a penetration testing process will take to this process much more time respect of having no additional engineers. If you are in rush don't add more people. People need to be trained and they need communication with current engineers to catch up the whole contest before being able to produce actively to the process. Take people into penetration testing at the beginning of the process, never at the end of it, you will not finish the process on time.
The perfect team. A chief-security engineer, a surgical-team made from a small amount of talents offers a way to get the process integrity of few minds and the total productivity of many helpers, with radically reduced communication.
Find the most valuable vulnerability. Finding the most valuable vulnerability often correspond to attack the conceptual integrity of the system. Understand how the system works, and firstly focus on the conceptual integrity of the system and later on technical aspects.
Communication between team members. Definitely the most important task a team manager have to guarantee. Communication. Thanks to communication people have new ideas, find solutions and find the way after having lost it.
Organization and role definition. A good organization and a good role definition is fundamental to coordinate talents and often "big egos".
Plan to throw one away. According to Frederick P. Brooks, JR. In The Mithical Man-Month, there is always a wrong way that eventually you and your team will take, you will, anyhow. Plan to throw it away, and start from the previous state. Don't loose time in tying to recovery a test, don't lose time to try to convert a specific designed tool to fit another bug, don't try to reuse a reverse engineering status from the previous code revision. Find the power to admit the failure and start it again.
Documentation, documentation and... (Try to guess... ) documentation! Is your only true weapon to speed up the learning process and enable a fast context change. I know, when you reached a result, such as a tool for testing a specific system, a 0day or a new injection status you think to be wasting time writing documentation. But is not like that... And you know that. So remember each time you should write docs, that is almost valuable as the task you have just concluded.

If you have to manage a penetration testing group, I hope it might be helpful. Let me know, any comment is appreciated

Yes, we all are immortals...

2012-09-05T13:33:00.001-07:00

Today I'd like to share a nice article on immortality written by Marcelo Gleiser. I know it's quite a bit out of topic for my blog, but it is worthy. The article presents a great theory on immortality based on Internet. I extracted few sentences to sum up the theory :

[...] Apart from gene transmission — not very satisfying from an emotional perspective and diluted with every generation — we could say that you existed so long as someone remembered you.
That's not true any more. Something of you now exists so long as electrons course through the wires of any person's computer in the world. It's quite a thought to recognize that we have a new kind of immortality to share. It should raise our collective awareness of how we'd want to be remembered. The words and pictures will remain, long after we are gone, for anyone who cares to look for them. [...]

Hope you enjoy it as I did. It made me think about how the immorality concept has radically changed during the past decade and with it all the life has been changing since the information became shared.

Raising Risk Awareness on the Adoption of Web 2.0 Technologies in Decision Making Processes

2012-08-17T04:48:00.001-07:00

Today I'd like to share a paper that Marco Prandini and I wrote on the use of Web2.0 in decision making process. The paper can be found here on the Journal of Future Internet.

Abstract: In the recent past, the so-called “Web 2.0” became a powerful tool for decision making processes. Politicians and managers, seeking to improve participation, embraced this technology as if it simply were a new, enhanced version of the World Wide Web, better suited to retrieve information, opinions and feedbacks from the general public on subjects like laws, acts and policies. This approach was often naive, neglecting the less-obvious aspects of the technology, and thus bringing on significant security problems. This paper shows how, in the end, the result could easily be the opposite of what was desired. Malicious attackers, in fact, could quite easily exploit the vulnerabilities in these systems to hijack the process and lead to wrong decisions, also causing the public to lose trust in the systems themselves.

Web 2.0 is for sure a great opportunity and an amazing paradigm that could be very useful for politicians or decison makers in the more broad way. However web 2.0, as described in e paper, could be very dangerous if used to attack a decision chain. The paper describes and gives examples on how a possible attacker could attack current political decisions by exploiting simple and well known Web 2.0 bugs. I recommend this reading to all of you involved in politics and/ord decision making, in addition to everybody who works for government agencies.

JavaScript and Botnets

2012-08-07T09:35:00.001-07:00

After an entire period of time busy in traveling and moving to a new city I am finally back on my blog. Not sure abut the frequency of my future posts but still very interested on keeping on posting my working topic ;). Probably I'll be able to post a little bit more from now... Most of you are already aware about the DevCon 2012 and its new topics on security, so I won't spend time on this discussion, but I do want pointing out an interesting technical paper presented by Chema Alonso and Manu "The Sur" titled :" Owing Bad Guys {& Mafia} with JavaScript Botnets".

The paper describes how attackers, by exploiting TOR networks and public available proxies, can intercept user's traffic, and injecting malicious JavaScript to exploit users' browsers. The technique per-se is well known from years and the framework they used to load malicious payloads (BeeF) is already widely used around the hacking community. So what's so interesting about this paper if it does not introduce any new concept? I found really interesting the analysis on the users they had. in other words who is using public available proxies and TOR networks.

Let's take a deeper view of it. The following image shows the general idea about the implemented attack on a proxy server (BTW they setup a SQUID proxy and the registered it on public proxy registries).

SQUID server has the property to modify traffic following specific roles. Originally these roles have been designed for parent control and for blocking some specific domains, but it can be used under a malicious perspective to inject malicious JavaScript on downloads pages. The authors used a poison script to inject malicious JavaScript. Following the infection:

Again I don't see any interesting technique in this. BUT I do see the beauty of this study in capturing the "stakeholders". If you follow on reading the paper, authors show who used this proxy and what he did with it. Obviously most of the performed operations by exploiting the free (and hacked) proxy were with malicious intents. One of the most interesting proves that authors provided is about Scam and people who answered back by giving personal informations.

Most of the stakeholders come from Ex-URS, Brasil and USA. Many of them from Cina, only few of them from Europe. Beside normal stats on where users come from, understandings how malicious hackers use proxies to attack is really interesting. Another little but significative theoric brick could be added to all the knowledge we had from honey-net project.

Computer Security: Training and Education

2012-06-22T07:43:00.001-07:00

Today I want to spend a little bit of time pointing out an important concept of computer security: the Education. I want literally cite the Security and Privacy's Guest Editors' introduction on what is education, what is the difference between training and education and why is so important on computer security .

As technology creators, providers, and users, we must answer significant questions to address these problems, for example:

How can we help individuals be good cybercitizens ? In particular, how can we give them a clear understanding of both cybersecurity issues and how their personal choices affect cybersecurity?
Can building an effective cyberworkforce help users understand their responsibilities online and with computer-based technologies ?
[...]

Some People are still thinking on why computer security is such an important topic, or why there is the need of having security online, or even worst, people who say they "don't believe on computer security" (whatever it means)... Well , I believe this Guest Ednitor's introduction should be a mandatory readying for every student and even for every "security skeptical " around the globe. It explains by using simple concepts and practical examples why computer security is such an important topic in the current world and why security education is even more important since could affect citizen behaviors.

Another great lesson comes from the distinction between education and training. Training refers to learning concrete skills for meeting specific, real-life goals in a clearly understood situation. By contrast, education focuses on understanding and knowledge, learners can associate principles and concepts, apply them to solve a variety of new problems, and evaluate those solutions' effectiveness .

This is another huge and quite delicate topic: training, often represented by private companies and private sectors VS educating, often represented by Universities and the entire academic world . Those two entities often in totally disagreement between them, share one of the most important topic related to computer security.

I do finally suggest this reading, even if it's not a technical one it offers great cornerstones to fully understand security education and security training: when they should occur, when and where one is the most useful an when and where the other one is needed.

A great analysis post on Flame string encryption

2012-06-02T06:57:00.001-07:00

Hi folks,

It's quite a long time since last post, I am sorry about that. I am in the middle of a quite long traveling period, so forgive me to slowing down a little bit my security posts. Today I d like to share an interesting Post written by "Spider Labs Anterior " regarding the string deobfuscator using IDAPython.

Yes, it is on Flame too.. I wouldn't write about Flame since everybody out here is talking about it, plus I had no time to personal analyze it, so unfortunately I have nothing to add to the enormous flock of posts on it :) (BTW this paper is high recommended ).

The author, Josh Grunzweig, shows his path to find out the obfuscating technique used in Flame. I think it is worth to keep in mind because perfect to didactic purposes. From IDA graph he reproduced the following code. Every analyst should do this step!! I often miss it and try to solve by patching the code or by pencil and paper, but doing in this way will save a lot of time in long term analysis. I collect his main analysis following.

The function above is taking the obfuscated String as a parameter, and checking the sixteenth byte to determine if it is null. This byte is acting as a Boolean value to tell the function if the String has already been decoded. In the event that this byte is not set to null, or 0x00, another function is called, and the sixteenth byte is set to 0x00. Finally, the result of String that was initially supplied as a variable, with an offset of +20, is returned. If I were a betting man, I’d suspect that the second function (named ‘deobfuscate() in the above Ruby code) is manipulating the data somehow. In order to find out, let’s investigate what is going on. If we look above, we can see that this new function is supplied two arguments—The 'obfuscated_string' variable with an offset of +20, as well as the eighteenth byte in 'obfuscated_string'. So this function appears to call a third function (last one I promise), and proceeds to subtract the resulting number from the specific character in the string before replacing it. So if we were looking at the first byte (0xA7), and the third function returned 0x82, we would get the following:0xA7 – 0x82 = 0x25 (“%”)

Great job Josh and thank you for sharing it !

Automatic Exploit Generation: a Provocative Post

2012-05-14T21:17:00.000-07:00

Today I went trough a very interesting paper written by Thanassis Avgerinos, Sang Kil Cha, Brent Lim Tze Hao and David Brumley from Carnegie Mellon University titled: "AEG: Automatic Exploit Generation". The paper describes a technique and an implementation of an automatic engine able to generate exploits from source code and binaries. AEG has been introduced in NDSS 2011 and it is really amazing :D

From the Abstract:

We used AEG to analyze 14 open-source projects and successfully generated 16 control flow hijacking exploits. Two of the generated exploits (expect-5.43 and htget-0.93) are zero-day exploits against unknown vulnerabilities. Our contributions are: 1) we show how exploit generation for control flow hijack attacks can be modeled as a formal verification problem, 2) we propose preconditioned symbolic execution, a novel technique for targeting symbolic execution, 3) we present a general approach for generating working exploits once a bug is found, and 4) we build the first end-to-end system that automatically finds vulnerabilities and generates exploits that produce a shell.

The following picture shows the way the authors designed their Automated Exploit Generation system.

Te system performs both analyses: Static analysis on source code and Dynamic analysis during the runtime execution. It then generates an automated exploit and it verifies it before resulting it as output. Following, an astonishing video proving the reality of the AEG system.

Now, I've never tried AEG, I cannot say that it really works or what are the limits it has got, but I would be very interesting in reviewing it. It seems that it might really change everything into the security world.

On one hand I am a little bit scared about it for two main reasons: (a) it could be used from good guys as well as from bad guys. And bad guys with this powerful tool could act very badly. I know, this is like many other theories and tools in computer security... Even my book could be used from bad guys to learn how to exploit systems right ? My worries here is about the usability. it seems to be pretty "user friendly"and really effective too. Plus it covers almost all areas in the software exploiting process that everybody could use it and be very effective. And (b) AEG rises a serious question: do the security professionals really need to exist anymore ? ( I am very provocative )I know, AEG is probably a very Beta tool, but what will happen once it will be tested and ready to be used ?

Let 's just analyze what happened during the past decade to computer security experts. At the beginning of the computer security era, only few people were able to compromise systems, it was considered something like a gift. Then it become an Art, I remember the magic book of Matt Bishop, Computer Security: Art and Science which fixed basic concepts of what computer security was and what penetration testing was going to happen. Only few skilled people were able to practice such an Art because it was hard to study and difficult to learn such low level techniques. Later on it became a discipline, with tools, weak theories and wide documentation on how to attack or to exploit systems... few scholars were able to exploit systems. Finally it become a Science thanks to Methodologies that made the Exploit process reproducible over time, basically everybody with a strong technical background and passion for the computer security can learn how to compromise it. Now.... is it becoming an automatism ?

AEG seems to be a perfect tool to automate the full stack exploiting process, from analysis to exploiting. The question is the most obvious one: Do we still need penetrator testers, and vulnerability hunters ? )Or it is going to be enough an automatic tool ? (I am provocative deliberately )

Is the exploiting process becoming quick and easy as running an automated tool ? If this is going to happen what will happen to the computer security scientists/expert/engineers ? Anther question, maybe the most important one ... if a software able to discover most of the possible vulnerabilities is going to be available what about the "Computer Security Science" ? Will it be science yet ? Or will it become a simple Technique ? Or even an Automatism ?

Following the exploiting process steps I see :

Gift (few rare persons able to exploit) -- Art (few very skilled people able to exploit) -- Craft (books, tools, and tutorials. Few scholars and very motivated people able to exploit) -- Science (reproducible, basically everybody with strong technical background could be able to exploit) -- Automatism (everybody, or even nobody, there is no need of having people able to exploit, one automata will do it for everybody)

Plaid CTF results

2012-05-01T21:58:00.001-07:00

I am so proud about our security group, made by the most talented hacking students in the university of Bologna. CeSeNA ( Cesena Security, Network and Applications ) is the official name of the security team I used to lead, but when those students compete in hacking contests the official name jumps to ANeSeC ! CeSeNA for security and ANeSeC for hacking purposes.

The past weekend ANeSeC participated to a quite known hacking contest: the plaid CTF. 720 teams from 82 different countries. We were 42th (and first Italian team) !! Not bad at all considering some "key elements" were not playing !! Good job CeSeNA-ti I am so proud !!

Bypassing .htaccess by using GETS

2012-04-27T09:43:00.001-07:00

Hi folks, during these days I am traveling a lot for job, and unfortunately I don't have much time to write posts. Hovewer today I wanna share a really nice post about a classic problem affecting the HTTP basic authentication method in PHP applications. The post ( written by armoredcode ) is about a 2 years old bug described by Owasp in 2010 (here) , by cd34 (here) and by Eguaj (here, which btw, explained with lot of details). I'd like so much this post because is not about vulnerability (which is very known, even if very spread over websites) but is about the whole hacking process, from scratch. Pablo Perego wrote a very detailed process and very deep considerations that drive the reader to a full understanding of what the problem is. Following the images of the fundamental steps taken from armoredcode. First a HTTP request with empty body.

And then the request for the backed page.

Again a great place to start to look into the hacking reality and a good example of simple vulnerability exploiting process .

Following the main followed steps:

fingerprint the operating system, the web server and the programming language version using netcraft He discovered a “/backend” directory looking into a javascript file he found in a browsable “/static” directory.
Paolo crafted custom HTTP requests in order to bypass HTTP Basic Authentication that it was in place to avoid curious people to look into the backendI was able to make updates into the database…

Please refers to the original website to learn more about the "lessons learned" .

EXE null EntryPoint execution

2012-04-21T18:53:00.001-07:00

Hi folks, today while I was surfing on my personal feeds I hit this interesting picture ( the original from Twitter is here). I am not going into the details since the picture is quite self explaining (plus I am traveling and not much time, unfortunately )

The first binary is a DLL with a null EntryPoint, basically it won't load. The second binary is a a PE executable with null EntryPoint too. The third and last executable is a "good" PE executable, in the sense that it gots a valid EntryPoint . In the black shell the author shows the execution of the two PE files. Both of them run ( both of them end in the execution of the null reference DLL). The actual PE with null EntryPoint got its %EP executed. Quite interesting isn't it?

The Biggest App Sec Mistakes Companies Make

2012-04-17T20:01:00.001-07:00

His folks, today I would share some thoughts about the "mistake that company often do on computer security" . Mu thoughts on that topic have been published on veracode website. Directly from veracode:

Veracode Marketing recently polled a list of InfoSec luminaries, asking them “What is the biggest mistake companies make with Application Security and how can they fix it?” We’re pleased to present the responses from a wide array of security experts including Bill Brenner of CSO Magazine, Andrew Hay of the 451 Group, Jack Daniel of Tenable Network Security and Veracode’s own, Chris Wysopal. While all our experts have their unique perspectives, some common themes arose including the basic idea of taking application security more seriously and committing to a programmatic approach vs. ad hoc manual testing. We want to thank all our respondents for participating and we welcome your thoughts too – use our comment area and tell us, “What do you think is the biggest appsec mistake companies are making today?”

Is your company actually doing these mistakes too? If you are interested in sharing opinions about that or you want your thoughts don't esitate to contact me.

X86 detailed informations

2012-04-15T05:29:00.001-07:00

Hi folks, today I share a nice x86 resource called sandpile. It wraps out all the most important things to know about x86 processors, a very nice place where to find all the information that you need. Before it, I used to search into many different resources loosing time and energies in content switching and in figuring out the many different searching functionalities belonged to various resources.

The website offer 4 maing groups of categories: regs, where you find all the registers related informations. Codes everything you would like to know about code, data and misc where bayou will find everything else you need about x86 architecture. Let's take a look to interrupt table:

Each information is sotored in a clear and intuitive table. I Totally suggest to have a bookmark within its reference. Good job !!

A Design Methodology for Computer Security Testing

2012-04-11T06:33:00.001-07:00

Yes, finally the first edition of my new book is available online. The book collects 3 years of researches in the penetration testing security field. It does not describe underground or fancy techniques to attack systems, it is most focused on the state of the art in penetration testing methodologies. In other words, if you need to test a system, how do you do ? What is the first step ? What tools can be used ? Or again, what is the path to follow in order to find flaws ?The book shows many real world examples on how the described methodology has been used. For example: penetration testing on electronic voting machines, how malware did use the describe methodology to bypass common security mechanisms and attacks to reputation systems.

Contributions :

Penetration Testing Methodologies Overview.
Penetration Testing Evaluation Properties.
Proposed Penetration Testing Methodology.
Enhanced Penetration Testing Methodology for E-Voting Systems.
Practical scenarios: Applying Penetration Testing Methodologies.
Proposed Coordination-Based Approach to Electronic Voting Systems.
Examples of Methodology in Real Cases.

Index (click on it to make it big):

Please if you want some information or if you have some suggestions about it, drop me an email I'll be happy to answer to your questions.

CVE-2012-0507

2012-04-02T00:41:00.001-07:00

My folks used to work with Java code, for many different reasons we often prefer Java rather then other languages and knowing Java vulnerabilities, for sure, helps developers in doing their job. Blackhole is like most other malware, it spreads over iframe and it executes a downloaded payload. ESET Threat blog in this post explains its execution in a colloquial but pretty complete way, a good reading. But what is interesting about this malware (at least for me) is the brand new used vulnerability : CVE-2012-0507 . CVE-2012-0507 describes an interesting vulnerability found in the Java AtomicReferenceArray class implementation, which wasn’t checking properly whether the array was of an appropriate Object[] type. A malicious Java applet could use this flaw to bypass Java sandbox restrictions in order to execute malicious code outside of sandbox.

The blackhole infection starts with a classic iFrame like the following one:

The infection goes on following these steps ( image taken from here) :

David Harley did a great job in decompile the java code and in describing its workflow. Basically the java executable is built over 3 main functions:

Init(). The malicious Java applet builds the object AtomicReferenceArray ( the vulnerable one) for the execution of malicious Java code outside the sandbox.
Work(). This method builds the code of a class which executes outside the sandbox.
DownloadAndExec(). This function downloads a malicious executable file to %TEMP%dsh89gyu.exe and executes it. Which happens to be a Win32/TrojanDownloader.Carberp.AH. In order to bypass detections by security software, the attackers changed the encryption algorithm and string obfuscation for the payload class executed outside the sandbox

Java malware are becoming day by day more and more spread over the net, on one hand because Java bugs are pretty common nowadays and on the other hand because java is "platform independent" by meaning that the attacker needs to write only one exploit overall and not one exploit for each attacked platform. I am very fascinating about java exploiting, and I totally think that CVE-2012-0507 is remarkable example to show while explaining java vulnerabilities and Blackhole a great example of java malware.

Windows Malware: a reversing engineering document.

2012-03-28T10:00:00.001-07:00

Today I'd like to share an interesting PDF found while surfing on some of my favorite feeds. The PDF is titled: "Deep dive into OS internals with WinDB" . Well, you might think this is going to be the same document explaining windows malware analysis, but not ; it is not the "always the same document". What I liked about it, is the easy way it shows information, small document with a lot of information. You could read it as a cheat sheet or as a little manual as well.

There is more than one reason to reverse malwares these days. As time passes by, the awareness about Reverse Engineering is spreading. However, there are few obstacles encountered for a person new in the field of Reversing Viruses. Unlike other domains of security where you can make your way through with the reliance on some security tools, this field demands a strong understanding of the Operating System Internals and Assembly Language Programming.

The author covers many of the most important arguments in the field of the reverse engineering by giving the essential flavors of the following topics: basic concepts of reversing, a very brief summary of PE anatomy, DDI and importing tables, exporting table (those sections are very intensive;) and so on.. Well, I personally suggest this reading to averybody aims to know more about reversing engineering stuff, but have not much time to read whole manuals, and to everybody working on hardsecurity topics but not everyday practitioners. And obviously to " security students" who should be avid readers of such things. :)