Ok so jokes aside, there is a lot more to VPNs than just plugging them in and attacking them to your IAM source. Yet, in far too many cases, the default (and sometimes the only) options are less than secure. These controls which you would think are vital to the security of the environments they protect, are not really designed with proper security and mitigations in mind. I spoke with Ori David, Security Researcher at Akamai on this topic while at Black Hat. Ori gave a talk at Black Hat “Tunnel Vision: Explaining VPN Post-Exploit Techniques” which discussed some of the challenges around how VPN appliances connect into sensitive areas in the networks they are supposed to protect.
We have already seen some of the major players in VPN get popped, from Avanti to Fortinet (Fortigate) Initial Access Via these systems is not the end of the game. According to Ori, here are a lot of things that can be gathered from the appliances once an attacker gets inside the wall. This not even going the “advanced” route of dropping a custom implant into the OS of the VPN. This is just using what an attacker can do from the VPN management interface. This living off the land Is much simpler than needing to obtain RCE on the device. Due to bad standard configurations, or a lack of proper secure configurations one of the most concerning is access into Identity and Access Management solutions or access to application secrets due to hardcoded or weak keys. In some cases, credentials were observed being sent in clear text to parse Active Directory, or EntraID. This is the equivalent of having a stone wall on the outside of your castle and paper for walls inside.
One technique which Ori talks about is capturing user credentials via a rouge access a rogue authentication server, which you can set up in the management interface. Ori noted that instead of matching a user to the authentication context they should be in, both VPNs tested, Fortigate and Ivanti, compared the credentials against all authentication options available. This allowed the rogue authentication server (configured as RAIDUS for ease of use), to capture the passed credentials for decryption later. It is not what you would call the best design for authentication…
Ok quick side trip:
I am not sure about you, but I am more than a bit over seeing security product with insecure default configurations. I am just as over seeing some of these same solutions lack proper security options when connecting back into core or sensitive environments. I mean, these are supposed to be security products, right? Shouldn’t they have put some effort into… you know… security? Ok, perhaps the Pandemic caused a rush to get these appliances rolled out and implemented, but I would think that 3 years later these bad defaults and configuration options should have been remediated by either the vendor, or the organization where they are installed. It boggles my mind that there are still people who still will not do the basics these days. Ok, soapbox put away for now.
Back to the conversation:
Ori and I talked about additional concerns in connecting applications into the VPN appliance and how easy some systems were to recover the secrets for the apps, once again due to bad default configurations. These allow an attack, who has gained access to the appliance, to move internally using existing access granted to the apps in question. Just as clear text credentials for parsing your IAM solution will give them easier movement behind the wall.
Security and IT teams need to change their focus from “ok we have a lock on the door” to, “what could someone do, if they picked the lock?” This should not be an unusual thought process and should be part of tabletop exercises, and as part of general planning for cybersecurity and resilience. There need to be some form of attack path graphing to understand what these edge appliances touch, what permissions they have, and what access an attacker would have at different stages of compromise. Without these considerations in design there is a very high chance that a failure of imagination will result in someone having a very, very bad day.
Ori’s research has only highlighted what many people have known about for years, perhaps in the backs of their heads, maybe they even decided it was an SEP (someone else’s problem), However these bad configuration options did not appear overnight. They have walked among us for a long time. Now there needs to be a combined effort to address these, again, at both the vendor and the organizational level. Failing to do so, just adds to an already rich target environment for attackers and no one should want that. There is a ton more data and information to Ori’s research which you can find on Akamai’s Security Research Portal. It is a good read, and I highly recommend it.
