For the %90 of my working time, I am hunting bugs on the Synack for 2 reasons:
- Fast triage/payout times: No matter what the deal is, after you submit a bug, if it is accepted, you got the money on your account within 1 week at maximum. While better cases/examples exist on different bug bounty programs, most of them have inconsistent triage and bounty payout times. In Synack, the reports are evaluated within the week at most and the money is transferred to your account within 1–2 business day after cashout request, which is a really essential thing for a full time bug bounty hunter.
- Vulnerability analytics: Synack has a perfect feature which shows accepted vulnerability types/categories in an analytics section they have on the all different targets. For the ones who are not in SRT & do not know that, it is like this:
While this section is created for avoiding the duplicate reports (Which both decreases of the workload of triage team & bug hunters), it also works for a perfect reconnaissance area with:
- Enumerating endpoints/applications/subdomains of a target
- Knowing what kind of vulnerabilities and weaknesses the applications have in scope
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 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:
- If the SSRF’s were existed on a specific endpoint such as
/vulnerable.php, the analytics should have the URL’s for these ashttps://IP-Address/vulnerable.phpinstead of just having the IP addresses and ports. - Since it does not have any endpoints on it, it should be a general issue causing the SSRF vulnerability.
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:
So that was it! The vulnerability existing on the analytics as SSRF was a Open Proxy issue which was causing a 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:
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:
- Opened the analytics section again and identified all domains in scope
- Searched subdomains of them at VirusTotal and crt.sh within the help of my scripts
- Identified which subdomains are in-scope within the IP ranges supplied and which are not
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 same IP address are also vulnerable, which the IP does not exist on the vulnerability analytics section and go unnoticed!
I sent the request for localhost and it responded for the test page in index directory as:
Scanning for internal ports returned success:
And trying to access internal hostnames/IP addresses enumerated from other parts of applications returned internal management systems!
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 adding 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 notices 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 seems 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:
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 seperator as:
Which returned 2 different responses at the end of the attack. Quick check within same payload revealed that these parameters are also vulnerable but not reported yet!
While additional parameters pays only %10 of the original report and really have low payout on normal circumstances, since this one got bonus on it, it actually paid more than the original report which have %100 payout! At the end, this report paid $600 in total, within just a single intruder attack, inspired from vulnerability analytics.
#Example 3 — Access Violation Issues Found Thanks to Changed Privileges
On the long-term projects, sometimes the test accounts’ privileges are changing 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 the all internal web applications that customer have 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 does 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 vulnerability analytics section, I found out that there are only a few report 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 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 in here was, 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 URL’s 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 privilege error, we starting reporting the issues. At the end of the day, we found nearly 4–5 different applications vulnerable within this technique.
I got:
- 1 authentication bypass report worth around $700 + $1k additional bonus.
- 1 SQL injection report which I found after bypassed the authorization on the prior application, worth around $4k + 1k additional bonus.
My friends got:
- 2 authentication bypass reports worth around $700 + $1k additional bonus multiplied by 2.
- 2 access violation report worth around $400 without bonuses due to submitted instantly afterwards its ending time.
Which we got nearly $10k total within one day 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 on 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.
