Weaponizing BURP to work as an evil SSRF Confluence Server.

I was doing bounty on a private H1 program that interacts with various external services one of them was Atlassian Confluence and Jira.

As you know, you can run Atlassian on their cloud service at Atlassian.net, or in your own server. The Web application provided an input box to the URL and another input to the token to auth.

I created a Confluence wiki at atlassian.net, created a wiki page, wrote a few strings and added attachments, connected to this application, and the application downloaded completely the wiki page with their attachments on separate files.

What if I try to emulate an Atlassian server and manage to serve a 302 redirect at the time of serving the wiki attachments?

Let’s make a try,

The first thing that I did, was to open 8081 port to my router, and set up Burp to forward all the traffic to Atlassian IP so I redirected my HTTP traffic to HTTPS Atlassian IP like this:

The first MUST rule to add to search and replace is changing Host: MYOWNIP to Host: testwiki.atlassian.net. Otherwise, the Atlassian server will don’t know how to forward my traffic because that hostname with my IP is not on their WebServer config.

I tried the application on the testing app and It worked, the first HTTP request was forwarded, but all the next requests was going back to testwiki.atlassian.net.
I had to add a second match and replace this time in the Response Body, to find all https://testwiki.atlassian.net and change them to http://MYIP:8081.

After those 2 “match and replace” rules, on HTTP Proxy I could sniff and see all the HTTP Requests between the App and the Confluence server, so I waited for the app to try to synch attachments

And the HTTP Request was like this:

GET /wiki/download/attachments/229377/mobile_login_screen.png?version=1&modificationDate=1575987229920&cacheVersion=1&api=v2 HTTP/1.1
Host: testwiki.atlassian.net

With Response:

HTTP/1.1 302 Found 
Server: AtlassianProxy/1.15.8.1
Cache-Control: private, max-age=2880 
Content-Type: text/html;charset=UTF-8 
Strict-Transport-Security: max-age=315360000; includeSubDomains; preload 
Date: Tue, 10 Dec 2019 14:47:32 GMT 
ATL-TraceId: 8b71903514af8688 
Location: https://api.media.atlassian.com/file/56a6cf71-cb37-473d-ba1b-9d5fbab9f2d3/binary?token=eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiI2Y2M5MmM2YS0xMzc5LTQ0ZmEtODJjMy02OTM3N2ZlMmEyZDciLCJhY2Nlc3MiOnsidXJuOmZpbGVzdG9yZTpmaWxlOjU2YTZjZjcxLWNiMzctNDczZC1iYTFiLTlkNWZiYWI5ZjJkMyI6WyJyZWFkIl19LCJleHAiOjE1NzYwNzIxNzIsIm5iZiI6MTU3NTk4OTE5Mn0.PMUm-azK6W-pxtssU_acN6Ut4ZZRXWJGxsE17m1JAfk&client=6cc92c6a-1379-44fa-82c3-69377fe2a2d7&name=mobile_login_screen.png&max-age=2940

And you can see the Location redirect to api.media.atlassian.com, that’s AWESOME.

A simple match/replace rule with regex, a test and finally:

HTTP Proxy showed up the original response and the modified with match/replace one.

And now all the attachments were 205 bytes with the access token inside of them. YEAH!

Burp helped me a lot on this one, otherwise, I would have to set up an HTTP Proxy with logs to sniff al the traffic, emulate each JSON request with PHP, Python or whatever scripting software you feel comfortable.
This method from start to end took me about an hour, but coding myself a proxy script and emulate all could have taken me a whole day. Thumbs up to Burp to be a bounty hunting tool and a proxy weapon sometimes too! That license worth every penny.

H1 Profile: https://hackerone.com/edduu
Twitter: https://twitter.com/MasterSEC_AR