3 ms·

I'm wondering why they would image the server. Did SR2 not use full disc encryption using LUKS? How would they be able to access anything on it, I know if I wer

by zanny 12y ago

I'm wondering why they would image the server. Did SR2 not use full disc encryption using LUKS? How would they be able to access anything on it, I know if I were running SR2 I'd have the longest private key ever stored in my brain to decrypt the drives.

wmf 12y ago
If you're in San Francisco, how do you type the disk password into a server in Iceland? Through a BMC with clownshoes security?
- deleted 12y ago
  [deleted]
yourad_io 12y ago
> I'm wondering why they would image the server. For offline analysis and to be used as evidence, presumably. > Did SR2 not use full disc encryption using LUKS? (...) longest private key ever So the process for you would be slightly different: There would be a "power outage" in your rack, your encrypted disk would be imaged and (unencrypted) bootloader would be bugged. Then they'd wait for you to see that your server had some issues, upon which time you'd have two choices: -enter your private key to resume the service. -abandon the server. The correct choice would be (2), but you don't have enough information to make that call.
- feld 12y ago
  It's not log bugging your bootloader can magically send your password for the key off the server. They would have to be watching and be very quick, but I'm sure they'd want to see the server start to boot to ensure they have it. I'd compare the bootloader to a known good image as an early boot step and if it isn't what you expect immediately start destroying data. :-)
  - yourad_io 12y ago
    I meant "power outage" as the pretext that would justify (to the HS owner) why the server has been power-cycled (assuming they decided to cooperate with the FBI/whoever). Here's how I would do it: - I assume that your hard drives are in RAID. I gamble that they're in RAID 1 - most typical - and strip one out while the server is still running. Some kernel messages are logged, whatever. - I start imaging the disk. If it isn't a mirror of the other after all, I strip the remaining drive(s) out and start imaging them too. - While the disk(s) is/are transferring, I patch both your boot loader and your kernel with a rootkit. This should be laughably easy for the level of adversary we're talking about. - When the disk(s) are done, I power cycle your server. I may cold-boot your RAM and get the passphrases there if i'm lucky. The downtime was either seconds (if it kept going with one RAID 1 disk) or <however long the imaging takes>. - When you realise your service is down you may contact customer support. In that case they will respond (with their usual timing) about something-something-blown-fuse-UPS in your rack. - When you log onto your server, you will most likely be faced with the passphrase input and most likely will go for it, but even if you don't... > I'd compare the bootloader to a known good image as an early boot step If you do so after you've given away the passphrase, you've lost already. Destroying the data won't help, as they have the encrypted copy of it and you just gave them the key. I don't think you could detect a good boot/OS rootkit remotely at all. One would cover for the other. You can't unplug the disk and examine it. You can't plug a read-only drive in and boot some forensic tool. All you have is your lying bootloader and your lying OS. Your encrypted partition doesn't protect the integrity of the binaries there either, as after it's been decrypted, the rootkit would happily intercept any values that would give it away. I'm not sure how you could ensure hardware security without ensuring physical security. Usually, physical access == pwned. Maybe TPM changes/will change that, but I somehow doubt it. Some other routes not covered here (probably easier, heh): Getting host to decrypt your TLS/KVM session where you typed the passphrase in the first place, malware in firmware on misc devices, etc.
    - zanny 12y ago
      > I patch both your boot loader and your kernel with a rootkit. This should be laughably easy for the level of adversary we're talking about. Well, you won't be getting the kernel, its on the drives. It would have to be in a separate partition so you can start it before mounting the sensitive filesystems, and you may have a key that the bootloader uses on it, but in either case if you are not present and a sever goes offline you basically have to do the following: Verify the ROMs integrity in that first stage - before you put in the key for your actually sensitive data. That means you need open firmware or some mechanism to hash the ROM that is installed, you need to have a means to read it in its entirety, and then you need to hash it. I say open firmware because you need to be able to guarantee the FBI couldn't embed a backdoor firmware. If you can get open spec / openfirmware mainboards and verify their authenticity only then can you be safe. Then you verify the kernel, which is much easier because you can compile it yourself, maybe even pad it with some random and scramble the ELF tables in some custom orientation. And then you need to worry about how you input the key - if its by USB, you can backdoor the USB and network controllers and keylog in hardware depending on the vendor and model of the mainboard. Over the network, just the NIC is in question, because any secret sharing over ethernet better be over a secure connection. But that should be it. It is a fine line at best, and a bottomless pit at worse, but there are ways to try to be hardware secure.
