Several cloud servers were deployed on Monday in preparation for the four-day AWS course. These used a Bitnami-provided Amazon Machine Image (AMI) containing a PHP vulnerability. By Wednesday evening, an attacker had found one of them and was using it to mount a denial-of-service attack on a server in Stockholm.
Amazon does their own intrusion detection (actually extrusion in this case, right?), but the report came in from “a confidential third party source”. Presumably the attack was low-key enough to escape detection near its source. Amazon sent a message to the corporate account about nine hours after the detected activity, saying that they had changed the firewall rules to only pass TCP ports 22 (SSH) and 3389 (RDP) and requesting immediate attention.
As soon as the message bounced to the appropriate person, the instance in question was terminated.
There are holes, but the system works.
A little over a week later, Amazon sent a message to the corporate account reporting that Bitrock had reported a vulnerability in the AMI that had been used. Amazon and Bitnami together provided further information on the vulnerability, on how to either work around the problem or (preferably) retire the vulnerable remaining hosts and move the activity to replacements, and on security guidance both in general and on this series of AMIs in particular.
It is interesting that there were five other instances based on the same vulnerable image but only the one had been found and exploited. Amazon’s cloud is enormous, even if you’re vulnerable you may not get noticed — but I would not count on that!
By this time Bitnami had replaced the vulnerable AMI with a patched and compatible one. The vulnerable AMI was gone, Amazon did not want to provide a risk for no reason. They reminded us that we need to change our design if were going to rely on automatically starting more of these instances to scale our cloud architecture under increased load.
In Learning Tree’s Cloud Security Essentials course we start some rather outdated Amazon-owned Fedora Linux images and have an exercise where we do a quick and simple security audit. It has outdated and vulnerable Apache and MySQL network servers started by default.
So, just because it’s available in the cloud doesn’t mean that it’s safe and current. The cloud provider will let us know if something really blows up and someone complains, but in IaaS system maintenance and security is our responsibility.
Well, that’s precisely what it has to be according to the accepted definition of “cloud computing”. The rapid elasticity and measured service require us to take responsibility, and our control and visibility of the process gives us better compliance along with that significantly lower price.