What BIOS does that PCI compliant server have?

Tenable’s research group recently added a Nessus plugin that makes use of a credentialed WMI query to determine the type of BIOS that has been installed on the audited computer. Similar plugins were added to perform the same task on UNIX systems via SSH as well as over SMB. The WMI and SMB plugins reside in the Windows plugin family and the SSH plugin belongs to the General plugin family.

When run in the Nessus Client with credentials, it reports information about the remote BIOS version as demonstrated in the following screen shot:

Why Gather BIOS Information?

Last week, I was part of Tenable’s participation in the IANS New England Information Security Forum. This event allowed me to present the Tenable solution of Unified Security Monitoring to a group of potential and existing customers in groups of 5-15 people at a time. During these sessions, there are obviously a lot of people that understand Nessus, but occasionally, I run into someone who has no idea that Nessus can be used for patch auditing, configuration auditing and gathering a wealth of information about the systems being audited.

“Why does a vulnerability scanner need to collect BIOS information?” I had an attendee ask. This attendee was almost immediately rebuked by another attendee who said “If I can get this level of detail about systems being audited by Nessus, this makes my life a lot easier!”.

Were these two users living in different universes? Sort of. More and more I am running into two distinct types of organizations: resource constrained risk managers and resource constrained compliance managers. The first type of organization concerns itself with doing risk avoidance to the extent they only look for security issues and attempt to mitigate them. The second type of organization uses their security auditing process to look for problems with their procedures. 

To a security auditor in the first type of risk avoidance organization, any information which is not a vulnerability is irrelevant. All they are concerned about is finding vulnerabilities and then mitigating them. However, in the second organization which is focused on auditing policy, any information that can help audit that a policy is in effect is useful.

I’m greatly oversimplifying a very complex debate in the information security and systems management communities concerning risk management. What I am not exaggerating is the sort of attitudes and approaches I see in some operational administrators and auditors. Consider these types of flawed comments:

• “We don’t need to scan with credentials because our IT group has their own patch management system.”
• “Once we get our scan results, we filter it to just the ‘high’ vulnerabilities and focus on those because we don’t have the resources to fix everything else Nessus finds”.
• “I don’t want to make our IT guys looks bad. Nessus finds all sorts of security issues as it is, I don’t want to inspect our IT shop to see if they are actually running the network how they say they are running it.”

Being able to collect BIOS information is another example of the different types of useful audits that Nessus can perform which typically don’t directly relate to discovering a vulnerability. This information allows an auditor to demonstrate that they have full transparency into the operations of the IT organization.

Technically, what can I do with BIOS information? 

Leaving the debate about auditing risk versus auditing policy behind us, there are some very good technical reasons to look at the type and version of BIOS that is installed on a system:

BIOS can need patching

BIOS images have life cycles just like any other type of software, which means bugs can be found and new releases for these bugs as well. If your organization has a requirement to run a certain type of BIOS, this technique is an excellent way to audit this. I’ve encountered some organizations that have had to roll out a new type of BIOS to support upgrades to new OSes, such as Windows Vista.

BIOS images can have security issues

At this year’s Black Hat, Johanna Rutkowska demonstrated a blue pill attack via a flaw in an Intel
BIOS image that allowed an attack against a Xen hypervisor. More recently, iViZ released a series of advisories on various vendors BIOS keyboard buffer implementations that allowed for password disclosure. If your organization is effected by a security issue in one of your BIOS images, Nessus can be used to audit when these systems have been upgraded.

Hacked BIOS images can be used to Unlock Vista

It was recently revealed that by modifying the BIOS, a user could be able to crack Vista’s OEM activation.  These techniques typically involve editing an existing BIOS image, but some attacks can also be launched by using a new BIOS image more suitable for cracking. If this becomes a preferred method to activate Vista illegally, it is likely that a BIOS update will be distributed specifically for this purpose.

Maybe those systems have the wrong BIOS image

Performing a very simple audit of asking “why?” certain systems have certain types of BIOS images can be very informative. It is possible this can be used to discover inconsistencies in hardware, such as an appliance vendor sending you new motherboards.

BIOS can be used as a form of asset classification

Lastly, this information can be used to classify systems under an asset management system. With a product such as the Tenable Security Center, data from Nessus scans containing BIOS information can be used to create dynamic asset lists. These are lists of IP addresses that share a common set of features. We’ve blogged in the past about various strategies that can be used to help organizations use technical methods to dynamically classify political and business  assets here, here and here.

For More Information

These previous blog entries concern using Nessus to perform a variety of WMI checks and configuration audits:

• WMI Based Compliance Checks
• Advanced Nessus 3 WMI Checks Against Windows Systems
• Example WMI “nlib” Library Usage
• Wireless SSID Enterprise Discovery

If you would like to read more general blog entries concerning the relationship between IT and security, I suggest these:

• Security Metrics – Counting Security and Compliance Incidents
• Reporting Vulnerabilities in an IT Managed Environment
• Auditing Anti-Virus Software without an Agent
• Finding Vulnerabilities older than 30 Days