Closing (and bolting) the back door in ScreenOS

by Dr. Mike Lloyd, CTO RedSeal

The recently disclosed back door in Juniper’s ScreenOS software for NetScreen firewalls is an excellent reminder that in security, the first and foremost need is to do the basics well.  The details of the vulnerability are complex and interesting (who implanted this, how, and what exactly is involved?), but that is not what matters for defenders.  What matters is knowing whether or not you have basic network segmentation in place.  This may sound counterintuitive – how can something as routine as segmentation solve a sophisticated problem like this?  But this is a textbook example of the benefits of defense in layers – if you think too much about only one method of protection, then complex things at that layer have to be dealt with in complex ways, but if you have layers of defense, you can often solve very complex problems at one layer with very simple controls at another.

The vulnerability in this instance involves a burned-in “skeleton key” password – a password capable of giving anyone who can use it potentially catastrophic levels of control of the firewall.  To compromise your defenses when you have this particular version of software installed, an attacker needs only two things – 1) the magic password string itself, which is widely available, and 2) ability to talk to your firewall.  For point 1, the cat (saber-toothed in this instance) is long since out of the bag, but point 2 remains.  If someone can talk to your firewall and present a credential, they can present the magic one, and in they go, with full privilege to do whatever they want (for example, disabling all the protections you bought the firewall for in the first place).  No amount of configuration hardening can prevent this, since the issue is burned in to the OS itself.  But what if the attacker cannot talk to the firewall at all?  Then the magic password does no good – they cannot present a credential if they cannot talk to the firewall in the first place.

So note that someone who relies on strong password policies has a real problem here.  If you think “it’s OK to allow basic access to my firewalls, nobody can get in unless I give them a credential”, well, that’s clearly not true.  Unfortunately, many network defenses are set up in this way.  If you think about this problem at the password or credential layer, the situation is a disaster.  But if you think about multiple layers, something more obvious and more basic emerges – why do you need to allow anyone, coming from anywhere, to talk to you firewalls at all?  You should only ever need to administer your infrastructure from a well-defined command and control location (using “C&C” in the positive sense used by the military), and you can lock down access so that only people in this special zone can say anything AT ALL to your firewalls and the rest of your infrastructure – you can effectively reduce the attack surface for an attack, directly mitigating the huge risk of this kind of vulnerability.  Thinking in layers moves the question from “how do I prevent someone using the magic password?” (Answer: if you have the vulnerable software, you can’t), over to the easier and better question, “How do I limit access to the management plane of the firewall, to only the zone I run management from?”