Code Spaces Hosting Shutting Down After Attacker Deletes All Data

An anonymous reader writes Code Spaces [a code hosting service] has been under DDOS attacks since the beginning of the week, but a few hours ago, the attacker managed to delete all their hosted customer data and most of the backups. They have announced that they are shutting down business. From the announcement: 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. Reaching out to the address started a chain of events that revolved around the person trying to extort a large fee in order to resolve the DDOS.

At this point 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.

Comments

Git

[blackiner]

This is why git is such an effective code hosting solution. Everyone who has cloned the repository is a potential backup copy.

Re:The cloud

[Penguinisto]

Good thing people hosted their stuff on the cloud...

I don't think their problem is necessarily because it was "on the cloud" - the same thing could have happened if someone penetrated a corporate network and got hold of a VM farm. A bigger obstacle to be sure, but if your corporation has partner/vendor access and a not-so-sharp security guy...

One question I have though - instead of changing a password, why couldn't they have called Amazon, had the thing universally locked out for that company, replaced all root-level access with a new account, and sent the new username and p/w by phone back to the company?

Also, why didn't they have an offline (think: off-cloud) backup of the stuff? Sure it costs time/money/skull-sweat to do that, but it's worth the time and trouble in the end. After all, if your family jewels are hanging out there, it always pays to have a DR plan for 'em...

If nothing else, they could have set up a separate and distinct AWS account/rigging as a "DR" of sorts, with DB replication and the works feeding it as a warm DR site. That way if some jackass compromises the first, you only need to stop DB replication, turn on the rest of the DR servers, do a quick test, and shift your DNS to the backup site - 15 mintues later, you can delete the objects yourself in the original site if you want (while you set up yet a different site and build a new backup site to replace the one you just put into production.)

We have a sizable AWS setup where I work, and first/foremost we back that shit up (the DB contents) to machinery that we control. We also have a means of re-deploying/rebuilding if necessary; sure it takes time, but it's better to have it and not need it...