Microsegmentation and How to Attack it

By Chase Alexander

cma7711@rit.edu

4/11/22

***

DISCLAIMER The materials discussed in this article are solely intended for informational purposes. I hold no responsibility for any damages caused with these materials.

***

What is Microsegmentation?

This is a very important question to ask, as microsegmentation has become a bit of a buzzword in the security industry as of late. Cisco defines microsegmentation as follows: “Micro-segmentation creates secure zones across cloud and data center environments to isolate application workloads from one another and secure them individually” (1). As helpful as that is, we can do a little bit better by breaking it down by function. Microsegmentation is an attempt to move away from perimeter network security, and instead focus on securing individual workstations and devices. Devices are typically grouped by functionality, and then given a label based on what group they fall into (databases, load balancer, router, etc…). Devices can also be grouped by the department that they exist within, so this can be things like finance, research and development, information technologies, etc. . .. The existence of these groups is important to the actual security policy that gets generated. A machine learning algorithm will observe devices and learn their key functions based on the labels placed on those devices by the security/IT teams. It will then generate policies looking to strip those devices down to their bare minimum required network protocols. For example, a business user has almost use for SSH, so we would block any inbound or outbound SSH transmissions. It does this at the workload level through a lightweight agent on the device, often using IPtables for linux, and windows firewall for windows. There are a few goals that go along with microsegmentation technologies:

  1. Limit the attack surface- by limiting the number of protocols that a device will acknowledge, you limit what tools attackers can use to penetrate a network or a device. For example, databases requests should go though a proxy, so any http request made from an address that isn’t the proxy should be ignored.
  2. Reduce lateral mobility across the network- With less protocols available between devices, the likelihood of compromising multiple boxes beyond the first is not likely. A box that is used by a business user who only has http enabled will not be very helpful in compromising other boxes on the network.
  3. Digital forensics knowledge- With agents on every device that people want to protect, a 360 degree picture of the network is created. Every single network transmission is stored by the machine learning algorithm, and can be referenced if there is ever an incident.

What is Microsegmentation not?

Microsegmentation is not some magic weapon against attackers that makes the whole network immune. Sure things are limited greatly, but this is nothing that cannot be done already by users applying security rules across devices using IPtables or Windows firewall. Things are made much easier through microsegmentation with policies being pushed out with group labels, and being updated automatically through a machine learning algorithm. This however comes at a cost. Policy generation has a number of sliders falling somewhere on the spectrum of very aggressive to very passive in policy generation. Machine learning is not a perfect science, and every decision comes with a certain degree of confidence. This often means that there will be some protocols left on allow that shouldn’t be, or some policies that get blocked that could have key functionality. To summarize, this is not some perfect security solution or by any means something that radically changes security at an individual machine level. If anything, it leaves individual devices more susceptible since their security policy is now based on a machine learning algorithm that is by no means perfect.

Microsegmentation deficiencies

There are also some issues that exist around potential intruder scenarios. If an attacker is able to compromise a box with something like a dead drop usb, which does not leverage networking protocols, microsegmentation does nothing to remove them. If they are not generating network traffic, microsegmentation cannot do anything to detect them or act on them. Once an attacker is in and generating traffic, anything that is an approved protocol will not raise a flag. What this means is that if an attacker is able to learn what is and is not approved on a network, they can then do their operations completely under the radar. Let’s say that an attacker doesn’t know what the rules are, and they fire off a bunch of traffic that gets blocked. In an ideal scenario, the system is able to limit or cut off functionality because it can assume the box is compromised. In reality though, all it will do is alert administrators.

Attacking Microsegmentation

I would like to explore how one might go about attacking a network using a microsegmentation service like what has been discussed earlier in the article. First we should identify who this service is for. This is not a solution for smaller or even medium size companies, seeing as how the product is incredibly expensive. We can safely assume that the only targets using this service are of considerable size with multiple users and workstations per sector. We now have a target, being a section of a large company, but what is the objective? The ultimate goal of the attack is up to the attacker, but before we get there, the preliminary objectives are as follows:

  1. Learn the security rules across the network
  2. Gain control of a box using an approved network protocol
  3. Spread influence to as many boxes as possible using using approved techniques