- c3 12y ago
  fyi they don't need to power cycle your machine to remove it from the data center (if there is physical access); there's a battery backup that clips onto the power prongs while it's still 3/4 in the socket.

by zanny 12y ago

wmf 12y ago

If you're in San Francisco, how do you type the disk password into a server in Iceland? Through a BMC with clownshoes security?

deleted 12y ago
[deleted]

yourad_io 12y ago

> I'm wondering why they would image the server. For offline analysis and to be used as evidence, presumably. > Did SR2 not use full disc encryption using LUKS? (...) longest private key ever So the process for you would be slightly different: There would be a "power outage" in your rack, your encrypted disk would be imaged and (unencrypted) bootloader would be bugged. Then they'd wait for you to see that your server had some issues, upon which time you'd have two choices: -enter your private key to resume the service. -abandon the server. The correct choice would be (2), but you don't have enough information to make that call.

feld 12y ago
It's not log bugging your bootloader can magically send your password for the key off the server. They would have to be watching and be very quick, but I'm sure they'd want to see the server start to boot to ensure they have it. I'd compare the bootloader to a known good image as an early boot step and if it isn't what you expect immediately start destroying data. :-)
- yourad_io 12y ago
  I meant "power outage" as the pretext that would justify (to the HS owner) why the server has been power-cycled (assuming they decided to cooperate with the FBI/whoever). Here's how I would do it: - I assume that your hard drives are in RAID. I gamble that they're in RAID 1 - most typical - and strip one out while the server is still running. Some kernel messages are logged, whatever. - I start imaging the disk. If it isn't a mirror of the other after all, I strip the remaining drive(s) out and start imaging them too. - While the disk(s) is/are transferring, I patch both your boot loader and your kernel with a rootkit. This should be laughably easy for the level of adversary we're talking about. - When the disk(s) are done, I power cycle your server. I may cold-boot your RAM and get the passphrases there if i'm lucky. The downtime was either seconds (if it kept going with one RAID 1 disk) or <however long the imaging takes>. - When you realise your service is down you may contact customer support. In that case they will respond (with their usual timing) about something-something-blown-fuse-UPS in your rack. - When you log onto your server, you will most likely be faced with the passphrase input and most likely will go for it, but even if you don't... > I'd compare the bootloader to a known good image as an early boot step If you do so after you've given away the passphrase, you've lost already. Destroying the data won't help, as they have the encrypted copy of it and you just gave them the key. I don't think you could detect a good boot/OS rootkit remotely at all. One would cover for the other. You can't unplug the disk and examine it. You can't plug a read-only drive in and boot some forensic tool. All you have is your lying bootloader and your lying OS. Your encrypted partition doesn't protect the integrity of the binaries there either, as after it's been decrypted, the rootkit would happily intercept any values that would give it away. I'm not sure how you could ensure hardware security without ensuring physical security. Usually, physical access == pwned. Maybe TPM changes/will change that, but I somehow doubt it. Some other routes not covered here (probably easier, heh): Getting host to decrypt your TLS/KVM session where you typed the passphrase in the first place, malware in firmware on misc devices, etc.
  - zanny 12y ago
    > I patch both your boot loader and your kernel with a rootkit. This should be laughably easy for the level of adversary we're talking about. Well, you won't be getting the kernel, its on the drives. It would have to be in a separate partition so you can start it before mounting the sensitive filesystems, and you may have a key that the bootloader uses on it, but in either case if you are not present and a sever goes offline you basically have to do the following: Verify the ROMs integrity in that first stage - before you put in the key for your actually sensitive data. That means you need open firmware or some mechanism to hash the ROM that is installed, you need to have a means to read it in its entirety, and then you need to hash it. I say open firmware because you need to be able to guarantee the FBI couldn't embed a backdoor firmware. If you can get open spec / openfirmware mainboards and verify their authenticity only then can you be safe. Then you verify the kernel, which is much easier because you can compile it yourself, maybe even pad it with some random and scramble the ELF tables in some custom orientation. And then you need to worry about how you input the key - if its by USB, you can backdoor the USB and network controllers and keylog in hardware depending on the vendor and model of the mainboard. Over the network, just the NIC is in question, because any secret sharing over ethernet better be over a secure connection. But that should be it. It is a fine line at best, and a bottomless pit at worse, but there are ways to try to be hardware secure.
c3 12y ago
fyi they don't need to power cycle your machine to remove it from the data center (if there is physical access); there's a battery backup that clips onto the power prongs while it's still 3/4 in the socket.