Home / Blogs

SQL Injection in the Wild

Gunter Ollmann

As attack vectors go, very few are as significant as obtaining the ability to insert bespoke code in to an application and have it automatically execute upon "inaccessible" backend systems. In the Web application arena, SQL Injection vulnerabilities are often the scariest threat that developers and system administrators come face to face with (albeit way too regularly). In fact the OWASP Top-10 list of Web threats lists SQL Injection in first place.

This "in the wild" SQL Injection attempt was based upon the premise that video cameras are actively monitoring traffic on a road, reading license plates, and issuing driver warnings, tickets or fines as deemed appropriate by local law enforcement.
(Click to Enlarge)
More often than not, when security professionals discuss SQL Injection threats and attack vectors, they focus upon the Web application context. So it was with a bit of fun last week when I came across a photo of a slightly unorthodox SQL Injection attempt — that of someone attempting to subvert a traffic monitoring system by crafting a rather novel vehicle license plate.

My original tweet got retweeted a couple of thousand of times — which just goes to show how many security nerds there are out there in the twitterverse.

This "in the wild" SQL Injection attempt was based upon the premise that video cameras are actively monitoring traffic on a road, reading license plates, and issuing driver warnings, tickets or fines as deemed appropriate by local law enforcement.

At some point the video captures of the passing vehicle's license plate must be converted to text and stored — almost certainly in some kind of backend database. The hope of the hacker that devised this attack was that the process would be vulnerable to SQL Injection — and crafted a simple SQL statement that could potentially cause the backend database to drop (i.e. "delete") the table containing all of the license plate information.

Whether or not this particular attempt worked, I have no idea (probably not if I have to guess an outcome); but it does help nicely to raise attention to this category of vulnerability.

As surveillance systems become more capable — digitally storing information, distilling meta-data from image captures, and sharing observation data between systems — it opens many new doors for mischievous and malicious attack.

The physical nature of these systems, coupled with the complexities of integration with legacy monitoring and reporting systems, often makes them open to attacks that would be classed as fairly simple in the world of Web application security.

A common failure of system developers is to assume that the physical constraints of the data acquisition process are less flexible than they are. For example, if you're developing a traffic monitoring system it's easy to assume that license plates are a fixed size and shape, and can only contain 10 alphanumeric characters. Meanwhile, the developers of the third-party image processing code had no such assumptions and will digitize any image. It reminds me a little of the story in which reuse of some object-oriented code a decade ago resulted in Kangaroos firing Stinger missiles during a military training simulation.

While the image above is amusing, I've encountered similar problems before when physical tracking systems integrate with digital backend processes — opening the door to embarrassing and fraudulent events. For example, in the past I've encountered similar SQL Injection vulnerabilities within systems such as:

  • Toll booths reading RFID tags mounted on vehicle windshields — where the tag readers would accept up to 2k of data from each tag (even though the system was only expecting a 16 digit number).
  • Credit card readers that would accept pre-paid cards with negative balances — which resulted in the backend database crediting the wrong accounts.
  • RFID inventory tracking systems — where a specially crafted RFID token could automatically remove all record of the previous hours' worth of inventory logging information from the database allowing criminals to "disappear" with entire truckloads of goods.
  • Luggage barcode scanners within an airport — where specially crafted barcodes placed upon the baggage would be automatically conferred the status of "manually checked by security personnel" within the backend tracking database.
  • Shipping container RFID inventory trackers — where SQL statements could be embedded to adjust fields within the backend database to alter Custom and Excise tracking information.

Unlike the process of hunting for SQL Injection vulnerabilities within Internet accessible Web applications, you can't just point an automated vulnerability scanner at the application and have at it. Assessing the security of complex physical monitoring systems is generally not a trivial task and requires some innovative approaches. Experience goes a long way.

By Gunter Ollmann, CTO, Security (Cloud and Enterprise) at Microsoft
Follow CircleID on
Related topics: Cybersecurity
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

How do I clean a physical SQL injection? Peter Stolmar  –  Mar 26, 2013 11:43 AM PST

One more attack vector to worry about…

As someone who cleans up hacked websites every day, all I could think was:

"Well I can't exactly use my usual linux sed tricks to parse RFID input or other physical input..."

But as you said, it has to be stored in the database… So then I realized if the backends were properly built, the security is essentially the same:

Don't worry about where the input is coming from - use sound database and app design principles including (especially) the principle of least privilege - for instance a "licence plate" Object / record should never have access to "DROP DATABASE" or anything similar. In general we need to separate those physical "interfaces" from an actual Interface / View - it shouldn't matter whether the input is a keyboard, voice commands, RFID tag, barcode / QR code, license plate, or optical recognition system. The intermediate code should do everything necessary to product the same consistent sanitized input regardless of the source.

Sure, there will probably be some crafty attacks at first, but if we continue to build the backend to be as secure as possible a new input method should not be able to get around that.

Tips: whitelists not blacklists, don't allow direct DB access to physical interfaces, make sure inputs are sane and valid (and if possible, consistent regardless of the input device), and make sure you log and monitor things.

Kind of reminds me of the days of "hacking" with DTMF tones…

To post comments, please login or create an account.

Related

Topics

IP Addressing

Sponsored byAvenue4 LLC

DNS Security

Sponsored byAfilias

New TLDs

Sponsored byAfilias

Cybersecurity

Sponsored byVerisign

Domain Names

Sponsored byVerisign