According to the ISC warning, the upgraded yellow warning was made because Juniper’s NetScreen firewalls are popular and that the “'backdoor’ password is now known, and exploitation is trivial at this point,” and for most businesses, this “being a short week for many of us, addressing this issue today is critical.”
+ More on Network World: The weirdest, wackiest and coolest sci/tech stories of 2015 +
Juniper owned up last week to unauthorized code being present saying its ScreenOS enables two exploits. The first is a password – <<< %s(un='%s') = %u – see that works with any valid username. The second is a vulnerability in the version of the IPSec encryption code used by the machines that enables decrypting the VPN traffic.
Disabling the universal backdoor password is impossible without applying the patches, the ISC says. It’s easy to figure out if a machine needs the update: try out the universal password with a valid username. Or just compare the ScreenOS version on the macine with the list of vulnerable versions, ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20.
+More on Network World: Juniper faces many questions after spying code planted in software+
Detecting whether anyone exploited the vulnerabilities on particular machines is more complicated and less sure, ISC says, because it calls for checking login logs, and the unauthorized entries look just like the legitimate ones.
The first suggestion is for checking telnet logins. It calls for following snort rules published by security consulting firm FoxIT, which detect telnet sessions that have been established with the devices. If there are such sessions, the rules then look for the telltale password.
A second flaw that allows SSH logins is also addressed, but differently because the password is encrypted. In that case the rules finds all the SSH logins and searches for “the typical NetScreen SSH banner,” ISC says.
Meanwhile, Juniper has remained silent about the problem since its initial disclosure last week, leaving unanswered some important questions.
Customers understandably want to know how the unauthorized code got into the operating system for a security device in the first place, shipping with every unit. And how did it go undetected for so long, at least two years by most accounts
The implication is that VPN traffic customers was secure actually wasn’t because, at the very least, whoever sabotaged the IPSec encryption code could decrypt it. A second problem is that the devices could be used as a way in to infiltrate networks in hopes of stealing data or causing damage.
How the code got there is important because it will speak to the likely culprits and more accurate conclusions about their motives and possible intended targets. It will also speak to whether customers ought to be worried about possible flaws in other Juniper products.
Juniper’s silence can be interpreted in several ways.
It could be its legal team is telling it to say as little as possible in order to minimize the grounds for lawsuits against the company.
Juniper may be taking time briefing its biggest customers on the details under NDA in hopes they will issue public assurances that they are satisfied the devices, once patched, are trustworthy. Such endorsements could help ease the fears of smaller customers.
If placing the unauthorized code was the work of a government agency, say the NSA, the company could be under a Patriot Act gag. Since there are two instances of unauthorized code, the possibility exists that they were put there by separate parties.