Qualys previously announced the introduction of Qualys Periscope in 2020.  This technology allows Qualys Web Application Scanning (WAS) to detect out-of-band vulnerabilities such as server-side request forgery (SSRF). Qualys Periscope provides confirmed detections for additional vulnerabilities, such as Log4j, where it enables rapid development and release of the QID. Occasionally, Qualys receives questions and support cases related to Qualys Periscope. This article will provide more detail on the common questions/situations seen with out-of-band detections. 

As of publishing, the vulnerability detections that utilize Qualys Periscope are:

• QID 150055 – OS Command Injection
• QID 150179 – Blind XXE injection
• QID 150255 – SMTP Header Injection
• QID 150258 – Server-Side Request Forgery (SSRF)
• QID 150267 – Oracle WebLogic Remote Code Execution Vulnerability (CVE-2019-2725)
• QID 150278 – DNN RCE Vulnerability (CVE-2017-9822)
• QID 150279 – Jira Server Side Request Forgery (SSRF) Vulnerability CVE-2019-8451)
• QID 150298 – SSRF to AWS Metadata Service
• QID 150307 – External Service Interaction via HTTP Header Injection
• QID 150339 – Oracle WebLogic Server Unauthenticated Remote Code Execution Vulnerability
• QID 150364 – Keycloak SSRF Vulnerability (CVE-2020-10770)
• QID 150426 – Adobe Experience Manager: SSRF via Salesforce Secret Servlet
• QID 150427 – Adobe Experience Manager: SSRF via Reporting Services Servlet
• QID 150428 – Adobe Experience Manager: SSRF via Site Catalyst Servlet
• QID 150429 – Adobe Experience Manager: SSRF via Auto Provisioning Servlet
• QID 150430 – Adobe Experience Manager: SSRF via Opensocial
• QID 150440 – Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell CVE-2021-44228)
• QID 150441 – Forms Vulnerable to Apache Log4j Remote Code Execution (RCE) Vulnerability (Log4Shell CVE-2021-44228)
• QID 150445 – Apache Solr SSRF Vulnerability (CVE-2021-27905)
• QID 150494 – Spring Cloud Function Remote Code Execution (RCE) Vulnerability (CVE-2022-22963)
• QID 150495 – Spring Core Remote Code Execution (RCE) Vulnerability CVE-2022-22965 (Spring4Shell)
• QID 150498 WordPress AnyComment Plugin: Arbitrary HyperComments Import/Revert via CSRF Vulnerability (CVE-2022-0134)
• QID 150503 – NodeJS Command Injection Vulnerability (CVE-2021-21315)
• QID 150504 – Apache Struts 2 Remote Code Execution Vulnerability (CVE-2021-31805)
• QID 150557 – Apache Spark Shell Command Injection Vulnerability (CVE-2022-33891)
• QID 150574 – Atlassian Bitbucket Server and Data Center – Command Injection Vulnerability (CVE-2022-3680

Functionality

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 scans the web app at “www.example.com”. Imagine this web app includes functionality to display an image that is retrieved from a specific 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 a domain of qualysperiscope.com mentioned in the payload.
   http://2a3b948a2b0a.1463985_40627.1466122137.ssrf01.ssrf.in03.qualysperiscope.com
3. Now, as a part of the 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, Qualys 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 Qualys Periscope along with the scan ID and a hash. Qualys Periscope again verifies the hash and serves the external request data corresponding to that scan ID (if present).
   The data received from Qualys Periscope is in JSON as below:
   { “lookup”: “A-record” “request”: “2a3b948a2b0a.1463985_40627.1466122137.ssrf01.ssrf.in03.qualysperiscope.com”, }
   
5. Web Application Scanning (WAS) processes the data received from Qualys Periscope, and reports the vulnerabilities corresponding to the payload which were successfully executed.

Request Source IP Address

Qualys WAS sends a unique URL for each vulnerability test. This allows a correlation between the injected value and the request received by Qualys Periscope. We can be sure which injection caused the external service interaction. What may be less clear is what system made that request to Qualys Periscope.

As the detection is executed against an application, the injection point is known. This is apparent from the QIDs:

Since unique dynamic URLs are used, the address must be resolved via DNS. Typically, the target application will not resolve the DNS itself. A DNS resolver will query through the DNS hierarchy to resolve the address. Therefore, the DNS request that comes to the Qualys Periscope server may be from a DNS resolver or other system that is not the target application/server. The numerous devices/software in a networked system can lead to any number of devices being the source of the DNS request. Proxies, reverse proxies, firewalls, web application firewalls, load balancers, host-based security software, etc., could all potentially issue the request, and we have observed cases where that has occurred. 

Potential “False Positives”

When a Qualys Periscope detection occurs during a CVE-based QID, you can be assured it is valid. However, there are times when the non-CVE detection could be false positives. Take a contact form on an application. This form takes a name and a message. If Qualys WAS injects the Periscope URL in the message body, most likely, the email will be sent. This email then hits an email security appliance that performs a reputation check on the URL. There is no history for the URL as it is dynamically created, so the service visits the URL to evaluate it. First, it must resolve the DNS address, which would result in the Qualys Periscope server receiving the request from the email security provider. A similar situation may occur if the request with Periscope URL results in an error. This error could be logged, and an email is sent to the application administrator. As the URL is now in an email, the email security system checks the URL and results in a hit to Qualys Periscope.

Potential False Negatives

Internal systems may not have Internet access which is required to reach our Qualys Periscope system. If a proxy is required, the injected URL cannot use that path. SSRF does not need to reach out to a network to cause issues. If an attacker has knowledge of the internal network, they could use SSRF to pivot/make requests to an internal server. 

Final Thoughts

Even when a different system makes the request, it is advised to mitigate the issue at the application level. Focus on the injection point in the scan report. Should this field, parameter, and header value accept untrusted URLs? Applications should not accept untrusted input. If you must accept URLs, whitelist the approved URLs.

Ultimately, the customer’s organization is better equipped to investigate false positives than Qualys support. Because unique URLs are utilized, Qualys can be confident the scan did trigger a system to make the DNS request. Application owners/developers and network engineers should know the inner workings of systems necessary to determine where the request originated. As Qualys Periscope is not available outside of scan, if additional testing or verification is needed, consider using interactsh available here, or the hosted version at app.interactsh.com. Once the vulnerability is addressed, rescan with Qualys WAS to close the detection.