Penetration Testing Your AWS Environment – A CTO’s Guide

So, you’ve been thinking about getting a Penetration Test done
on your Amazon Web Services (AWS) environment. Great! What should
that involve exactly?

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, the 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
• Secrets management

We’ll look at each one, starting with the most important:

External Infrastructure

The good news here is that, by default, AWS does its best to
help you stay secure. For example, the default 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 are still a
problem, and the nature of DevOps means services can be coming up
and down regularly, not always with the knowledge of team
managers.

Though, there is no easier way for a hacker to compromise you
than finding a simple security weakness missed in your
internet-facing infrastructure, whether that’s an exposed database
or software with known vulnerabilities. Attackers have the maximum
payoff for the minimum effort, so the likelihood of this happening
is the highest — therefore should be your first port of call to
fix.

It can be challenging to stay on top of cloud vulnerability
management due to the dynamic nature of these systems and
continuous changes to your environment, with new vulnerabilities
being released daily. However, modern vulnerability scanning
solutions, such as Intruder^[1], are customised to your
cloud environment. You
should consider using one of these tools before running a
penetration test^[2], as they help
continuously manage vulnerabilities in your infrastructure with
automatic scans.

Intruder can sync targets from major cloud providers, and keep your targets sync’d when new systems are added to your cloud accounts using the CloudBot functionality. This ensures new systems are included in future vulnerability scans.

As it’s your most exposed attack surface, you probably wouldn’t
want to remove your external infrastructure from the scope of any
pen-test. And, still, 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.

Web Application

Many companies use AWS to host web application(s) for customers,
employees, or partners. Unfortunately, web applications, designed
to be exposed by their nature, present attackers with the second
easiest way into your systems – if they’re not developed securely.
This makes them the second most crucial attack surface after your
external infrastructure.

Examples of such attacks include the Kaseya incident in 2021,
where attackers successfully compromised Kaseya and distributed
ransomware to its customers in a supply-chain attack. The
right-wing social media site Gab was also compromised early in 2021
and had 70GB of sensitive user data leaked because of a SQL
injection vulnerability. Going further back, the famous TalkTalk
hack, 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 a limited set of customers only should factor into your decision
making. For example, applications with “free trials” 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 employees’ apps are still lower. On the other
hand, some applications contain such sensitive information that 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 helpful 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.

Intruder uses a unique algorithm to prioritise issues that leave your systems exposed, making it particularly easy to find out what presents the highest risk.

Internal Infrastructure

The next layer of attack is the infrastructure where your
application is built. Having covered off the external
infrastructure, the internal side is only accessible if an attacker
already has breached your defences somehow. 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 critical systems. Here is
where AWS environments can differ from traditional penetration
tests, though, as AWS networks’ software-defined nature often means
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 simplest of
AWS accounts get away with such simple configurations. In addition,
as shown in the Capital One breach in 2019, attackers can
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 compromised
environment-wide “administrator” accounts via any of your EC2
instances. Instead, 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 others. It’s also worth understanding if you have a
point-to-point VPN between your on-premises network and your cloud
environments. If you do, an internal penetration test may be
appropriate to find out what an attacker can bridge the gap between
these two networks.

The more complexity you have, the more an internal penetration
test may add value. For example, suppose you’re running a handful
of EC2’s each with their security group, or you’re using some of
AWS’s shared/managed services like lambda functions – you may want
to skip a traditional “internal” penetration test and consider a
config review instead.

AWS Config

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 or a lack of multi-factor authentication to
access the AWS console. But, it can also include things like admin
accounts with too many users being able to access them or more
complex IAM rules like how a read-only access policy may allow an
attacker to gain additional privileges in your environment^[3].

Once again, this can often descend into paying someone to tell
you what you already know (or could easily have found out). Before
you commission a penetration test, try out some free tools (a quick
google throws up a variety of options). The methodology is likely
the same, and you may have the answers to your questions
already.

If you’re not confident in the security stakes or need a
third-party audit for compliance reasons, it is valuable to connect
with a cyber-security specialist, like Intruder, to uncover how
they can help.

Secrets Management

Secrets management is how secrets, like access tokens, are
stored and used by your people and applications. It is at the
bottom of our list, but it affects all the previous areas and
deserves some consideration. The AWS configuration review should
include, and inform you of, how your users and services access and
interact with your AWS environment, including permissions assigned
to those users and services. However, this configuration review
will likely only be able to assess the configuration in your AWS
account, meaning in the process secrets management may be
overlooked.

Do your teams use continuous integration or continuous
deployment (CI/CD)? If they do, then it’s likely that the pipeline
used during the CI/CD process will have a level of integration into
your AWS environments. For example, they may have to start new EC2
instances or deploy new Lambdas. How are your internal applications
or services which integrate with your environment storing secrets?
How are your administrators holding secrets?

If an attacker can get access to these secrets, they will be
able to access your AWS environment and be able to escalate
privileges or maintain access to the cloud environment once they’ve
been cleared off your internal network.

So, when you’re considering a penetration test of your AWS
environment, you may be interested in including the configuration
of other integration systems in the scope of the test.
Alternatively, you can split the process across multiple
tools/assessments to focus on individual risk areas. An AWS
configuration review will give you an understanding of how many
things are connecting to your AWS environment using access keys and
the AWS API.

Conclusion

Penetration testing in AWS should be treated carefully, as it
would be easy to spend time and money in the wrong places. AWS is a
vast ecosystem, and it’s hard to cover all the ever-expanding
number of services within a single point-in-time assessment,
especially if you have a significant AWS presence. Sensible use of
automation should always come before expensive consultancy hours,
and when those are needed, they should always be used most
cost-effectively. You may find that the most cost-effective way is
a hybrid approach; you provide access to your AWS configuration,
which can inform and guide a manual review of your complete AWS
estate.

The Intruder Vulnerability Scanner

Intruder is a cloud-based vulnerability scanning platform used
to check for known vulnerabilities in your AWS environment to
reduce your attack surface.

Intruder offers a 30-day free trial of their platform. Click here to try today.^[4]