Cisco recently announced a slew of vunerabilities, including three 10 out of 10 vulnerabilities in their popular small business line of VPN routers. Some of the devices vulnerable are out of support, no updates will be available. 10 out of 10 means it is simple to exploit, without privilege, remotely. And, this is not a good thing for the device that protects your network from the world, the single bastion.
In 2010 Forrester Research published an article called ‘No More Chewy Centers: Introducing The Zero Trust Model Of Information Security’. The thesis was that network design was currently based on the concept of an M&M: a hard outer shell, a soft interior. And, that this was no longer sufficient since threats could get in, could walk sideways once in.
Like many research articles it spawned debate, discussion, but, immediately, not a lot of action. People continued to slap a single security device at the perimiter, use it to VPN to the interior. They would then ‘harden’ the access, forcing things like multi-factor for remote access, assuming that all threats came in from the outside. The walled garden surrounded by the desolate desert.
Recently Cisco has announced a list of vulnerabilities affecting common business routers. Notable in this list is 3 vulnerabilities rated 10 out of 10 (see the CVSS calculator to understand what this means). And, this got me to thinking. What are the vulnerabilities? How would they be exploited in a way that demonstrates the fallacy of the castle-and-moat security?
Well first, one of the vulnerabilities is in the SSL layer. To exploit it you do not need to have credentials, merely layer 3 access. Since these Cisco devices are typically the access router + VPN, they will indeed be network accessible. Let’s do a quick Shodan.io search. OK, confirmed. These devices inhabit the Internet. This means that your VPN is indeed now the magic carpet into that ‘Chewy Centre’, no questions asked, courtesy of the Remote Code Execution flaw.
Second, one of the vulnerabilities is in the management web UI. Let’s assume we have one of these devices solely inside our network. No inbound access from the Internet. This must be safe, right? Well, let’s hypothesise for a second. Do you micro-segment your internal network? If you were a valid user sitting at a desk would you have access to this router? The answer is nearly certainly yes, why not? Now, I wonder if I could entice one of your users to go to a web site I controlled? Maybe via spear-phishing, a doppelganger domain, some social engineering attack, an advertisement, whatever? Now, on that site I can place some JavaScript. And it can guess the name of your router. Is it ‘rtr’? ‘router’? etc. And, that JavaScript runs as you, in your browser, inside your network. Inside the Chewy bit. It has direct access sideways to this ‘protected’ router.
That’s right, you became the ‘bounce’ point, the pawn, in this game of lateral traversal. So, the inbound firewall did nothing to protect the ‘damaged’ router. Now the attacker has run some code on it, has a vantage point in your network to move sideways.
Now, you might be thinking, my network team will have patched this already, right? But, some of these devices do not have (and will not have) patches available. This is a general industry problem: embedded devices tend to run for longer than their support. And, you have a lot of embedded devices around (thermostats, smart TV, PLC’s and SCADA in manufacturing, etc.) Any one of these could have one or more vulnerabilities this critical right now. Worse, there is not a systematic publishing of vulnerabilities for the embedded space. We are talking about the Cisco ones since the info is public, what about the one we don’t know about? Someone does.
OK, now that I’ve explained a couple of the risks of the fallacy of the ‘hard outside, soft inside’ perimiter approach, what would I suggest? Well, a generic strategy of Defense In Depth. Assume you have no single strong defense, but a collection of defenses. Instead of the Maginot Line, you have a set of fallback and delay approachs. Think about limiting the ‘blast radius’. Think in terms of “when the bad thing occurs, what is my next defense” rather than “i must prevent the bad thing at all costs.”.
Here are ten suggestions to chew on:
- Multi-Factor Authentication should be for all users (not just admins)
- Multi-Factor Authentication should be for all devices (not just personal)
- Multi-Factor Authentication should be for all networks (not just external or remote)
- Use privileged access management (no layer 3 access should be possible for unauthenticated users to your infrastructure)
- Use zero-trust concepts like identity<->resource pairwise authorisation
- Have sensors, logs, tripwires so you can answer the “where did it go next?”
- Move devices and longer lived things to their own networks
- Use Private VLAN / Client Isolation to prevent devices talking to each other
- Use a Web Application Firewall as a terminating SSL gateway to prevent SSL overruns
- Call me and discuss