Detecting the Juniper Netscreen OS Backdoor

##The Challenge Juniper issued an advisory on December 18th indicating that they had discovered unauthorized code in some versions of the ScreenOS software that powers their Netscreen firewalls.

The advisory covers two issues:

  • One was a backdoor in the VPN implementation that may allow a passive eavesdropper to decrypt traffic.
  • The other was a backdoor that allows an attacker to bypass authentication in the SSH and Telnet daemons. This would give an attacker administrator privileges over the firewalls—the highest level of access.

The Solution

Juniper has posted logs from a successful login via the backdoor. The logs look like this: Figure 1. Juniper Log The first log provides us the username “system,” and the second log provides us the username of “username2.” These are, in fact, both reflecting the same authentication event.

The way the bypass is implemented allows you to login with any username if you use a specific password. However, the first log reflects the internal username of “system” when you login with this method. Thus, you now have your methodology for detecting the compromise with a high degree of certainty.

LogRhythm has built-in processing policies for the Netscreen Firewall, and the sub-rules for the two logs shown above are copied below:

Figure 2. SSH Admin User Login

Figure 3. Warning 00528

Detect when a user logs in as system using a different user name.

Create an AI Engine “Unique Values” rule:

Figure 4. Unique Values

We are looking for User Logon events coming from our Netscreen firewall where the Vendor Message ID is 515 and the username is “system,” or where the Vendor Message ID is 528 and the username is anything at all.

If we see two logs coming from the same source IP within one minute, and the two Vendor Message IDs are different, then we know that we have had the two logs that reflect this scenario and should raise an alarm.

This rule configuration will automatically filter out any username typos by requiring one of the two logs to contain the user name of “system.” It will also catch any valid usernames being exploited with the backdoor password.

Both of the logs are triggered with the same timestamp, so we can’t use two rule blocks in this case. Instead, we are using the ability of AI Engine Rule “Include Filters” to have multiple filters—these are “OR’d” together:

Figure 5. Unique Values Observed

###Ongoing Monitoring For ongoing monitoring of the Netscreen Admin users, we can implement a simple Log Observed Rule against the “Authorised Netscreen Admin Users” list.

Create a list called “Authorized Netscreen Admin Users.” This should be maintained with all the valid users for my Netscreen.

Figure 6. Authorized Netscreen Admin Users

In this case, I just have one user called “admin1.”

And then the corresponding AI Engine rule:

Figure 7. AI Engine Rule

Essentially we are looking for anyone logging in with an account that isn’t in the authorized users list.

It is not possible to detect the VPN backdoor being exploited, because that involves decryption of VPN traffic that had been intercepted outside of the network—this is invisible by definition.

The authentication bypass backdoor can be detected from the logs, and an AI Engine rule to do just this is shown below. Obviously, Netscreen users should prioritize patching as soon as possible, but if for any reason the patching is delayed, then this rule could act as a compensating measure in the meantime.

A rule is also provided for monitoring against a customer-specific list of valid Netscreen users, and this would be worthwhile implementing irrespective of the patch being applied.

The Benefit

As ever, visibility is everything, and providing the ability to monitor for the exploitation of a vulnerability such as this on a security enforcing device is a useful interim measure if patching cannot immediately be applied to the affected device for whatever reason.

Ongoing monitoring of who is logging into the firewall admin console, and with what credentials, is simply security best practice.

LogRhythm provides out-of-the-box processing rules for Netscreen that parse out the metadata in such a way that creating a rule to detect this behavior is quite straightforward.

For those organizations who have some history of collecting logs from their Netscreen devices, a search through historical logs looking for EventID 00515 with a user of “system” should at least provide some confidence that the authentication bypass backdoor has not been exploited against their environment in the past.

Finally, you can only monitor what you collect! Ensuring that all devices that are providing any kind of authentication services are configured with the correct level of logging, and are being collected by LogRhythm, is a best-practice.

“Juniper noted that a skilled attacker would likely remove even this cryptic entry from log files to further eliminate any indication that the device had been compromised,” says Kim Zetter of Wired.

Without the logs being sent to a centralized SIEM, there would indeed be no way to detect this.

More from Andrew Hollister