- 1. Asset discovery
- 2. Vulnerability discovery
- 3. Vulnerability exploitation
- 4. Report resolution
- 5. Lessons learned
This bug was reported in a private program in which it is not allowed to publish the vulnerabilities found. So this is a partial disclosure, only the essential technical details are exposed.
1. Asset discovery
I found this asset through amass + httpx. If you are looking for http services on subdomains of the domain example.com and you have your config file in the path /home/user/.config/amass/config.ini, you can use the following command
amass enum -brute -d example.com '/home/user/.config/amass/config.ini' | httpx -title -tech-detect -status-code -ip -p 66,80,81,443,445,457,1080,1100,1241,1352,1433,1434,1521,1944,2301,3000,3128,3306,4000,4001,4002,4100,5000,5432,5800,5801,5802,6082,6346,6347,7001,7002,8080,8443,8888,30821
Amass is an OSINT tool to perform network mapping of attack surfaces and external asset discovery which is a very famous tool used in the recon step in bug bounty. The output of the above amass command is a list of subdomains of the given domain, i.e, a list of potential targets.
Httpx is a multi-purpose HTTP toolkit allow to run multiple probers. In this case, the input of httpx is a list of subdomains and the output is a list of subdomains that have an http service in any of the ports given as a parameter. Also it shows some additional information about the service such as the title, the detected technologies… that I have specified in the parameters to be displayed.
This domain is one of the most important domains of the company in question, so it could also be obtained by googling the name of the company without the need to use any specific subdomain discovery tool.
2. Vulnerability discovery
I found this vulnerability through gau + kxss. If you are looking for XSS in the subdomain www.example.com, you can use the following command
gau www.example.com | kxss
Gau is a tool used to fetch known URLs from AlienVault’s Open Threat Exchange, the Wayback Machine, Common Crawl, and URLScan for any given domain. This tool does not always find all the URLs of a domain but it is a good starting point to search XSS or other types of vulnerabilities.
Kxss is a tool used to find all the “problematic characters” that are reflected in the response of any URL given as a parameter. The reflection of some problematic characters does not mean that an XSS exists but it is an indication that it could exist.
Both tools are based in other tools of tomnomnom.
In this case I got an output like the following
where the blue color is obfuscating unimportant findings and the red color is obfuscating the XSS candidate URLs.
As you can see, there are 2 parameters that reflect all the dangerous characters: utm_campaign and utm_source. Both parameters belong to the same URL and in fact in the URL there were more UTM parameters in the same situation. It is not the first time I find an XSS in this type of parameters so it is always worth taking a look at them.
3. Vulnerability exploitation
3.1. Steps of exploitation
Although there are several UTM parameters that may be vulnerable to XSS, I am going to focus on the utm_source parameter. I have seen that the utm_source parameter reflects all the dangerous characters but it’s important to see where the parameter is reflected in the response, that is, the context of the XSS. Why is this important? Because it’s essential to build a customized payload.
By sending the payload HackCommander through the utm_source parameter I got the following response
- ” to close the string.
- } to close the dictionary.
- ) to close the call to the push method.
I got the following response
So far so good! Then I tried to send the following payload
and I got the following response
In spite of this, I received the following response
DAMN! It doesn’t work. So… I had to follow another strategy.
After taking a look at all the proposed payloads, I thought that the seventh method discovered might fit my needs. Therefore I sent the following payload
and I received the following response
The payload is completely reflected! Redirection bypassed!
After that, clicking in the option Show response in browser I got the following response
with an empty alert. After clicking OK I got the following response
with the alert(1). I am not sure why the empty alert appeared but the important fact is that the alert(1) was executed.
This is why it is important to keep up to date in the cybersecurity field and read all the researching articles.
3.2. Why does the payload work?
It is not the purpose of this section to explain the meaning of the payload as this can be seen in the PortSwigger link above. What this section is intended to explain is… Why did this payload bypass the 302 Security Redirect? It is impossible to know for sure the answer to this question without having the source code but here is my theory.
If you remember, in the previous section, the following payload
returned a 302 Security Redirect.
But… What is the origin of this redirection? The alert string? The brackets? The combination of both?. The following payload
is the same as the previous one but changing the alert string to the HackCommander string, and I got the following response
so… the problem was the alert string? To solve this question I sent the following payload
and I got the following response
so the problem was not the alert string. As you can see the problem was combination of the alert string plus the input argument.
alert prompt ...
So the following payload
probably bypass the redirection because the string call is not in the blacklist.
4. Report resolution
As I said before, the affected domain was one the most important domains of the company so the asset criticity was classified as high. In fact at the time I reported this vulnerability there was a 3X reward multiplier on any vulnerability reported in certain domains of the company, including this one. Also an XSS usually is considered a medium severity vulnerability and because I wasn’t able to sign up and log in the website, I couldn’t demonstrate a high impact such as session hijacking. Therefore, the report was classified as
- Asset criticity: High
- Vulnerability severity: Medium
- Bounty: More than $600 (because of the 3X reward multiplier)
5. Lessons learned
- Scan all the company’s domains, do not stop looking for vulnerabilities in a domain because it is well known and you think that all the vulnerabilities are already reported. In this case I discovered an XSS in a well known domain of the company because the XSS was not obvious, it required a bypass, which although it was simple no one had discovered before. So… be humble with your colleagues but be confident, it is fundamental if you want to dedicate yourself seriously to bug bounty.
- Be aware of the multipliers applied to the programs in which you participate. These multipliers can turn a low hanging fruit into a big banana .
- It’s important to keep up to date in the cybersecurity field and read all the researching articles. Today’s discoveries can invalidate yesterday’s security measures.