One of the truths of computer security, to which there are a few exceptions. See also: physical security.

Even if a system is impenetrable from over a network, unrestricted physical access is an easily forgotten or disregarded security vulnerability. If an attacker can simply walk into the room the machine is in without restriction of her actions there, it is only a matter of time before she can begin to do Bad Things to it, such as changing its root password.

Means by which to exploit such a weakness include:

Exploit a lack of access control on the console.
Some operating systems, such as Microsoft Windows, do not or can be configured not to require someone at the machine's console to authenticate (usually by entering a password) at all. Alternatively, if the system does require such authentication at the console, but someone is still logged in there, then you can use whatever privileges they have, such as access to sensitive data.

Exploit a lack of access control in the boot loader.
This can be accomplished by means such as pressing F8 while recent versions of Microsoft Windows are booting, specifying 'init=/bin/sh' as a boot parameter to Linux (usually done at LILO's 'boot:' prompt), etc.

Use a bootable floppy disk or CD-ROM.
Reboot the machine and boot from it, and voila, you can do whatever you like. The program on your boot disk might simply give you an unrestricted command prompt, or it might be some automated procedure for e.g. installing a rootkit. The machine's BIOS might be set to not boot from floppy or CD-ROM, in which case that setting will need to be changed. On an IBM PC-like machine, if a BIOS password is set which prevents this, it can be removed by opening up the chassis and pulling out the battery on its motherboard that powers the NVRAM that holds this password. However, all of the other BIOS settings will be erased as well!

Pull the recording media.
If you only need to get at what's on it, and you have the time, you can simply power off the machine, physically remove its recording media (usually one or more hard disks), and leave. The machine probably won't work after you do this, in which case it will be apparent that someone has done something to it; if you close everything up and make it look like it hasn't been tampered with (e.g., by replacing the chassis cover and plugging everything back in), it may take longer for someone to realize what's happened.

Swipe the whole thing.
If you can do so without being noticed or stopped, you may want to unplug the entire machine and haul it out. Stealing the machine outright means that, aside from getting at whatever is on its recording media, you can then use the machine itself for a new Web server or something. :) The viability of this method is significantly affected by the physical size of the machine: laptops and PDAs are a lot easier to steal than mainframes.

Destroy the machine.
If you only need to sabotage the system, rather than use it or get at its data, it might be easier or otherwise more viable to simply render the machine permanently inoperable. There are, of course, plenty of ways to accomplish this: shoot it, blow it up, hack it to pieces with an axe, etc. Use your imagination. It will probably be important that any recording media are properly destroyed, so a post-mortem inspection of the machine before leaving would be wise.

There are, of course, countermeasures:

BIOS settings.
Setting the BIOS to require a password to change BIOS settings and not boot from removable media will, at the very least, slow an attacker down.

Boot loader settings.
Setting the boot loader to require a password to do anything other than a normal boot would prevent attacks that exploit the lack of such restrictions.

Deny physical access to the machine itself.
If an attacker only has physical access to the console, and the console requires authentication as described above, the attacker will not be able to compromise the system by removing its recording media, etc.

Deny physical access, period.
Keeping the whole machine — console and all — under lock and key will theoretically deny physical access entirely, preventing all of the above attacks. Of course, if the attacker can penetrate the physical barrier protecting the machine (e.g., by getting ahold of the key to the door), then this won't help.

Security cameras / guards.
If your activities look suspicious, and someone can see you (e.g., through a security camera), then you might wind up having some guards walking in on you, thus thwarting your attack outright. Of course, this won't work if the only people that see you are working with you.

Chassis intrusion detection and self-destruct.
Chassis intrusion detection hardware, which can tell if someone has broken into the chassis (e.g. by removing the chassis cover), combined with some sort of self-destruct mechanism (e.g. a small explosive that blows away the recording media), could prevent sensitive information from falling into the hands of an attacker, by destroying it before the attacker even knows that there is a self-destruct mechanism. Such a system could be broken by anyone (e.g., a disgruntled employee) that knows how to disarm it.

Encryption of sensitive information.
If the sensitive information on the machine's recording media is encrypted, an attacker who simply swipes the recording media (or the whole machine) will have to crack the encryption, which is often infeasible due to the enormous keyspaces allowed for by modern ciphers. Such encryption might be accomplished with a straightforward encryption tool such as PGP, or with something more sophisticated, such as an encrypted filesystem. Such encryption can be defeated by covertly installing a piece of software on the machine that waits for someone on the machine to decrypt the data, then records the decrypted data or the key that was used to access it, for the attacker to pick up later. As the keys are usually passwords, the attacker could install a keylogger on the machine, leave it for a while, and wait for someone to type in the encryption key. A more sophisticated attack would be needed to break the encryption if the key and/or encryption engine is on a smart card (perhaps by intercepting the decrypted data on its way back from the smart card). Of course, if the encrypted data is only stored on the machine, and never decrypted there, then such an attack will not work.

