Common vulnerability check examples

The Writing vulnerability checks tutorial takes you through a simple example of how to write an HTTP-based vulnerability check and run it in the Security Console. This page contains more examples of different types of checks you can create.

Service banner checks

The element checks for the presence of a certain service running on the network. The type attribute indicates the protocol. Multiple OR'd types are separated by a | (pipe) character. The example below uses "HTTP|HTTPS" to indicate HTTP or HTTPS.

The element indicates a fingerprinted product found running on that service. The element checks for a range of product version numbers. NOTE: The version number is exclusive -- in other words should be equal to the next NON-vulnerable version of that product. In the example below, Apache 2.0.45 contains the patch.

http-apache-excessive-newline-dos.vck

1
<VulnerabilityCheck id="http-apache-excessive-newline-dos" scope="endpoint">
2
<NetworkService type="HTTP|HTTPS">
3
<Product name="Apache">
4
<version>
5
<range><low>2.0.0</low><high>2.0.45</high></range>
6
</version>
7
</Product>
8
</NetworkService>
9
</VulnerabilityCheck>

ftp-proftpd-cwd-format-string.vck, which tests for the existence of a vulnerability using a FTP banner version test:

1
<VulnerabilityCheck id="ftp-proftpd-cwd-format-string" version="1.0" scope="endpoint">
2
<NetworkService type="FTP">
3
<Product name="ProFTPD">
4
<version><range><high>1.2.0rc3</high></range></version>
5
</Product>
6
</NetworkService>
7
</VulnerabilityCheck>

ftp-servu-directory-traversal.vck, which connects to an FTP server with any available credentials, executes a directory change command, and checks the result code and text.

1
<VulnerabilityCheck id="ftp-servu-directory-traversal" version="1.0" scope="endpoint">
2
<NetworkService type="FTP"/>
3
<FTPCheck login="1">
4
<FTPRequestResponse>
5
<FTPRequest>CWD \\..%20.</FTPRequest>
6
<FTPResponse code="250">
7
<regex>Directory changed to /..</regex>
8
</FTPResponse>
9
</FTPRequestResponse>
10
</FTPCheck>
11
</VulnerabilityCheck>

http-website-long-options-bof.vck, example version check for two different product editions in one check file.

1
<VulnerabilityCheck id="http-website-long-options-bof" scope="endpoint">
2
<NetworkService type="HTTP|HTTPS">
3
<Product name="WebSite">
4
<version><range><high>3.5.15</high></range></version>
5
</Product>
6
<Product name="WebSitePro">
7
<version><range><high>3.5.15</high></range></version>
8
</Product>
9
</NetworkService>
10
</VulnerabilityCheck>

Sometimes you want to check for the version of a particular of a , for example PHP.

php-ecalloc-integer-overflow.vck

1
<VulnerabilityCheck id="php-ecalloc-integer-overflow" scope="endpoint">
2
<NetworkService type="HTTP|HTTPS">
3
<Product name="Apache">
4
<Component name="PHP">
5
<version><range><low>4.0.0</low><high>4.3.0</high></range></version>
6
<version><range><low>5.0.0</low><high>5.2.0</high></range></version>
7
</Component>
8
</Product>
9
</NetworkService>
10
</VulnerabilityCheck>

Authenticated Windows checks

In order for the Security Console to execute authenticated Windows checks, it must have access to either WMI or the Remote Registry service, which is usually discovered using a default account check (known default passwords) or administrative credentials specified in the site configuration of the web interface.

ActiveXControlInstalled - Checks for the presence of an ActiveX control

The element allows you to test for the presence of ActiveX control on a Windows system (by GUID). By default, this element does honor the kill-bit. In other words, if the ActiveX control is installed but the kill-bit is set, the check will report "not vulnerable". If you want to report the vulnerability even if the kill-bit is set, specify

ibm-access-support-activex-bof.vck

