If you’re a startup developing native cloud apps, then resources like Amazon Web Services are a great way to test your assumptions and then scale your business. Used improperly, though, they’re also an excellent way to expose your code and customer data online. This November, Sean Cassidy, CTO of DefenseStorm, will show you how attackers can bring your cloud infrastructure to its knees – and how to stop them.
In his role developing and managing DefenseStorm’s security data platform, Cassidy sits at the intersection of SaaS and infrastructure security. They are two realms that many security pros don’t connect, he warns, adding that they should.
“It’s surprising how little those worlds collide,” he warns. “For SaaS engineers, sometimes security is just an afterthought, and pen testers often don’t know what’s going on with AWS unless they’ve really been digging into it, and that still hasn’t happened to a large degree.”
From SQL injection to cloud misconfiguration
Traditional attacks on SaaS applications have focused on vulnerabilities such as SQL injection, cross-site scripting and cross-site request forgery attacks. Those all still exist, Cassidy says, but the real danger today lies with a new class of vulnerability.
As SaaS has moved increasingly to cloud -related environments, developers have access to an unprecedented set of capabilities. Development and operations are merging in the discipline commonly known as DevOps, and developers are increasingly encouraged to access computing infrastructure programmatically.
Infrastructure management tasks formerly handled by sysadmins using systems management tools, PowerShell or bash scripts are now increasingly open to developers. They configure their own infrastructure using a mixture of cloud APIs, virtual machines and containers. In short, infrastructure is becoming accessible via code.
This leads to some quick wins for developers, who can develop, test, and deploy code using automated workflows. They can respond quickly to user feedback and turn around application updates in short order. Unfortunately, untrained developers can also leave gaping security loopholes in their applications by not configuring their infrastructure properly.
“Empowered engineers and automation is great, but if you don’t have security leadership to help them, those things will spiral out of control,” he says. “Engineers love to make things work, but they don’t always love to make things secure.”
If you’ve followed the OWASP guidelines and secured your SaaS application against SQL injection attacks, that’s great, he says – but if your Chef server is open to the world, you’re just as exposed.
Data, data everywhere
These configuration errors extend into the public cloud. Developers who deploy to Amazon Web Services without the proper infrastructure discipline can end up badly exposing themselves and potentially endangering the business. These stories keep cropping up.
Last month, Dow Jones finally shut down an AWS repository after misconfiguring it so that anyone with an AWS account could access the data of millions of subscribers. Then, Republican data analytics firm Deep Root exposed almost 200 million US voter records on an open Amazon S3 storage server. Early this month, security firm Kromtech also found three million WWE fans’ personal data exposed on an S3 box.
Most recently, Israeli tech firm Nice Systems exposed millions of Verizon customer records on a misconfigured S3 server. This kind of thing just keeps happening because developers and cloud admins keep making mistakes like these.
This class of error is bad enough, leaving personal data exposed online, but Cassidy worries that misconfiguration could leave intruders with access to core administrative tools.
Shiny, new and dangerous
“It’s no longer about SQL injection. It’s about attacking their Jenkins compilation server, or attacking their monitoring infrastructure. It’s attacking the things that engineers use,” he says.
Part of the problem is that cloud development and deployment tools are both powerful and new, he warns. That’s a dangerous combination.
“The person who has root in a Docker container actually has root in a host machine. You might not realize that, because Docker is pretty new,” he says. “You might not realize that if someone has access to your Kubernetes config panel that they essentially have root on your entire enterprise.”
What happens if attackers gain access to core administrative tools in an AWS environment, for example? They have the keys to the kingdom, meaning that in the worst case, they could take your company down.
That’s what happened to security firm Code Spaces, which offered developers source code repositories and project management services. The company had to shut up shop in 2014 after an intruder gained access to its AWS control panel and asked for a ransom. It refused to pay, so the attacker trashed its users’ files.
At SecTor 2017, Cassidy will release an AWS remote access tool, proving how an attacker could install malicious code within an AWS dashboard after infecting an administrator’s machine.
“Everyone is familiar with traditional root kits for Windows, but I haven’t seen a lot of them for AWS. If you have access to AWS how do you persist and maintain and hide your access?” he asks.
“It will let you do these things with a minimal chance of observation,” he says. Rather than exploiting any bugs in AWS, it will simply hide itself by stealth, using tricks such as creating users with similar names to default users.
At some point, he would like to create a detection tool to help admins stop such shenanigans. In the interim, though, he hopes that this proof of concept tool will raise awareness about security in cloud administration.
What’s the solution to this security problem, other than training developers? Cassidy recommends a mixture of security monitoring and automation. The less that developers and admins have to configure by hand, the more likely a company is to close off loopholes caused by omission or error.
This is a problem that companies wowed by the cloud are only just now waking up to. Register for SecTor 2017, and see Sean talk about the issue in more depth.