How To Head Off ATA HDD Password Abuse

An anonymous reader submits "German c't magazine has a story about abusing the security features of ATA hard disks. The bottom line is that almost all ATA hard disks in desktop PCs can be password-protected. However, on most desktop PCs, the BIOS does not support locking this option -- so viruses or malware could set a random password, making any data unreadable unless recovered by professionals."

Comments

why would you do this?

[Doppler00]

Why on earth would you want to password "protect" a hard drive? How would that be any better than properly encrypting your files?

Re:why would you do this?

[darkwhite]

If you have started the machine and logged in, it is assumed that you are actually in control of the machine and its environment. The proper way to protect a running machine is to lock the screen and the bootloader (so the only way to get local access to the disk is to power cycle and face the master password) and to have a secured network interface (which you can never be 100% sure about but you can get pretty close).

Of course, if you have a trojan installed or are being held hostage, these security principles don't work. The ATA password feature was designed to protect corporate data without the slowdown and incompatibilities possible when using software encryption.

Re:why would you do this?

[archen]

My understanding is that this was intended mainly for laptops. I'm not sure how long this has been a part of the standard, but I wouldn't be surprised if many laptops were still being distributed with Windows 98 when this was drawn up. Is it better than encrypting your files? Well of course not, but it doesn't slow down the hardware at all, and it's rather simple.

But how safe is encrypting your files? What algorithm does it use? Is it implemented properly? Even if you know for sure, someone can read the data off the drive use a brute force attack (impractical but possible). With the ata password you can't (easily) read anything off the drive short of a raw read off of the platters, so I wouldn't say it's that bad of an idea.

I'm just sort of curious how this would affect ATA RAID controllers. Would it pass such a command through, or just ignore it?

Re:why would you do this?

[that _evil _gleek]

Ya.
This is just supesition but I'm assuming if 1 enables this in the bios, your password is then stored
in bios's cmos memory and the bios then uses that to unlock the drive, to the support an autoboot feature.
so the machine can boot by itself , w/o user interaction. So any computer that someone could just snatch and grab
will likely autoboot and unlock the drive, and not be very good security, maybe for office desktops where maybe
someone could open the case, take the drive , but not abscond with the the whole machine.

Of course, there could be a CMOS bios lock as well, and if the password is there and booting options restricted,
then if one zaps the cmos via jumper, one loses the drive password, and that could work pretty well for security,
Though if it send to autoboot a cd or floppy , it would be easy to get the appropiate cmos util, run it to clear
the password, then steal drive password. If the bios was set to only boot the locked drive, then 1 might be able to
replace the drive, maybe using 1 with exact same parameters ( if auto config is off), and boot (then steal info from cmos again) unless the bios will refuse to boot an unlocked the drive -- I mean if the bios goes to trouble of checking that
the drive is locked... again just guessing but if a locked drive just returns ERR_LOCKED or whatever to any ati command
then the bios might only try to unlock the drive, if its locked... so swapping drives might work.. Considering a good implementation and good user behavior , it could be good. Also if you can't lock a drive w/o the old password..

Now if the above is true, and the hacker knows the CMOS of the machine very well, then its possible that a prog
could access the cmos memory lock down the cmos setting to only boot the now infected drive, put the drive password
in cmos (its probably encrypted with some simple hash, but assume he or she has broken that ) , now do the drive lock,
and 0wn the machine... Now the user is locked in. He or she has noticed that his computer is slower, but he can't
do anything about it, and he can't boot to trusted media, because the cmos is locked, if the cmos is zapped the drive password is lost and all data is lost, he can use the machine but has to live with slowdowns as the machine is used for ddos attacks and the like.

Re:the word being "could"

[Tony Hoyle]

It depends... in nature viruses silently reproduce before killing the host. There's no reason why computer viruses couldn't do the same - this would be very effective.

Re:professional?

[Cylix]

Eh,
you can wipe the disk for a recover if the master password is tampered.

Read the provided roxbox link.

Security hole?

[Gzip Christ]

How is this any worse than if a virus were to erase the hard drive?

Or even worse

[dilvish_the_damned]

What if someone encrypts all your data one night? You show up for work one morning only to find the latest worm has encrypted all your data and it forces you to recite the lyrics to ELOs Another Heart Breaks ("one, two, three," etc..) before you can get at your data again. Look, if it has enough access to reset the password on your ATA drive, you probably have bigger issues to worry about, like the gaping hole in your OS that allows user code direct access to your hardware.

Re:the word being "could"

[Lord Kano]

What if someone is trying to get revenge on a former employer?

Design the virus to propogade for a fixed period of time and then lock down all of the hard drives over night.

LK

