4 ms·

How did the attackers know what they were looking for. I'm going to assume that it's a small minority of linode users who have bitcoins on their machines. How

How did the attackers know what they were looking for. I'm going to assume that it's a small minority of linode users who have bitcoins on their machines. How were just these users targeted so accurately? What tied together knowledge they used bitcoins to those VMs and their linode accounts? Also, was the nature of the attack just that the were able to login to your linode admin panel and from their root the machines and then loot your wallets?

3pt14159 15y ago
Simplest answer is probably the right one in this case: Someone at Linode did it. Ran a script to see how many bitcoin files there were on all the machines (they probably do these types of queries for anti-virus/whatever anyways) and took a customer support password to log in and get the coins. If he did it right he still might be working there, as it is easy to get credentials from friends/coworkers (even though it should be really really hard).
- trotsky 15y ago
  Pretty sure there is a default port that accepts connections as part of bitcoind, so you can just portscan for it.
- ajross 15y ago
  I'd be very surprised (and suspicious) if they were running any kind of diangostics over their customer's data without an explicit signed contract. The liability worry there alone is scary.
  - gravitronic 15y ago
    you do realize that in this theory, the same person then went and stole thousands of dollars in bitcoins, right? I don't think they were worrying about liability...
    - ajross 15y ago
      You misunderstand. Not the thief's liability, Linodes. If someone, say, engages in insider trading because of something they saw in Linode's own analysis system, Linode can be sued for failing to protect that information. If they have a policy of never reading customer data (and can prove it) that becomes much harder. The posited "anti virus checker" would throw that promise out the window.
      - Drbble 15y ago
        How so? Google credibly claims (somehow) that they don't "read" customer email, even though they run the largest-scale automated email reading system on the planet.
- lawnchair_larry 15y ago
  Sorry, there is just no way that this is the case. Please don't throw such a serious allegation out there without any evidence. To even suggest that this is technically possible for an employee to do is a serious allegation, let alone suggesting that someone did it maliciously. This spreads all kinds of FUD. I'll happily eat my words if that turns out to be what happened, but it is definitely not the simplest answer.
  - ohgodthecat 15y ago
    > To even suggest that this is technically possible for an employee to do is a serious allegation It is technically possible for an employee to do it because it seems (from the linked pastebin above) that is how it was compromised, an elevated account for linode manage was compromised. As for an employee being the one that did it, that is probably the least likely cause.
    - showerst 15y ago
      I believe he's referring to the part about employees (at least the ones that have access to the customer dashboards) being able to run a script to scan for bitcoins.
  - RLG_RLG 15y ago
    Inside job is usually the answer for targeted attacks against inside systems. Inside collusion at a minimum. I wonder how anyone can trust their linode systems after an admin account being compromised. It would likely ruin their business to re-install everything, but that is the only way to know root kits have not been installed.
    - lawnchair_larry 15y ago
      Or just check if your instance was restarted and your root password was changed. If it wasn't, you were not exploited this way.
  - nknight 15y ago
    You can't secure against God. Of course it's technically possible for a Linode employee to do.
