When it comes to cloud computing, APIs more or less drive everything, but in the eyes of some researchers, existing security controls around them haven’t kept pace.

While individual components of a system can be secure, when that system gets deployed in the cloud it can often become insecure – and get worse at scale, according to Erik Peterson, a cloud technology researcher with Veracode. Peterson, who also refers to himself as a Cloud Security Weapons Manufacturer, described the ‘Emergent Insecurity’ of the cloud in a talk Wednesday at the Source Conference in Boston.

Early on in his presentation, Peterson recounted a Chris Hoff quote that he claims sums up the concept: “If your security sucks now, you’ll be pleasantly surprised by the lack of change when you move to cloud.”

In particular Peterson warned about the dangers associated with API credential exposure, something which could easily lead to apps being rigged to spread malware, cloud infrastructure adapted for use in a Bitcoin mining operation, additional attacks being launched, and the most critical: the downloading of sensitive customer data.

“API access is the new equivalent to physical access,” Peterson said, “If someone compromises your most sensitive API credential, it doesn’t matter.”

API keys, which protect cloud metadata – information that usually includes Amazon Web Services (AWS) access credentials, and startup scripts – can often be the only thing standing between users and total compromise, he stressed.

Peterson, who’s researched cloud and architect solutions in AWS since 2009, warned that old, vintage software vulnerabilities can easily be leveraged for compromise.

He’s seen it all: Server-side request forgery vulnerabilities, XML external entity vulnerabilities, command injection vulnerabilities, unintended proxy or intermediary vulnerabilities. Each one can lead to the unintended exposure of metadata, but when they all come together, it can result in a full stack hack, or what Peterson likens to “death by 1,000 cuts.”

For instance, he claims, if an attacker gained access to an API key they could escalate privileges. If they gained access to cloud DNS, it could reveal the private IP of the web server. If an attacker got access to an IP address, they could uncover an app that hasn’t been tested. Once in, it’s possible an attacker could do the worst, Peterson claims, clone the database for quiet extraction.

“Lots of people are shuffling cloud data and not thinking of the flaws,” Peterson said, “they all lead to exposing that user data, all that great info my system needs to startup.”

There are ways to prevent a full stack hack, mainly through encryption, but common sense doesn’t hurt either.

“No more checking your API keys into GitHub,” Peterson advised.

Attackers often scour the service looking to exploit vulnerabilities and access cloud metadata API. Storing sensitive information like API keys there can be a quick lesson in futility. That still doesn’t stop users from doing it though; a cursory search on the service for “SECRET_ACCESS_KEY” last year yielded 7,500 placeholder results, Peterson said.

One developer discovered 140 servers running on his Amazon Web Services account last year after a bot scanning GitHub sniffed out his Amazon Elastic Compute Cloud (EC2) keys.

Developers should get off the old EC2 classic and lockdown their Simple Storage Service (S3) buckets, Peterson said Wednesday. If they aren’t already, developers should log everything, especially API activity, he said, adding that some AWS tools, like Cloudtrail, which records AWS API calls, and Netflix’s Security Monkey, which can be used to monitor and analyze AWS configurations, can be invaluable.

Instead of trying to control change, developers should react to change, rethink their threat model and realize that lower priority software vulnerabilities, like SSRF, or XXE, can still be deadly, Peterson said.

“If you have a key that an app is using ask yourself: What’s the worst thing that could happen if it was compromised?” Peterson asked aloud, “Is there a path that leads to my entire environment getting deleted by some unknown entity?”

Categories: Cloud Security, Vulnerabilities, Web Security