Juniper Admits to backdoors in their ScreenOS code as far back as 2012

Juniper has acknowledged that “unauthorized code” was somehow inserted into their ScreenOS. The code appears to have been around since at least 2012 which means that it went unnoticed during multiple code updates, patches and even full version updates. Although the code was buried deep in cores parts of the OS it still should have been noticed during at least one update over the last three years.

The code, which affects multiple NetScreen firewall models, was intended to allow someone to remotely control the devices. It also had the added bonus of allowing the reading of encrypted VPN traffic. This would mean that the code gave full access to all of the workings on the device. The attacker would have been able to access the encryption routines, public and private keys, and much more. It was a complete system compromise.

Juniper has already released patches for the affected OSes and high recommend that Juniper firewall owners update as soon as possible. The affected versions of the OS are ScreenOS 6.2.0r15 – 6.2.0r18 as well as 6.3.0r12 to 6.3.0r20. The code used an embedded master password to allow external access. This means that it would have been accessible to anyone examining the affected versions of code.

Although Juniper did catch this during an internal code audit it seems that they might want to step up their game a little or at the very least shorten the time between these audits. If something like this can go unnoticed for three years there is certainly a problem.

As of this writing most of the press is leaning towards a nation-state as the party responsible for the code. This makes sense on many levels as Juniper firewalls are not something you would see in homes. That being said there are some items that make the idea of a nation-state less likely. One of these is the use of a hardcoded master password. You would think that any government agency would have made accessing their backdoor a little more complicated. This almost seems like something put in place to make all Juniper firewall easy to compromise for anyone. Getting access to code is not hard and you can identify Juniper devices on the internet very quickly.

This incident does raise concerns that something could be slipped into production code with such apparent ease. Was someone at Juniper complicit in getting the code in place? Did multiple people overlook the code for years until a larger flaw was found that made getting rid of it important? Why was this there in the first place? Of course the “who and how” are all academic and we are unlikely to ever get an answer to either of those questions.

For now, if you are running Juniper NetScreen firewalls, patch them as soon as you can.

No comments

Leave your comment

In reply to Some User