Mapping Network Attack Paths

Leveraging cloud APIs to identify network risks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

🔒 Related Stories: Network Security | Penetration Testing

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Every time I perform a penetration test or security assessment, I’m looking for ways to improve the results and meet a customer’s specific objectives. I wrote about how I created a simple web API fuzzer for one client engagement because the client wanted an API pentest. In an upcoming IANS research report, I’ll write about a tool I wrote for finding blind XSS that sends me a text message when an attack succeeds because that was the client’s primary concern. For a recent security assessment, a client wanted to know if developers could access anything in a production VPC. This objective led me to a project I’ve been meaning to work on for a while — mapping network attack paths in the cloud.

More Paths = Increased Risk

I’ve written in my book on Cybersecurity for Executives in the Age of Cloud and on this blog already about the exponential attack paths created by broad network rules. I provide a general formula as a way to think about the risk increase for each exposed port. For example, let’s say you have an application server and a database server. You set up precise rules in the spirit of zero-trust networking to only allow access from the application server to the database server. You have a one to one mapping, and no other host may access the database server. You’ve given an attacker one point of entry to your database from one application server in this over-simplified scenario.

Now imagine you don’t specify a security group ID or a specific IP address that can access the database. Instead, you allow any IP address (0.0.0.0/0) to your database on port 3306, but you don’t have an Internet Gateway in your route table, so nothing on the Internet can get directly to your database. You think you’re safe since you haven’t exposed the database to the Internet.

But say you have 20 hosts in your internal network that are accessible from the Internet. Each of those hosts has no outbound network access restrictions (the default in an AWS security group). Now you have given an attacker 20 chances to get to your database instead of one because those hosts have network access to your database. Say you have five databases in your network set up the same way. Now the attacker has even more ways to get at your data because they can get on any one of the 20 hosts and try to get to any one of your five databases if the network is wide open. These are the types of attack paths I wanted to quantify.

Mapping Paths Through the Network

I spoke at RSA in a presentation called Red Team vs. Blue Team on AWS a few years ago about the concept of picking a target and mapping your way backward to a public-facing host that you might be able to leverage in an attack using AWS CLI commands. In that case, I mapped out the ability to get to a database facilitated by a network with open outbound network access that lacked appropriate segregation. I provide some simple enumeration scripts and steps in a lab in my cloud security class to give students a starting point for how this can work.

However, I wanted to take this a step further. What if you can map out all the attack paths on a network? I think of a network as a database full of data I can query. Paths through the network are similar to complex financial queries I wrote as a back-office developer for Capital One Investing. Some of the queries were pretty complex when trying to find that needle in the haystack transaction gone awry. Finding interesting data on your network or in your network logs is similar. I want to query attack paths and quantify risk based on the number of paths and sensitivity of resources that may be exposed.

People to query data in different ways. Some tools provide a visual of the type of mapping I’m describing, but I am often better at reading data than looking at a complicated diagram with lines going all over the place. On a complex network, the whole screen is full of lines, and it is hard to decipher what’s going on. I want to understand the risk of exposure numerically — How many connections are possible, and how can we reduce those numbers, thereby reducing the risk? Also, data in its raw form, grouped appropriately, allows me to quickly scan it for the critical connections for the specific relationships that I’m seeking.

For this particular assessment, I enhanced my scripts to list every possible resource accessible on the network, along with every other cloud resource in the account that could access each target by leveraging an open network path. This approach requires understanding route tables, network access control lists (NACLs), and security groups on AWS. The ultimate question I was trying to answer was whether a resource in the development environment could access the production environment.

Querying the Network Map

After mapping out the relationships, I queried for any resources that had access between the two environments. Mapping all potential paths and querying them allows me to quickly determine what cloud resources in the development environment may access a production environment. If no network path exists between the resources, including any pivot points, one can presume an attack is impossible between those systems. If a path does exist, I have more work to do.

Network access alone doesn’t give access. I’ll need to consider other things like IAM (identity and access management) controls and any other security controls that might stop me from accessing the data. But as you can hopefully see, the network stops me in my tracks if no path exists. That is what makes network segregation and zero-trust networking so powerful. (Not to mention well-architected networks help you spot attacks, as I explain in my class.)

Of course, the path from development to production is not the only point from which an adversary can initiate an attack, but it was the ask for this assessment. Taking this a step further, I can take a target and map out any host that an attacker can leverage to access that host by taking these endpoint to endpoint mappings and linking them together to form more complete paths. An attack path could exist from any publicly accessible resource through any pivot points to any target data or cloud resource on the network. Paths may exist between different types of cloud resources. I can map out all these relationships programmatically using cloud APIs.

What about reducing the risk?

Running a query of attack paths in a network demonstrates the number of ways an attacker could get to a host if a vulnerability exists and what the attacker could pivot to once obtaining access. The result could be an exponential number of connections on a network lacking segregation. You can end up with hundreds or thousands of potential attack paths. I can demonstrate this to a customer by means of data — a list of allowed connections — and a quantifiable number of avenues of attack.

I can also show how locking down the network to only the required ports, protocols, and IP addresses reduces potential threats. Instantly the number of possible paths through the network dramatically decreases in an extensive network with numerous systems. By reducing the number of attack paths, the organization decreases risk because an adversary has less to leverage in an attack. One can argue about the likelihood of those paths providing a useful attack vector due to other mitigating factors and put some arbitrary risk qualification on the open path — high, medium, or low. However, if the path doesn’t exist, the risk of an attacker leveraging it in an attack is zero.

Want to find out what attack paths exist in your cloud network? Do you want to know if your developers can access your production resources? Hire 2nd Sight Lab for a penetration test or security assessment.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2020

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab