5 ms·

Linode exceeds technically in providing reliable VPS instances. Unfortunately, that's overshadowed by their lax approach toward security and their inability to

Linode exceeds technically in providing reliable VPS instances. Unfortunately, that's overshadowed by their lax approach toward security and their inability to be transparent when problems come up. This is not the first incidence where their lack of transparency has come under fire. This latest update dances around the issue and doesn't go far enough to explain what happened, whether or not your data is at risk, and what is being done to rectify it. If you are a Linode customer reading this, there is no indication as to whether or not you should cancel your credit card number. You, the customer, are left to decide on your own without all the information. Does Linode have an obligation to advise their customers to request new card numbers? It doesn't look as if they card information was stored in compliance with PCI-DSS and their systems were breached and private information was compromised. Is "the private key was also compromised but we don't think they can guess it, so let's just move on" good enough? Customers shouldn't have to read between the lines on security updates like this. I expect the companies I deal with to be up front and transparent, even if it makes them look bad. The reality here is that they messed up, not because they didn't patch a week-old exploit soon enough, but because of the poor security practices they had in place internally that allowed the hacker to get the information they did, and by not being up front with their customers to begin with. Any company can tell you that they take security seriously and that their customers best interests are their highest priority, but what ultimately matters are your actions. What are your security policies? What is your company culture toward security? How quickly do you announce problems and how transparent are you in those announcements?

dangrossman 14y ago
> It doesn't look as if they card information was stored in compliance with PCI-DSS Why do you say that? The requirements are basically to use strong encryption, only store those encrypted numbers on a system not accessible from the public internet, have auditable access controls and logs, and have a procedure for keeping systems up-to-date. The last 4 digits of the card are not subject to the same requirements as the full account number. All of that doesn't prevent the scenario that happened playing out -- someone gets into an internet-connected server, then can connect from there to the database server with the encrypted credit card numbers.
- toomuchtodo 14y ago
  So they violated the whole "only store those encrypted numbers on a system not accessible from the public internet" part.
  - dangrossman 14y ago
    No, they didn't... You have to be able to reach the server over a network somehow to be able to store new cards and charge existing ones. The requirement is not that the server have no NIC, just that it not be internet-facing itself. The DB server was only accessed through the compromised web server, not directly through the public internet.
    - jmillikin 14y ago
      The attacker claimed that he compromised their webserver. If he had access to the private key and encrypted numbers, then they were indeed being stored on an internet-facing machine. 07:52 < HTP> the CCrypter class of the linode application context was accessable from outside the wwwroot using undocumented ColdFusion methods. i was fully able to decrypt the ccs using the in-memory privkey that they supplied the password for.
      - dangrossman 14y ago
        Let's make this more clear: Linode has two servers. One is a web server that runs their website and contains its source code. One is a database server containing customer information and encrypted credit card numbers. The web server is connected to the internet. The database server is not. They communicate over the private network. The web server is compromised. The attacker has the source code, which includes the IP/host and login credentials for the database server, since the website code talks to the database to function. The attacker can now access the encrypted credit card numbers in the database by connecting from the web server. At no point are the encrypted numbers stored on an internet-facing machine, but the attacker now has access to them. There is no evidence that says otherwise. There's no way to build this that doesn't have a path from the internet to the card numbers either, since eventually they need to get onto an internet-connected machine to talk to the payment gateway and actually charge those cards.
JshWright 14y ago
> Is "the private key was also compromised but we don't think they can guess it, so let's just move on" good enough? You have to take that a step futher... "we don't _thing_ they can guess is, and we don't _think_ they were able to recover it from RAM"

dangrossman 14y ago

> It doesn't look as if they card information was stored in compliance with PCI-DSS Why do you say that? The requirements are basically to use strong encryption, only store those encrypted numbers on a system not accessible from the public internet, have auditable access controls and logs, and have a procedure for keeping systems up-to-date. The last 4 digits of the card are not subject to the same requirements as the full account number. All of that doesn't prevent the scenario that happened playing out -- someone gets into an internet-connected server, then can connect from there to the database server with the encrypted credit card numbers.

toomuchtodo 14y ago
So they violated the whole "only store those encrypted numbers on a system not accessible from the public internet" part.
- dangrossman 14y ago
  No, they didn't... You have to be able to reach the server over a network somehow to be able to store new cards and charge existing ones. The requirement is not that the server have no NIC, just that it not be internet-facing itself. The DB server was only accessed through the compromised web server, not directly through the public internet.
  - jmillikin 14y ago
    The attacker claimed that he compromised their webserver. If he had access to the private key and encrypted numbers, then they were indeed being stored on an internet-facing machine. 07:52 < HTP> the CCrypter class of the linode application context was accessable from outside the wwwroot using undocumented ColdFusion methods. i was fully able to decrypt the ccs using the in-memory privkey that they supplied the password for.
    - dangrossman 14y ago
      Let's make this more clear: Linode has two servers. One is a web server that runs their website and contains its source code. One is a database server containing customer information and encrypted credit card numbers. The web server is connected to the internet. The database server is not. They communicate over the private network. The web server is compromised. The attacker has the source code, which includes the IP/host and login credentials for the database server, since the website code talks to the database to function. The attacker can now access the encrypted credit card numbers in the database by connecting from the web server. At no point are the encrypted numbers stored on an internet-facing machine, but the attacker now has access to them. There is no evidence that says otherwise. There's no way to build this that doesn't have a path from the internet to the card numbers either, since eventually they need to get onto an internet-connected machine to talk to the payment gateway and actually charge those cards.

JshWright 14y ago

> Is "the private key was also compromised but we don't think they can guess it, so let's just move on" good enough? You have to take that a step futher... "we don't _thing_ they can guess is, and we don't _think_ they were able to recover it from RAM"