XSS, Command and SQL Injection vectors: Beyond the Form
This article is less of a "how to" and more of an inspiration piece. I wanted to kick start your brain into thinking about alternate ways of exploiting a system, especially when it comes to the sanitation of input. We are all used to the idea of injecting an XSS, SQL or a command string into a web form, but what about other vectors for injection? Part of this article is inspired by this XKCD strip:
This strip helped to kick start my brain into thinking about alternate ways people can pull off injection attacks. Also, I've noticed a lot of log analysis/scanning software that generate reports in HTML format, either saving it as a local file or directly to a web front-end. HTML is just such an easy, pretty and accessible way for a programmer to display reports from their software (I know I've used it a lot in my tools). While this won't be a comprehensive list by any means, it should give you some ideas of where to look for exotic injection vectors. I'm mostly going to be talking about using these vectors for XSS (Cross Site Scripting), but the same techniques may be useful for SQL and command injection with a little more work. Many folks just mention the canonical "<script>alert("XSS");</script>" when they show off XSS, but unfortunately this give many the false idea that Cross Site Scripting is only good for defacing a website. For ideas of something more interesting to inject than the tired "<script>alert("XSS");</script>" take a look at the following thread I started on the PaulDotCom mailing list:
http://mail.pauldotcom.com/pipermail/pauldotcom/2009-May/001620.html
What I want to put in your mind is the idea that all you really need for XSS is the ability to submit unsanitized data that is rendered in a script enabled viewer. For other types in injection, like SQL or command, you don't even need that, but you will need a greater understanding of the backend that will be parsing the input. If you come up with other ideas, by all means please email me.
User Agent String (and other things in the header)
The mantra of "never trust the client" has been drilled into our heads over and over again. Competent web developers are well aware that user submitted forms need to be sanitized, but there are some things that the client sends to a web server that the developer rarely thinks about: for example, the User Agent string your browser sends to the web server every time it makes a connection. I've written before about changing your User Agent string, but what if you changed your User Agent to have the string "<script>window.location = "http://www.irongeek.com/"</script>" in it? Many "What is my IP?" type sites would be susceptible to a reflected XSS attack using this vector, but that's not all that interesting as you would only be attacking yourself. A more compelling idea is stored XSS, which is still possible sometimes with a User Agent XSS. For example, when a webmaster goes to check out their logs via a web front end to see who has visited their site, if the data is not sanitized, they may be hit with an XSS attack. The easiest way to switch your Agent string is to use Firefox and add the "User Agent Switcher" plugin:
https://addons.mozilla.org/en-US/firefox/addon/59
Once installed, you can just configure it to use whatever Agent string you like, or if you're lazy, just copy the following text into an XML file:
<useragentswitcher><useragent description="XSS Test" useragent="Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0 <script>window.location = "http://www.irongeek.com/"</script>)" appname="Microsoft Internet Explorer" appversion="4.0 (compatible; MSIE 7.0; Windows NT 6.0)" platform="Win32" vendor="" vendorsub=""/></useragentswitcher>
Then import it into the User Agent Switcher plugin. The XSS embedded in the Agent string above just redirects folks to my site, but there are far more sinister scripts a web master could be hit with when they go to view their logs. While we are talking about things in an HTTP request header, what other items might a pen-tester modify as an injection vector? Try the Tamper Data plugin for FireFox and play with the concept of modifying cookies, accept parameters and other header fields.
SSIDs
Ok, this is a very hypothetical attack, but it should get your intellectual juices flowing. SSIDs on WiFi networks (wireless network names for the uninitiated) can be up to 32 characters, and don't even necessarily have to be printable ASCII. The XSS possibilities should be self-evident for those that save their wardrive logs as XML, and later may make an HTML report, but what about SQL Injection? What if I made my network name something along the lines of "';DROP TABLE ssids;"? How sanitized are the wardrive logs you export to Wigle.net or some other database?
Event Log
Many folks use third part event log viewers/parsers that can save reports as web pages (hell, I've written ones that do that). What if an XSS string showed up in the event log? Failed logons on a Windows box may create an event with the failing user name logged in the event occurrence. Now what if you tried logging in as "<script>alert("XSS");</script>", and the admin used their log parser to look for failed logons? Barring that, you could write a quick app to add the XSS to the log directly. Could be fun times.
Computer Name/Description
Now this one I've gotten to work in Softperfect's NetScan when I exported the scan log to HTML. The computer name has somewhat limited options as to what characters you can use, depending on the OS, especially in Windows where there are a lot of characters that are not allowed in a valid NetBIOS name. That said, the Description property is wide open. :) I've used this before to insert an XSS attack into a scan report. Soon as the pen-tester looks at their report, bam, XSS attack.
Active Directory
Not to beat a dead horse, but what about all of the fields you can fill out on an Active Directory or LDAP object? Now that I think about it, maybe it's time for me to update my ADS Reaper tool.
Application Names and Metadata
Not to beat a dead horse, but what about all of the fields you can fill out on an Active Directory or LDAP object? Now that I think about it, maybe it's time for me to update my ADS Reaper tool.
Application Names and Metadata
Got an asset tracker that lists the software installed on a machine to a lovely HTML report? Does the assets tracking software look at the metadata in files? That could be another possible vector.
Banners
Is your custom scanning software logging the banners it sees on open ports? What if the banner has a little malicious XSS?
Conclusion
Granted, many of these possible attack vectors are hypothetical, and depend on reporting tools not sanitizing data. Still, I hope this short article makes the wheels in your head start grinding away at new way of thinking when it comes to injection attacks. For more ways to mangle XSS to get it past filters, check out RSnake's excellent cheat sheet:
http://ha.ckers.org/xss.html