doublec 15y ago
They could have looked at the ip's of bitcoin services and noted those running on a linode. Or collected ip's from bitcoin nodes that their own node has seen and looked up those allocated to linode.
darklajid 15y ago
>Also, was the nature of the attack just that the were able to login to your linode admin panel and from their root the machines and then loot your wallets? The way I understand it the attackers were able to get access to the admin panel and invoked some kind of 'change root password' emergency stuff. The machines were rebooted it seems, which makes sense: The interface of Linode has probably/hopefully no access to the root password. Maybe this 'Reset my root' feature (now I'm guessing) reboots the machine in single user mode or passes init=/bin/sh to the kernel to reset the password once and reboots again afterwards. Only THEN the attacker had access. But yes, he had root. The good (if you want to call it that) part of it is that this procedure rings every alarm possible. The real owner doesn't have the password anymore, as he'll soon figure out. It's everything but sneaky. I DO wonder why root is allowed to log in at all, though..
- larrys 15y ago
  "The real owner doesn't have the password anymore, as he'll soon figure out." He won't figure it out until he tries to login though.
- slig 15y ago
  I disabled root login when I was setting up the server. Could my server be affected too? Also admins that only log with ssh keys and don't use root won't be able to notice that, will they?
  - darklajid 15y ago
    1) No idea, that's something Linode needs to answer. I only guessed what it takes to change a root password of a VPS system. 2) Very good point. In that case it might work undetected for quite a while..
  - devicenull 15y ago
    Probably. You disabled root login how, via the sshd_config file? If so, you're still screwed. Even if you fully disable root, that's not going to stop the init=/bin/sh script. Even if you fix that (securing grub?) you're still screwed because it's a virtual machine, and they can just mount the partition to another VM, and pull all your data/reset root that way. So, maybe if you have an encrypted partition, no root access, secure grub, and real hardware (it's probably possible to dump the VMs memory by snapshotting it, then pulling the key out that way), you would be secure against attacks like this. With a VM? No, it's not nearly secure enough for very important things.

3pt14159 15y ago

Simplest answer is probably the right one in this case: Someone at Linode did it. Ran a script to see how many bitcoin files there were on all the machines (they probably do these types of queries for anti-virus/whatever anyways) and took a customer support password to log in and get the coins. If he did it right he still might be working there, as it is easy to get credentials from friends/coworkers (even though it should be really really hard).

trotsky 15y ago
Pretty sure there is a default port that accepts connections as part of bitcoind, so you can just portscan for it.
ajross 15y ago
I'd be very surprised (and suspicious) if they were running any kind of diangostics over their customer's data without an explicit signed contract. The liability worry there alone is scary.
- gravitronic 15y ago
  you do realize that in this theory, the same person then went and stole thousands of dollars in bitcoins, right? I don't think they were worrying about liability...
  - ajross 15y ago
    You misunderstand. Not the thief's liability, Linodes. If someone, say, engages in insider trading because of something they saw in Linode's own analysis system, Linode can be sued for failing to protect that information. If they have a policy of never reading customer data (and can prove it) that becomes much harder. The posited "anti virus checker" would throw that promise out the window.
    - Drbble 15y ago
      How so? Google credibly claims (somehow) that they don't "read" customer email, even though they run the largest-scale automated email reading system on the planet.
lawnchair_larry 15y ago
Sorry, there is just no way that this is the case. Please don't throw such a serious allegation out there without any evidence. To even suggest that this is technically possible for an employee to do is a serious allegation, let alone suggesting that someone did it maliciously. This spreads all kinds of FUD. I'll happily eat my words if that turns out to be what happened, but it is definitely not the simplest answer.
- ohgodthecat 15y ago
  > To even suggest that this is technically possible for an employee to do is a serious allegation It is technically possible for an employee to do it because it seems (from the linked pastebin above) that is how it was compromised, an elevated account for linode manage was compromised. As for an employee being the one that did it, that is probably the least likely cause.
  - showerst 15y ago
    I believe he's referring to the part about employees (at least the ones that have access to the customer dashboards) being able to run a script to scan for bitcoins.
- RLG_RLG 15y ago
  Inside job is usually the answer for targeted attacks against inside systems. Inside collusion at a minimum. I wonder how anyone can trust their linode systems after an admin account being compromised. It would likely ruin their business to re-install everything, but that is the only way to know root kits have not been installed.
  - lawnchair_larry 15y ago
    Or just check if your instance was restarted and your root password was changed. If it wasn't, you were not exploited this way.
- nknight 15y ago
  You can't secure against God. Of course it's technically possible for a Linode employee to do.

doublec 15y ago

They could have looked at the ip's of bitcoin services and noted those running on a linode. Or collected ip's from bitcoin nodes that their own node has seen and looked up those allocated to linode.

darklajid 15y ago

>Also, was the nature of the attack just that the were able to login to your linode admin panel and from their root the machines and then loot your wallets? The way I understand it the attackers were able to get access to the admin panel and invoked some kind of 'change root password' emergency stuff. The machines were rebooted it seems, which makes sense: The interface of Linode has probably/hopefully no access to the root password. Maybe this 'Reset my root' feature (now I'm guessing) reboots the machine in single user mode or passes init=/bin/sh to the kernel to reset the password once and reboots again afterwards. Only THEN the attacker had access. But yes, he had root. The good (if you want to call it that) part of it is that this procedure rings every alarm possible. The real owner doesn't have the password anymore, as he'll soon figure out. It's everything but sneaky. I DO wonder why root is allowed to log in at all, though..

larrys 15y ago
"The real owner doesn't have the password anymore, as he'll soon figure out." He won't figure it out until he tries to login though.
slig 15y ago
I disabled root login when I was setting up the server. Could my server be affected too? Also admins that only log with ssh keys and don't use root won't be able to notice that, will they?
- darklajid 15y ago
  1) No idea, that's something Linode needs to answer. I only guessed what it takes to change a root password of a VPS system. 2) Very good point. In that case it might work undetected for quite a while..
- devicenull 15y ago
  Probably. You disabled root login how, via the sshd_config file? If so, you're still screwed. Even if you fully disable root, that's not going to stop the init=/bin/sh script. Even if you fix that (securing grub?) you're still screwed because it's a virtual machine, and they can just mount the partition to another VM, and pull all your data/reset root that way. So, maybe if you have an encrypted partition, no root access, secure grub, and real hardware (it's probably possible to dump the VMs memory by snapshotting it, then pulling the key out that way), you would be secure against attacks like this. With a VM? No, it's not nearly secure enough for very important things.