Juniper Netscreen 25 Firmware Ios 11
Pablo Barjavel
I've just got a NetScreen 5GT, unfortunately with an old (5.x.x) firmware -- it was in production until today. It seems Juniper requires active support contract to make such firmware accessible. Needless to say, as a private person I don't have anything like that.
Juniper's advisory mentioned that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected. Juniper provided a new 6.2.0 and 6.3.0 build, but also rebuilt older packages that omit the backdoor code. The rebuilt older packages have the "b" suffix to the version and have a minimal set of changes, making them the best candidate for analysis. In order to analyze the firmware, it must be unpacked and then decompressed. The firmware is distributed as a ZIP file that contains a single binary. This binary is a decompression stub followed by a gzip-compressed kernel. The x86 images can be extracted easily with binwalk, but the XScale images require a bit more work. ScreenOS is not based on Linux or BSD, but runs as a single monolithic kernel. The SSG500 firmware uses the x86 architecture, while the SSG5 and SSG20 firmware uses the XScale (ARMB) architecture. The decompressed kernel can be loaded into IDA Pro for analysis. As part of the analysis effort, we have made decompressed binaries available in a GitHub repository.
Although most folks are more familiar with x86 than ARM, the ARM binaries are significantly easier to compare due to minimal changes in the compiler output. In order to load the SSG5 (ssg5ssg20.6.3.0r19.0.bin) firmware into IDA, the ARMB CPU should be selected, with a load address of 0x80000 and a file offset of 0x20. Once the binary is loaded, it helps to identify and tag common functions. Searching for the text "strcmp" finds a static string that is referenced in the sub_ED7D94 function. Looking at the strings output, we can see some interesting string references, including auth_admin_ssh_special and auth_admin_internal. Searching for auth_admin_internal finds the sub_13DBEC function. This function has a strcmp call that is not present in the 6.3.0r19b firmware:
We would like to thank Ralf-Philipp Weinmann of Comsecuris for his help with unpacking and analyzing the firmware and Maarten Boone of Fox-IT for confirming our findings and providing the Snort rules above.
Screenos engineering support is promised for several more years but development has basically stopped, juniper would steer you towards their junos based srx as a replacement - lots of other players though including sonic wall, fortinet, paloalto...
We are having the same issues across 4 sites including 2 Netscreen 5GT's 1 Netscreen 25, and an SSG 5 and it's been driving me crazy. So some are running the latest 5.4 firmware, and SSG is running the latest 6.3 firmware. I'm hoping disabling the SSL and management on the outside interfaces eliminates the issue for now. According to what I've found on Juniper's web site, the ScreenOS devices are not affected by Heartbleed, but I can see how it might be indirectly affected with all the SSL probing going on.
Last week it was revealed that some builds of the devices' ScreenOS firmware suffer from two severe security weaknesses: one allows devices to be commandeered over SSH and Telnet, and the other allows encrypted VPN communications to be monitored by eavesdroppers.
However, the string is actually used during login checks. When the magic text is presented as a password over SSH or Telnet, the firmware grants total access to the equipment: regardless of the username given, it allows anyone to bypass authentication, and the password is hardwired into the operating system.
This guide provides information that can be used to configure a Juniper SSG or Netscreen device running firmware version 5.4+ to support IPsec VPN client connectivity. The Shrew Soft VPN Client has been tested with Juniper products to ensure interoperability.
It sounds like the VPN re-negotiation is failing. This should happen before the original VPN expires. It may be that the two ends handle this in a different way - and may not be resolvable (at least not without firmware upgrades).
In this paper, we described the results of a full independent analysis of the ScreenOS randomness and VPN key establishment protocol subsystems, which we carried out in response to this incident. While Dual EC is known to be insecure against an attacker who can choose the elliptic curve parameters, Juniper had claimed in 2013 that ScreenOS included countermeasures against this type of attack. We find that, contrary to Juniper's public statements, the ScreenOS VPN implementation has been vulnerable to passive exploitation by an attacker who selects the Dual EC curve point since 2008. This vulnerability arises due to flaws in Juniper's countermeasures as well as a cluster of changes that were all introduced concurrently with the inclusion of Dual EC in a single 2008 release. We demonstrate the vulnerability on a real NetScreen device by modifying the firmware to install our own parameters, and we show that it is possible to passively decrypt an individual VPN session in isolation without observing any other network traffic. This incident is an important example of how guidelines for random number generation, engineering, and validation can fail in practice. Additionally, it casts further doubt on the practicality of designing a safe "exceptional access" or "key escrow" scheme of the type contemplated by law enforcement agencies in the United States and elsewhere.
In this paper, we attempt to tell the story of that incident, pieced together by forensic reverse engineering of dozens of ScreenOS firmware revisions stretching back nearly a decade, as well as experimental validation on NetScreen hardware. We first provide background on Dual EC itself, then examine the way that it is used in ScreenOS and why this leads to such a severe vulnerability, then move to examine the history of the incident itself, and finally consider what lessons we can draw from this story.
To validate the attacks we describe above, we purchased a Juniper Secure Services Gateway 550M VPN device. We generated our own point Q and corresponding Dual EC secret d. We modified firmware version 6.3.0r12 to put in place our point Q, matching Dual EC Known Answer Test (KAT) values, and the (non-cryptographic) firmware checksum, and we installed the modified firmware on our device. (Our device did not have a code-signing certificate installed, so we did not need to create a valid cryptographic signature for our modified firmware.)
Using the new firmware, we configured the device with three separate VPN gateways, configured for IKEv1 with a preshared key, IKEv1 with a 1024-bit RSA signing certificate, and IKEv2 with a preshared key, respectively. We made connections to each gateway using the strongSwan VPN software as our initiator and recorded the traffic to our device. We successfully decrypted each connection by recovering the Dual EC state and traffic keys using just that connection's captured packets.
This state of affairs continued for four years. At some point prior to the release of ScreenOS 6.2.0r15 (September 2012) and ScreenOS 6.3.0r12 (August 2012), someone modified Juniper's source code. Based on the patched firmware revisions Juniper would later release, the modifications were quite small: The x-coordinate of Juniper's Dual EC's Q was changed as was the expected response to Dual EC's Known Answer Test. As a result, the set of people who could passively decrypt ScreenOS's VPN traffic changed from those who know Juniper's d (if any) to those who know the new d corresponding to the changed Q (presumably the attacker who made the change).
We are not able to answer these questions with access to firmware alone. Juniper's source code version-control system, their bug-tracking system, their internal e-mail archives, and the recollections of Juniper engineers may help answer them.
And as everyone now rushes to patch, it may put the original backdoor into place? They're effectively forced to, because of the other backdoor being closed at the same time in the same firmware update.
This seems to indicate in-depth knowledge of the both the firewall and the underlying OS throughout the development and debugging. It is doubtful the government could pull off these types of hacks without inside information from the builders of the firmware, OS and the firewall.
When both the hardware and software can be pawned you have witches brew in communications systems. On a granular level the BIOS must check the firmware/hardware and hook the OS. With both pawned the system is leaky sieve.
I have hand coded firmware patches in the field under the constraint that the bits in the ROM could only be changed from 1 to 0 and not vice versa and learned to squeeze several uses out of each byte.
Since this code is in the firmware of the affected Juniper NetScreen and SSG appliances, the only way to remove it is to re-flash the firmware with a new version of ScreenOS. Steve Puluka has written a guide on how to perform the upgrade and avoid some of the potential problems around installation, including dealing with the configuration of a new signing key for the upgrade.
Congressman Will Hurd, R-Texas, has a seemingly simple request for U.S. government agencies: Tell us how many Juniper Networks ScreenOS devices you're using and give us a version history of the firmware on that networking equipment.
That query is pertinent because security experts suspect that Juniper's ScreenOS firmware - which runs its NetScreen firewalls and VPN devices - was backdoored by up to three different domestic and foreign intelligence agencies, beginning in 2008. Thus it's imperative that all organizations immediately install a related patch, which was released last month by Juniper (see Who Backdoored Juniper's Code?).
e2b47a7662