Re:I love how they plan to force apple to comply

[theid0]

to the effect that we will program a demonstration of the damaging action and make it available to Apple

This seems to imply that it has not yet been done. Any hardware changes that I have done (Open Firmware changes, DVD region set) have needed an admin password.

However, in the article it basically says that the machine has to compromised PRIOR to startup (when the security extension loads). If someone already has access to your machine with an admin password, I really don't see the point in locking the drive. There are easier ways to pull a prank or cause damage.

Re:professional?

[Qzukk]

There are two options, use a logic analyzer and try to intercept the pieces of the password on it's way in to generate the checksum (haven't heard of anyone being able to accomplish this), or take the drive apart in a clean room, erase the password of the platters and attach a virgin controller ....

If this is just password protection and not encryption, wouldn't it be simpler to replace the drive controller with one using firmware that ignores the password? I'm certain the drive manufacturers would have a few of these laying around.

Re:professional?

[Spoing]

1. 1. Why the heck can't you just replace the chip with the flash with a new one?

   The password is duplicated on each platter, so the new firmware will read the password and halt again.

Since the controller likely reads the password and stores it, if you can remove the flash chip, and you know what pin is the write pin, you should be able to;

Get duplicate drive.

Yank the rom and flash chip from the duplicate and break the write pin.

Swap the chips or just the boards.

Boot. (The password can't be written back to flash.)

Passwords are ignored.

Copy data off of the drive.

The downside being that you now have two useless drives, though you could swap in the flash chip from the protected drive to see if it can be used in the new duplicate.

Dell BIOS HD Flaws

[__aaijsn7246]

In general, these features don't seem coded to well. Here's a post I made to Bugtraq back in December of 2003.

The Dell BIOS allows users to set several different passwords to protect
their machines from unauthorised access. There is 1) a Setup Password,
which is required to enter the BIOS setup, as well as 2) a Hard Drive
Password, as per the ATA Security Feature Set Specification.

Unfortunately, once a Hard Drive Password is set which contains one or
more of the following characters,

, . ; : ' [ ] { }

it can not be later entered to access the machine. It appears as though
a bug in the BIOS code prevents those characters from being taken as
input when the user is asked for the password - however, the BIOS
incorrectly allows users to set passwords containing those characters.

This is not an incredibly serious problem as such, since a user can go
back into the BIOS setup and change the password there, provided the
BIOS Setup is not protected with an unknown password. Or, as a last
resort, Dell can be phoned to provide a master backdoor password, as
long as the user can prove herself the legal owner of the computer. Of
course, the prerequisite of physical access to the machine highly
mitigates this vulnerability.

It is however an interesting bug from the point of view of Dell's
practices. I have contacted them over two weeks ago, but their
'technical support' is unable to understand or resolve the problem. Two
of their representatives told me to reinstall Windows XP Chipset
drivers, even when I asked to be forwarded to people higher in the
technical support chain. Perhaps this post will encourage Dell to pay
more attention in the future.

Affected Systems: Dell Inspiron 2650 System BIOS, A11
(A11 is the current BIOS as of writing, and was released in late
September of this year)
Other BIOS/Dell models are perhaps vulnerable but have not been tested.

Re:professional?

[Lehk228]

yes there is, get an identical drive and swap the logic boards.

Re:professional?

[darkwhite]

The controller likely reads the password from the platter on each power up and stores it in the on-chip cache or the SDRAM (the modern ATA drive controller has to be a full-featured processor). It most likely doesn't copy the password to the flash.

If it puts the password in the SDRAM and you try to yank the SDRAM write pin, the controller probably won't start at all. However, if you tap the memory bus, you might be able to issue your own command to erase the password in the RAM while the controller is running.

Simple FPGA interface?

[xtal]

I've been doing more work with FPGA's recently:

If this is the case, there are some IDE controller projects available on opencores. It shouldn't be a serious problem for someone to build a board that would allow you to mount the drive so you can copy data off of it - there are also open, well tested, PCI bridge modules freely available now.

http://www.opencores.org/browse.cgi/by_category

If it is indeed the serious concern that people indicate, and it can be broken by the means you suggest - I challenge someone with a few dollars to donate it to opencores with the objective of getting this done.

Indeed, the "sticking it to the man" factor is high enough that I am intrigued enough to have a more in depth look. :)

easy prevention: only set administrator password?

[F�an�ro]

the way i understood it, there are two passwords: user password and administrator password.

Access to the harddrive will only be prevented if the user password is set, but the user password can only be set when the administrator password is known.

So if I only set the administrator password, then the drive can be accessed as usual, but the user password cannot be set by some software.

Correct? or did I misunderstand that?