Back to Basics: Firmware in NFV Security

In the NFV environment, physical devices such as firewalls, load balancers, routers or other traditional devices become software applications residing in virtual machines (VM). When a rootkit is implemented, or the system firmware compromised, it can cause VM escapes [6]. This means a VM and its application no longer stay within the isolated containment of its guest operating system but can interact with or attack other virtual machines and host operating systems (Figure 2). In NFV deployments, a firmware vulnerability on a single manufactures’ chip can expose and compromise large segments of infrastructure and networks. In the example above where the impact of the compromised Cisco routers were limited to the proprietary physical devices, models 1841, 2811 and 3825, in NFV environments, these same routers would be software based virtual routers or virtual network functions (VNFs) residing on virtual machines on commodity x86 hardware. Because of the ubiquity of the system firmware on commodity hardware, compromised firmware (Figure -1) would have a network segment wide impact, and not limited to infrastructure hosting specific router VNFs. Instead the impact would be felt regardless of the virtual network function hosted. Firmware vulnerabilities that were isolated by the confines of proprietary physical devices now have a broad network or data centre wide reach of exposure. The extent of impacts of exploited BIOS/UEFI and other system firmware vulnerabilities in NFV, raises firmware security up the list of security priorities into the spotlight.

In some ways, it is a return to the past, to dust off and reinstate, with new importance long forgotten security basics.

Be vigilant of your supply chain and ensure only manufacturer certified or authorised agents are sources and handle your equipment.

Software updates and patches for OSes and applications are a regular feature in most environments with vendors often pushing these patches over the internet to their customers. However, firmware updates and fixes, while released by most major OEMs, are typically not implemented with near as much diligence as software updates in most enterprises. OEMs release firmware patches for their newer hardware, while firmware vulnerability from a couple or more years prior may lay latent through the life cycle of the deployed hardware. In NFV environments it is of particular importance not to utilise infrastructure where the vendor has ceased to provide firmware updates. Additionally, it is imperative that firmware updates are included in routine corporate patch management practices.

Purchase hardware that have protection against malicious firmware modification. Some vendors are implementing CRC type checking routines that halt the execution of the BIOS if unapproved modification is made [7].

Notice the trusted platform module (TPM) chip in figure 1. Where the TPM chip is already present on the x86 hardware, consider using them. A TPM is a specification from the trusted computing group (TCG) that can perform cryptographic operations to protect small amounts of sensitive information to enable signing and measurements (hash values) that allows for a trusted boot process [8]. The TPM enables verification that the system boot utilised firmware that was not tampered with. TPM however is not a heavy duty cryptographic engine or accelerator, and hardware security module (HSM) may be considered for more robust security.

NFV is being deployed in clouds, in data centres, in vRAN in mobile edge networks, cloud based IoT management and data-analytics platforms, in general where volumes of infrastructure can be aggregated and operations optimised. In such aggregated environments, vulnerabilities have large domino effect and security by obscurity is not an option. The discussed measures for firmware security are not new however NFV has given them renewed value and a heightened security context.

Author’s Note: Opinions expressed in this article are the author’s and not necessarily those of her employer.

References

1. Intel, “server-chipsets,” [Online]. Available: http://www.intel.com/content/www/us/en/chipsets/server-chipsets/server-chipset-c600.html. [Accessed 17 Oct 2015].
2. X. Kovah and C. Kallenberg, “Are you giving Firmware Attackers a Free Pass?,” in RSA, San Francisco, 2015.
3. B. Hau, T. Lee and J. Homan, “SYNful Knock – A Cisco router implant – Part I,” Fireeye, 15 Sep 2015. [Online]. Available: https://www.fireeye.com/blog/threat-research/2015/09/synful_knock_-_acis.html. [Accessed 17 Oct 2015].
4. K. Jain, “SYNful Knock – Backdoor Malware found on Cisco Routers,” The Hacker News, 16 Sep 2015. [Online]. Available: http://thehackernews.com/2015/09/cisco-router-backdoor.html. [Accessed 17 Oct 2015].
5. K. Zetter, “Researchers create first firmware worm that attacks MACs,” wired.com, 3 Aug 2015. [Online]. Available: http://www.wired.com/2015/08/researchers-create-first-firmware-worm-attacks-macs/. [Accessed 17 Oct 2015].
6. M. Gorobets, O. Bazhaniuk, A. Matrosov, A. Furtak and Y. Bulygin, “AttackingHypervisorsViaFirmware – Intel Security Threat Research,” 6 Aug 2015. [Online]. Available: https://web.archive.org/web/20170106121646/http://www.intelsecurity.com/advanced-threat-research/content/AttackingHypervisorsViaFirmware_bhusa15_dc23.pdf. [Accessed 17 Oct 2015].
7. R. A. Grimes, “what-you-need-to-know-about-firmware-attacks,” Infoworld.com, 7 Aug 2012. [Online]. Available: http://www.infoworld.com/article/2618113/security/what-you-need-to-know-about-firmware-attacks.html. [Accessed 17 Oct 2015].
8. M. Garrett, “Securing the entire cloud with TPMs,” in Openstack Summit, Vancouver, 2015.