Code Spaces’ Cloud Goes Up In Smoke

Code Spaces was a community for developers that was built on Amazon’s cloud. As of Tuesday, June 17th 2014, the website that operated uninterrupted for over 7 years suddenly came to a screeching halt.

CodeSpaces was built using Amazon AWS. In a letter to former users of the service, the current CodeSpaces.com website says, “We received a well-orchestrated DDOS against our servers, this happens quite often and we normally overcome them in a way that is transparent to the Code Spaces community. On this occasion however the DDOS was just the start. An unauthorized person who at this point who is still unknown (All we can say is that we have no reason to think its anyone who is or was employed with Code Spaces) had gained access to our Amazon EC2 control panel and had left a number of messages for us to contact them using a hotmail address.”

How Did It Happen?

Up to this point, it is still unknown but there are several theories. Perhaps an admin’s personal computer was key logged; perhaps someone within the organization had a malware infection that leaked sensitive corporate information? Other theories surround the company being social engineered or someone from CodeSpaces logging into the Amazon AWS account over a public network or computer.

At this point, the analysis is unclear as to how this security breach happened. However, it does appear that this “Cloudjacking” vulnerability is discussed in the Cloud Security Alliance’s Notorious Nine threats to Cloud Security. Reviewing these nine threats that CloudWedge has written about in depth will help you keep your cloud safe from attacks such as the attack on CodeSpaces.

Once news of this breach started to circulate, the first questions many cloud analysts asked was, “Why doesn’t CloudSpaces just restore the backups?” While cloud service providers such as Amazon provide robust backup options, backups are also the target of this type of attack. If someone has access to your cloud management portal, your backed-up images and data are also at risk. While backing up data within your cloud is recommended, other cloud experts suggest that you should also use backup resources outside of your cloud such as onsite data backups or cloud to cloud backups.

In this case, CloudSpaces’ backup data was also targeted and CloudSpaces did not have external backups created. CloudSpaces writes, “We took action to take control back of our panel by changing passwords, however the intruder had prepared for this and had already created a number of backup logins to the panel and upon seeing us make the attempted recovery of the account he proceeded to randomly delete artifacts from the panel. We finally managed to get our panel access back but not before he had removed all EBS snapshots, S3 buckets, all AMI’s, some EBS instances and several machine instances. In summary, most of our data, backups, machine configurations and offsite backups were either partially or completely deleted.”

The result of this unauthorized entry into CodeSpaces’ AWS account has been detrimental as evidenced by the organization’s homepage. In fact, CodeSpaces has apologized profusely for the incident and has indefinitely stopped conducting businesses while simultaneously issuing refunds. CodeSpaces writes, “All that we can say at this point is how sorry we are to both our customers and to the people who make a living at Code Spaces for the chain of events that lead us here.”

CloudWedge