Introducing Periscope: Out-of-Band Vulnerability Detection Mechanism in Qualys WAS

Dave Ferguson

Last updated on: December 21, 2022

Web applications and REST APIs can be susceptible to a certain class of vulnerabilities that can’t be detected by a traditional HTTP request-response interaction.  These out-of-band vulnerabilities are challenging to find but provide a way for attackers to target otherwise inaccessible, internal systems.  An attacker can potentially use this to their advantage.

An example from 2019 was a much-publicized data breach against a large U.S. bank, where a key component to the attack was exploitation of a server-side request forgery (SSRF) vulnerability. With SSRF, a vulnerable application (or API) is essentially used as a proxy for an attack against an internal application, a cloud service, or other protected system.  The vulnerable application incorporates attacker-supplied data in a request or message that’s sent to an internal/protected system. The request or message is assumed to be safe since it comes from a trusted source.

An external sensor is a useful technique for dynamic scanners to identify these types of out-of-band vulnerabilities.  An external sensor serves as a way to capture information sent by a vulnerable application upon successful execution of the scanner’s payload.  This technique is sometimes called out-of-band application security testing or OAST.

What is Qualys Periscope?

Qualys Web Application Scanning (WAS) is our leading dynamic application security testing (DAST) product.  Periscope is a new out-of-band vulnerability detection mechanism within Qualys WAS.  With Periscope, an external sensor captures and processes DNS lookup requests generated by a vulnerable application or API, thereby allowing WAS to detect and report on a new class of vulnerabilities.

As of August 2020, the vulnerabilities detected with Periscope are:

  1. QID 150179 – Blind XXE injection
  2. QID 150255 – SMTP Header Injection
  3. QID 150258 – Server-Side Request Forgery (SSRF)
  4. QID 150267 – an RCE vulnerability in Oracle WebLogic (CVE-2019-2725)
  5. QID 150279 – an SSRF vulnerability in Atlassian Jira (CVE-2019-8451)
  6. QID 150307 – SSRF via host header injection

These new QIDs are enabled by default as part of the core detection scope in WAS. In the future, we expect to add more vulnerability detections that leverage this external sensor approach.

How does Qualys Periscope work?

Periscope includes an external sensor that captures DNS lookup requests generated by a vulnerable application. A scanned web application with a vulnerability will execute the payload sent by the scanner for a specific vulnerability type. The payload execution triggers an external DNS lookup request, where the source of the request is the application itself. Qualys Periscope comes into play by capturing and analyzing this incoming DNS request. Its job is to decompose the data embedded in the request to understand which type of vulnerability was identified, which scan triggered the request, and the specific URL and parameter that served as the injection point. Furthermore, it sends the relevant information about the vulnerability to WAS which subsequently reports the appropriate QID.

The detection mechanism consists of the following steps:

  1. When Qualys WAS scans a web application for out-of-band vulnerabilities, it fuzzes/injects the fields with specially-crafted payloads. Different payloads are used for different vulnerability types. In this example, WAS is scanning the web app at “www.example.com”. Imagine this web app includes functionality to display an image that is retrieved from a certain URL. To test for SSRF, a request similar to the one below would be sent by the scanner. Here we see the field being fuzzed is the “url” query string parameter and the specific payload is for SSRF.
    https://www.example.com/loadImage?url=http%3A%2F%2F2a3b948a2b0a.1463985_40627.1466122137.ssrf01.ssrf.in03.qualysperiscope.com

  2. If the scanned web application is vulnerable, it tries to make the following HTTP request but first must resolve the FQDN having domain of qualysperiscope.com mentioned in the payload.
     
    http://2a3b948a2b0a.1463985_40627.1466122137.ssrf01.ssrf.in03.qualysperiscope.com

  3. Now as a part of DNS resolution process, the request will hit Qualys Periscope’s DNS service. The DNS service initially processes the request to verify the hash embedded in the request is valid. This ensures the lookup request is genuine and was generated from a WAS scan. Once everything is verified, Periscope logs the request internally. If verification fails, the request is simply dropped.
  4. Subsequently, Qualys WAS will ask for the lookup request data from Periscope along with the scan ID and a hash. Periscope again verifies the hash and serves the external request data corresponding to that scan ID (if present).
    The data received from Periscope is in JSON as below:
    { "lookup": "A-record" "request": "2a3b948a2b0a.1463985_40627.1466122137.ssrf01.ssrf.in03.qualysperiscope.com", }
  5. WAS processes the data received from Qualys Periscope, and reports the vulnerabilities corresponding to the payload which were successfully executed.

New Insight to Reduce Risk

With the new Periscope detection mechanism in Qualys WAS, organizations have an OAST technique and gain deeper insight into their web application vulnerabilities. This new information can then be used to drive remediation efforts to decrease attack surface and reduce risk.

Availability

At this time, Periscope-based vulnerability detections are available on the following Qualys platforms:

  • EU1, EU2
  • US1, US2, US3
  • IN1 (India)

If you have a Qualys login, but aren’t sure which platform your organization is using, please refer to Identify your Qualys platform.

Share your Comments

Comments

Your email address will not be published. Required fields are marked *