1
<?xml version='1.0' encoding='UTF-8'?>
2
<VulnerabilityCheck id="ibm-access-support-activex-bof" scope="node" version="1.0">
3
<ActiveXControlInstalled guid="74FFE28D-2378-11D5-990C-006094235084"/>
4
</VulnerabilityCheck>

WindowsRegistry - Checks for registry keys/values in the Windows registry

Windows registry check tests are tests which check for the existence of certain keys, values, or value data in a windows registry service found by the Security Console during a scan

w32-protoride-b-worm.vck

1
<VulnerabilityCheck id="w32-protoride-b-worm" scope="node">
2
<WindowsRegistry>
3
<registryKey name="HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run" mustNotBePresent="1">
4
<registryValue name="Windows Taskbar Manager"><regex cflags="REG_ICASE">.*</regex></registryValue>
5
</registryKey>
6
</WindowsRegistry>
7
</VulnerabilityCheck>

The element is the top-level element of a windows registry test. This element must contain at least one sub-element. No other elements are allowed.

The element is the top-level element describing a registry key and value to test for. It has two attributes: name and mustNotBePresent. The name is the name of the registry key to check for. The mustNotBePresent attribute is worded a backwards. If mustNotBePresent="1", it means "Fire this check if the key is present, otherwise return not vulnerable".

The element specifies the expected data assigned to a specific registry value. It contains three attributes: name, type and default.

  • The name attribute specifies the name of the registry value (under the parent key).
  • The type attribute specifies the expected type of the registry value, which must be one of: REG_SZ, REG_EXPAND_SZ, REG_BINARY, REG_DWORD, REG_DWORD_LITTLE_ENDIAN,, REG_DWORD_BIG_ENDIAN, REG_LINK, REG_MULTI_SZ, REG_RESOURCE_LIST, REG_FULL_RESOURCE_DESCRIPTOR, REG_RESOURCE_REQUIREMENTS_LIST, REG_QWORD, REG_QWORD_LITTLE_ENDIAN. See http://msdn.microsoft.com/en-us/library/ms724884%28VS.85%29.aspx for more information on different value types.
  • The default attribute is used when you want to check for the registry "default value" under a key without specifying the name attribute.

If you want to test for existence of registry keys and registry values, use the and elements.

trojan-gimmiv.vck

1
<VulnerabilityCheck id="trojan-gimmiv" scope="node">
2
<or>
3
<!-- created by the dropper component (Gimmiv.A) -->
4
<WindowsRegistry>
5
<registryKeyExists name="HKLM\SYSTEM\CurrentControlSet\Services\sysmgr\Parameters">
6
<registryValueExists name="ServiceDll"/>
7
<registryValueExists name="ServiceMain"/>
8
</registryKeyExists>
9
<registryKeyExists name="HKLM\SYSTEM\CurrentControlSet\Services\sysmgr">
10
<registryValueExists name="DisplayName"/>
11
<registryValueExists name="ImagePath"/>
12
</registryKeyExists>
13
</WindowsRegistry>
14
<WindowsFileExists>
15
<!-- created by the dropper component (Gimmiv.A) -->
16
<fileExists name="%CSIDL_SYSTEM%\wbem\sysmgr.dll"/>
17
<!-- created by the worm component (Gimmiv.B) -->
18
<fileExists name="%CSIDL_SYSTEM%\wbem\winbaseInst.exe"/>
19
<fileExists name="%CSIDL_SYSTEM%\wbem\winbase.dll"/>
20
<fileExists name="%CSIDL_SYSTEM%\wbem\basesvc.dll"/>
21
<fileExists name="%CSIDL_SYSTEM%\wbem\syicon.dll"/>
22
</WindowsFileExists>
23
</or>
24
</VulnerabilityCheck>

WindowsFileExists - check for existence of files

