Out-of-Band Detections Using Qualys Periscope
2022-12-2 07:11:35 Author: blog.qualys.com(查看原文) 阅读量:32 收藏

Qualys WAS previously announced the introduction of Qualys Periscope, https://blog.qualys.com/product-tech/2020/01/15/introducing-periscope-out-of-band-vulnerability-detection-mechanism-in-qualys-was. This technology allows WAS to detect out-of-band vulnerabilities like server-side request forgery (SSRF). Periscope provides confirmed detections for additional vulnerabilities such as Log4j where it enabled rapid development and release of the QID. Occasionally, Qualys receives questions and support cases related to 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

If you are unsure if a QID uses Periscope, look in the “Threat” section of the QID and you will see “vulnerable servers will make a DNS query that will trigger Qualys Periscope detection mechanism.”

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.

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

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

QID 150557 - Apache Spark Shell Command Injection Vulnerability (CVE-2022-33891)

QID 150557 – Apache Spark Shell Command Injection Vulnerability (CVE-2022-33891)

QID 150258 – Server-Side Request Forgery (SSRF)

QID 150258 – Server-Side Request Forgery (SSRF)

Since unique dynamic URLs are used, the address needs to be resolved via DNS. Typically, the target application will not be resolving 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 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 would 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 and this would result in the 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 administrator of the application. As the URL is now in an email, the email security system checks the URL and result in a hit to Periscope.

Potential False Negatives

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

Even when a different system is making 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, 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 have the knowledge of the inner workings of systems necessary to determine where the request originated. As Periscope is not available outside of scan, if additional testing and verification is needed considering using interactsh available at https://github.com/projectdiscovery/interactsh or the hosted version at app.interactsh.com. Once the vulnerability i addressed, rescan with Qualys WAS to close the detection. 


文章来源: https://blog.qualys.com/product-tech/2022/12/01/out-of-band-detections-using-qualys-periscope
如有侵权请联系:admin#unsafe.sh