If you could get physical access to a server, you could change the root/admin password even if you did not know the current password.

However with encrypted disks, I don't think this is possible (or is it?).

So, does this mean physically securing your server has become less important - it's still needed for other reasons - but is this reason no longer there?

  • 2
    Why should it be impossible to change the password if the disk is encrypted? The disk is not in readonly mode, the system can save logs, etc. So a malicious user can modify any file (including the password storage) if he has an access to the server. – A.L Dec 29 '15 at 22:32
  • 4
    I understand that information is - probably - the most valuable asset for you, and chances are it is also valuable for your competition. But if you are the target of a "hacktivist", criminal or terrorist group that just want you out of the game, leaving an small explosive on the server room seem pretty effective. Even if we don't go to that extreme wiping your disk, stealing them (maybe replacing them), or installing malicious hardware or software (as the current answers has pointed out) can do a lot of damage. – Theraot Dec 29 '15 at 22:41
  • 8
    Open case, hotplug in PCI card, dump memory, hunt in memory image for password. blackhat.com/presentations/bh-dc-07/Rutkowska/Presentation/… – pjc50 Dec 30 '15 at 13:23
  • 3
    @MartinArgerami Open case, coldplug in PCI card, boot, dump memory, wait for clueless user to log in, dump memory, diff memory dumps for password, remove PCI card since, you know, hardware ain't cheap and we have more to hack. Or, ya know, USB keylogger. No screwdriver required. – candied_orange Dec 31 '15 at 13:07
  • 3
    @CandiedOrange: I was specifically responding to pjc50's comment on "hotplug". If it is about stealing the password, you can also install a webcam filming the keyboard; you don't even need to open the case. Or even easier, you can smash the operator with a $5 wrench. – Martin Argerami Dec 31 '15 at 13:58

Physical access, in many, likely most, situations means a total loss of security - for a variety of reasons (this all assumes encrypted disks):

  • Theft - An attacker could steal the server or disks, to attack at their pace. This allows an attacker to take their time, and you have no idea if they've actually gained access to data.
  • Physical Modification - If I can access a server, I could add hardware, this could be anything from USB or keyboard logging to adding a wireless interface to allow remote access.
  • Cold Boot Attack - There are attacks that can be used to extract encryption keys, allowing decryption of the disks.
  • etc.

There are others of course, but this is just a sample of what can happen if an attacker has physical access. There are possible attacks that are still somewhat theoretical, such as applying backdoored UEFI images and the like.

Possibly the worst part of a physical attack, is that you may not even know what exactly was done, so there's a real problem with being able to trust the hardware afterwards.

  • 8
    The part about not knowing what was done is not really specific to physical attacks. – kasperd Dec 29 '15 at 13:23
  • 2
    There is however a 0% chance that you can trace them at all and detect unexpected behavior either on the network or on the device I would imagine. – veryRandomMe Dec 29 '15 at 14:01
  • 2
    On the subject of Physical Modification: With physical access comes access to the PCIe bus, and that gives the ability to exploit DMA access. I don't think it even needs the OS to properly load a driver for it, but that doesn't really matter since an attacker can spoof the card's identity. A PCIe implant can effective break the system wide open in a hard to trace way. – Kaithar Dec 30 '15 at 17:03
  • 2
    I once had an experience where all the firewalls, routers and HSM devices at a site was stolen. As you can imagine, there wasn't only a financial burden replacing devices that cost $30,000 to $120,000 each, but the fact that culprits had access to encryption keys meant that all data had to be re-encrypted. So is physical security less important? Hell no! – bloudraak Dec 31 '15 at 19:41
  • JTAG, SMM, IPMI, ... – a CVn Jan 1 '16 at 22:40

Physical access is total access. Kinda. Give me physical access to a server with an encrypted disk and the first thing I'd do is plug a key logger into the keyboard to take care of that pesky encryption.

Show up at my door with an encrypted hard drive and I'll format it and dump movies on it.

