dd

On destroying data

The Known Plaintext blog has a pretty interesting high-level article called Ten Commandments of Data Destruction, which gives some advice on how to handle destruction of data on hard drives or USB thumb drives (e.g. if you want to sell them on eBay)...

While most of the stuff is good advice, there's one thing in there which is certainly not a good idea: "format your hard drive before giving it to the recycler"! That will usually not help at all! Don't ever think that formatting will really erase your data! Using simple, and widely-available tools everybody could restore data from such a formatted drive, even without requiring any costly equipment.

If you absolutely must sell or give away an old hard drive (physical destruction is always better!), wipe it with a Gutmann-style tool, such as wipe(1), or shred(1). Oh, and apply the tools to the raw partitions (e.g. /dev/hda) after booting from a live CD. Wiping single files on a mounted file system might not yield the expected results on some (journalled) file systems, because they are caching stuff etc...

The follow-up article presents some further ideas, e.g. an acid bath for your hard drive. It also mentions that simply breaking the read/write head or the motor of the disk might not suffice, forensics labs could replace those parts successfully...

David Bianco makes a very good point about data on company laptops (especially so if you consider the alarmingly high rate of "laptop theft, xxx million data records lost"-type news stories): "don't put the freakin' data on the laptop in the first place!".

(via Jesse Kornblum)

Computer Forensics Wiki

For everyone who might be interested in computer forensics, data recovery (e.g. ext2/vfat undelete), file system internals, digital evidence, or just playing around with dd, The Sleuth Kit or similar tools:

Checkout Simson Garfinkel's Forensics Wiki which gathers information on the above topics and many more. The content is licensed under the Creative Commons Attribution-ShareAlike 2.5 license.

Contributors welcome!

How to dump your BIOS/LILO/root password as plain text [Update]

This is old news by now, but still interesting IMHO. Jonathan Brossard has posted an article on BugTraq which gives a pretty good introduction to the inner workings of the BIOS (with lots of links to more detailed resources) as well as known vulnerabilities of the BIOS password mechanism.

The most interesting part is when he explains that the BIOS doesn't seem to erase its own keyboard buffer before it hands over control to the operating system. Also, current OSes (Linux, Windows, *BSD, etc.) don't seem to clear that buffer either.

This may not sound dangerous, but it actually allows anyone who can read the contents of your RAM, starting from address 0x041e, to view the keyboard buffer contents. And this buffer contains the BIOS password you type in when booting your machine (if you set/use a BIOS password, of course).

This one-liner (executed as root) should let you view your password as plain text:

dd if=/dev/mem bs=512 skip=2 count=1 | hexdump -C | head

(Only every second character belongs to the password, the rest are key scan codes, I think).

I also noticed that this same buffer also contains your LILO password, too! The same is probably true for passwords of other boot loaders such as GRUB, but I didn't test that.

Yes, reading this part of the RAM usually requires root privileges in Unix-like OSes, but as the security problem is OS-independant other OSes (e.g. DOS, or older Windows versions) might be directly affected.

But even on more secure OSes this plain-text storage of the BIOS/boot loader passwords might be a problem. Combine this with some Firewire insecurities and attackers with physical access to your machine (e.g. your unattended laptop, while you are on the toilet) might be able to read your BIOS/LILO passwords even though you locked your machine. I haven't yet tried this, but I'm pretty sure it's possible. Please post the results here if you try this.

(via Stefan 'Sec' Zehl)

Update 2006-01-09: It seems that when you use software suspend (swsuspend2) the RAM area can/will also contain your root password! Thanks nelson for reporting.

Syndicate content