Writing vulnerability checks

This is a tutorial on developing custom vulnerability checks in the Security Console.

For more information, see: Vulnerability Check Examples and Converting a NASL check.

The Security Console includes a framework for creating complex vulnerability checks using a simple XML format. Vulnerability checks are split across two or more files which are parsed by the Security Console when the scan engine is started.

There are 2 types of XML files that make up a vulnerability check:

  • Vulnerability descriptor - A file ending in the .xml extension which contains information about a specific vulnerability (title, description, severity, CVE IDs, CVSS score, etc.).
  • Vulnerability check - A file ending in the .vck extension containing multiple tests, which are compiled at runtime and used by the Security Console to verify the existence (or non-existence) of the vulnerability described in the descriptor.

One vulnerability can have multiple different types of checks (vck's) associated with it.

Creating your first vulnerability check

In this article, we're reimplementing a simple vulnerability check from Nikto, because it's an open source tool that many people will be familiar with. The most recent check added to Nikto is for a WordPress version information leak. Let's do the same check in the Security Console so you can see the difference in approach.

The Nikto check is written as:

1
"006184","0","3","/wp-links-opml.php","GET","generator=\"WordPress/","","","","","This WordPress script reveals the installed version.","",""

In this check, 006184 is the Nikto vulnerability ID, /wp-links-opml.php is the URL path to request, and generator="WordPress/ is the string to look for in the response that would indicate the presence of this vulnerability (the quote is escaped in the Nikto file format).

Now let's create a check for the same vulnerability in the Security Console -- you'll find that the format is more complex and takes a bit longer to write (although internally here at Rapid7 we have authoring tools to speed up the process).

Create a vulnerability descriptor (.xml) file

First we create the XML descriptor file. The file looks pretty complex, but it's actually fairly easy to explain. Create a file named cmty-http-wordpress-wplinks-opml-info-leak.xml, containing the following contents:

1
<?xml version='1.0' encoding='UTF-8'?>
2
<Vulnerability id="cmty-http-wordpress-wplinks-opml-info-leak" published="2007-05-26" added="2010-03-13" modified="2010-03-13" version="2.0">
3
<name>WordPress version information leak via wp-links-opml.php</name>
4
<Tags>
5
<tag>WordPress</tag>
6
<tag>Web</tag>
7
<tag>Community</tag>
8
</Tags>
9
<cvss>(AV:N/AC:L/Au:N/C:P/I:N/A:N)</cvss>
10
<AlternateIds>
11
<id name="URL">http://blogsecurity.net/wordpress/tools/wp-scanner</id>
12
</AlternateIds>
13
<Description>
14
<p>The version of the WordPress blog software can be leaked by a request to
15
a file named wp-links-opml.php. This page outputs link information in OPML
16
format. OPML is the
17
<a href="http://en.wikipedia.org/wiki/OPML">Outline Processor Markup Language</a>,
18
used to exchange information between blog and RSS aggregators.</p>
19
</Description>
20
<Solutions>
21
<Solution id="cmty-http-wordpress-disable-wplinks-opml" time="30m">
22
<summary>Disable access to the wp-links-opml.php page</summary>
23
<workaround>
24
<p>Evaluate whether OPML needs to be enabled for your blog. If not, disable access to the wp-links-opml.php page by either
25
deleting it or by using your web server's access control mechanism (for example .htaccess on Apache) to disable HTTP access
26
to this file.</p>
27
</workaround>
28
</Solution>
29
</Solutions>
30
</Vulnerability>

Let's explain the different parts of this file briefly.

  • The id attribute - Every vulnerability in the Security Console has a unique identifier. This ID distinguishes this vulnerability and is referred to by the corresponding vck files (described below). In this case, the vulnerability ID is "cmty-http-wordpress-wplinks-opml-info-leak". The "cmty" stands for "community". This prefix is used to keep this vulnerability from colliding with anything published by Rapid7. NOTE: The XML file must have the same base name as the ID. The vulnerability ID contains a unique series of up to 255 alphabetic characters, numbers, or hyphens (-).

  • The published attribute - Vulnerabilities may have a published date which describes the date when information about the vulnerability was first released. This attribute is optional, although it is highly recommended to include the attribute if the information for the vulnerability is available. In this case we have chosen 2007-05-26 as our published date because that's the earliest reference I could find for this particular information leak. This attribute may contain a valid date in the form of “YYYY-MM-DD”.

  • The added attribute - The descriptor may have an added date, which is used to note when it was first included in the Security Console. In this case, the added date is 2010-03-13, which is the date this tutorial was written.

  • The modified attribute - This describes when this XML file was last modified. NOTE: If you modify the XML file, you must modify the modified attribute otherwise the Security Console will not re-process this file. If you want the Security Console to re-import this data into its internal database, you must change the modified attribute every time you change this file.

  • The version attribute - This attribute refers to the version of the vulnerability descriptor file format. This should always be set to "2.0".

  • The element - The name element is the title of the vulnerability, as displayed in the vulnerability detail listing in the the Security Console UI and reports.

  • The element - This element stores the complete CVSSv2 vector which scores this vulnerability. See http://www.first.org/cvss/cvss-guide.html for more information about CVSS. NOTE: the Security Console automatically computes the CVSS base score from the vector.

  • The element - Tagging is used to categorize the vulnerability for purposes of category searching or customization of scan templates. I've given this vulnerability two tags: "Web" and "WordPress".

  • The element - This element is used to group several reference identifiers to the vulnerability descriptor. These typically include references to Secunia advisories, CVE IDs, and URLs. The Security Console will automatically generate the correct hyperlink in the UI and reports for most types of IDs based on built-in logic. Alternate IDs can take several forms including: *<id name="BID">8725</id> for a Bugtraq ID

    • <id name="CVE">CVE-2002-1850</id> for a CVE ID
  • The element - This element is used to provide useful information on the behavior of the vulnerability which is displayed in the vulnerability details page in the UI. This element supports a limited subset of "HTML" markup, including <a>, <p>, <ul>, <ol>, and <li> so that it can be parsed into an intermediate documentation format, and subsequently be transformed into (X)HTML, PDF, RTF, and plaintext formats.

  • The element - This element describes "How can I patch or remediate this vulnerability?". The solutions for a vulnerability are grouped under the solutions element and are either referenced by id (for out-of-file solutions) or constructed in the file itself (inline solutions). The reason for solution IDs is so that the Remediation Report can automatically figure out how to optimize the remediation steps (e.g. collapsing multiple vulnerabilities into a single common solution that remediates them all). I will skip over most of the logic on how solutions work. The time attribute refers to the estimated amount of time it would take to follow the steps listed in the solution. You can use "30m" to represent 30 minutes or "2h20m" to represent 2 hours and 20 minutes.

Create a vulnerability check (.vck) file

Now create a file named cmty-http-wordpress-wplinks-opml-info-leak.vck containing the following contents:

1
<VulnerabilityCheck id="cmty-http-wordpress-wplinks-opml-info-leak" scope="endpoint">
2
<NetworkService type="HTTP|HTTPS"/>
3
<HTTPCheck>
4
<HTTPRequest method="GET">
5
<URI>/wp-links-opml.php</URI>
6
</HTTPRequest>
7
<HTTPResponse code="200">
8
<regex>generator="WordPress/(.*)"</regex>
9
</HTTPResponse>
10
</HTTPCheck>
11
</VulnerabilityCheck>

Let's explain the different parts of this file.

  • The id attribute refers to the same ID used in the xml file. This tells the Security Console which vulnerability this check is checking for.
  • The scope attribute should be set to "endpoint" for service-specific vulnerabilities (vulns affecting a particular port or service) or "node" for system-wide vulnerabilities (vulns affecting the entire system). Web vulns endpoint-specific by definition, while an exploit of the TCP/IP stack would be for the entire node.
  • The element basically says "Fire this check against any port found to be running the HTTP or HTTPS protocol". Notice the use of the | (pipe) character to indicate HTTP or HTTPS.
  • This particular .vck uses the "" element to indicate a basic HTTP "send a request, match the response" type of check. may contain only one child element and one element. The element may contain one or more elements. If multiple elements are present, each URI will be requested in turn, looking for a match to the conditions.
  • The element says "Look for a response with an HTTP status code of 200 whose body matches the given regular expression".
  • The basically uses Perl 5 syntax, with some small differences. This is matched against the HTTP response body. See http://nlp.stanford.edu/nlp/javadoc/gnu-regexp-docs/syntax.html for a complete syntax reference. If you want to do case-insensitive matching, specify . Pattern matching occurs on a line-by-line basis -- if you want the regex to match across multiple lines, specify .

Deploying your vulnerability check

To deploy this vulnerability check, simply copy your .xml and corresponding .vck file into the following directory:

1
<nexpose-install-dir>/plugins/java/1/CustomScanner/1/

and run the console command "load content". Watch for errors on the console (look in nsc.log) when content is being reloaded. If you made any mistakes, the Security Console will log some error messages when it compiles the new vulnerabilities. If everything was successful, you should see something like the following message in the log:

1
2015-12-18T08:59:43 [INFO] Inserted 1 vulnerabilities.
2
...
3
2015-12-18T08:59:55 [INFO] Load Content command complete.

Browse to https://:3780/vulnerability/vuln-summary.jsp?vulnid=cmty-http-wordpress-wplinks -opml-info-leak. You should see the details of your new vulnerability. Review the information and correct any mistakes (don't forget to re-deploy the file to the Security Console directory after you've made changes).

Run a scan with your new vulnerability

Your new vulnerability will automatically be included in most default scan templates. Simply run a scan against a server that has this vulnerability and see whether it shows up. The Security Console should show any new affected assets under the vulnerability.html page URL described above (don't forget to refresh the page). If the system is vulnerable but your check is not being detected, try running a Vulnerability Report Card report (with detail level set to High) for the affected asset(s) to see why the Security Console did not find the vulnerability.

Common Vulnerability Check Examples

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

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

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>

php-ecalloc-integer-overflow.vck

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

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>