This is often stated as some sort of truism, but in fact this is just a statement that often happens to be true, rather than some immutable law of computers. You might equivalently say things like "All software sucks" or "Sex is fun" or "Milkshakes taste good". These are all generally true, and counterexamples are rare, but that does not mean that they are universally correct. Just like sometimes you find a good piece of software or get a bad milkshake, you can build systems such that physical access gains an attacker very little, if anything. It's expensive and takes a lot of work, but you can do it. For most uses, it is not worth that effort, since most computers are not really that valuable, nor are they placed anywhere that an attacker will normally be able to access them (your house, a colocation facility, etc). On the other hand, devices such as ATMs are both in vulnerable public locations and have a great deal of intrinsic value -- in the case of ATMs, that is not so much the fairly limited amount of cash inside of them, as it is access to the bank networks that the ATM is connected to.

In fact, of the list that argv presents, the only ones that are more or less universally correct are that it is much easier to steal or destroy the device when you have physical access. Personally I don't consider either of those particularly interesting, nor do they reflect anything upon the device in question besides the fact that it apparently doesn't come equipped with a team of killer androids to guard it. While I think that would be a wonderful value added scheme, the margins on killer androids are too low to make a good profit. Not to mention the product liability concerns...

For completeness, I will run down the list argv presents in sequence:

  • Console access, or messing with the boot loader These are simply pointing out that some operating systems don't have very good access control. Many other ones do (assuming they are configured correctly).

    Walking up to an unused but logged in console and getting something juicy is what is called a time to check to time of use (sometimes abbreviated to the lovely acronym TTCTTOU) problem. It's a common problem, and difficult to solve. I think it is worth pointing out that the exact same problem applies to any sort of remote connection as well, be it a session to a web application left open in a browser, an SSH terminal, or any other sort of channel that you can send commands over or read information from. In fact, using only the physical interface is a big disadvantage to an attacker - the machine itself could be at least somewhat secured (locked room, etc), and there is only one place to check if you want to make sure that nobody has left themselves logged in. In contrast, a remote connection might be coming from... well, anywhere, in theory, giving a nearly infinite1 number of possible places to secure or check.

    1: For small and finite values of infinite. Say a couple billion, I guess.

  • Substitution of boot media There are many well known cryptographic techniques which would prevent this. For example, the hardware could contain a small chip which checks RSA signatures on the boot loader and operating system kernel before it runs them. This is, more or less, how Palladium and TCPA will work, and within a few years most PCs are probably going to have chips just like the ones I mention courtesty of an unholy alliance of the MPAA, RIAA, Intel, IBM, AMD and Microsoft.
  • Steal the media Obviously encryption will make such an act pointless. In addition, this can be made quite difficult by, for example, covering the chip that contains the encryption keys with a metal shield and using lots of epoxy to seal it. You can drill in, but it takes some work, and there are tamper detection and response mechanisms used in high end crypto processors which can prevent all (known) physical attacks. These processors are used to secure billions of dollars worth of financial transactions. While it is certainly possible that some clever person has figured out how to defeat them and used it to steal money, this seems unlikely to me. Some of the best people in the public world doing computer security have tried to break in these processors, and generally failed. And large scale bank fraud is actually quite rare, and as breaking one of these cards could allow one to steal many millions of dollars, it seems likely that we would have heard about it. The banks often cover up fraud (European banks are especially bad about that), but it seems implausible that a single fraud event that reached into the millions of dollars would go unreported or unnoticed.

    To defeat encryption, argv suggests running a key logger or something on the machine. This makes a huge number of assumptions, presumably because argv is thinking about your typical Windows/Unix PC, not computers in general. It assumes that a key logger can actually work on the machine, which, these days, is basically only true on Windows machines where the regular user account has Admin privileges. A very common case, to be sure, but there is more to the world. A physical keylogger is a little more difficult to protect against; for that you're going to probably want smart cards that open up an encrypted tunnel between the smart card and the computer, so even if there is a tap in the reader or the line from the reader to the computer you should be safe. Assuming you can protect your smart card against differential power analysis and other nifty attacks that often work against smart cards, of course.

  • Chassis intrusion detection and self-destruct is suggested as a possible countermeasure, but the suggested problem, that "Such a system could be broken by anyone (e.g., a disgruntled employee) that knows how to disarm it." is almost silly. This is easy to work around: make it so that there is no way to disarm it. At first this seems like a really bad idea, but in fact there are plenty of devices out there like this. Doing this for an entire server or PC is obviously annoying, since you can't upgrade your hard drive to store more pr0n, which is certainly inconvenient. So typically what is done instead is put a small ARM or MIPS based computer, with its own memory and operating system, on a PCI board. This board is then covered with all kinds of stuff to stop or detect physical intrusions; if any tamper attempt is detected, the device zeros out its master crypto keys (which everything else on the device is encrypted with), and/or blows fuses which render it inoperable or physically destroy its memory. Many of these tamper detection mechanisms are extremely sophisticated; the IBM 4758 is around the top of the line and has never fallen to a physical attack.

So, the summarize, the title of this node should in fact be "If you leave your computer entirely undefended against physical attacks, and an attacker gets physical access, then your system is already compromised."

Log in or registerto write something here or to contact authors.