Hacker Mindset - General Theory of Laziness

When approaching computer forensics I try to put myself in the shoes of the subject of the case. In intrusions I try to think like the attacker... This is the inaugural post of a tag series I'll call mindset. During this series I'll try to uncover the thought process behind different types of hackers and show how understanding their individual nuances can increase your proficiency in examining intrusions.

In this post I reveal the base principle I use in examining an intrusion:

General Theory of Laziness

The theory works like this: Given two solutions that meet the attacker's requirements, the attacker will use the solution that is "easiest" to implement.

Therefore, considering the attacker's objectives are met by the solution...

1. The easiest attack vector will be used
2. Files of Interest will be in a relatively tight-knit location and time frame
3. Multiple types of system events will be occurring in a tight-knit time frame, for example: log file entries at the same time as binaries being modified or created on the system
4. Malicious behavior will be obfuscated no more than required
5. Malicious binaries will reside in a system PATH location or other easily accessible location
6. Malicious binaries will not contain convincing extended Copyright, Program, Version or other 'normal' executable information (Right-click -> Properties)
7. Spell checking will be obviously overlooked
8. Full error checking is really hard, expect use of Windows System libraries to make life easier

Case Studies:Let's look at some different examples and identify areas that highlight this theory and places we would expect to see exceptions.
Professional Intellectual Property Thief
- Objectives: Gather one or more particular types of information from a given Target taking care to not identify the "customer" this data will be given to or that the proprietary information is even being taken.
- Prolonged access may be necessary, attacker may make more of a conscious effort to hide the backdoor.
- Secretive ex-filtration of data is critical, malicious communication may be highly obfuscated or even encrypted.

Script Kiddy- Objectives: Gain community credibility, gain competence in intruding.
- Expect to see the noisiest intrusion ever. Lots of security log errors, possible service crashes etc.

Bot-Net Intruder/Manager
- Objectives: Take control of as many systems as possible.
- Security is not a priority, mass infiltration is. Expect binaries that attempt to self-propagate, call to their controller often and are not hidden or obfuscated well.

Expect to see more on these topics in the future.

Do you agree or disagree? Let me know in the comments!

RAID Part 2, RAID 5

I am going to talk a bit today about the various configurations of RAID 5. As I have mentioned before, RAID is not a standard, but a concept of how to use multiple disks as a single device. First defined by the paper "A Case for Redundant Arrays of Inexpensive Disks (RAID)” by Gibson, Katz, and Patterson in 1988 by the CS powerhouse of the time…you guessed it, Berkley. However, the paper described the concept of RAID, it did not define a standard nor was the concept ever boiled down to one. As a result, RAID 5, or most any other RAID level, is implemented differently by each manufacturer. This makes it difficult indeed to recover an array when things go bad.
The concept of RAID 5 is striping with rotating parity. The idea is that data is written in blocks to an ordered disk set and one of the disks for every stripe contains the parity (simple XOR) of the data in the stripe. There are a bunch of sites out there that explain this, but the basic idea is that the data from each data block in the stripe is XOR’ed with the others, the result of which is written to the parity block. Thus, if a disk fails, the data from the remaining blocks can be XOR’ed to reconstruct the missing disk. The parity level is the number of data blocks plus the parity block, e.g. parity 3 (p3) is two data blocks plus parity. Since the parity block and its member blocks must each be located on a unique disk, the maximum number of blocks per pass is the number of disks minus one (n-1). While it is of the norm to see the parity level equal the number of disks in a set, it is not a requirement. Therefore, the parity level can equal any number between 3 and the number of disks in the array, which can cause al sorts of headaches for those trying to recover data off a dead array.

RAID 5 can be broken down into four different methods. There are certainly more variations on these methods which I will talk about in another article, but this is the best place to start. The methods are left asymmetrical, left symmetrical, right asymmetrical, and right symmetrical. For the purpose of the explanation, I am going to ignore block sizes and iteration (delayed rotation), which must be known or discovered to recover data.

Left asymmetrical is most employed by hardware RAID cards. It writes data to blocks n, n+1, n+2, … n-1 then parities those data blocks to the last block so that the resulting sequence is n, n+1, n+2…n-1, p. Parity is then rotated left (backwards) one block so that the sequence is n, n+1, n+2…p, n-1.

left-asymmetrical RAID 5, Parity 5, on 5 disks

