Multi Domain DOM Cross Site Scripting

2 minute read

General Description Of DOM XSS

DOM Cross Site Scripting is a XSS attack where the attack payload is being executed in the DOM environment which tends to execute in the victim’s browser which allows to run JavaScript code in an unintented manner. This kind of flaw is a result of an “attacker-controllable” source being passed to the sink that may support dynamic code execution.

For more information including labs and description regarding common DOM XSS flaws, I strongly recommend the following:

Background Behind The Flaw

A few months ago, while looking into my favorite program with wide scope on Synack Red Team, it came to my interest certain endpoints with html extension that have been reported as DOM-Based Cross site scripting. Therefore, I proceeded to check the endpoints with the purpose to replicate the vulnerability, with the possibility to exploit the flaw in several more subdomains belonging to the client. The flaw ended up being exploitable in 3 more subdomains that were sharing all together 12 vulnerable endpoints.

Reconnaissance

Note: Information regarding the client’s name and paths will not be fully disclosed in this write up due to vulnerability disclosure policy.

When identifying and replicating the vulnerable endpoint, it displayed a blank HTML page with the following source code.

picture

Therefore, we proceed to generate understanding of how the JavaScript code is being used where the following key points came to mind:

  • The function GetAttach() is being executed every time the user loads the web page due to <BODY onload='GetAttach()'> HTML tag containing the onload event.
  • The variable strSearch is controlled by the attacker which allows to inject code after a question mark (?), due to location.search property, which in this case works as an attacker controlled source from the URL.
  • Later, the value variable strSearch will be passed to document.location.replace which will trigger the XSS flaw every time the web page loads the web page, as strSearch variable is being controlled by the attacker from the URL, and it’s being passed to document.location.replace in the DOM.

To conclude, the variable strSearch will be the attacker controlled source from the URL due to location.search property and the sink will be document.location.replace as its using the strSearch variable which allows to inject JavaScript code in the DOM.

Then, create a Proof of Concept (PoC), the attacker proceeds to inject the payload javascript:alert(document.domain) after the querstion mark (?) which triggers the DOM XSS flaw effectively as:

  • http://sub.domain.ca/web/source/tutorial/fraud/play/flaw.html?javascript:alert(document.domain)

picture

Multi Path Exploitation

Once the flaw has been discovered and successfully exploited, it’s time to see what other paths are affected by the same flaw.

Therefore, it’s recommendable to fuzz common english words being gathered from english-words repository in order vulnerable paths that may contain the same flaw. This can be achieved by using ffuf as the following:

  • ffuf -c -v -w english-words.txt -u http://sub.domain.ca/web/source/tutorial/FUZZ/play/flaw.html -mc 200

After fuzzing english words in the vulnerable URL path the following were found:

  • http://sub.domain.ca/web/source/tutorial/fraud/play/flaw.html
  • http://sub.domain.ca/web/source/tutorial/password/play/flaw.html
  • http://sub.domain.ca/web/source/tutorial/identity/play/flaw.html
  • http://sub.domain.ca/web/source/tutorial/malware/play/flaw.html

picture

Multi Domain Exploitation

Once the vulnerable paths have been gathered, it’s time to see what other subdomains are being affected by the flaw. This can be achieved by having a list of alive subdomains and with the usage of httpx. Then, the following can be used in order to test which alive subdomains are being affected, remember to repeat this for every vulnearble path:

  • cat alive-subdomains.txt | httpx -path /tutorial/fraud/play/flaw.html -status-code -content-length -mc 200

After recognizing more vulnerable paths, 3 more subdomains were being affected with the same 4 vulnearble endpoints which ends up with a total of 12 vulnerable endpoints in total.

Then, after recognizing all 12 vulnerable endpoints, it was reliable to report the vulnerability which thankfully was accepted and awarded with a 6.1 CVSS score.

Conclusion

If you’re a Synack Red Teamer, the analytics section can be a good way to start understanding a target as Ozgur explained in his article “Using Vulnerability Analytics Feature Like a Boss by Ozgur Alp”. In case if you’re in other platforms, you can use CrowdStream or Hacktivity for public available programs.

Any feedback and future recommendations are always welcome :)

Thanks for making it to the end!

If you want to chat or just connect, feel free to shoot a direct message on Twitter.

Updated:

Leave a comment