Introduction

Software is a benign tool to many people. Software engineers will download freeware or open source code blocks from the internet and integrate the dubious code into commercial products. But as we move into the evermore confusing world of cyber security nation states, with a growing number of hacktivists and cyber criminals, it's important to realize that not all hacks are overt or easily detected. Some hacks are subtle, devious, and hit organizations where they least expect. Hacks and insecure code may be lurking within the internal software, unbeknownst to software development groups and the targeted victims, as you will see in the following story.

<<< %s(un='%s') = %u

As reported by Arstechnica: 

“On December 17 [2015], Juniper Networks issued an urgent security advisory about "unauthorized code" found within the operating system used by some of the company's NetScreen firewalls and Secure Service Gateway (SSG) appliances. A patch was issued to the affected device OS and forensic investigation determined the unauthorized code acted as a backdoor into the device.”

The forensic investigation determined that the administrator password used to evade normal authentication was "<<< %s(un='%s') = %u." Many security researchers immediately realized that this particular password was crafted to appear as debug code, or test code, within a software source code file.

In essence, the unauthorized Juniper Backdoor was put there intentionally and the backdoor was crafted to evade detection. This is truly the beginning of a new era of hacking threats.

As we step into this new time of sophisticated system exploitation, all companies need to realize that the software itself can be intentionally compromised for unauthorized purposes, and some companies are taking this threat very seriously. Cisco, for example, has announced a significant effort and initiative to detect if they have similar backdoors in their respective network and products.

The purpose of the backdoor incident mentioned above was to gain access to the network devices configuration and its seed parameters for the VPN encryption routines. It appears that Juniper used a non-standard set of parameters to initialize encryption, and the only way to obtain the encryption parameters was to gain admin access. There is great discussion as to who could be responsible for this, and most cyber security experts might say that the persons responsible and their goal are obvious. But, this of course is all speculation

It’s About the Network and Only the Network

The reason why network device vendors would be targeted by such a sophisticated backdoor is because of the importance of a network to the enterprise. Network device security is the soft underbelly of an organizations’ security planning. A secretly placed backdoor with deceptively normal code and text is a frightening thought, and even more frightening in its implications.

Many organizations view their network devices as merely way points in their information distribution system. The idea that these information switches could be accessed in such a way as to be undetectable, is disturbing. But, the real implication is that 20 years of network security best practice has now been rendered obsolete.

Examples of how this new network device threat will change security best practice:

No More believing that Network switches implementing Virtual Local Area Network (VLAN) separation between Industrial Controls and Business networks is adequate.

• No organization can design networks with VLAN separation and expect it to be secure. If devices can be compromised at the administrative level then any virtual (not physical) separation cannot be guaranteed.

No More depending on VPN encryption as being the magic bullet to protect confidentiality.

• An organization will need to start looking at how deeply they depend on VPN to be the ‘go to’ solution to transit under secured networks. No longer can a company assume that the VPN tunnel is a bullet proof solution across ANY network (especially if it is transiting a suspect part of global operations)

No More passive assumptions that all is well in network device configuration.

• An organization can no longer depend on the “no one touched the device, so it’s got the same configuration that it was left in” argument. Companies will need to ramp up configuration control and auditing to account for the possibility of device configurations changing in unauthorized ways.

And this list is just the start. With the Pandora’s Box of suspect code being opened no one really knows how far the trail goes into rethinking cyber security.

What to Do if You're an End User/Organization

Review Device Patch Status: The first thing any organization should do is start on an organization wide review of vulnerable network devices; this is obvious Again referring to our previous example, Juniper devices should not be the only organization to initiate an organization-wide review of network devices. Other well-known network gear vendors (like CISCO, BELDEN) Should as well, because… if one vendor is compromised there must be others.

