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 that you can create.

Service banner checks

The <NetworkService> 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 <Product> element indicates a fingerprinted product found running on that service. The <version> element checks for a range of product version numbers. Be aware that the <high> version number is exclusive -- in other words <high> 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

xml
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

This check tests for the existence of a vulnerability using a FTP banner version test:

xml
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

This check connects to an FTP server with any available credentials, executes a directory change command, and checks the result code and text:

xml
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

This example version check is meant for two different product editions in one check file.

xml
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 <Component> of a <Product>, such as PHP.

php-ecalloc-integer-overflow.vck

xml
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 your site configuration.

ActiveXControlInstalled

This check verifies the presence of an ActiveX control. The <ActiveXControlInstalled> 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 <ActiveXControlInstalled honorKillBit="0">.

ibm-access-support-activex-bof.vck

xml
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

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

xml
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 <WindowsRegistry> element is the top-level element of a Windows registry test. This element must contain at least one <registryKey> sub-element. No other elements are allowed.

The <registryKey> 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. Note that the mustNotBePresent attribute is worded in the negative. If mustNotBePresent="1", it means "fire this check if the key is present, otherwise return not vulnerable".

The <registryValue> element specifies the expected data assigned to a specific registry value. It contains three attributes: name, type, and default (described below).

• 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 the following. See http://msdn.microsoft.com/en-us/library/ms724884%28VS.85%29.aspx for more information on different value types.
  • 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
• 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 <registryKeyExists> and <registryValueExists> elements.

WindowsFileExists

The <fileExists> element is used to determine whether or not a file is available on a system. The trojan-gimmiv.vck example below shows how this kind of 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%

trojan-gimmiv.vck

xml
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>

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

This check looks for versions of a Windows .exe or .dll. <WindowsFileVersion> 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:

xml
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):

xml
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:

xml
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

This check looks for versions of installed software.

xml
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 and password checks work basically the same way. You have a <NetworkService> element with the type of service, followed by a <DefaultAccount> element. The <uid> and <password> elements should be self-explanatory. The optional <realm> 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 <NetworkService> with a <DefaultAccount> check:

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

cifs-default-password-administrator-password.vck

This check looks for the Administrator/password on CIFS:

xml
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**

This check looks for root/password on SSH:

xml
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**

This check looks for root/password on Telnet:

xml
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)

This check looks for an admin with no password on MySQL:

xml
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

xml
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, such as a denial-of-service check. In this case, set the safe attribute of <VulnerabilityCheck> to 0. This will cause this check to be skipped unless the user explicitly enables unsafe checks in their scan template.

xml
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 <and> or <or> (or either in combination) to form complex boolean tests. For example:

xml
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>