Bypass of Wildcard Allowlist which leads to Full SSRF

Disclosed by
Sim4n6
  • Engagement Atlassian
  • Disclosed date 8 months ago
  • Points 5
  • Priority P4 Bugcrowd's VRT priority rating
  • Status Resolved This vulnerability has been accepted and fixed
Summary by Atlassian

Server-side Request Forgery Vulnerability in Jira 8.20.6

Summary by Sim4n6

Interesting old one

Report details

  • Submitted

  • Target Location

    Jira Software Data Center

  • Target category

    Web App

  • VRT

    Broken Access Control (BAC) > Server-Side Request Forgery (SSRF) > Internal High Impact

  • Priority

    P4
  • Bug URL
    Empty
  • Description

    Hi Atlassian team,

    While doing testing on a different bug bounty program, they were hosting a Jira data version "8.20.6". During the task, I found a Full SSRF through the endpoint "/plugins/servlet/gadgets/makeRequest". This SSRF permits requests using any HTTP methods, with any custom headers, to any internal endpoint with the next specified conditions.

    The allowlist used in Jira is:

    • Type: wildcard expression.
    • Expression used: https://*.sim4n6.club
    • Allow incoming, allow anonymous users.

    According to the official documentation, this suggests:

    Allows all matching URLs. Use the wildcard * character to replace one or more characters.

    This means that an allowlist for https://*.sim4n6.club would permit only sim4n6.club subdomains through the secure HTTPS. However, it is not the case, since HTTP requests were made to any external/internal domain in an URL crafted as follows https://anydomain.com?www.sim4n6.club or even https://anydomain.com?r=www.sim4n6.club.

    It seems that such crafted URLs bypass the allowlist parsing in a way that respects the wildcard expression, but the domain it points to is different from the one a user intended. The string "sim4n6.club" could be used in a path or a query. Thus, the attacker could induce the server-side into performing requests (SSRF) and getting the response with the headers.

    To illustrate the bug, I made a couple of screenshots. As you can see in the first screenshot. The request to the OAST catcher was 403 forbidden.

    1.png

    The request to the URL similar to https://xxxxxxxxxx.oastify.com?r=www.sim4n6.club was 200 OK while retrieving the response body and headers.

    2.png

    3.png

    Please, consider my bug report because it may be a bypass for CVE-2019-8451. A confluence product is concerned too.

Activity