A few weeks ago while looking for some information on something else I was working on I came across the Open Vulnerability and Assessment Language (OVAL) website. Now these’s type of certification organization are nothing new and there are many around we have one locally in Australia based at the Queensland University. The big difference with this site is that they are publishing the vulnerabilities in a XML file in a format that you can basically plug straight into a testing tool. They have a sample test tool already which looks good but didn’t really give the sort of result I was after. With the schema that is used this XML file really lends itself to scripting so I thought I’d try to put together a script that would first separated out all the Exchange specific tests within the OVAL definition file and then perform the tests using the appropriate API via a script. This turned out to prove challenging and the script I ended up with was on the large side and covered a gamete of different API’s and VBS functions including Xpath, ADSI, Regular Expressions, Bitwise Operations, WMI, FSO and the registry provider.
OVAL definition file
The current OVAL definition file has a lot of vulnerabilities listed for Exchange 2003 at the moment which is what I targeted this script at. Most of the vulnerabilities appear to come from the Exchange Benchmark produced by the Centre for Internet Security. You can download the benchmark document for there site its well worth a read it contains a lot of good information and explanations that describe the reasoning behind some the vulnerabilities that are included in the OVAL definition file (and some of these vulnerabilities do need a little bit of explanation as they don’t all initial make sense).These guys are also building a scoring tool for there benchmark which should be interesting once it gets released.
To navigate the OVAL definition file in a script I’ve used Xpath via the Microsoft XMLDOM object. To limit it to only testing for vulnerabilities on Exchange 2003 it does a wildcard search of nodes that have a text value equal to “Microsoft Exchange Server 2003”. It’s important to note this script doesn’t test for Windows 2003/2000 vulnerabilities listed in the OVAL file only the Exchange specific ones.
OVAL test
The OVAL definition file lists a number of tests to be performed to work out if the current server’s configuration is vulnerable. Because some tests in the file are listed as unknown and some of the results are open to a little interpretation what I designed the script to do was just attempt the test if it can and display the result. Its doesn’t analyse wether it was a pass or fail (which I did have it doing initially but dropped)
Basically there are 5 types of tests
File Test looks at files to see if they are below a certain version meaning that a patch(hotfix) or service pack may not have been applied. To do this test via a script I’ve used WMI to first retrieve a registry entry that helps in finding the right filepath and then it uses the CIM_DataFile WMI class to look at the actual file version.
Registry Test looks at particular registry entires to determine if a patch is installed or different configuration or version information. To perform the registry test via a script I’ve used the WMI registry provider.
Active Directory Test looks at the value of particular Active Directory attributes. The OVAL definition provides a regular expression of the Distinguished Name of the object to look for and the attribute and value to evaluate. Because of this the Active Directory test isn’t 100%. To perform the test ADSI is used, a search is first performed for all objects in Active directory that have the attribute being search for set. A list of objects that matches this criteria is then evaluated against the Regex expression from the OVAL definition. Any objects that match then are then examined to see if these are server specific configuration setting. If they are then a test is performed to see if the configuration relates to the server that the script is testing. Non server specific keys such as global setting are always checked regardless. Because of the potential results that are returned for some Active Directory attributes it’s not possible to display the results of all the evaluations. Eg Keys that have a value type of Octent_string are sometimes stored in there own binary format which needs further decoding. Because of a few irregularities in the OVAL definitions there is a fix up section that reformats some of the Regular expressions so they can be searched successfully using VBS.
WMI_test looks at particular server configuration setting that are accessible via the WMI classes provided by Exchange or Windows. Currently there are 2 WMI tests in the current definitions that tests for IIS directory security settings. These 2 tests both use a WMI class that is only available on a Windows 2003 server.
The last type of test is the Unknown_test which means the script will just list a description of what should be tested but does not provide any means of carrying out the test
Results
The script is very verbose and outputs most of the actions it’s performing to the command line as it runs. It also builds a XML of the results of the entire test as it goes along. With the OVAL specification there is a result file format you can used but I decided to not use this and build my own mainly because of time and flexibility. To read the results I have a HTM page that runs another VBS script that uses Xpath again to navigate the result xml file and then display the results formatted in a HTML table.
Running the script
Because the script uses remote-able API’s this script can be run from any machine as long as the users you are logging on as has the necessary rights to query the file and WMI classes required. There are few hardcoded paths set in the script that point to a c:\oval directory which is where the results of the scan are saved to and the definition file is read from. Before you can use this script you need to download the OVAL definition file from http://oval.mitre.org/oval/download/datafiles/index.html . The file that contains the Exchange definitions is called windows.definitions.xml and needs to be downloaded to the c:\oval directory. The script takes one commandline parameter which is the servername of the server you want to run this script against. So to run the script use something like cscript.exe exovalchk.vbs servername
After the script has run you can then use the DisplayOvalResults.htm file to view the results of the scan. This file contains a script which you need to allow to run to parse out the ovaltestresult.xml file and display the result in a HTML Table. The script looks for the result file in the c:\oval directory. When viewing the result if you want to view the OVAL definition itself the name of the definition is hyperlinked to the definition description on the OVAL site.
Interpreting the results
The most time consuming thing you need to do with security (and this is probably the way it should be) is to interpret the results there is no real simple pass /fail result. Even vulnerability does need some level of human consideration and interpretation behind it to consider if this really does apply to you and weather you should make changes. Making the changes prescribed in some of these vulnerabilities will break things like OWA and OMA and these type of effects are not very clearly defined in the OVAL definition itself so always research any changes you are going to make before you make them (eg use Microsoft or the Exchange Benchmark which does list the reasons and effects of the changes.).
The script is very beta-ish because of the potential for errors there is no guarantee that this script will scan all the Exchange 2003 vulnerabilities in the OVAL definition file or display the results correctly. This script should be only viewed as a starting point
The script itself is a bit large to post verbatim I’ve put a downloadable copy of the script and display webpage here
OVAL definition file
The current OVAL definition file has a lot of vulnerabilities listed for Exchange 2003 at the moment which is what I targeted this script at. Most of the vulnerabilities appear to come from the Exchange Benchmark produced by the Centre for Internet Security. You can download the benchmark document for there site its well worth a read it contains a lot of good information and explanations that describe the reasoning behind some the vulnerabilities that are included in the OVAL definition file (and some of these vulnerabilities do need a little bit of explanation as they don’t all initial make sense).These guys are also building a scoring tool for there benchmark which should be interesting once it gets released.
To navigate the OVAL definition file in a script I’ve used Xpath via the Microsoft XMLDOM object. To limit it to only testing for vulnerabilities on Exchange 2003 it does a wildcard search of nodes that have a text value equal to “Microsoft Exchange Server 2003”. It’s important to note this script doesn’t test for Windows 2003/2000 vulnerabilities listed in the OVAL file only the Exchange specific ones.
OVAL test
The OVAL definition file lists a number of tests to be performed to work out if the current server’s configuration is vulnerable. Because some tests in the file are listed as unknown and some of the results are open to a little interpretation what I designed the script to do was just attempt the test if it can and display the result. Its doesn’t analyse wether it was a pass or fail (which I did have it doing initially but dropped)
Basically there are 5 types of tests
File Test looks at files to see if they are below a certain version meaning that a patch(hotfix) or service pack may not have been applied. To do this test via a script I’ve used WMI to first retrieve a registry entry that helps in finding the right filepath and then it uses the CIM_DataFile WMI class to look at the actual file version.
Registry Test looks at particular registry entires to determine if a patch is installed or different configuration or version information. To perform the registry test via a script I’ve used the WMI registry provider.
Active Directory Test looks at the value of particular Active Directory attributes. The OVAL definition provides a regular expression of the Distinguished Name of the object to look for and the attribute and value to evaluate. Because of this the Active Directory test isn’t 100%. To perform the test ADSI is used, a search is first performed for all objects in Active directory that have the attribute being search for set. A list of objects that matches this criteria is then evaluated against the Regex expression from the OVAL definition. Any objects that match then are then examined to see if these are server specific configuration setting. If they are then a test is performed to see if the configuration relates to the server that the script is testing. Non server specific keys such as global setting are always checked regardless. Because of the potential results that are returned for some Active Directory attributes it’s not possible to display the results of all the evaluations. Eg Keys that have a value type of Octent_string are sometimes stored in there own binary format which needs further decoding. Because of a few irregularities in the OVAL definitions there is a fix up section that reformats some of the Regular expressions so they can be searched successfully using VBS.
WMI_test looks at particular server configuration setting that are accessible via the WMI classes provided by Exchange or Windows. Currently there are 2 WMI tests in the current definitions that tests for IIS directory security settings. These 2 tests both use a WMI class that is only available on a Windows 2003 server.
The last type of test is the Unknown_test which means the script will just list a description of what should be tested but does not provide any means of carrying out the test
Results
The script is very verbose and outputs most of the actions it’s performing to the command line as it runs. It also builds a XML of the results of the entire test as it goes along. With the OVAL specification there is a result file format you can used but I decided to not use this and build my own mainly because of time and flexibility. To read the results I have a HTM page that runs another VBS script that uses Xpath again to navigate the result xml file and then display the results formatted in a HTML table.
Running the script
Because the script uses remote-able API’s this script can be run from any machine as long as the users you are logging on as has the necessary rights to query the file and WMI classes required. There are few hardcoded paths set in the script that point to a c:\oval directory which is where the results of the scan are saved to and the definition file is read from. Before you can use this script you need to download the OVAL definition file from http://oval.mitre.org/oval/download/datafiles/index.html . The file that contains the Exchange definitions is called windows.definitions.xml and needs to be downloaded to the c:\oval directory. The script takes one commandline parameter which is the servername of the server you want to run this script against. So to run the script use something like cscript.exe exovalchk.vbs servername
After the script has run you can then use the DisplayOvalResults.htm file to view the results of the scan. This file contains a script which you need to allow to run to parse out the ovaltestresult.xml file and display the result in a HTML Table. The script looks for the result file in the c:\oval directory. When viewing the result if you want to view the OVAL definition itself the name of the definition is hyperlinked to the definition description on the OVAL site.
Interpreting the results
The most time consuming thing you need to do with security (and this is probably the way it should be) is to interpret the results there is no real simple pass /fail result. Even vulnerability does need some level of human consideration and interpretation behind it to consider if this really does apply to you and weather you should make changes. Making the changes prescribed in some of these vulnerabilities will break things like OWA and OMA and these type of effects are not very clearly defined in the OVAL definition itself so always research any changes you are going to make before you make them (eg use Microsoft or the Exchange Benchmark which does list the reasons and effects of the changes.).
The script is very beta-ish because of the potential for errors there is no guarantee that this script will scan all the Exchange 2003 vulnerabilities in the OVAL definition file or display the results correctly. This script should be only viewed as a starting point
The script itself is a bit large to post verbatim I’ve put a downloadable copy of the script and display webpage here