Three Strategies To Help: Cisco ASA AnyConnect and WebVPN added to CISA Known Exploits

CVE-2020-3259 has been patched for a few years now, but, it seems that a lot of users place their key security appliances on autopilot. And, when you place the device on autopilot, bad people move into the neighbourhood (e.g. Akira Ransomware exploits it). And when that happens enough, CISA adds it to the Known Exploited Vulnerabilities catalog. The best time to patch this was when the notice came out, the second best time is now. Patch early, patch often. But, since you tired of hearing about patching, I give you three strategies you can implement to generically reduce your risk, reduce your cost, give your team time to react as you mull over your Cisco ASA AnyConnect and WebVPN added to CISA Known Exploits.

Purdue Conceptual Model

I have seen a lot of these devices used in “secondary” locations. Maybe a firewall between layers in the Purdue model (e.g. between the Information Technology and Operational Technology network). Maybe running the DMZ to your outside vendors. The device doesn’t have to have a direct external Ethernet jack to be a risk to you, lateral traversal is a thing.

The nature of the ‘attack’ is that ‘sensitive information’ is readable remotely, without being authenticated. Perhaps you have this device, and your more important routers, and you share the password on them. After all, how could this matter? One admin account for a few devices, shared, the password is strong, right? Its only as strong as the weakest link.

Now, this is an example where folks have had years to patch, and not patched. Is patching the only thing they should have done? Defence in depth is the strategy I would recommend. Lets examine a few ways.

Multi-factor authentication

597fb5a9 image

First, multi-factor authentication. The nature of this attack is secret extraction. IPSEC certificates, passwords, SSL trust chains. If we were to use multi-factor on all places these secrets might be shared (the ASA, other Cisco routers, etc), that would make it much harder for the attacker to traverse. If all the devices has multi-factor, and, the attacker extracted the shared password from the Cisco ASA, well, we’d fall back to single-factor. Couple that with some logging and alerting, we’d have a shot at stopping the attacker in their tracks. Couple that with some segmentation, and, the attacker would be materially slowed, giving us time to react.

You may feel there are barriers to implementing multi-factor authentication on some of those “legacy” devices. Maybe you need to access them with local accounts not part of your Domain Identity Provider? Maybe you need to have a contractor or network managed service provider use them? Agilicus has you covered, see the case study at the right, implementing multi-factor authentication as an identity-aware proxy without any changes.


Second, logging. Devices and software generate logs. These are not just used for install-time debugging and diagnostics. Make sure the logs are available in a central, non-tamperable location. Make sure the devices all have NTP real-time, synced properly. Use UTC to avoid embedded device databases not understanding changes in Daylight savings time. This is non-negotiable… If its not UTC, the odds of some random Y2K bug showing up are high.

Logs can be stored in a fancy SIEM. Logs can also be stored in flat files in a syslog collector. Start collecting, get the timestamps, and, then, on the first incident, you will at least have some information to work through. And, after that incident, you’ll have a better understanding of what you want to budget here.


9448f9d9 image

Third, segmentation. Think of your medieval castle here,its got a moat, its got a drawbridge, its got a wall, its got a keep. Every time some monty-pythonesque attacker got through the first line, you fell back.

Now think of the famed Maginot line, a long thing ‘infinitely strong’ line of defence built by France in the 1930s to deter Nazi Germany. Worked great, the Germans went around to the Benelux and… boom, the wall was not so great from the inside.

Network segmentation is a core principle of Zero Trust. In fact, Zero Trust is the limit, one user, one resource, rather than the VPN model of one user, all resource.

Implementing network segmentation can seem daunting. Look up private VLANs in your switches. Look up ACL’s. Group devices by either type or purpose. Every bit helps. Make sure there are logs generated (see above) for things traversing, or being blocked from traversing, the segments.

Conclusions, Next Steps