This is probably the simplest form of RAID 5 to understand; however, from a performance standpoint, the system can read only from Parity-1 blocks before running to the possibility of reading a disk twice. This is where symmetrical RAID 5 comes in. Here this blocks are written as before, n, n+1, n+2...n-1,p; however, instead of the next block being written to next sequential device, it is written after the parity block (which is below the previous parity block) and the stripe is written in-line from that point on, until it wraps to the parity block. This method allows for all blocks in a stripe to be read.


left-symmetrical RAID 5, parity 5, on 5 disks

There are the right hand versions of the above as well. Right asymmetrical starts with the parity block at the first placement, and rotates right. The first data block in the stripe is always in the first placement (except when the parity block is located there, then it is incremented).


right-asymmetrical RAID 5, parity 5, on 5 disks
Right symmetrical writes the data blocks following the parity block, as with its left rotating brother, it writes data following the parity block and wraps around until it reaches the parity block again.


Right symmetrical RAID 5, parity 5, on 5 disks


Adding to the confusion
In the above examples, we looked at RAID 5, parity 5, on 5 disks. The parity level could be any integer greater than or equal to 3. To make things more difficult, the number of disks is not limited to parity level. They can number greater than or equal to the parity level. Lets take a look at a left-asymmetrical RAID 5, parity 4, on 5 disks.


Left asymmetrical RAID 5, parity 4, on 5 disks
Here the data is striped with three data blocks and a parity block, which is parity 4. However, in the second stripe, position 0 is on the first block or the 5th disk, so the beginning of the stripe starts there. Notice that if we did not know the configuration of the array, we would end up with 2 parity blocks in some rows.
In the next installment, I will talk about rotation iteration (delay), block sizes, and ways to determine parity levels. Stay tuned.
j

Powered by Qumana

RAID Tool Update

I have released a FUSE file system that can put together an asymmetrical RAID 5 with any parity level and any iteration level. I don't have any controllers to test the thing on other than the Compaq one it was developed with. Remember this tool is a proof of concept, use it accordingly. I am working on the update to this tool that will use one single fuse mount command and plugins to add "files" at will. Reassembled RAID images will be the first of these files and it will allow for compound RAID with only one fuse instance running.

If your interested in the tool, check it out at http://raidfs.sourceforge.net/ or download at http://sourceforge.net/search/?type_of_search=soft&words=raidfs

Jason

Powered by Qumana

RAID Part 1

Large dataset analysis and recovery has been an interest of mine for some time. The server room is vastly important in today’s business enviroments and is increasingly part of any investigation involving business, including small businesses. Unfortunately, computer forensics is slow to catch up to this trend and has all but neglected designing tools to approach large datasets and has instead continued its trend to focus on the home user machines. While I understand this is where the bang for the buck is in the industry, it does leave a gaping hole that needs to be filled. Thus my interest ;-)

RAID is one such subset of my interest in this area. Encase and X-Ways have RAID reconstruction functionality, but it is very limited. They seem to have designed their algorythms for this functionality as an afterthought or stub, again a bang for the buck issue. The problem with RAID is that it is not standardized. Sure there is a loose definition of each type of RAID, RAID 0-6 and such; however, there is not implementation standard. For example, a RAID5 from Compaq looks nothing like a RAID5 from Adaptec. For example, configuration information information is stored in different locations/sizes and parity rotatation is implemented differently. It is not just the direction of rotation either but the iteration of rotation. In short it is just a mess.

So I am working on a program to deal with this. Actually, I started it some time ago and I have now come back to it. I will release the program on sourceforge when I feel it is at least to alpha quality and properly documented. It should handle every structured RAID from 0 – 5, regardless of rotation direction, number of disks, rotation iteration, blocksize, or parity level. Next I will move on to a program that evalutes component disks and deduces likely configurations.

j

Getting Started

I am moving on to fight the good fight in another venue. After working/running the Intrusions Forensics team at DCFL for 5 years, I am moving over to the commercial side. One of the things I have on my mind is working on the exchange of vital information on techniques and tactics for dealing with Intrusion Forensics and Malware Analysis. There is lots of information out there on traditional computer forensics and lots of information on network defense; however, intrusions forensics and malware analysis is somewhere in between. This blog is a start, hopefully not a false start, at getting information out there to those that care.

Jason