Scanner signatures

Zirkul Agent automatically downloads vulnerability detection rules from the official server, however, the community can also help by creating their own rules and sharing them with other users.

In this section you will find the format used for creating passive or active scan rules as well as the steps needed for testing them.

Passive scan signatures

Passive scan refers to exploring a web site without sending any exploit, this is done by the spider included in the scanner which crawls all the locations found in the URL provided, for each URL discovered, the scanner will try to match the conditions defined in the passive scan rules then reporting the vulnerability if the conditions are met.

Here's an example:

{
	"name": "Missing Content Sniffing protection",
	"key": "content-sniff-protection",
	"type": "vulnerability",
	"severity": "medium",
	"cwe": 693,
	"owasp": "A05:2021",
	"cvss": 4.3,
	"cvss_string": "AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
	"cve": null,
	"details": "The server is not returning the following security header: X-Content-Type-Options",
	"technology": {"application": "Jenkins", "lang": "Java"},
	"rules": [
		{
			"in": "response header name",
			"header name": "x-content-type-options",
			"compare": "missing"
		},{
			"in": "response header value",
			"header name": "status",
			"compare": "contains",
			"value": "200"
		}
	]
}

Keywords definition:

name: This is the name of the vulnerability or object to be reported

key: This should be a unique identifier, using a duplicate key will produce an error.

details: Details explaining why this is a risk and the potential impact.

type: This is the object type from:

vulnerability: The reported object is a vulnerability.

waf: This will be used for Web Application Firewall detection

platform: The rule will be used for platform detection

severity: The severity assigned for vulnerabilities: Critical, High, Medium, Low, Info (For types waf and platform, the severity should be info)

cwe: (Optional) Common weakness enumeration from MITRE if applicable.

owasp: (Optional) OWASP Top 10 reference id if applicable.

cvss: (Optional) Common vulnerability scoring system (CVSS) numeric score if applicable, from 0 to 10.

cvss_string: (Optional) CVSS vector string with the factors for calculating the score from MITRE's calculator.

cve: (Optional) Common vulnerabilities and exposures id if applicable.

remediation: (Optional) Remediation guidance for fixing the vulnerability.

technology: (Optional) The signature would identify platform details if the conditions defined in rules are met, this can be used later for conditions defined in the rules or other signatures based on the technologies detected:

application server: (Optional) Application server identified with the value provided, examples: GlassFish, Tomcat, Flask, etc.

web server: (Optional) Web server identified with the value provided examples: IIS, NGinX, Apache, Websphere, etc.

lang: (Optional) Programming language identified with the value provided, examples: Java, Python, Ruby, .NET, etc.

application: (Optional) Application name identified with the value provided, examples: Jenkins, Wordpress, Drupal, Joomla, Jira, etc.

rules: The rules are the conditions for deciding if the detection is True or False, see rules section further in the page.

Active scan signatures

Active scan signatures are interactions with the target host or application, the interaction could be an exploit for known vulnerabilities or discovery of exposed assets or services.

Here's an example:

{
	"name": "Wordpress vulnerable to Distributed Denial of Service Attacks (DDoS)",
	"key": "active-wordpress-xml-rpc",
	"type": "vulnerability",
	"severity": "high",
	"details": "Wordpress functionality XML-RPC is enabled and exposed, this functionality can be used by threat actors for performing Distributed Denial of Service (DDoS) attacks against the vulnerable site.",
	"remediation": "Restrict the access to XML-RPC so it can only be used internally instead of exposing it to external users, this can be done with .htaccess rules if you're using Apache, access control configuration in NGinX or via rules in WAF configuration.",
	"technology": {"application server": "PHP", "application": "Wordpress", "lang": "PHP"},
	"active scan": {
		"type": "one issue",
		"trigger": [
			{
			"in": "technology",
			"compare": "contains",
			"value": "wordpress"
			}
		],
		"do": {
			"post": "{{current_dir}}/xmlrpc.php",
			"data": "<?xml version=\"1.0\" encoding=\"utf-8\"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>",
			"rules": [
				{
					"in": "response header value",
					"header name": "status",
					"compare": "contains",
					"value": "200"
				},
				{
					"in": "response body",
					"compare": "contains",
					"value": "<string>pingback.ping</string>"
				}
			]
		}
	}
}

Keywords definition:

Most of the keywords defined for passive scan signatures are also applicable here, the following are the ones only applicable for active scan signatures.

active scan: This object contains the pre-requirements for running the signature (trigger) and the conditions for validating the results (rules).

