'Super' Computing!

It's been a big day! My supercomputer arrived in a rather large box, much to the obvious annoyance of the delivery man who had to drag the thing 30 yards as he couldn't get the van up the lane near the office.

Unwrapped and connected up to a suitably large screen the beasty purred into life and promptly crashed. No Apple technology here. Side off, found a couple of loose cards,tighten up, reboot and we are away.

The machine is based on AMD motherboard technology with 2 uber ATI 4870X2 boards providing 800 parallel processing cores per board giving a total of 1600 processing cores. With the right software designed for GPU parallel processing it will chug along at 2.4 terraflops or 2.4 trillion floating point calculations per second.

The definition of a supercomputer is 1 trillion terraflops and the first one was built by Intel just 11 years ago, it took up 2000 sq ft of space. 11 years on I have a machine 2 1/2 times more powerful under my desk, the lights dim when I fire it up but you can't have everything!

I've bought it to carry out super fast password cracking, I can chew through 60,000 passwords per second or 5.1 billion per day which is some work rate especially when using intelligent varying dictionary based attacks. Instead of pure brute forcing which is all down to key space (password length * all possible combinations), an intelligent varying dictionary attack takes a word such as 'password' and attempts all likely variations such as :-

pa55word
pa55wOrd
6a55w0rd
password1
password123 etc etc

Using this process a 3 million word dictionary can quickly be turned into a 150 million word table or much more. When done 60,000 times per second you can try an awful lot of variations and the success rate becomes very high indeed. A completely, pattern free, randomized password/phrase will still require brute forcing and we will all probably retire before a guaranteed success.

The new software I'm using focuses on WPA 4 way handshake attacks, you can check it out here. Other software allows the GPU accelerated attacks against Office files and loads of others.

My first job arrived from a Police Department yesterday so we shall see how it goes.

We're jamming

Again, I have been neglecting my blog and I apologise! Little one was in hospital for the first 2 weeks of the year and I've taken 3 weeks to catch up.

Continuing with the wireless attack theme I came across an interesting way (illegal) to force a deauth. As some of you will know, to get the 4-way handshake needed for WPA cracking you need to force a authentication of a client and pick up the transaction of packets as it reauthenticates. However, this is easier said than done and does not always work.

One way to ensure deauth is to employ a hardware wifi jammer. You can readily source from the Far East a jammer with 30+ft range which is sufficient to take out a house's wifi network whilst walking by. Now I am at pains to say that jamming a radio signal in the UK is illegal and I mention this only for my LE friends who may be able to get the appropriate clearances/warrant to achieve a deauth this way. Of course you would need an antenna faced on the property ready and running Kismet or Airodump to grab the packets as the reauth takes place. I wrote some great Linux Shell scripts to automate the process recently to achieve just this type of situation.

I wont publish where to purchase them, you can always get in touch.

You can also pick up a GSM jammer while you have your credit card out and next time you see in your rear view mirror the lorry driver chatting on the phone whilst passing the local primary school you could have the satisfaction of hitting the button and jamming his call. Oh if only it was legal!!

WPA Cracking

In Yorkshire on holiday with the extended family. Touch of man flu!

Its been a while since my last post as life has been flat out. Just a week back I taught the first LE only wireless attack course. I taught it at the Defford SB facility which was perfect, as apart from a bunch of huge radio telescopes there is no wireless interference at all.

What was interesting was the vast difference made by different antenna's. I guess this is obvious but I had the chance to really test the differences between the omni-directional and directional antennas I had available. The out and out winner was the 12dbi directional 'can' antenna which took us to the edge of the facility, at least 100 meters from the Access Point with plenty of power left over. Having returned to the office I thought I would invest in a parabolic mesh antenna slated as 24dbi. I bought 2, one for me and one for an operation I'm working on with a Police force. When they arrived they were HUGE! When put together the dish was at least 70cm square, not terribly useful in a covert setting. When hooked up the coverage was astonishing, I reckon that 1km could be possible with clear line of sight.

