Using Vulnerability Analytics Feature Like a Boss | Blog | Synack

For the %90 of my working time, I am hunting bugs on the Synack for 2 reasons:

Synack Vulnerability Analytics Section

While this section is created for avoiding the duplicate reports (Which both decreases the workload of the triage team & bug hunters), it also works for a perfect reconnaissance area with:

I will share different techniques that I use and several examples of the accepted vulnerabilities within only using this feature with you.

Example 1 — Accessing Internal Network Due to Improperly Configured Proxy Services

After returning from a holiday, I started to look at the targets activated on that period. I found a host target which has at least 10 IP addresses existing in the vulnerability analytics section within accepted category as SSRF as IP-Address:443 with all of them having SSL ports as vulnerable. I started to formulate the methodology as:

I browsed all of the vulnerable IP addresses from the web browser, while 9 of them returned “404 Not Found” error, one of them returned a similar error as “502 Proxy Error”, which made me think that the issue could be causing due to misconfigured open proxy servers.

I sent the main request to the Repeater directly and changed GET / HTTP/1.1 line with directly GET https://google.com HTTP/1.1 directly and got the result:

Finding open proxy vulnerability with Burp Repeater

So that was it! The vulnerability existing on the analytics as SSRF was an Open Proxy issue which was causing an SSRF vulnerability.

I copied & pasted all of the IP addresses in the scope to a text file, added both http:// and https:// strings before them one by one, pasted all of the URL’s to the Firefox’s Open Multiple URL’s extension and opened them while listening with Burp, with the below Match & Header rule:

Match & Replace rule for testing open proxy issues

Opened the Burp Search functionality, searched <title>Google</title> string on the in-scope items HTTP responses and found 10 results matching! Which were all of the reported IP’s existing on the analytics.

Ok, now how to proceed, could it be there more left without noticed/reported?

Thought that there could be virtual hosts & web applications existing pointing to an IP which is not reported yet but exploitable. For identifying these:

After enumerating the web applications in scope, I returned to the copy & paste section which I used for testing IP addresses and proceeded all over for the subdomains I found. After I used Burp Search again for the web applications, I saw that 4 different web applications which point to the same IP address are also vulnerable, which the IP does not exist on the vulnerability analytics section and goes unnoticed!

I sent the request for localhost and it responded for the test page in index directory as:

Accessing localhost:80 within exploiting open proxy SSRF

Scanning for internal ports returned success:

Burp intruder SSRF port scan

And trying to access internal hostnames/IP addresses enumerated from other parts of applications returned internal management systems!

Accessing internal Jenkins instance login page

Thanks to the vulnerability analytics section & the bug hunter which went unnoticed to look to the web applications in addition to IP addresses, I got approximately $1300 bounty from it!

Example 2 — Additional Parameters Sometimes Pay More

From time to time, researchers add full endpoints within parameters and payloads to the vulnerable location parts, instead of just adding the endpoints itself. If the triager of the report does not notice or changes it, the full exploitation URL becomes available on the analytics section.

One time when a target has a $500 Blitz (Means a bonus payout for the matched criteria reports on the Synack Language) on it for the +5.0 CVSS vulnerabilities, I found a full exploitation URL on the analytics for a Reflected XSS vulnerability which may match the CVSS criteria like this: https://subdomain.example.com/endpoint.aspx?t=%27-alert(document.domain)-%27&did=%27-alert(document.domain)-%27. After I visited the endpoint, I saw that it is still vulnerable to the XSS. I also noticed that the parameters seem meaningless and simple which was t and did on that case. So, what about to find additional parameters that could be vulnerable on this endpoint?

I send this request to the Burp Intruder, selected one parameter name as payload position like this:

Selection parameter name value as payload position

And brute-forced it from 1 to 3 character counted strings with the payload option as custom iterator and list as characters from a-z with empty separator as:

Brute-forcing parameter names for all of the combinations of letter characters

Which returned 2 different responses at the end of the attack. Quick check within the same payload revealed that these parameters are also vulnerable but not reported yet! While additional parameters pay only %10 of the original report and really have low payout on normal circumstances, since this one got a bonus on it, it actually paid more than the original report which had %100 payout! At the end, this report paid $600 in total, within just a single intruder attack, inspired by vulnerability analytics.

Example 3 — Access Violation Issues Found Thanks to Changed Privileges

On long-term projects, sometimes the test accounts’ privileges are changed without any notices or updates from the client. One target was existing again with a “Blitz” of $1k, which the target was active since I began work as SRT 3 years ago. The scope was full of the test environment of all internal web applications that the customer has and nearly unique 100 web applications exist on it.

I was mentoring 2 of my friends on that time when they were freshly started to both Synack platform and bug bounty world. After we started testing together, I noticed that all of the supplied test accounts do not have access to the nearly most of the application functionality at all. Since the target was very old, there were lots of different endpoints existing on the vulnerability analytics. After we checked the vulnerability analytics section, I found out that there are only a few reports existing regarding to the access/privacy violation issues. I searched all the URL’s for a specific web application which the test account was returning a response as “You are not privileged for this application” on the main page. I noticed that direct browsing (As forced browsing vulnerability) to the administrator URL’s which already exist on the vulnerability analytics within different reported vulnerabilities (such as reflected xss) was causing access/privacy violation problems!

The thing happening here was, the customer changed the test user accounts' privileges from administrator to low level, without letting Synack team know so there were no updates existing on the target about it. Since this application was tested within administrator users before and there were lots of URLs existing on the analytics which can be used to find these issues, we started to browse all of the reported URL’s on the analytics one by one. If any data returns from the accessed URL successfully and access to the main/root URL of the application returns a privilege error, we start reporting the issues. At the end of the day, we found nearly 4–5 different applications vulnerable within this technique.

I got:

My friends got:

Which we got nearly $10k total within one day's work, thanks to changed account privileges and vulnerability analytics!

Last Words

Using vulnerability analytics feature as a reconnaissance tool for different issues sometimes pay more than the actual reports. I am always a really fan of creative works constituted by the community & trying to contribute to that within original techniques, however sometimes this kind of easy findings/earnings really helps for the motivation in the long term, with this kind of little tricks used.

Hope you enjoyed the post and wishing you & your loved ones all the best especially about recent COVID-19 cases.

– Ozgur Alp

(Originally published at: https://medium.com/bugbountywriteup/using-vulnerability-analytics-feature-like-a-boss-655fc1f1543b, reprinted with permission.)