Finding a common cross-site scripting vulnerability in Cisco's new IOS Software Checker Feature.
During my normal day-to-day work I interface with a number of websites while researching the details of recently released vulnerabilities. It was a pleasant surprise when one day this mundane task turned into unearthing a vulnerability in one vendor's security checker web interface.
Now, everyone makes mistakes. I know I do, Little Flippant Inaccuracies happen. It's always good to remember how small the security community can be and engaging your peers with respect is smarter than taking pot shots at them. This post is not intended to be a jab at the vendor in question, their web developers were quick to understand the issue and produce a patch, but not before I could have a little fun practicing some web application filter evasion techniques.
The day started like any other, I was looking into a few new vulnerabilities reports provided by Cisco. With each new vulnerability report I looked into though, instead of getting a list of affected software versions I was directed to the new "Cisco IOS Software Checker" tool. It's a useful tool for administrators who need to identify whether a version of Cisco IOS is missing security patches/updates. Unfortunately this tool is not so useful for identifying what advisories affect which versions of IOS (what I needed to do).
Inconvenienced by a minor change, I half jokingly submit some garbage into their form field and was rejected for not inputting a valid IOS version string - which I expected.
Knowing that IOS version strings can contain a lot of various characters, I try again leading with a valid IOS version string. "15.1" followed by a bunch of A's. I was surprised to see the "AAAAAA" injection made it through onto the destination page.
Seeing what looked like a weakness in the app, I felt compelled to poke around a bit. Looking through the HTML, I found one injection point with promise: an input field's onclick attribute.
Now I needed to figure out what, if any, useful characters I would have to work with. I submitted a sample string of HTML-specific characters and found a few that did not get mangled or changed in the response.
That double quote and parenthesis they let through there, that made my day. I now knew what I would be able to inject into that input field and that was all that was needed.
The first step was to escape into that <input> tag, the onclick="…" attribute was my way in, with a basic double quote added to the attack string I would be able to add elements into the <input> tag. Here is the input tag after submitting 15.1"INJECTION_STUFF_HERE into the form.
<input … onclick="redrawRSS('15.1"INJECTION_STUFF_HERE … >
Now that I was outside of the onclick attribute, but stuck inside input, my first thought was to change the input field to an image type so I could get some visual response from their web tool.
<input … onclick="redrawRSS('15.1" type=image src=… >
This worked perfectly, but I wanted one to be sure I could execute javacsript as well … with a basic onload="" attribute added to the <input> tag. I was easily able to alert(1); on the destination page.
... but a basic alert(1); wouldn't suffice for the Spiderlabs Blog. I've spiced it up a little in the example walk through below:
With the attack validated, the information was sent over to Cisco who quickly addressed the issue. Now, any similar requests to the Cisco IOS Software Checker are denied.
The moral of this story is: never trust user input, and blacklists fail. Blocking just the characters that are assumed bad did not work, allowing just one character too many left the application vulnerable to this old and basic attack method.