Patch and/or attempt to Patch ALL network devices: After review patches should be applied to all current devices (yes even in advance of the approved patches from non-Juniper devices. The reason for this is to find out any devices that may be in areas that are critical (e.g. Industrial Controls) or that are so old they can’t be updated.

Create a Risk Matrix (or determine your attack surface): Now you can use the information from the steps above to create a Risk Matrix. This Matrix will have on one end the difficulty of patching (due to age, operational need) vs. the operational importance (used in 24/7 process vs. small branch office switch). This way your organization can be one step ahead of the inevitable disclosures of other network gear being compromised.

Create a Patching Plan Order of Importance to Change Your Attack Surface Vulnerabilities: With all this information security personnel can provide burn down list or percentage based metrics on the risk posed by the new network gear vulnerabilities. Also this provides a good plan of action if the unthinkable happens and a new network vulnerability is discovered WITH a zero day malware vector exploiting it.

Increase Network and Configuration Monitoring: If your organization is using snort FOX IT already has IDS signatures out to help detect this attack. Also an organization wide effort should be implemented to bring all network gear under configuration control. And any periodic security audits should not only audit the configuration of network gear but should also assess the actual live network configuration by testing traffic patterns.

What to do if you’re an Integrator Supplying Network Gear

Review Lab Device Patch Status and Implementation Guides: An integrator should patch any lab systems and then update their implementation guides to reflect the change in network gear configurations (e.g. Juniper now has a code signing step in firmware updates).

Implementation personnel should be prepared for the future to change as other network gear vendors are discovered to have similar issues.

Patch and/or attempt to Patch ALL network devices: Integrators should patch all devices with their clients and end users as soon as possible. Integrators should inform their customers that this IS a new generation of threat and to get ready for the long term solution of more patching and more monitoring. Using terms that this may indeed be another “Stuxnet” type event would be warranted.

Integrators Should Offer Solutions and Services to Increase Device Monitoring: System integrators should lead the effort on informing customers of this new threat and crafting solutions and services that can ramp up monitoring of security and network devices. Pushing customers for authorizing services aimed at determining network configuration control and network patch level should be pursued.

What to do if you’re a Device Manufacturer (Including Industrial Control Devices)

Review Development and Implementation Lab Device Patch Status: A device manufacturer should patch any development and lab systems, then update their security policy and procedures to reflect the change in network gear configurations. Device manufacturers should also begin tight controls on devices and software migrated into development environments.

Development Lab and Development Office Architecture Must Be Rethought: A device manufacturer must become slightly more paranoid about how development networks are connected to other networks. Juniper may spend a large amount of resources in finding out how a backdoor appeared in their device software. But you can be sure that Juniper will also invest more in the development of configuration control;and the development of network security.Both will need to be rethought to include greater auditing and monitoring.

Software Development Policies and Procedures, Along With Personnel Vetting Must Be Rethought:

I have seen certain best practices work very well, and they are as follows (in no particular order):

• Configuration Control of all source code under development
• Configuration Control of software (all personnel touching code, when, where)
• Segregated networks for software development (obviously not just VPN)
• Two person integrity on updates to source code files
• Critical files (encryption routines, Authorization routines etc.) under increased Configuration and Auditing
• Updated security policies that explicitly state adherence to code quality, security and integrity are mandatory for software engineers, testers and quality personnel.
• Background investigations on Software engineers, Testers and Quality personnel
• Implement source code classification according to critical security services. These critical software modules will undergo more security checks.
• Code reviews and testing for conformance to coding guides
• Code reviews that implement separation of duties on code determined critical.
• Coding guides that specifically spell out how formats of certain functions are to be done, to prevent obfuscation by bad actors
• Software supply chain reviews regular D&B checks on vendors with onsite inspections, audits and conformance to a vendors own security policies.
• Implement thorough review of ALL software moved into the development networks. This includes all commercial packaged software.

Device Manufacturers Will Need to Drastically Review Software Development Risks After the Juniper Backdoor: A device manufacturer should look at the Juniper backdoor as a new Stuxnet event. It goes without saying that any device manufacturer is to be considered a targeted victim of a similar type. Risk management of this new information will be key. All outside software code sources must be re-evaluated top to bottom in this threatening environment. It would be a very unfortunate situation if it were to be discovered that a fundamental flaw/backdoor existed in a supplier’s code, and the supplier was unable/unwilling to fix it, or supply the source code to enable mitigation's.

Conclusion

The impact that the Juniper Backdoor will have on the Networking industry cannot be overstatec. This breach is so audacious in its scope that it’s mind boggling. The implications for Juniper alone will be millions in additional costs,and innumerable losses in reputation and prestige. There are several industries that cannot afford to have a similar event occur, such as Industrial Control Device vendors. Everyone from end-users to Integrators and Device Manufacturers will need to fundamentally rethink how they approach software development in the future. It’s truly a new year and a new day in Device Cyber Security.

Read another article by Jeff: SecureIT - Create Complex and Easy-to-Remember Passwords