The element is used to determine whether or not a file is available on a system. The trojan-gimmiv.vck example above shows an example of how this check works. The name attribute is the name of the file. Certain well-known Windows paths can be specified using percent substitution. For example, it is not always known where the Windows directory is. Usually, this is ‘C:\WINDOWS’, however it may vary depending on the configuration of the device. During runtime (scanning), the Security Console will discover the windows root for the device under test and replace the ‘%windir%’ string in the path for the fileVersion test with the actual windows root directory on the device. The following substitution strings are supported:

  • %SystemDrive%
  • %windir%
  • %CSIDL_SYSTEM%
  • %CSIDL_SYSTEMX86%
  • %ProgramFiles%
  • %ProgramFiles(x86)%
  • %CommonProgramFiles%
  • %CSIDL_PROGRAM_FILES_COMMONX86%
  • %SQLPath%
  • %ExchangePath%
  • %OfficePath%

WindowsFileVersion - check for version of a Windows .EXE or .DLL

tests allow testing of versions retrieved from files on the file system of the endpoint under test during a scan. If a file versioning service is found during a scan, the Security Console will use them to execute these tests.

A file version check test would resemble the following:

1
<WindowsFileVersion>
2
<fileVersion name="%windir%\system32\scesrv.dll" mustExist="1">
3
<version><range><high inclusive="0">5.0.2195.3649</high></range></version>
4
</fileVersion>
5
</WindowsFileVersion>

Here is a more complex check which contains tests for a specific file version only on Windows XP SP2 (a combination of system and windows file version check tests).

1
<VulnerabilityCheck id="acme-windows-file-check-1" scope="node" version="1.0">
2
<System>
3
<OS minCertainty="1.0" name="Windows XP Professional" vendor="Microsoft">
4
<version>
5
<value>SP2</value>
6
</version>
7
</OS>
8
</System>
9
<WindowsFileVersion>
10
<fileVersion name="%windir%\system32\shsvcs.dll" mustExist="1">
11
<version><range><high inclusive="0">6.0.2900.3051</high></range></version>
12
</fileVersion>
13
</WindowsFileVersion>
14
</VulnerabilityCheck>

Here is an example check for a particular version of Internet Explorer which tests multiple registry values for that specific product.

1
<VulnerabilityCheck id="acme-windows-registry-check-1" scope="node" version="1.0">
2
<InstalledSoftware>
3
<Product minCertainty="1.0" name="Internet Explorer" vendor="Microsoft">
4
<version>
5
<value>5.01 SP4</value>
6
</version>
7
</Product>
8
</InstalledSoftware>
9
<WindowsRegistry>
10
<registryKey name="HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D9998BD0-7957-11D2-8FED-00606730D3AA}">
11
<registryValue name="Compatibility Flags" type="REG_DWORD">
12
<value>1024</value>
13
</registryValue>
14
</registryKey>
15
<registryKey name="HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{BE4191FB-59EF-4825-AEFC-109727951E42}">
16
<registryValue name="Compatibility Flags" type="REG_DWORD">
17
<value>1024</value>
18
</registryValue>
19
</registryKey>
20
</WindowsRegistry>
21
</VulnerabilityCheck>

InstalledSoftware - checks for version of installed software

1
<InstalledSoftware>
2
<Product minCertainty="1.0" name="Exchange 2000 Server" vendor="Microsoft">
3
<version>
4
<value>SP3</value>
5
</version>
6
</Product>
7
</InstalledSoftware>

Default account checks

In the Security Console, all username/password checks work basically the same way. You have a element with the type of service, followed by a element. The and elements should be self-explanatory. The optional element can be used to specify either a domain name (for CIFS), a database or schema (for database authentication), or an authentication realm (for HTTP).

