Monday, February 28, 2011

BlackHole for MAC

Hi Folks,
today I am going to write a little bit about the "new" RAT (Remote Access Trojan) called BlackHole available for Windows and for MAC. In the past few days a lot of news papers and more generally speaking a lot of news portals (pcworld, sophos on security, the register and many others ) focused on the so called "new entry": the BlackHole RAT.



As the previous picture suggests (it's the main screen of BlackHole) it's nothing really new, it's just another RAT, like NetBus was or many versions of BackOrifice and like many other are and have been. Is it new because it has been made for MAC ? Well I see nothing new on that: the following picture shows just another RAT for MAC available in the underground communities.








(note on that: this is an "undetecter" that uses my AVFucker, but it has RAT capabilities too )


(only a small piece, the author wont be reachable...)


Well, of course these are only one of the many available .. .. .. Boys, at the end of the day they are "simple" trojan which in most of the cases do not exploit any vulnerability but only implements regular operation as a normal server does. For example BlackHole for MAC asks you to insert the root password before being installed.... :O! very dangerous :D :D ... Again , uninformed people who falling into Social-Engineering traps open these malicious programs will have hard life if affected from a RAT, but informed people or people who do not often fall in social engineering traps will have easier life.. I mean it is always the "same soup" (an ancient way to say it is always the same old story) nothing new nothing old, I do not only figure why in these past few days a lot of famous, authoritative online (and non) magazines, which I respect and read, have been focused on this particular topic describing a new "MAC threat" when, instead, it is not a new MAC threat at all ;).

Please do not misinterpret my words, I definitely love pcworld, sophos on security, the register and all the others :D.

Monday, February 21, 2011

MAC OS X Binary Packer: UPX for MAC (OS X) !

Hi folks,
after some emails asking help to find out a good binary packer for OS X, I decided to write a little post on the topic.

Of course there are many binary packers out there, but today I am going to write about UPX (Ultimate Packer for eXecutables) for two main reasons: first of all because it supports many different executables formats as shown in the following table:






And second it offers a great compressing ratio, for example Netscape 4.06 (Window/PE) uncompressed is 2866KB while compressed becomes 1098KB a great ratio of 0.38. The following table shows some more results on its compression ratio



Last but not least it's an open-source project that runs perfectly on MAC platforms. Before compiling the source code you need UCL (UCL is a portable lossless data compression library written in ANSI C) installed on your MAC. MAC port helps us, so just type: sudo port install ucl it will be enough ;). After that just type make and sudo make install. Some people had troubles in compiling the libraries, in-fact some errors due to missing libraries could happen even if officially it depends only from UCL. So If you have trouble with the compiling process you can download UPX-FOR-MAC directly here.

Once you've compiled it (or downloaded from here ) you may try to test it in the following way:

1) Lets compress itself and see what happens



2) Lets give back executable rights to the resulting file (typing: chmod +x upx-compressed). We now are able to execute the macho file even if compressed. BTW we discussed about how it is possible that a compressed executable can still be executed in previous posts, but anyway, the compression process puts in the "top" of the execution chain a stub able to decompress the remaining data during runtime (of course the execution time will be little bit longer since the decompression procedure).




3) Lets compare the sizes. The above picture shows the different size of both macho files: the compressed executable 707K and the uncompressed one 3.2M. Well, what cha we say if not good job UPX folks !

Wednesday, February 16, 2011

Types of Malicious Hacker

This article from infoworld shows up 7 different types of hackers offering a nice explanation. I like taxonomies and I also use to catalog hackers during my classes, depending on targets technical skills and social background (for example, political, social, religious and so forth). For this particular reason I do like Grimes' taxonomy on the Hacker Differentiation.


Roger Grimes' Hacker Taxonomy:
  1. Cyber criminals
  2. Spammers and adware spreaders
  3. Advanced persistent threat (APT) agents
  4. Corporate spies
  5. Hactivists
  6. Cyber warriors
  7. Rogue hackers
Today I suggest the small reading from infoworld, it provides a clear evidence of what are the differences between malicious hackers helping people to prevent attacks by keeping out systems from their intents.

Thursday, February 10, 2011

Disassembly Desynchronization Overview

Hi folks, today I would post on Anti-Static Analysis Techniques.
The primary purpose of Anti-Static Analysis Technique is to prevent an analyst from understanding the nature of a program without actually running the program. There are many different types of Anti-Static Analysis Techniques such as: Disassembly Desynchronization, Dynamically Computed Target Address, Opcode Obfuscation, Imported Function Obfuscation and Target Attacks on Analysis Tools.

Today I am going to give you a short overview on the first and probably the oldest techniques called disassembly desynchronization. This technique consists in executing a function call (as well as a jump) into the middle of another function code. In this way the decompiler, taking the first 5-bytes as instruction set, decodes wrong instructions confusing the revers engineer. So lets say to have a call near ptr 00000003 located in 00000001. Supposing the real function starts at 00000004 and calling 00000003 we are desynchronizing the assembly instruction set because the disassembler starts to decode instruction set from the wrong offset. In fact after the "call" the decompiler will decode one byte wrong instruction set propagating the error around the code. The following image shows you how this techniques is possible by modifying the calling addressing (loc_X+1 and loc_Y+2).



One of the most famous implementation of this techniques is Shiva. What shiva does is to map the executable in the following way:



The Shiva runtime block is the decryption point where it performs (in order): Anti-Static Reverse Engineer checks, allocating memory heaps, cloning dynamic monitor process and decrypting encrypted blocks (in the figure Block 3). Shiva Block 2 is optional, it is a password protected AES where the key is obfuscated into the encrypted code (it uses Tiny Encryption Algorithm with 128 bit of key). The encryption phase happens as previously described (loc_x+1, loc_y+2) by adding offsets to jumps, functions call or more generally speaking by misaligning the binary decoding process. The decryption phase works (of course) oppositely, by setting the right offsets.

Shiva divides encrypted blocks in two sets: (i) data set, aligned to natural ends of variable length, and (ii) code set partitioned about 1K in size. It keeps unused memory space filled up with 0xCC (INT3, basically jump to empty location memory), in response Shiva decrypts and maps the needed memory page.

There are many different ways to detect this kind of obfuscation and many different tools like for example IDA-Plugins or external program running emulation techniques. IDA emulation record list contains enough information to rebuild the right code blocks, once rebuilt the right (decrypted) code blocks, it becomes possible to generate ELF headers and segments to construct a separated and unwrapped binary. Beside IDA pro, another interesting tool called stripshiva; a command line tools containing a x86 emulator which performs the decoding steps as IDA does.



As shown in the previous figure, stripshiva runs the starting block and the overall program, in the meanwhile a "kind of " monitor engine records each stripped (or decoded) block. Once the program ends running stripshiva builds an ELF containing the decoded and ordered blocks: you are ready to go by analyzing the stripshiva outcome !

Obviously there are many different ways in both sides: Disassembly Desynchronization and Disassembly Synchronization. Goal of this post is not to explain how each of it works (for these purposes there are books and research papers, that actually are very good in this field) but to give a light flavor on the topic introducing the reader into Disassembly Desynchronization topic.

Saturday, February 5, 2011

ONDM 2011, I'll be there !

This year I am in the organization board of ONDM 2011. To everybody interested on network security, see you there ;) ! From Monday to Thursday, Bologna (ITALY) I am coming !