©2021 Reporters Post24. All Rights Reserved.
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, are customised to your cloud environment. You should consider using one of these tools before running a penetration test, 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 whether 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.
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.
source: https://thehackernews.com
