Home / Blogs

SQL Injection in the Wild

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

Filed Under


How do I clean a physical SQL injection? Peter Stolmar  –  Mar 26, 2013 7:43 PM

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…

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

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.

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



New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign


Sponsored byVerisign

Brand Protection

Sponsored byCSC