In a few of my previous posts, I discussed misleading results some scanners might produce with regard to the versions of software present on your system. In this post, I will demonstrate how to use an SCAP capable scanner using vendor-maintained OVAL patch definitions.
In order to assess my system, I need an OVAL-capable scanner and data it can use to assess my system against. Let's start by downloading the source code to the OpenSCAP scanner. Once downloaded, I'll build the scanner on my openSUSE 11.1 system:
# /bin/tar xzvf openscap-0.7.0.tar.gz # cd openscap-0.7.0/ # ./configure --prefix=/usr # /usr/bin/make # /usr/bin/make install
Next I need some appropriate content the scanner can use to assess my system. Since I am running openSUSE 11.1, I need to get my specific OVAL patch definitions from Novell. I simply use curl to get the exact file:
# /usr/bin/curl -O http://support.novell.com/security/oval/opensuse.11.1.xml
Now, use the OpenSCAP command utility to assess the system and write the results to a file:
# /usr/bin/oscap oval eval --result-file ./myresults.xml ./opensuse.11.1.xml
…
…
…
Evalutated definition oval:org.opensuse.security:def:20070048: false
Evalutated definition oval:org.opensuse.security:def:20070045: false
Evalutated definition oval:org.opensuse.security:def:20054881: false
Evaluation: All done.
====== RESULTS ======
TRUE: 36
FALSE: 1162
ERROR: 0
UNKNOWN: 0
NOT EVALUATED: 0
NOT APPLICABLE: 0
The last step is to create an HTML-formatted report from the results file:
# /usr/bin/oscap oval generate report \
--output ./howamidoing.html ./myresults.xml
The report could do a better of job of correlating the reference identification to the actual vulnerable software. According to OpenSCAP's website, this is on their “to-do” list.
The OVAL patch definitions comprise a definition which identifies the tests to be performed. The tests determine if an object is in a particular state. Let's consider a real world example and then we'll walk through the OVAL definition. A port scanner detects an Apache web server running:
# /usr/bin/nmap -sV -p 80 localhost Starting Nmap 4.75 ( http://nmap.org ) at 2011-04-06 08:32 EDT Interesting ports on localhost (127.0.0.1): PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.2.10 ((Linux/SUSE)) Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 6.17 seconds
From this the security officer believes it is vulnerable to CVE-2009-1195. Within minutes, they communicate the issue and demand the web server be shut down because it is not at least version 2.2.12! The Nessus® vulnerability scanner also reports version 2.2.10 however, its plug-in (#39521) Backported Security Patch Detection (WWW) reports a low-severity problem. Better than a false-positive but it still means that you'll need to investigate your installed version to see if it has been patched correctly.
At this point, the system administrator verifies the package installed is version 2.2.10-2.9.1:
# /bin/rpm -q apache2
apache2-2.2.10-2.9.1
However, the package's change log and a scan performed using the vendor-maintained OVAL definitions reports it is okay. This is effective because the vendor knows when the problem was patched (backported security fixes) and it is defined in the OVAL data file. Here is Novell's definition:
<definition id="oval:org.opensuse.security:def:20091195"
version="0" class="vulnerability">
<metadata>
<title>CVE-2009-1195</title>
<affected family="unix">
<platform>openSUSE 11.1</platform>
</affected>
<reference ref_id="CVE-2009-1195"
ref_url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1195"
source="CVE"/>
<description>
The Apache HTTP Server 2.2.11 and earlier 2.2 versions does not properly
handle Options=IncludesNOEXEC in the AllowOverride directive, which allows
local users to gain privileges by configuring (1) Options Includes, (2)
Options +Includes, or (3) Options +IncludesNOEXEC in a .htaccess file, and
then inserting an exec element in a .shtml file.
</description>
</metadata>
<criteria operator="AND">
<criterion test_ref="oval:org.opensuse.security:tst:2009044425"
comment="suse111 is installed"/>
<criteria operator="OR">
<criterion test_ref="oval:org.opensuse.security:tst:2009055738"
comment="apache2-devel less than 2.2.10-2.8.1"/>
<criterion test_ref="oval:org.opensuse.security:tst:2009055739"
comment="apache2-doc less than 2.2.10-2.8.1"/>
<criterion test_ref="oval:org.opensuse.security:tst:2009055740"
comment="apache2-example-pages less than 2.2.10-2.8.1"/>
<criterion test_ref="oval:org.opensuse.security:tst:2009055741"
comment="apache2-prefork less than 2.2.10-2.8.1"/>
<criterion test_ref="oval:org.opensuse.security:tst:2009055742"
comment="apache2-utils less than 2.2.10-2.8.1"/>
<criterion test_ref="oval:org.opensuse.security:tst:2009055743"
comment="apache2-worker less than 2.2.10-2.8.1"/>
<criterion test_ref="oval:org.opensuse.security:tst:2009055744"
comment="apache2 less than 2.2.10-2.8.1"/>
</criteria>
</criteria>
</definition>
The definition's criteria includes a test (...:tst:2009055744) to determine if the Apache package is less than 2.2.10-2.8.1. The test itself evaluates the object (...:obj:2009030668) to determine if it is installed and in a specific state (...:ste:2009037265):
<rpminfo_test id="oval:org.opensuse.security:tst:2009055744" version="0"
comment="apache2 is <2.2.10-2.8.1"
check="at least one"
xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux">
<object object_ref="oval:org.opensuse.security:obj:2009030668"/>
<state state_ref="oval:org.opensuse.security:ste:2009037265"/>
</rpminfo_test>
The object is an RPM package object and the name of the package is “apache2”:
<rpminfo_object id="oval:org.opensuse.security:obj:2009030668"
version="0"
xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux">
<name>apache2</name>
</rpminfo_object>
Finally, if the package object's epoch-version-string (EVR) is less than 0:2.2.10-2.8.1 then the test is true and the installed software is vulnerable.
<rpminfo_state id="oval:org.opensuse.security:ste:2009037265"
version="0"
xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux">
<evr datatype="evr_string" operation="less than">0:2.2.10-2.8.1</evr>
</rpminfo_state>
However, our system is not vulnerable because we have 2.2.10-2.9.1 installed on the system. Too often system administrators believe they must build and maintain their own version of the Apache web server because they think the vendor's package is out-of-date and vulnerable. Unfortunately, in some cases they just want to avoid the heartburn and frustration which comes with trying to explain to auditors and security officers that they are not vulnerable.
I have found that OVAL patch definitions are useful and accurate. However, if vendors don't maintain them, you'll have to do some more digging. And of course, if the software isn't installed as a package, you'll have to dig even more. Overall, I am impressed with OpenSCAP and am excited about the growing OVAL repositories.
NOTE: OVAL patch definition repositories for Debian, Red Hat, and others (including Microsoft) can be found here.
great info !
ReplyDelete