Juniper experiences security flaws
I can’t remember the last time I heard about a true “Back Door” – but it appears Juniper has released a patch to fix just that.
There have been cases where a back door has been inadvertently added through bad coding or not following standards, but it appears that the Juniper CVE-2015-7755 vulnerability is a deliberate attempt to put a back door into their ScreenOS Code (ScreenOS is their own proprietary software that provides the OS/base for their firewall products).
What does the back door do?
The back door provides a login to the ScreenOS devices using a known password – basically a hard coded string that if entered bypasses any other security and lets the attacker straight in.
Anyone would think that with modern coding techniques, back doors were a thing of the past, what’s cleaver about this is that the password is disguised in plain sight as it looks like a “debug string”, so it doesn’t look out of place.
Juniper have released a patch and clearly the advice is get patched as soon as possible.
The timing here seems to add an interesting twist – Juniper released the CVE2015-7755 on December 18th, then by 20th December researchers on the internet had discovered the extent of the problem and published the password. Shodan shows there are roughly 26000 internet facing NetScreen devices with SSH open – so clearly not everyone’s following best practice by disabling SSH from the internet and there is an attack surface.
Most corporates would put a change freeze in over Christmas, so upgrading a whole fleet of Junipers over Christmas is going to present a significant challenge. There are workarounds and measures that can be put in to prevent the exploit, and if best practice has been followed (i.e. not allowing SSL login from the internet) then the attack surface is limited, however by far the simplest and most effective approach is to apply the upgrade.
I often have conversations around the benefits of using out of the box cloud constructs such as security groups or acls, or even VPN Capability in the cloud vs putting a traditional firewall as part of the cloud infrastructure, and here it seems a couple of things are apparent:
- Juniper is a Security company – if they can suffer this kind of unauthorised code getting into their system, anyone can.
- The password is in the public domain, just before the Christmas break.
If it can happen to Juniper, a similar vulnerability could occur in a cloud based firewall service – however in a cloud scenario:
But with the cloud…
- Best practice is enforced – there is no SSH login to the firewall service available from the internet
- It is unlikely the code would be available for researchers/hackers to take it apart and publicly disclose the password.
- It would be patched with no involvement from customers so everyone else can continue enjoying Christmas.
Personally – I’ve spent Christmas before fixing servers – it’s not fun – if you’re fixing Junipers this Christmas, maybe next Christmas you could be letting the cloud deal with the problem for you.