Penetration Testing your AWS environment - a CTO’s guide
So you’ve been thinking about getting a Penetration Test done on your AWS environment. Great! What should that involve exactly though? There are many options available and knowing what you need will help you make your often limited security budget go as far as possible.
Broadly, there are four key focus areas for most penetration tests involving AWS:
- Your externally accessible cloud infrastructure
- Any application(s) you’re building or hosting
- Your internal cloud infrastructure
- Your AWS configuration itself
We’ll take a look at each one, starting with the most important:
The good news here is that by default AWS does its best to help you stay fairly secure. For example, the default “launch-wizard-#” security groups don’t let your EC2 instances receive communication from the outside world, unless you actively specify it by adding additional rules.
That said, AWS still allows you plenty of rope to hang yourself with if you‘re not careful. Classic mistakes like engineering teams changing security groups to allow all inbound access is still a problem, and the nature of DevOps means services can be coming up and down on a regular basis, not always in the knowledge of team managers.
Put simply though, there is no easier way for a hacker to compromise you than finding a simple security weakness in your internet-facing infrastructure that has been overlooked, whether that’s an exposed database, or software with known vulnerabilities. This gives attackers the maximum payoff, for the minimum effort, and so the likelihood of this happening is the highest — therefore should be your first port of call to fix.
Typically though, these types of weaknesses can be picked up easily by a vulnerability scanner, and due to the changing nature of your environment (and the new vulnerabilities being released daily); are more suited to ongoing checks than they are a penetration test, which is typically conducted only once or twice a year. Fortunately, there are plenty of solutions out there, and you should definitely be using these prior to even considering a penetration test, or you’ll be paying someone to tell you something you could already have known.
As it’s your most exposed attack surface though, you probably wouldn’t want to remove your external infrastructure from the scope of any pen-test, but you shouldn’t assign a large proportion of your budget to it if possible, and don’t expect to see many results beyond what you’ve come to expect from your vulnerability scanning tools.
Many companies who are using AWS will be using it for hosting some kind of web application(s) for their customers, employees, or partners. And as web applications are designed to be exposed by their nature, they grant attackers the second easiest way into your systems — if not developed securely. This makes them the second most important attack surface after your external infrastructure.
Examples of such attacks include the famous TalkTalk hack, where a 17-year-old customer managed to find his way into their customer database and extract millions of records.
Always consider the impact and likelihood of an attack at this layer. Whether your application is fully accessible to the public, or to a limited set of customers only should factor into your decision making. Applications with “free trials” for example would allow an attacker to sign up and start having a go. B2B services for paying customers/partners may have a lower threat profile, although still not negligible, and apps for employees lower still. On the other hand, some applications contain such sensitive information the impact may seriously outweigh the likelihood.
So depending on the risk profile of your application, you may find that if you can only afford penetration testers to do a few days work, this is highly likely where you should be looking to spend their time. While automated tools exist for this type of testing, and can be useful to cover the gap between penetration tests, nothing on the market today can replace the quality of a human tester who will understand the business logic of your application, and look for ways to impact it.
The next layer of attack is the infrastructure your application is built on. Having covered off the external infrastructure, the internal side is only accessible if an attacker already has breached your defences in some way. So the threat profile here is secondary to the previous two.
Old-school penetration tests of data centres or corporate networks often revolve around gaining a foothold, then “pivoting” from one system to another, eventually leading to full-blown compromise of administrator accounts or key systems.
This is where AWS environments can differ from more traditional penetration tests though, as the software-defined nature of AWS networks often mean that tighter controls are maintained between networks, and lateral movement is a challenge. For example, once again, the default “launch-wizard-#” security groups don’t let your EC2 instances talk to each other unless you actively specify it by adding them to a VPC or by adding additional rules. However, all but the most simple of AWS accounts get away with such simple configurations, and as shown in the recent Capital One breach, it is possible for attackers to compromise IAM role credentials and use those to access resources.
Additionally, the baked-in access and security controls in AWS mean that you’re far less likely to have created environment-wide “administrator” accounts that can be compromised via any of your EC2 instances. It’s more likely that you’re using privileged AWS accounts to do this, and so an AWS Config Review can add much more value than an “internal” infrastructure test.
Similarly, while unpatched software and insecure services on internal systems can be an issue, it depends to what extent you’ve created private networks in your AWS environment, and what systems can access what others. The more complexity you have, the more an internal pentest may add value. If you’re simply running a handful of EC2’s each with their own security group, you may want to skip a traditional “internal” pen-test, and consider a config review instead.
As mentioned, out of the box AWS does a lot for you in terms of security, but an AWS config review can tell you if you’ve set things up in a robust way.
Classic examples of poor AWS config are the exposed S3 buckets you often hear of, but can also include things like admin accounts with too many users being able to access them.
Once again, this can often descend into paying someone to tell you what you already know (or could easily have found out), so it could be well worth trying out some free tools before you commission a pen-test (a quick google throws up a variety of options), as the methodology is likely the same and you may find you have to answer a lot of questions you could have just answered yourself anyway.
If though you’re not confident in the security stakes, or for compliance reasons need a third-party audit, then feel free to get in touch with one of our cyber-security specialists to discuss what we can do to help.
Penetration testing in AWS should be treated carefully as it would be easy to spend time and money in the wrong places. Sensible use of automation should always come before expensive consultancy-hours, and when those are needed, they should always be used in the most cost-effective way.
We hope this article serves you well, and if there’s anything we’re missing or you didn’t find here — do get in touch at firstname.lastname@example.org. We’d love to hear your thoughts!
Intruder is a cloud-based vulnerability scanning platform that can be used to check for known vulnerabilities in your AWS environment to reduce your attack surface. For a free trial for up to 30 days, click here.