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?
Physical access, in many, likely most, situations means a total loss of security - for a variety of reasons (this all assumes encrypted disks):
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.
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.
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.
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.
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?"
