EDIT: January 6th 2016 – it looks like I used the wrong tag on Censys, leading to a much higher number of potential NetScreen devices. Will update the post as soon as I get everything right. Fixed.
On December 18th 2015, Juniper published an advisory stating that unauthorized code was discovered in its flagship product ScreenOS. This unauthorized code were in fact two different backdoors: one related to a weakened encryption algorithm that makes traffic prone to eavesdropping by a passive attacker and another one that affects the authentication mechanism, allowing an adversary to gain unfettered access to the device using a secret account.
The focus of this blog post is to gather statistics on the approximate number of Internet-facing Juniper ScreenOS affected by this publicly-disclosed authentication backdoor. This study leveraged results from passive search engines such as SHODAN and Censys.
Open sesame: <<< %s(un=’%s’) = %u
As documented by Rapid7 and multiple other researchers, the authentication backdoor was engineered in a way that allowed for anyone able to connect to the device’s Telnet or SSH to gain remote administrator privileges. Researchers noted that potential attackers could connect with an arbitrary username (including non-existent ones) along with the backdoor password in order to gain administrative access.
$ ssh email@example.com firstname.lastname@example.org's password: <<< %s(un='%s') = %u Remote Management Console REDACTED-> ? clear clear dynamic system info delete delete persistent info in flash exec exec system commands exit exit command console get get system information mtrace multicast traceroute from source to destination ping ping other host reset reset system save save command set configure system parameters telnet Telnet other hostname trace-route trace route unset unconfigure system parameters REDACTED-> exit
It’s simple like this.
As stated in Juniper’s advisory, the following versions were found to be affected: 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20.
As of December 29th 2015, Censys returned 51,382 records for the query “22.ssh.banner.raw_banner:NetScreen”. SHODAN, on the other hand, returned 26,041 Internet-facing hosts running NetScreen. An analysis was performed using data from Censys as it contained a larger number of valid IPs as dataset.
This analysis used a data set of 42,709 IPs running ScreenOS in order to have a good estimate of the percentage of total number of devices affected by this backdoor. The scans were completed over the span of five days, but only a few hours of scanning were done on each day. All passive and active scanning ended on January 5th, almost 18 days after the disclosure of the backdoor by Juniper and a bit more than two weeks after the password was made public by Rapid7.
Most of the scanning, both active and passive, and this blog post, was done during the 32nd Chaos Communication Congress in Hamburg, Germany and the last part of the scan was performed over a ridiculous slow ADSL line while overseeing the mountains of Zakopane, Poland and a VPS hosted at Digital Ocean.
Evading honeypots on our way
On December 22nd, just a few days after the backdoor was disclosed, Greg Martin released on Github a Kippo honeypot mod to mimic a vulnerable ScreenOS. When performing a more sustained scan in the morning of December 29th it was noticed a very unusual large number of successful results from the scanner, unlike other scans conducted in the past. This immediately rang a bell that the scanner was being fooled by honeypots and was later confirmed to be true: many of the “backdoored devices” were actually Kippo honeypots disguised as vulnerable ScreenOS instances.
There are several ways to remotely detect Kippo, either already inside its shell or relying on other known methods. However, it was not necessary to resort to any of these methods in order to tell apart real backdoored devices from honeypots: the real backdoor accepts ANY username with the backdoor password whereas the honeypot only accepts the combo login: system password: <<< %s(un=’%s’) = %u which was published by Rapid7.
Long story short, the scanner was modified to connect with the username ‘honeytrap’ and the backdoor password instead of its original ‘system’ login and the scans have restarted from scratch to avoid false positives caused by the honeypots.
If you have seen an SSH connection attempt to your ScreenOS with the ‘honeytrap’ username, it was most likely the scanner used for this study.
In order to validate the presence of this vulnerability, this analysis performed a basic authentication check. No further actions were taken after this point. The sole purpose of this study was to collect statistics for vulnerability intelligence.
The scans were able to detect 1,595 potentially unpatched devices even after more than two weeks of the disclosure of the backdoor. This only highlights the fact a large number of organisations have poor vulnerability management practices and overlooked all reports the security community and IT media outlets gave about this particular issue.
The top 5 countries with the largest number of vulnerable devices were:
– United States: 480
– China: 134
– Japan: 112
– Germany: 107
– South Korea: 100
Approximately 31% of the total number of affected ScreenOS devices were found in the United States. As a side note, this study also found a very small number of backdoored Junipers in countries like Iran, Russia and Iraq.
A plotted map to aid the visualization of the results can be seen below:
More than two weeks after the full disclosure of the Juniper ScreenOS backdoor, it seems like many organizations did not get the memo and did not pro-actively react to the issue by updating their devices. Approximately 3.1% of the Internet-facing NetScreens are prone to remote intrusion, and out of all vulnerable devices a good part of them can be found in the United States.
A little speculation on the lack of timely patching: evidently there was not a Heartbleed-like media blitz on the Juniper backdoors, and this can be one of the reasons why many IT department in the affected organizations did not patch — they simply might have not heard of the issue yet, or possibly because their contract support with Juniper is no longer active. It is safe to assume that numerous organizations will have their networks exposed for many more months to come and penetration testers are likely to find unpatched devices, especially in internal networks, for even longer periods of time.