A Single Point of Failure in the Cloud

On June 17th this year an Australian company called CodeSpaces discovered it had a problem.

CodeSpaces provided cloud based source control services to software developers. Its infrastructure was build using Amazon Web Services.

On June 17th it was suffering from a distributed denial of service attack. This unfortunately is not an unusual event for web-based companies.

However, at the same time it started receiving extortion threats from someone who had evidently obtained access to its Amazon Web Services control panel.

It did not end well.

The company attempted to regain exclusive access to its control panel. When the extortionist realized this, he set about deleting everything he could in the company's web services account. This included virtual servers, data stores, and backups. By the time the company had regained exclusive control of its web services account, there was not enough of the company's digital assets left for it to continue in operation.

The company's single point of failure in this case proved to be the credentials required to login to its web services account. It's not known how the attacker obtained these credentials - perhaps a phishing or a social engineering attack. It's also not clear if the company had one set of credentials or many, or if the sets of credentials had been properly limited in scope using the "least privilege" principle.

In the Amazon Web Services security model there is always a master user, protected only by an email address and password. This account has total administrative access. Secondary users can be set up with highly restricted roles and optionally using two-factor authentication. The attacker may wll have set up additional accounts to maintain access if a compromised account was removed.

Some important lessons can be learned here:

• Accounts with full access need to be very well protected.
  Preferably they should only be used to set up other accounts with lesser privileges. There will always be a danger that they can be phished, or that the account credentials can be reset by social engineering of the supplier, but if the number of people using credentials with full access is restricted, the risk can be minimized.
• The list of users should be regularly checked to ensure that no extra users have been added, and that all users (human or machine) have the least privilege needed to perform their roles.
• Online backups are not a perfect substitute for offline backups.
  This is particularly true when human actors are involved. If the attacker had to request that tapes or disks be mounted or shipped before data could be deleted, it is unlikely he would have succeeded in causing so much damage. (This also applies in the case of human error, as well as in the case of malware problems).

For CodeSpaces description of the incident:
http://www.codespaces.com/