Juniper finds 'unauthorised code' in its firewall software

[Dos_Box]

This could be a bit disturbing for any of you who use Juniper firewalls: Router maker finds 'unauthorised' code - BBC News

 

Juniper Networks has issued a warning after discovering "unauthorised code" in its firewall software.Analysis of the rogue code shows that it can decrypt scrambled data being sent through virtual private networks.

In a security advisory, the internet hardware maker said whoever wrote the code would be able to use it to spy on encrypted conversations.

Juniper has released patches to strip the code out of its firewall software and urged customers to apply them.

 

They have released patches so please ensure you are fully covered before you knock off for Christmas!

[psydii]

"Unauthorised" uh-uh. More likely one government agency got licenced source code access as part of their due dillegence procedures and in their audit found code from another. Red faces all around and the only option given unbreakable secrecy agreements was for Juniper to disavow the code

[Arthur]

CVE-2015-7755: Juniper ScreenOS Authentication Backdoor

 

On 18th December 2015 Juniper issued an advisory indicating that they had discovered unauthorized code in the ScreenOS software that powers their Netscreen firewalls. This advisory covered two distinct issues; a backdoor in the VPN implementation that allows a passive eavesdropper to decrypt traffic and a second backdoor that allows an attacker to bypass authentication in the SSH and Telnet daemons. Shortly after Juniper posted the advisory, an employee of FoxIT stated that they were able to identify the backdoor password in six hours. A quick Shodan search identified approximately 26,000 internet-facing Netscreen devices with SSH open. Given the severity of this issue, we decided to investigate.

 

The argument to the strcmp call is <<< %s(un='%s') = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet, as long as they know a valid username. If you want to test this issue by hand, telnet or ssh to a Netscreen device, specify a valid username, and the backdoor password. If the device is vulnerable, you should receive an interactive shell with the highest privileges.

 

The interesting thing about this backdoor is not the simplicity, but the timing. Juniper's advisory claimed that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected, but the authentication backdoor is not actually present in older versions of ScreenOS. We were unable to identify this backdoor in versions 6.2.0r15, 6.2.0r16, 6.2.0r18 and it is probably safe to say that the entire 6.2.0 series was not affected by this issue (although the VPN issue was present). We were also unable to identify the authentication backdoor in versions 6.3.0r12 or 6.3.0r14. We could confirm that versions 6.3.0r17 and 6.3.0r19 were affected, but were not able to track down 6.3.0r15 or 6.3.0r16. This is interesting because although the first affected version was released in 2012, the authentication backdoor did not seem to get added until a release in late 2013 (either 6.3.0r15, 6.3.0r16, or 6.3.0r17).

 

http://i.imgur.com/kpWsxQ7.png