Ever go on a treasure hunt? Ever find any hidden treasure? It’s a blast! One of my favorite pastimes lately is to go to garage sales and thrift shops, just to look and see what, if any, VHS tapes are in stock. Any time I see a thrift store, antique shop, or Goodwill, I’m stopping in for a few minutes. My latest acquisition was a VHS copy of A Nightmare On Elm Street (1984) from a garage sale. I was beyond excited. These tapes are my hidden treasure, and I love a good treasure hunt.
Penetration testing provides a similar experience. As pentesters, we’re constantly on the lookout for vulnerabilities and misconfigurations – our hidden treasure. I mean, what hacker doesn’t love popping a shell? It’s a rush!
One time on a webapp test, I found a treasure in the form of a cross-site scripting (XSS) vulnerability. In the simplest terms, cross-site scripting is a code injection attack that occurs when input data on a web page is not sanitized or properly validated before being reflected back into the application (for a more in-depth description, see our other articles). Typically speaking, an attacker injects some malicious code (often JavaScript) into an application’s input, which is then sent to the application’s backend web server. If the server does not perform any validation or sanitization on the attacker-controlled input before sending it back to the browser, the application’s response can contain this payload, which the browser then runs as code.
Cross-site scripting vulnerabilities are particularly dangerous because of how they can allow attackers to steal cookies and/or credentials and install malware on user systems, among other malicious activities. We spend a great deal of time performing code injection attacks on web applications during tests. Often, the code is sanitized – either stripped from the response or simply rendered as text. But, when the code isn’t properly sanitized and runs in the browser, we can’t help but smile (or do the occasional happy dance) because we just found some treasure!
Most of the XSS vulnerabilities we find are fairly straightforward. The injection points exist in standard text inputs, or sometimes in a URL. They are easy to find. But, there are some XSS vulnerabilities that are so weird, esoteric, and hidden that the risk is incredibly low that anyone would think that they exist – let alone find them (and for the record, these types of XSS always cause a happy dance).
Here’s an example, and it’s probably the most unusual and interesting XSS I’ve ever seen.
This XSS vulnerability came, as it often does, in the form of unsanitized input on a web page. With that said, the injection point (input) was not what many people would consider a standard input. This meant the input was not simply characters placed in a text field. Now, the client did a great job of protecting the application from other code injection attacks by validating and sanitizing data on all other inputs. We found an upload function that we tried to abuse; however, we were unable to upload any webshells to the server, let alone execute them. This webapp was locked down well, but something was bugging us about the upload functionality.
The upload function was designed to allow users to upload a picture of the back of their driver’s license. The license, or more specifically, the PDF417 barcode inscribed on the back of the license, was then processed (scanned and interpreted) by the backend server. The barcode contains all of the information from the front of the license, including name, address, birthdate, eye and hair color, weight, and everything else one would expect to see on a driver’s license. The scanned data was then sent back to the browser and processed with client-side JavaScript.
At first glance (privacy issues aside), this seems relatively harmless, particularly because the webapp is reading a barcode on a driver’s license. The licenses are typically state-issued government identification cards, which means that there should only be state-issued information encoded in the barcode.
Right?
That got us thinking… what if there wasn’t just state-issued information in the barcode? What if the barcode had something else in it? To find that out, we used an online PDF417 barcode generator to generate barcodes containing pseudo-malicious JavaScript payloads in the different barcode fields. After a couple hours of generating barcodes, and a lot of trial and error, we eventually found an XSS vulnerability. This was the hidden treasure we were hunting for.
Now, this XSS vulnerability was relatively low risk. It had to be triggered by the user performing the upload, and placed back into a form that was already in process. From what we could tell, there was no real way to weaponize the vulnerability to use against another user or administrator for any malicious purpose. There was no cross-site request forgery (CSRF) present in the application or any other way to trigger it. However, it still posed a very real risk, and identifying it helped our client to think about their other applications that may be at risk. Just knowing that an exploit like this is possible helped them (and hopefully, now you!) understand that ALL inputs should be sanitized and validated, even if it comes from reading a “state-issued” government ID card.
Over the last 15 years, we have been told by many of our clients that they get excited when we identify a finding in their applications or networks. While that may seem counterintuitive, finding our hidden treasure often leads them to their treasure – a previously hidden issue that can be fixed to strengthen their security. With that said, more and more I have come to realize how the real treasure isn’t from popping that shell or XSS. The real treasure comes from helping our clients not only find, but resolve these issues. That is the essence of being Professionally Evil.
If you want to learn more about how we can help your organization find its hidden treasures, email us at info@secureideas.com, or you can email me directly at aaron.moss@secureideas.com.
Aaron Moss serves as a Security Consultant for Secure Ideas and authors the Quick Bites Series. Explore his insights here:
