Drive-by injection?

Opinion by Ken Munro

Cross-site scripting attacks are usually ineffectual, but what if hackers put exploit code into barcodes or numberplates?

Cross-site scripting attacks are usually ineffectual, but what if hackers put exploit code into barcodes or numberplates?

Often, when running a penetration test, you might start with testing a web form by entering a fake customer name with script tags to attempt cross-site scripting.

For example, a really simple test might consist of entering the first name as <script>, middle name as (‘alert'xss) and the surname as </script>. This might show the existence of a cross-site scripting attack, but more often ends up with direct mail reaching the office with a bizarre contact name!

Clearly, the code is entering the contact database, but usually it wouldn't do a great deal unless the Database Administrator (DBA) viewed the data or it was published for someone to read or be exploited.

This got me thinking: how else could people put exploit code into applications? What about the Automatic Numberplate Recognition (ANPR) systems used by the police to capture numberplates? I wonder what would happen if someone changed their plates to a short, SQL statement?

The biggest problem would be getting a statement short enough to fit on a numberplate to do anything of interest, if it were interpreted at all. Regardless, it's rather amusing to think the very system that was supposed to be monitoring us could be attacked.

I doubt that the ANPR system developers ever gave any thought to the potential for unusual characters, so an opportunity for mischief may be present. But, while this makes us smile, this type of hack attack raises questions about input into databases.

Public and commercial database systems can often be accessed over routes other than the web. ANPR systems, for example, are unlikely to be robustly validating input as they expect to receive normal, numberplate data. So, what would happen if they read an injection statement or cross-site scripting attack?

Other applications and databases couldn't be infiltrated in this way, but there are numerous potential attack vectors. It might sound a bit extreme, but what if someone changed his/her name by deed poll to a SQL statement?

There's a great cartoon doing the rounds (http://xkcd.com/ 327/) of a conversation between a teacher and parent: a database at the school has been compromised and the teacher is asking if the child's name really is “Robert ‘); DROP TABLE Students;--“.

Tempting, isn't it? It would make machine-readable formats such as driving licences, library cards or even machine-readable passports an interesting attack vector.

One could write to the magnetic stripes on many types of cards; an attack that could easily be masked to prevent detection. What about using barcode fonts to convert statements into barcodes? Some barcode fonts support enough characters to do this.

Furthermore, 2D barcodes are emerging for airplane boarding cards while new mobiles (e.g. Nokia N95) already have 2D barcode readers – often used for scanning links from poster advertising. In the US, driving licences already contain 2D barcodes. Separately, the Data Matrix standard is increasingly being used to 2D-encode URLs.

How about labelling over the barcode on a tin of beans in a supermarket? If scanned successfully, what would be the effect on the till system?

Barcodes are also often used for asset tagging. Again, the barcode could be rewritten, causing interesting problems. Couriers and the Post Office, both of which use barcodes for tracking, could be left red-faced when explaining the disruption to logistics departments and customers.

Even if it wasn't possible to run an injection attack, entering cross-site scripting code into a database through any of the methods above could cause serious damage.

The DBA, or any other viewer of the application data, could find themselves compromised simply by viewing the content of the database. The attacker would need to have some knowledge of the application or database configuration to make the attack effective, but a few iterations could result in an eventual hit.

So, what's the lesson? Validate, validate, validate – and not just on the web!

Ken Munro is director of SecureTest, the penetration and security testing division of NCC Group.
ken.munro@securetest.com

Topics:

Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events