4 ms·

Hmm, for a customer of a cloud provider, this sort of thing will be very hard to defend against. Maybe if the customer service system had had two-factor securi

Hmm, for a customer of a cloud provider, this sort of thing will be very hard to defend against. Maybe if the customer service system had had two-factor security, this might have been avoided (i.e., customer service can access your account only if you read them your hardware token's code). Requiring SSL/SSH client certificates even for intranet accesses might have deterred this attack. I hope other cloud providers take note of this incident. This is a very interesting incident.

ceejayoz 15y ago
> customer service can access your account only if you read them your hardware token's code At the very least, I'd hope Linode implements two-factor authentication for their own logins. A customer-provided OTP would be great but you'd need a customer service reset tool for that when people forget, which would put you back where you started...
- ajross 15y ago
  Not necessarily if the reset tool is manually driven and audited. The vulnerability we're worried about here is an automated attack against many customers of a single hosting provider. There will always be ways to human-engineer your way into any single host. Having a hosting provider just increases the attack surface a little.
  - ceejayoz 15y ago
    > The vulnerability we're worried about here is an automated attack against many customers of a single hosting provider. This was an attack against Linode's customer service systems, which allow their support reps to reset root passwords. There's no reason for that system not to be protected by two factor authentication on top of heavy logging.
- RLG_RLG 15y ago
  You obviously have never worked for a retail ISP.
wheels 15y ago
Actually not. Just use a loopback cypto FS to store the sensitive stuff. The reason they had to reboot the machine is that they just had access to the HDD where they could change the password, as opposed to having live root access.
- tlb 15y ago
  Indeed. Well-designed money storage systems aren't vulnerable no matter who has console access.
- lsc 15y ago
  where do you keep the key to the crypto fs?
  - kbuck 15y ago
    You memorize it.
    - lsc 15y ago
      how do you transmit it to the server in such a way that it can't be intercepted by someone that compromises the bits of your virtual that boot before the key is uploaded?
      - RLG_RLG 15y ago
        By using your public key. http://www.debian-administration.org/articles/152 http://www.debian-administration.org/articles/152 You can also require a password AND a cert.
        lsc 15y ago
        Yes, but will that help you if the attacker trojans whatever it is that is doing the decryption? I mean, I'm very clearly not a crypto expert, but I do believe that this would be quite a lot like what Bruce Schnier calls 'the evil maid' attack. Instead of having a bootloader, you have a minimal Linux install, then you get a key to that minimal linux install, and that minimal linux install uses that key to decrypt your encrypted disk. I believe that if that minimal linux install that does the decrypting is compromised before you log in, in theory, the attacker could then insert something in the code that runs after the data is decrypted to, say, send some of that data elsewhere, or, say, open a back door for them to log in and examine the decrypted data. I mean, certainly, you are making the attacker wait for you to log in (assuming that they've only compromised the admin interface and don't have full root on the dom0) and that's another step you are forcing the attacker to take, and you do at least have a chance then of detecting the compromise and /not/ sending the key, so I'm not saying that it's worthless. Of course, this is all protecting against a compromise of the admin tools that does not lead to a compromise of the dom0. If the attacker compromises the dom0 without rebooting it or otherwise disturbing the guests? they have access to your ram. They can snapshot both the ram and the disk and take apart the system at their leisure.
javajosh 15y ago
Yes. Tracing this back to one of their own employees, the company is clearly liable for any resulting loss. If they do not find themselves liable (and a court does not) this will be a big problem for people doing shared or cloud hosting, and traditional, physically secure datacenters will see a resurgence.

ceejayoz 15y ago

> customer service can access your account only if you read them your hardware token's code At the very least, I'd hope Linode implements two-factor authentication for their own logins. A customer-provided OTP would be great but you'd need a customer service reset tool for that when people forget, which would put you back where you started...

ajross 15y ago
Not necessarily if the reset tool is manually driven and audited. The vulnerability we're worried about here is an automated attack against many customers of a single hosting provider. There will always be ways to human-engineer your way into any single host. Having a hosting provider just increases the attack surface a little.
- ceejayoz 15y ago
  > The vulnerability we're worried about here is an automated attack against many customers of a single hosting provider. This was an attack against Linode's customer service systems, which allow their support reps to reset root passwords. There's no reason for that system not to be protected by two factor authentication on top of heavy logging.
RLG_RLG 15y ago
You obviously have never worked for a retail ISP.

wheels 15y ago

Actually not. Just use a loopback cypto FS to store the sensitive stuff. The reason they had to reboot the machine is that they just had access to the HDD where they could change the password, as opposed to having live root access.

tlb 15y ago
Indeed. Well-designed money storage systems aren't vulnerable no matter who has console access.
lsc 15y ago
where do you keep the key to the crypto fs?
- kbuck 15y ago
  You memorize it.
  - lsc 15y ago
    how do you transmit it to the server in such a way that it can't be intercepted by someone that compromises the bits of your virtual that boot before the key is uploaded?
    - RLG_RLG 15y ago
      By using your public key. http://www.debian-administration.org/articles/152 http://www.debian-administration.org/articles/152 You can also require a password AND a cert.
      - lsc 15y ago
        Yes, but will that help you if the attacker trojans whatever it is that is doing the decryption? I mean, I'm very clearly not a crypto expert, but I do believe that this would be quite a lot like what Bruce Schnier calls 'the evil maid' attack. Instead of having a bootloader, you have a minimal Linux install, then you get a key to that minimal linux install, and that minimal linux install uses that key to decrypt your encrypted disk. I believe that if that minimal linux install that does the decrypting is compromised before you log in, in theory, the attacker could then insert something in the code that runs after the data is decrypted to, say, send some of that data elsewhere, or, say, open a back door for them to log in and examine the decrypted data. I mean, certainly, you are making the attacker wait for you to log in (assuming that they've only compromised the admin interface and don't have full root on the dom0) and that's another step you are forcing the attacker to take, and you do at least have a chance then of detecting the compromise and /not/ sending the key, so I'm not saying that it's worthless. Of course, this is all protecting against a compromise of the admin tools that does not lead to a compromise of the dom0. If the attacker compromises the dom0 without rebooting it or otherwise disturbing the guests? they have access to your ram. They can snapshot both the ram and the disk and take apart the system at their leisure.

javajosh 15y ago

Yes. Tracing this back to one of their own employees, the company is clearly liable for any resulting loss. If they do not find themselves liable (and a court does not) this will be a big problem for people doing shared or cloud hosting, and traditional, physically secure datacenters will see a resurgence.