As WPA cracking is very reliant on a dictionary attack it is interesting to note that Elcomsoft are releasing a WPA specific cracking tool that uses a dictionary attack associated with GPU acceleration which is very exciting. They have offered me a beta copy and I will let you know how it goes.

The company already has brute force cracking a ability of WPA passphrases with GPU acceleration which the press have been having a field day over, saying WPA is dead. In reality a box with 2 super fast NVIDIA GTX 280 cards in will still take 3 months to break an 8 character password. I think the new dictionary version will be much faster.

We shall see...

Just take what you need!

Sat in Brussels airport, flight delayed for 2 hours, 10pm :(

I’ve been presenting today at the European Network Forensics and Security Conference in Holland. It is not a big event but there were some very interesting people in attendance including Laura Chappell from Wireshark University and James Lyle from NIST. I had not met either before but look forward to communicating more with them in the future.

I was presenting today on the subject of extracting just the information we perceive we need from a case rather an always imaging an entire drive, or more commonly now, a gaggle, bunch, collection (what is the term for multiple drives) of drives which regularly can exceed a TB. Now I know the purists amongst you will shout foul, the whole drive is best evidence and I do not disagree with you; but when dealing with, for example, a fraud case where the predominant evidence will be found in email, an accounting partition and chat logs, why ‘initially’ image vast amounts of data when we know where to start. It is very straight forward to image out just a .pst file or just take a partition and this can reduce processing and searching times tremendously. This does not mean that you never image the drive, however when we have multiple machines to look at why initially image them all when the pertinent data might be available in key containers.

A number of Police Forces in the UK and I’m led to believe ACPO too are looking at a methodology of pre-imaging triage to try and reduce workloads and backlogs and I am in general agreement with this.

There are a bunch of ways of extracting what you need. On a live machine you can simply write your own script to search a machine and extract just the files you need. For example, open notepad and just enter:-

xcopy "%systemdrive%\documents and settings\*.pst" /h /s

..save the text file as a batch file (myprog.bat) and put it on a USB key or external drive. When you plug the drive in to a machine and run the batch file it will search all folders under documents and settings and copy back any .pst file it finds. Easy as that! You could make a couple of subtle changes and it would find and copy back all the thumbs.db files which you could parse out in Encase, FTK, Vinetto and have a pretty good idea what images were on the machine. Quite handy.

xcopy "%systemdrive%\documents and settings\*bs.db" /h /s

If you want things to feel a bit more ‘forensic’ then use dd on the target system to extract what you need:-

dd if=\outlook.pst of=e:\harvest\outlook.dd conv=noerror

You could use this method with Helix and use either the Windows terminal on a live machine or boot to the swanky new Ubuntu Linux side and do it there. You can then MD5 the file and off you go.

md5sum > md5.txt

The argument is even more compelling with live servers in a corporate environment. Tell a sysadmin that you are going to shut down his email server for 8 hours while you image it and he will go a rather nasty colour. Do a live response and just take the pertinent .edb or whatever, files and everyone is happy and you likely have all you need. The same argument can be made when looking at a RAID array. The ‘Financial Director’ under investigation will rarely, if ever, have access to the RAID controller to hide any data anywhere clever on the array disks. So in that situation, do a live response on his machine and figure out what disk partitions/folders he has access to and just go and get those. Imaging the appropriate partition on a RAID will give you everything you need and saves a shed load of time trying to figure out the striping pattern.

I appreciate this blog entry is overly simplistic and all these decisions should be made on a case by case basis with full comprehension of what is potentially being missed, however the modern investigator should be aware of these techniques and use them where appropriate.

Backtrack 3 on the Asus EEE (that rhymes!)

I mentioned a few posts ago about the wonders of the tiny Asus EEE. I’ve just had the latest 901 version delivered with 8 hours battery life and an Intel Atom processor. One of the coolest things I’ve been doing is booting the machine to an alternative OS on an SD card. Perhaps one of the most useful is the ability to boot to the Backtrack distro. It means that you have your tiny portable machine totally ready to carry out sysadmin tasks and even wireless cracking using the inbuilt Atheros wireless chipset.

However getting Backtrack 3 to boot on the EEE has been a problem and a number of forums have questions about it. When you download the bootable USB version (http://www.remote-exploit.org/cgi-bin/fileget?version=bt3-usb) there is a helpful text file telling you which files to copy to the USB key or SD card, then simply browse to the ‘Boot’ folder on the card and run the ./bootinst.sh script. To get a command shell up in the EEE Xandros Linux distro just hold down CTRL-SHIFT-T. Then as if by magic you can boot to Backtrack by simply holding down the ESC key at boot time.

However, a number of people have noted that it seems impossible to run the shell script. You simply get an error message. The solution is very simple. If you look at the permissions for the script (ls -la) you will note that the files on the SD card do not have execute permissions. If you try and change the permissions:-

chmod 777 bootinst.sh

..it pretends to work but another look at ls -la and you see that it hasnt.

The problem is to do with the mount permissions for the device as a whole. If you execute the ‘mount’ command you will see that the device is mounted with the noexec flag set and that is what is messing things up! With no other keys or devices plugged in it seems to always mount at /media/D:, so.. simply unmount the device:-

umount /media/D:

then remount with the following:-

mount -o rw /dev/sdc1 /media/D:

Dropping the noexec flag makes the files executable. Now just browse back to the right directory:-

cd /media/D:/boot

then execute the shell

./bootinst.sh

That’s it, now you can reboot to BT3. Have fun.

The way Linux pages data

I've been spending some more time looking at why the bad sectors on the NIST tests (see last post) were in the middle of a read run. In their conclusions they state that:-

"Up to seven accessible sectors adjacent to a faulty sector may be missed when imaged with dd based tools in the Linux environment directly from the ATA interface."

This doesn't seem to make any sense if we are saying that some sectors are skipped when a bad sector is encountered. Surely it would always be the first sector with later sectors skipped? This explanation seems to go some of the way in finding a solution.

When dd requests a block, the mapping layer figures the position of the data on the disk via its logical block number. The kernel issues the read operation and the generic block layer kicks off the I/O operation to copy the data. Each transfer of data involves not just the block in question but also blocks that are adjacent to the required block. Hence a 4096byte 'page' transfered from the device to the block buffering layer in the kernel (often a page segment in RAM) will contain the bad block and adjacent 'good' blocks.

If you have a 4096byte page with a single 512byte bad block you will have, wait for it, 7 good 512byte blocks in that page. This fits with the observations of NIST that 7 sectors may be missed, obviously something bad is happening to the entire 4096byte page.

They then go on to conclude that:-

"For imaging with dd over the firewire interface, the length of runs of missed sectors associated with a single, isolated faulty sector was a multiple of eight sectors."

This makes perfect sense, as the kernel pages the data in 4096byte blocks including 7 good and 1 bad sectors, any 'loss' of data by the block buffering layer would be in 'whole pages' or 8 sector multiples. Am I making any sense?

Hence, I'm reasoning that when dd hits a bad block, something is happening to the block buffering layer to either overwrite, clear or otherwise remove some or all of the buffered pages. The speed of the differences in moving blocks to and from different media such as ATA rather than firewire may help to explain the different numbers of lost pages. e.g. there is physically more or less data in the buffer when it gets deleted/wiped/overwritten etc.

I now need to look at why the buffer is possibly being affected. Any comments are welcomed!

Link to the NIST research on dd isues

I've written a couple of simple overviews of the issues surrounding dd and the seeming lost sectors when bad blocks are encountered. I neglected in my previous posts to include a link to the research by NIST at http://dfrws.org/2007/proceedings/p13-lyle.pdf.

Speaking to both Drew Fahey and Barry Grundy the feeling is that there is no reason to overreact, virtually every tool we use has some flaw or another, however further research is needed to be clear about the issue and how to circumvent it.

I'm off to present at the ACPO conference tomorrow and I'm sure the subject will come up, I'll post any interesting comments.