Let’s assume that we are able to compromise the first box with something like a dead drop usb. The way that we compromise the first box is not terribly important, this could be a social engineering attack and we get physical access, this could be through a phishing attack though HTTP which for many users will be an approved protocol. Any way it happens, the first box gets compromised and we haven’t raised any alarms yet. The first step is to gather as much data as we can without generating network traffic. Like was stated earlier, there is no way for microsegmentation to detect us when we don’t generate traffic, and it has no way of kicking us out of the box. The next step is to figure out what security rules are allowed, and similarly to the assumptions we made about our target, we can make some more assumptions fairly safely. Whatever subnet we land on and compromise a box on, we can assume that there are relatively similar rules on the boxes around us. For example, the subnet that the legal department runs on may be 10.192.168.X. Most people in a given department will have very similar, if not the exact same groups assigned to them for policy generation, so we can assume that they will have very similar, if not the exact same security rules applied to them. We can also get a good idea of valid target IP addresses to expand our influence onto. If we learn that our initial box is 10.192.168.1, then given that we are attacking a large company, it is a fairly safe assumption that there will be a 10.192.168.2 , 10.192.168.3 , 10.192.168.4 . . . and so on. If we compromise 10.192.168.200, then we can simply work down to find our targets. So we can find other devices on the network, and we can assume they are using similar security rules, but we need to find out what those rules are. We can do that using the knowledge of how the system handles disallowed outbound traffic. That traffic gets dropped before it leaves the box. This will always result in a timeout. I have simulated this by creating IPtable rules on VM’s, and using ssh as a test protocol. As anticipated, all the traffic captured on wireshark is meaningless, and an ssh timeout error is generated, as shown below:

It is also worth noting that there was no traffic generated on the target box. Now this is very different from when there weren’t any IP Tables rules in place and we received a connection refused error, as shown below:

This time the transmission went through and was simply refused. Also of note, traffic was generated from both boxes. So what does this mean for the sake of the theoretical attack? This is how we can determine if a protocol is allowed or being blocked, based on the types of errors we are receiving. This can be scripted, and tested with a number of different network protocols, as the principles behind it do not change. Moving away from the theory of how we can determine rules and back to the theoretical attack, we have a script that will tell us what protocols are and are not allowed on this grouping of devices, but it comes at a cost. Firing off hundreds of test packets will raise a lot of flags and we have to assume that we have alerted an administrator. This is why we will carry out this attack at night, or some inconvenient time like a holiday. This will buy us some time but not a ton. Objective one of learning the rules on the system is complete. Moving on to Objective two, knowing what protocols are allowed, we can better inform our attacks on other devices. This is a luxury that this not afforded when security teams are more granular and assign policy individually, but is something we can do since microsegmentation assigns policies by groups. I’m not going to go over every single possible attack in existance and the protocols they rely on, but we need a diverse toolkit of attacks that rely on different protocols so we can cater the attack to the information we have just learned. Script kiddies will not be terribly effective with this structure as they need a deep understanding of everything going on. This attack requires some degree of skill. With that objective two is complete. Finally objective three is to spread our influence using our approved techniques. Up until now, we have to assume almost all of our traffic has been flagged, but knowing what is allowed on the network, we can move to other boxes without being flagged. This is how we can spread our influence and gain some real sticking power in the network. See the diagram below:

In our attack, we moved from the rightmost box, to the leftmost box. The initially infected box made a large amount of flagged traffic between itself and the newly infected box as depicted by the red line. The same can not be said for the safely infected box, as we only used approved protocols to compromise that box. There are only three boxes in the diagram above, but this could in theory be done as many times as there are boxes on the network. If we ever slip up and generate a significant amount of blocked traffic, we can always just respread our influence over other parts of the network to cover our tracks. Finally objective three is complete and the attacker is free to do as they please on the network. 

Common questions, defensive approach, and conclusions

One of the immediate thoughts with this attack structure is as follows: “If defenders know that a box is compromised, then they would logically go and check all neighboring boxes for intruders and work to defeat them.” While that is true, the rate of spread for this attack in theory is very high so attackers can likely move faster then the defenders could keep up with them. Another thing that will slow down defenders is the false positives generated by normal user traffic. Security teams will be on high alert once they are aware of an incident and want to investigate every piece of disallowed traffic, not all of which will be generated by attackers. They will spend a good bit of time investigating normal users as well, which is slowing them down even further. Another question that might be posed in response to this framework: “are there any way that the network can be configured to mitigate things like this?” The answer is yes*. There are routers and devices which can use stealth mode which will not respond to probing connections. The reason for the asterisk is that any network or security team that is doing network configurations like that, likely isn’t going to pay for microsegmentation in the first place. If they are going to manually configure things like that, they may as well segment the entire network themselves and save hundreds of thousands, if not millions of dollars. The final question that I would like to address is “why would someone even use microsegmentation if everything can be done manually?” While I have mostly pointed out flaws with the platform, I actually really adore Cisco’s product. I am a former network security engineer for Cisco and saw this tool be deployed with great success many times. It is a very easy tool that will also require companies to learn a lot about their own infrastructure, as a high degree of understanding is required to deploy the service and form the proper groups. While everything can be done manually it also takes far more time to do so. It also takes many meetings to figure out exactly what functionality each team in a company requires. Manual policy also doesn’t provide the immediate digital forensics and flagging that microsegmentation does. Finally, policy updates happen almost instantly, and any errors the machine learning algorithm has can be manually edited.

Citation:

  1. Cisco. (2021, November 18). What is micro-segmentation? Cisco. Retrieved April 11, 2022, from https://www.cisco.com/c/en/us/products/security/what-is-microsegmentation.html

All graphs and images were generated by myself

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s