The following type attribute values can be used for with a check:

  • "IBM AS400 PortMapper"
  • "pcAnywhere-control"
  • "CIFS" (optional specifies Windows domain name)
  • "DB2" ( specifies database name, e.g. SAMPLE)
  • "FTP"
  • "HTTP"
  • "MySQL" ( specifies database name, e.g. mysql)
  • "Novell Netware"
  • "Oracle" ( specifies database name)
  • "Postgres" ( specifies database name, e.g. template1)
  • "Remote Execution" (rexec i.e. port 512/tcp)
  • "SNMP" (specify only the element which will be the SNMP community name, e.g. private)
  • "SSH"
  • "TDS" (Microsoft SQL Server, specifies database name, e.g. master)
  • "Sybase" ( specifies database name, e.g. master)
  • "Telnet"

cifs-default-password-administrator-password.vck (checks for Administrator/password on CIFS)

1
<VulnerabilityCheck id="CIFS-GENERIC-0002" scope="node">
2
<NetworkService type="CIFS"/>
3
<DefaultAccount>
4
<uid>Administrator</uid>
5
<password>password</password>
6
</DefaultAccount>
7
</VulnerabilityCheck>

ssh-default-account-root-password-password.vck (checks for root/password on SSH)

1
<VulnerabilityCheck id="ssh-default-account-root-password-password" scope="endpoint">
2
<NetworkService type="SSH"/>
3
<DefaultAccount>
4
<uid>root</uid>
5
<password>password</password>
6
</DefaultAccount>
7
</VulnerabilityCheck>

telnet-default-account-root-password-password.vck (checks for root/password on Telnet)

1
<VulnerabilityCheck id="telnet-default-account-root-password-password" scope="endpoint">
2
<NetworkService type="Telnet"/>
3
<DefaultAccount>
4
<uid>root</uid>
5
<password>password</password>
6
<realm></realm>
7
</DefaultAccount>
8
</VulnerabilityCheck>

mysql-default-account-admin-nopassword.vck (checks for admin with no password on MySQL)

1
<VulnerabilityCheck id="mysql-default-account-admin-nopassword" scope="endpoint">
2
<NetworkService type="MySQL"/>
3
<DefaultAccount>
4
<uid>admin</uid>
5
<password></password>
6
<realm>mysql</realm>
7
</DefaultAccount>
8
</VulnerabilityCheck>

Operating System fingerprint checks

1
<System>
2
<OS minCertainty="1.0" name="Windows NT Server" vendor="Microsoft">
3
<version>
4
<value>4.0 SP5</value>
5
</version>
6
<version>
7
<value>4.0 SP6a</value>
8
</version>
9
<version>
10
<value>4.0 SP4</value>
11
</version>
12
</OS>
13
</System>

Denial-of-service checks

Sometimes you want to do an unsafe check, for example a denial-of-service. In this case, set the safe attribute of to "0". This will cause this check to be skipped unless the user explicitly enables unsafe checks in their scan template.

1
<VulnerabilityCheck id="http-jrun-long-url-bof" safe="0" scope="endpoint">
2
<NetworkService type="HTTP|HTTPS">
3
<Product name="JRun"/>
4
</NetworkService>
5
<HTTPCheck retries="3">
6
<HTTPRequest method="GET">
7
<URI>/<garbage length="5200">R7</garbage>.jsp</URI>
8
</HTTPRequest>
9
<HTTPResponse><thrownException class="java.io.IOException"/></HTTPResponse>
10
</HTTPCheck>
11
<TCPStatusCheck wait="2500" status="closed"/>
12
</VulnerabilityCheck>

Boolean expressions

Sometimes you may want to group a set of checks with or (or either in combination) to form complex boolean tests. For example:

1
VulnerabilityCheck id=”example-http-sensitive-data” scope=”endpoint”>
2
<NetworkService type=”HTTP|HTTPS”/>
3
<HTTPCheck>
4
<HTTPRequest method=”GET”><URI>/</URI>
5
<HTTPResponse code=”200”>
6
<or>
7
<regex>secret password</regex>
8
<regex>SSN: [0-9]{3}-[0-9]{2}-[0-9]{4}</regex>
9
</or>
10
</HTTPResponse>
11
</HTTPCheck>
12
</VulnerabilityCheck>