Blog: The Juniper Backdoor Is A Bigger Problem Than You're Being Told

December 2015

The discovery of a backdoor in some Juniper Networks devices running ScreenOS is concerning, to say the least. The backdoor was added to the devices' source code, and enabled anybody who knew the magic string to access the devices and take control. There is also a backdoor which enables decryption of VPN traffic. Both issues have been deliberately constructed; they are not mere coding errors.

Juniper has issued software updates which remove the backdoor and users should apply the updates as soon as possible.

But as of late 2015, there are still unanswered questions about this attack:

1. Who added the backdoor to the code? Was it an internal or external attack?

2. How was access to the source code possible?

3. Was the code review that discovered the backdoor routine or was there a reason it was conducted?

4. How many devices are estimated to be vulnerable?

5. Is Juniper contacting users directly and assisting with remediations?

6. Is there any suggestion that a superuser can “rootkit” or “jailbreak” the device?

7. Can a superuser extract existing user passwords/hashes from the device?

8. How can organisations determine if their device was accessed via the backdoor if the log has been erased?

9. If it becomes apparent that the backdoor has been used in production networks, will this be communicated publicly?

Additionally, every other networking vendor should be urgently auditing their own code to verify its integrity and issue a statement about their findings. [Update 15/01/2016: Cisco have apparently decided to do this.]

The wider computer industry needs a full explanation so they can learn from this disaster, and act to protect themselves and their users.

The other side of the issue is organisations that use affected devices and discover they are vulnerable. What does this now say about the security of their networks and databases? Simply patching the software does not invalidate any routes an attacker has already created into the network. Organisations will need to audit every firewall rule to ensure they are valid, and may have to assume they have been compromised and take the appropriate emergency actions. They cannot wait until they see signs of compromise.

Furthermore, organisations with vulnerable devices may have to assume their users' passwords have been decoded, databases copied, and customer credit card details snatched. They may need to reset every password, and advise every customer to cancel their credit card.

Ultimately, it may be necessary for some sort of disclosure regime to be created which enables Juniper, the wider computer industry, and corporations using Juniper devices to discuss the problem openly without fear of class action lawsuits by users. Fixing the issue and cleaning up afterwards will be more important than providing yet another feast for lawyers, and this can only be possible if there is frank discussion.

In the meantime, users of all Juniper devices should check each of their devices for the vulnerability by referencing the bulletins, and by manually attempting the exploit.

If a device is found to be vulnerable or listed in the bulletins:

• Update the firmware immediately;†

• Check the logs for signs of ingress;

• Audit user accounts on the device and check that each username and password is known (ie. hasn’t been reset by an attacker);

• Audit all settings;

• Consider whether to reset the devices back to factory and reconfigure from scratch;

• Bring forward any scheduled replacement of the device;

• Change internal network administrator passwords;

• Consider whether to force organisation-wide internal password resets;

• Consider whether to force external password resets (eg for customer accounts);

• Consider whether to activate emergency intrusion action plan — whether signs of intrusion can be found or not; and

• Consider the wider implications for the network.

Furthermore, organisations using enterprise-grade networking hardware from other vendors should contact their support representatives and seek assurances about the state of their code. At this point, we don't know if the attack on Juniper was internal or external, so there's no reason to expect, prima facie, that other vendors have not been attacked also, and they won't actually know this until they have checked. All enterprise vendors will need to urgently conduct their own code reviews, including by third-party security experts.

† Note to network administrators. We know it's the holidays. We know you don't want to create an unscheduled outage. We know you want to test firmware in the lab first. Truth bomb: this is your job; it's a crisis; stay up all night if you have to.