Encryption is most commonly defeated not by breaking it but by going around it. It only protects you as well as you use it. You have access because you have something that gives you access. Be it password, RFID, finger print, whatever. Give me physical access while you're still using it and I'll figure out how you get access.

  • What kind of keylogger are you going to install without unencrypting the disk first? – Eloy Roldán Paredes Dec 30 '15 at 17:07
  • 16
    presumably a hardware keylogger – PeterL Dec 30 '15 at 17:54
  • Is the thing that asks for the password software or firmware? If so, it could be replaced with a clone that logs the password somewhere. If not, hardware keylogger it is. – joeytwiddle Dec 30 '15 at 17:59
  • 1
    @EloyRoldánParedes Why would you need access to the disk to install something? Given physical access, you can be able to read and modify anything in its memory while it's still running, so you can either read whatever you need, or gain root access to the OS and drivers, and run the keylogger that way. – Peteris Dec 31 '15 at 19:33
  • 4
    "I'll format it and dump movies on it. " +1 – Ave Jan 1 '16 at 20:21

Disk encryption can be defeated by replacing the machine with a malicious one that looks and behaves exactly the same but its only purpose being to fool the legitimate user into typing in the FDE password. In case of a local user it can be as simple as an USB keylogger, in case of a remote user (entering the key via SSH) you need to extract the SSH private keys (which are located on the unencrypted part of the storage since the FDE key isn't yet available) and then start your own SSHd with that key and wait for the user to return.


The Cold Boot Attack has been used on laptops to defeat disk encryption, and would certainly work on servers. There have also been RAM attacks using DMA via Thunderbolt, PCI Express, and other bus technologies. And malware has access to the unencrypted data; a physical attacker may have an easier time of installing it via local hardware.

Remember, in order to work, the server has to be booted up, which means the disk keys are located somewhere in the machine.

  • "which means the disk keys are located somewhere in the machine.". Any good password check is not just a simple string comparison. – mathreadler Jan 1 '16 at 22:56
  • @mathreadler What? We're talking about decryption keys, not passwords. – Navin Jan 2 '16 at 16:17
  • Yes key, password. Potayto, potaato. – mathreadler Jan 2 '16 at 21:09
  • @mathreadler, in modern cryptography encryption keys are not used as passwords, and passwords are not used as encryption keys. Passwords are sometimes used to derive encryption keys algorithmically, but it's just as possible they are only validated as one step of retrieving the encryption key. Cold Boot defeats disk encryption by directly recovering the disk encryption key. The user's password is used inside the OS to derive a key used to access the key used to decrypt files encrypted by the user; it is not related to disk encryption. – John Deters Jan 4 '16 at 5:43
  • Yes I know the user password for the operating system is usually not the same as the key for disk encryption. The key still does not need to be stored on the machine. It can be stored on a removable device or not stored at all but just validated. Also I see what you are trying to do and it does not work very well. – mathreadler Jan 4 '16 at 12:03

In the case of physical access you're bypassing a lot of security devices like firewalls and ips ids devices on the edge of the network, so you're several steps ahead. When you get remote access to the server you still have to deal with encryption so its the same for both cases. There's a quote about it which says: "They don't have to bypass your firewall if they can bypass your receptionist."


It should be noted that security doesn't only concern with privacy and confidentiality, it also includes availability and integrity (and traceability, etc..).

As such, with physical access - even if they can't access your data - an attacker can do a lot of damage.

I assume integrity and availability are your "other reasons". Yet if the question is whatever or not physical security is less important the answer is that even if you remove confidentiality from your concerns, physical security is still paramount.

Consider this answer as acomplement to the others here, there is no need to repeat their points.


If you could get physical access to a server, you could change the root/admin password even if you did not know the current password.

Which OS wont ask you for current password when you want to change? Or you mean change other user's (which is an admin) password?

However with encrypted disks, I don't think this is possible (or is it?).

With my experience on Windows, EFS folder/file wont be accessible if other administrator changes the password forcefully. You will need to have EFS certificate for the same if you lose password or forceful password change occurs (or if account itself is deleted).

So, does this mean physically securing your server has become less important - it's still needed for other reasons - but is this reason no longer there?

IMO, both are needed.

  • 7
    For Linuxes, Unixes and Windows, if you have physical access to the machine you change change the root/admin. You boot through a different image and change it. Google for it. – user93353 Dec 29 '15 at 5:36
  • 1
    That's exactly my question, right? Earlier the disks were not encrypted - you could change the password if you had physical access - hence physically securing machine was very important. Now with encrypted disks, that reason for physically securing machines is no longer there. – user93353 Dec 29 '15 at 5:42
  • 2
    In an unencrypted disk, password can be changed (though not retrieved) if you have physical access to the machine. This is because you can boot from a different image & overwrite it on the disk. liberiangeek.net/2013/03/… – user93353 Dec 29 '15 at 8:41
  • 3
    @CandiedOrange: With good network security and permission settings it's vary hard to steal etc/passwd. If I have your SATA drive then I just need to plonk it on a SATA connector on MY OS on MY PC to mount it to steal etc/passwd - that's what physical access defeats - all the software that protects etc/passwd since those software (including the OS) won't be running. The only thing that might save you is encryption. But without any software that can execute and throttle my password hacking attempts the only cost to me is time. – slebetman Dec 29 '15 at 9:55
  • 2
    ...whereas if it is encrypted, you need to get into memory forensics. Which is a very real class of attacks, particularly if your attackers are well-funded (at last recall, PCI cards for pulling down live memory images ran about $8k or so). – Charles Duffy Dec 30 '15 at 19:25

Short answer: No, it is still very important

Most people have posted answers that include social engineering, or attacks that are necessarily interactive (such as keyloggers or variants of the evil maid attack). These can be defeated using secure remote attestation techniques (typically involving Intel TXT or SGX). Because most of these are interactive, and many adversaries can't afford to wait until someone logs into the server, I'll provide a few examples that can be used to compromise an encrypted server at any time, as well as mitigations. Note that this will be Linux-centric, but the hardware points are OS-agnostic.

Directly recovering memory using cold boot attacks

The method everyone knows, a cold boot attack, can recover encryption keys on most hardware with moderate reliability with two methods. The first involves cooling down memory using a freezing spray, and physically taking it out and putting it into a new motherboard to read the contents. The second involves keeping the memory in, optionally cooling it to improve reliability, and rebooting the system into a malicious and lightweight operating system, bootloader, or, in at least one known case, custom BIOS, which reads and dumps the memory onto a non-volatile medium.

The cold boot attack works because modern high-capacity computer memory, called DRAM, which stores data in capacitors that must be refreshed at a high rate when they are storing a charge, or they'll lose their charge. They are typically refreshed every 64ms for reliability, but even without power, many of them retain their data for a short time.

There are three main types of memory in common use in servers today: DDR2, DDR3, and DDR4. DDR2 can sometimes retain data for 30 seconds or more without power. DDR3 and DDR4 will lose power in just a few seconds, making them much harder to mount cold boot attacks against. Additionally, DDR3 and DDR4 memory will scramble their contents to reduce electrical interference, but the algorithm it uses is an LFSR, which is not cryptographically secure and is trivial to break.

Mitigating the first method is as simple as ensuring the DIMMs cannot be removed. This can be done by proper use of anti-tamper epoxy resin. If used properly, any attempt to remove it will destroy the memory in the process. This may not be possible if you are using a server which you do not physically own. Mitigating the second method requires your BIOS erase memory before booting. Disabling fast boot can sometimes cause memory to be wiped as part of POST. ECC memory also often requires being initialized by the BIOS before use. However, at least one time, a cold boot attack of this type involved a customized version of cold boot. BootGuard, a feature on many new Intel systems, will prevent custom BIOSes from being installed, but a particularly advanced adversary will still be able to bypass it.

There is still one, final method to defeat the cold boot attack, which works against both types of cold boot attacks, and that is to never allow the encryption key to ever come into contact with memory. The TRESOR kernel patch for Linux does just this, by putting the keys in the x86 debug registers. This does not make your computer immune from all attacks involving physical access, it only prevents cold boot attacks from reading your encryption keys. Data from your disk which remains in filesystem buffers for example will still be recoverable.

Reading and writing to memory using DMA attacks

Any device attached to the PCH (PCI, PCIe, LPC) have the potential to directly read and write to memory through DMA, or Direct Memory Access, attacks, also called evil bus mastering (a device which is bus master is allowed to send DMA requests, among other things). DMA is a technique that allows devices to asynchronously read and write to memory, without needing to involve the CPU, for improved performance. Unfortunately, if such a device is hijacked or maliciously inserted, it can read and write to all memory and the CPU can do nothing about it. The CPU can tell if the device has DMA capabilities, but if it is enabled, the CPU is putting its faith in the device, trusting it not to betray it.

There are three types of DMA attacks which I am aware of. The first is PCI/PCIe hotplugging, involving putting a malicious device into a slot on the motherboard, and letting the operating system auto-configure it. This is trivial to mitigate, by disabling hotplugging. This may require a change to the kernel configuration. The second type of attack is to hijack an existing, trusted device which is bus master, and use it to read or write to memory. This can be done either through exploiting the firmware running on the device, or hijacking the hardware through exposed debug interfaces, reflashing firmware and triggering a cold reset of the device's CPU, etc. The final type, which is much lesser known, is an attack over the LPC. The LPC is the equivalent of the archaic ISA bus on modern hardware. It handles old, low-speed peripherals. However, it can also be made bus master by asserting the LDRQ# interrupt. Not all motherboards expose this, and while this is purely anecdotal, an Intel developer I met said he had never seen a laptop which exposed LDRQ#. It may be different for servers. Unfortunately, the Intel PCH datasheet specifies that the LPC's bus master bit is read-only, forced on. If your system supports LDRQ#, mitigating LPC-based DMA attacks must be done in other ways.

There are two ways to mitigate DMA attacks. The first takes advantage of the fact that, while DMA works independently of the CPU, turning DMA on still requires the CPU give it permission by enabling the bus master bit. A driver, which is just software, can refuse a device which wants this permission. If the device is not given permission, it cannot initiate DMA. For example, not using the Firewire driver, or using the more modern Firewire driver which has DMA disabled by default, the Firewire PCI device will have DMA disabled (the bus master bit will be unset). This technique has its downsides, because some devices require DMA to function. Network interface cards, graphics cards, etc. require DMA, or they would be so slow that they would be unusable. While you would not have to worry about a new, malicious one being plugged in, an exploit against the card, or an attack against the hardware (controlling it using debug interfaces, for example) can use this privilege against the host.

The other mitigation is to use a feature in most modern CPUs, the IOMMU (the feature is named VT-d on Intel processors). The IOMMU is capable of efficiently filtering all DMA access, without disabling it outright. This is called DMAR, or DMA Remapping. The ACPI specification specifies a blob of data called the DMAR table which is stored in the BIOS which the IOMMU will use to isolate individual DMA-capable devices, redirecting any direct memory accesses to a specific, safe area of memory. On many Linux systems, you have to enable this by booting with the parameter intel_iommu=on (for Intel), or amd_iommu=force (for AMD). These options are not enabled by default because many BIOSes have a broken DMAR table, preventing the system from booting, or causing problems. Check if your system is using the IOMMU to isolate devices if dmesg | grep -e IOMMU -e DMAR shows Intel(R) Virtualization Technology for Directed I/O (obviously Intel-specific) in the output, and multiple devices are referenced.

Hijacking the CPU itself using JTAG

JTAG is a group of standards specifying interfaces and protocols for hardware debugging. One standard, titled IEEE 1149.1, allows putting a CPU into a low-level debug mode just by attaching a JTAG probe onto a header on the motherboard. Intel systems use use a modified, proprietary header, called ITP-XDP. If someone wants to attack an encrypted server with JTAG, they need to connect the probe to the XDP header. Even if the header is not clearly visible, the traces will still be there, and will still be live and viable. As soon as the probe is attached, all CPU cores will halt, and the attacker will be able to read the contents of all registers, read all memory, write to any registers, write to any memory, step the CPU instruction by instruction, change the instruction pointer, unpause and pause the CPU, and much more. In short, JTAG allows an attacker to take complete control of the CPU, controlling it like a puppet, and it can do nothing about it.

There is no way to mitigate a JTAG attack in software. Essentially all motherboards have XDP headers. A possible way to mitigate it, if you have physical access to the server and are allowed to permanently modify it (e.g. colo, hosting at home, etc.), you can use a strong epoxy resin and put it over the XDP header. This technique can be improved further by putting a thick plate of metal over the epoxy, preventing fine drills from breaking holes in the epoxy. I've been told that there isn't a worry about an attacker drilling through the bottom, because there are so many layers of traces in a modern motherboard that that would destroy the system. I don't know whether or not that would cause the system to shut down or prevent JTAG from working, so it may be better to put epoxy and a metal sheet on both sides.

Exotic, extremely difficult, or theoretical attacks

There is the well-known problem of side-channel attacks through power analysis and thermal analysis. This can be possible when the program performing encryption/decryption does not use constant-time operations where they are critical, resulting in detectable delays or large power draws that occur at different times depending on the value of the key. Modern crypto drivers are unlikely to have this problem, and hardware acceleration like AES-NI makes this even less of an issue. Mitigations include using ciphers that support hardware acceleration, like AES on proper hardware, using ciphers which have small S-boxes and can be optimized using bit slicing, like Serpent, or using red/black separation for proper EMSEC (look up NATO SDIP-27 for the specifications. Usually you'd just need to buy an approved computer).

Logic bus analyzers can be connected directly to any exposed trace or electrical wire, without ever needing to break the circuit. This is possible to do with DRAM, but as speeds get higher and higher, it gets increasingly difficult. PCIe uses techniques to improve speed which result in very strange electrical phenomena that logic analyzers do not at all like (a PCIe lane does not have a clean separation between hi and lo, as data bleeds into adjacent lines and electrical signals echo back and forth). It may be possible, but it would be difficult to do. If your PCI root hub supports AER, error reporting, you could configure your system to immediately disable bus master from any device which reports correctable errors, rather than continuing, as is the default. This fail-fast technique may be able to detect an attempt at inserting a logic bus analyzer into a PCIe device. Because this is such a theoretical and exotic attack which very well may not be possible anyway, and the mitigation is untested (merely an idea which came about during a conversation I had with a researcher), I'm just explaining the concept, not the steps to do it. It's likely that you wouldn't need to worry about reading PCIe data anyway, since it is unlikely to be carrying the key, but I'm including it for completeness' sake.

Finally, and most unrealistically, an extremely advanced attacker could trigger bugs in the CPU by exploiting timing and power quirks. These attacks (called glitching attacks) are commonly used to exploit simple microcontrollers such as cheap Atmel 8051s, but those are many orders of magnitude less well-tested than Intel processors. Glitching can involve setting the clock or clocks to invalid or unstable values, putting voltages out of specs, violating timing specs, etc. In particularly advanced cases, glitching can involve a technique called laser fault injection, where the processor is decapped (the top is carefully dissolved or burnt off), and a precisely controlled laser is used to elicit electrical activity in specific areas, inducing faults. The end goal of glitching is to cause a fault which changes the internal state of the device to a more attacker-friendly state, such as one where bus master may be enabled, or IOMMU restrictions may be broken. Real world examples with 8051 microcontrollers often attempt to disable security lock bits, such as the firmware read bit. They are almost always successful on such simple devices.

Mitigating everything, at least in theory

Finally, there is one commercial mitigation which protects from everything but the JTAG attack, and that is PrivateCore vCage. It is a virtualization solution which encrypts all memory, and puts the kernel in the CPU cache. DMA attacks are prevented fundamentally, and the TCB (Trusted Computing Base) is reduced entirely to the CPU itself, meaning that no matter what is hijacked, only the CPU must be trusted. In theory, even JTAG attacks could be defeated if the system executed all untrusted code in an SGX enclave. This would work because probe mode, the CPU mode JTAG puts the system in, cannot be used in the context of an SGX enclave. Unfortunately, this implementation is closed source, and the service is very expensive, so it's more interesting from an academic standpoint.


I have a UNIX based "crack" disc that can defeat most Windows-based std logon systems, server and desktop. And its no National Defense secret, these are fairly available worldwide. So if you give me your server and an open USB or CDROM, I'll prob be in in under 15 minutes, sometimes under 5. So yes, keep your physical security just as tight as your virtual. Otherwise you are going to be hit, sooner or later, the only question will be "how big was the breach?"

  • 7
    it works even on an encrypted disk? – schroeder Dec 30 '15 at 2:03
  • 1
    Sorry for the downvote Darien, but you I don't want to leave an incorrect answer looking correct. The OP explicitly mentions disk encryption. – Neil Smithline Dec 30 '15 at 5:11
  • 2
    And there are discs which can crack Linux/Unix logon systems. But like your one, won't work on encrypted systems. – user93353 Dec 30 '15 at 14:49
  • Those livediscs don't do DMA attacks. At best you can pull hiberfil.sys+pagefile.sys, or raw copy the swap partition. OP has an encrypted drive, most likely with a gpg keyfile, and a password challenge on boot. It has only a few files in /boot and elsewhere that are cleartext. In this case, an attacker needs to subvert the binary which provides the challenge to also write out the password to file/remotehost. – user400344 Feb 28 '17 at 2:55
  • @user93353 Crack sha512 hashed passwords which are now standard? You need a big GPU rig or it will take too long. OP isn't talking about a logon system anyway, he is (likely) talking about a LUKS cryptodisk, which can keep everything except a few files in strong crypto. OP cannot remote login to this system again, since by now a moderately skilled attacker can have backdoored its cleartext binaries. – user400344 Feb 28 '17 at 3:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.