Partner Perspectives  Connecting marketers to our tech communities.
3/11/2015
09:55 AM
Steve Grobman
Steve Grobman
Partner Perspectives
50%
50%

Raising the Stakes: When Software Attacks Hardware

Beware the risks of cyberattacks on your computer hardware.

Most people think of cyberattacks as software against software – traditional malware such as Trojans, viruses, and worms infiltrating and attacking applications, operating systems, or data. This arms race has been escalating for decades and is now at a high level of sophistication, requiring advanced skills on both sides.

But there is another type of attack, one that pits software against hardware. These attacks typically try to corrupt the firmware or configurations used by processors or other core components. Attacking hardware or firmware enables an adversary to have enhanced abilities to hide from detection and can also increase damage to a platform, such as preventing the machine from booting. This can render the machine unusable and unrecoverable with the tools available in an average IT department. Since the machine would not be able to get as far as initializing the memory or external interfaces, even an external drive would not be able to boot.

Often, the target of these attacks is the BIOS (basic input/output system) code that is the first to run when a machine is powered on. Secondary targets are firmware for essential components such as network adapters, IO controllers, power management, and graphics processing units. For greater flexibility, most hardware manufacturers store firmware and its configuration details in flash memory so that it can be patched or updated if necessary. Unfortunately, this rewritable flexibility makes firmware vulnerable to attack. The industry has tried to lock down access to these sensitive areas of flash memory and minimize vulnerabilities. However, the complexity of code and the number of components create numerous attack vectors that are a rich environment for the security research community and malicious adversaries to explore.

Simple Attack, Difficult Recovery

Although the recovery of a machine with corrupted firmware is quite difficult, the attack itself is often much simpler. In many cases, standard software can be used to perform an attack on firmware or hardware. Such a simple attack (that makes your machine a paperweight) is facilitated by writing garbage to the critical configuration variables used by the BIOS and triggering a reboot. Some systems have backup or default settings, so those would have to be corrupted or deleted as well. Many operating systems expose these variables to privileged applications – Microsoft Windows has SetFirmwareEnvironmentVariable, for example – making it trivial to attack once the malware has been delivered. It is the responsibility of the system integrator and OEM to ensure that adequate protection and validation for BIOS and configuration is implemented in a system to prevent this type of attack, and many machines in the wild do not employ adequate protection.

If this is so easy, why are we not seeing more hardware attacks? Probably because the majority of attacks have an objective of stealing information or turning the machine into a controllable bot, and bricked machines do not support these goals. However, as new or different criminal actors and nation states start to exercise their cyberthreats, we may see more hardware-based attacks as a means to create chaos or deny service to an organization. The other factor that makes hardware-based attacks less prevalent in bulk malware is that they often need to support multiple configurations or be individually tweaked to work on the specific hardware platform that is being targeted.

Validating that a platform’s BIOS implementation is not vulnerable to known low-level attacks is a highly complex task. Luckily, there are tools that can make this possible for an IT organization. One tool, called chipsec, was developed here at Intel and then released free and open under an open source license. Key use cases for the chipsec platform include vulnerability assessment, advanced forensics, and security research. We continue to update it and encourage others to contribute as well.

The firmware attack surface is large, and the vulnerabilities are not new and are not terribly difficult to exploit. It is critical that the industry recognizes that both hardware and software are critical assets that may become an area of exploitation in an advanced attack.

Steve Grobman is the chief technology officer for Intel Security Group at Intel Corporation. In this role, Grobman sets the technical strategy and direction for the company's security business across hardware and software platforms, including McAfee and Intel's other security ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
xmarksthespot
50%
50%
xmarksthespot,
User Rank: Strategist
3/19/2015 | 5:40:26 AM
I'll check it out
Free and open source. I like!  I think many of us have been wondering about how we can scan our BIOS/firmware for nasty little things.  Up until now, I didn't know of a way.  Thanks!
Veterans Find New Roles in Enterprise Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/12/2018
Understanding Evil Twin AP Attacks and How to Prevent Them
Ryan Orsi, Director of Product Management for Wi-Fi at WatchGuard Technologies,  11/14/2018
7 Free (or Cheap) Ways to Increase Your Cybersecurity Knowledge
Curtis Franklin Jr., Senior Editor at Dark Reading,  11/15/2018
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19355
PUBLISHED: 2018-11-19
modules/orderfiles/ajax/upload.php in the Customer Files Upload addon 2018-08-01 for PrestaShop (1.5 through 1.7) allows remote attackers to execute arbitrary code by uploading a php file via modules/orderfiles/upload.php with auptype equal to product (for upload destinations under modules/productfi...
CVE-2008-7320
PUBLISHED: 2018-11-18
** DISPUTED ** GNOME Seahorse through 3.30 allows physically proximate attackers to read plaintext passwords by using the quickAllow dialog at an unattended workstation, if the keyring is unlocked. NOTE: this is disputed by a software maintainer because the behavior represents a design decision.
CVE-2018-19358
PUBLISHED: 2018-11-18
GNOME Keyring through 3.28.2 allows local users to retrieve login credentials via a Secret Service API call and the D-Bus interface if the keyring is unlocked, a similar issue to CVE-2008-7320. One perspective is that this occurs because available D-Bus protection mechanisms (involving the busconfig...
CVE-2018-19351
PUBLISHED: 2018-11-18
Jupyter Notebook before 5.7.1 allows XSS via an untrusted notebook because nbconvert responses are considered to have the same origin as the notebook server. In other words, nbconvert endpoints can execute JavaScript with access to the server API. In notebook/nbconvert/handlers.py, NbconvertFileHand...
CVE-2018-19352
PUBLISHED: 2018-11-18
Jupyter Notebook before 5.7.2 allows XSS via a crafted directory name because notebook/static/tree/js/notebooklist.js handles certain URLs unsafely.