Hunting VPNs
Working in the PCI space makes for some really fun penetration testing challenges. With the PCI-DSS 3.1 language stiffening on what qualifies as acceptable segmentation, we get to see lots of different popular segmentation strategies. To be able to say that somethign is out of scope for PCI compliance, it has to be segmented from the cardholder data environment (CDE), “such that even if the out-of-scope system component was compromised it could not impact the security of the CDE”.
One of the more popular designs is to create a separate network for the CDE and allow users to VPN into it to access or administrate CDE systems. There is a certain fundamental beauty about this design, especially when properly implemented with a good multifactor authentication. It can make for a difficult target for the penetration tester.
In this type of environment, the problem to be solved by the pen-tester (after making the obligatory escalation to domain admin on the internal network) is finding the users who can VPN, and then exploiting any weaknesses in the VPN access method to get access to the CDE. So how do we find those people?
My first approach hopes that they enable split tunneling – in this case, it’s really easy to find people who access the CDE because they tend to stay connected all day and not think twice about it. I’ll collect a netstat for all domain-attached systems and look through the results to find any active connections to the CDE network. Once I find some, it’s a straightforward matter of pivoting through those hosts into the CDE, and success criteria aren’t that far away.
Split tunneling is always wrong, though, so lots of places do actually disable it. What options do we have now? And once I find someone who uses the VPN to access the CDE, how do I leverage that to get access for myself? This was the situation I was presented with in a recent pen-test.
Finding VPN users was the first step.