Three Non Web-based XSS Injections

Sec Testers: Let's Be Creative
Three Non Web-based XSS Injections

Alejandro Hernández (@nitr0usmx)

Disclaimer: this article is not about voodoo XSS or any evasion technique. Just a bit of fun with XSS.


A few days ago brainstorming with my friend Chris Navarrete, I recalled why I choose this career:

We enjoy make things work in a different way than their original purpose. Like when exploiting a buffer overflow to change the direction of the execution flow. Like injecting JavaScript code where it’s not supposed to be.

Most tutorials and courses on web security taught us to test Cross-site Scripting vulnerabilities in a very simplistic manner: data input sent in a web request being reflected or stored unsanitized leads to a reflected or stored XSS. Period.

When it comes to general application security, we all know that sacred commandment of “never trust any data input”; unfortunately not all the developers have a clear understanding of what “any data input” truly means.

 

PowerDNS Recursor

During our talk, Chris mentioned that he found an uncommon XSS in a popular DNS software, so I decided to start with it to emphasize the point that web is not always the only attack vector.

PowerDNS Recursor is a high-end, high-performance resolving name server that powers the DNS resolution of at least a hundred million subscribers. Recursor is one of two name server products whose primary goal is to act as resolving DNS server.

A detailed walkthrough explains how it was possible to inject a XSS payload through a DNS query using the command-line tool dig:

Which in turn is rendered in the web UI:

Symantec SSL Toolbox
This is an already fixed vulnerability I found and reported three years ago in the Symantec’s SSL Certificate Tester. This free online service used to extract and display values from the x509 SSL certificate of a URL given, trusting in its contents, without sanitizing the data in the fields.

Hence, I created an SSL cert with the value “<script>alert(document.cookie);</script>” in different fields and installed it in front of a web server:

The result of analyzing such certificate is the JavaScript code being executed:

RATS (Rough Auditing Tool for Security)
Developed by the CERN Computer Security Department, RATS is a pretty good tool for static code analysis. I like it and been using it for years. Nevertheless, the last version dates from Dec 2013 and is probably unmaintained nowadays, not sure though.

Last year I was bored in a train and found this useless XSS. RATS receives a folder containing the source code and creates an HTML report with the results, which also includes the name of the files analyzed, hence the attack vector is quite obvious. I created a file with JavaScript code in its name:

After the analysis, the injected JavaScript is rendered in the report:

If I were a developer and my code had to be audited in my repos, I would definitely troll the auditors by creating an entry with some code in the filename.

 

Takeaways

• Data inputs not always come in HTTP requests.
• Think of all the possible data inputs, all of them, from the file system, to databases, usernames, timestamps, logs, practically anything.
• Developers, do not trust any data input, sanitize all the received values before using them in the backend or send back to the users.

Thanks for reading,
Alejandro
@nitr0usmx