type: This is the way the signature should be applied: one issue: The scanner shall report just one issue of this type per scan, this is useful for avoiding duplicates if the same conditions are met in multiple locations during the scan. every request: The scanner will evaluate this signature for every URL detected by the spider.

trigger: The trigger contains the rules used for deciding if the signature should be executed or not, all conditions must be True. (see rules section for syntax reference)

do: This object contains the actions to be executed by the scanned if the trigger conditions are met. <http_method> : <url> # The request http method followed by the URL , examples: "get": "http://zirkul.com" "post": "http://zirkul.com" "put": "http://zirkul.com" "patch": "http://zirkul.com" "delete": "http://zirkul.com" data: (Optional) This is the payload used for the http methods: POST, PUT or PATCH headers: (Optional) HTTP headers to be included in the request in json format, example {"User-Agent": "My user agent"} rules: The rules are the conditions for deciding if the detection is True or False, see rules section further in the page.

Rule syntax

The "rules" are conditions evaluated for making decisions, the result is True only if all the conditions are met, otherwise the result is going to be False.

The object "rules" can contain one or a list of json objects, the following examples are both valid:

"rules": [
	{
	"in": "response header value",
	"header name": "status",
	"compare": "contains",
	"value": "200"
	},
	{
	"in": "response body",
	"compare": "contains",
	"value": "<string>pingback.ping</string>"
	}
]

"rules": {
	"in": "response header value",
	"header name": "status",
	"compare": "contains",
	"value": "200"
	}

Keywords definition:

Every rule has the following sections for defining:

• in: where is the value to be compared.

• header name: (Optional) If the "in" clause is based on a header value, you can define the specific header name here.

• compare: What kind of validation or comparison should be done.

• value: (Optional) The value to compare based on the "compare" clause.

in (Required)

Defines where is the value to be used, here are the allowed values:

response header name

Compare something in the response header name, the additional header name clause is required for defining the name of the header.

Example:

{
"in": "response header name",
"header name": "x-powered-by",
"compare": "exists"
}

response header value

Compare something in the response header value, the additional header name clause is required for defining the name of the header.

Example:

{
"in": "response header value",
"header name": "server",
"compare": "contain numbers"
}

response body

Compare something in the response body value.

Example:

{
"in": "response body",
"compare": "contains",
"value": "<address>Apache"
}

request header name

Compare something in the request header name.

Example:

request header value

Compare something in the request header value.

Example:

request data

Compare something in the request data for POST, PUT or PATCH methods.

Example:

request method

Compare something in the request http method value. Methods or verbs such as get, post, head, put, patch, delete, etc.

Example:

url

Compare something in the url. Keep in mind the rules can be tested against all URLs crawled by the spider or manually provided in the scope before running the scan.

Example:

{
"in": "url",
"compare": "contains",
"value": "jsessionid"
}

technology

Compare something in the technology labels identified for the current scan based on other signatures for platform detection or the built-in fingerprinting functionality. This is useful for restricting signatures that should be only tested against confirmed platforms and avoid false positives.

Example:

{
"in": "technology",
"compare": "contains",
"value": "wordpress"
}

header name (Optional)

This is only required if "in" is "response header name" or "response header value". The expected value is the header name to be analyzed, for comparing against the response status code you can use the reserved keyword "status".

Example:

{
"in": "response header value",
"header name": "status",
"compare": "contains",
"value": "200"
}

compare (Required)

This is how the values are going to be compared, the allowed keywords are:

• contains : If the value analyzed contains a value provided (case insensitive)

• not contains : If the value analyzed do not contains a value provided (case insensitive)

• exists : If the value analyzed exists.

• not exists : If the value analyzed does not exist.

• is : If the value analyzed is equal to the value provided (case insensitive)

• is not : If the value analyzed is not equal to the value provided (case insensitive)

• is numeric : If the value analyzed is a number.

• contain numbers : If the value analyzed contains any number.

• missing : If the value provided is missing in the value analyzed (case insensitive)

https_only (Optional)

Specify if the signature is only applicable to https requests.

Example:

{
"name": "Strict Transport Security header not configured",
"key": "hsts",
"type": "vulnerability",
"severity": "medium",
"cwe": 693,
"owasp": "A05:2021",
"cvss": 4.3,
"cvss_string": "AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"cve": null,
"details": "The server is not returning the following security header: Strict-Transport-Security",
"in": "response header name",
"header name": "strict-transport-security",
"compare": "missing",
"https_only": true
}