Will This Hack LPR Cameras?

Here's an image floating around various social media sites, with the caption "Best SQL injection EVER":
One story goes (no firsthand info) that an LPR software programmer wanted to prove a point to his team that a vulnerability existed in the code, so rigged up the sign to prove a point. The code on his sign, when registered by the OCR software would delete records of his 'real' plate number: ZU 0666 from the database.
This might be theoretically possible, but it seems so unlikely to work in actual practice it is hard to believe.
What do you think? Would this work? Or is the idea just internet forum fodder?

03/14/13 05:02pm
The drivers name is "Little Bobby Tables".
I seriously doubt that would work, but the xkcd reference made my day.
Back in the dialup chat days, the DDial systems used "/q" (quit) for the logoff command... we used to tell newbies that in order to get a login password, they needed to type "/quest", which of course, would kick them off immediately :)
On the BBSes, every now and then someone would try to post a command that was meant to trigger the other end to send a "+++ATH0", as when you were online via a terminal, +++ would cause the modem to drop to command mode, where one could enter the ATH0 command to hang up. The problem with this idea, is that the +++ had to be followed by 2-3 seconds of no input before it would go to command mode, so of course, the gimmick never worked.
I would expect the above tales fall prey to the same sort of thing - an SQL query, for example, typically needs to entered directly to the database's command processor; entering it into a field would do nothing, as the database would not normally try to RUN an entry. Of course, there's the chance they were using some glitchy backend that WOULD make such a thing possible... I would find it highly unlikely though.
Yes, I believe it could. What happens is in their code, they likely have code to determine if a plate number is a match or not. It may look like "select count(*) from plates where plate_number = 'ZU 0666'" in this example. They just stick whatever is recognized in the query without qualifying it. But imagine the plate number had a closing quote and a semicolon to denote another SQL instruction follows. So in his example, using that text, the SQL instruction would say "select count(*) from plates where plate_number = 'ZU 0666'; drop database tablice;". SQL would run those two statements and drop the entire database.
But there's caveats. A) you would have to know the name of the database or table to drop. B) the userid used to issue the SQL would have to have "drop database" permissions. Since people that develop this sort of code do not have say the same security disiplinces an IT developer would have, I could see this hole as being real.
Now you just have to find LPR software that will read a string that long and get it 100% correct.

I find this example hard to believe for two reasons:
1) How many ALPR systems read continuous text fields 3' or wider? A plate with 6 - 8 characters is one thing, but a string of 40 digits? I don't even think the camera FoV is guaranteed to be wide enough to see everything?
2) The ALPR systems I've seen throw misreads regularly, even during optimal operation. Maybe only 2%, but that means two characters are bad out of every hundred. The accuracy needed to read an entire line of code without error, especially at highway speeds, just seems flat out impossible.
Thanks for the comments here. Like I mentioned when posting, I have no idea if this story is true or not, but the more time goes by the less likely I think it is possible.
I love this one.
Possible, but quite a stretch.
Since the purpose of LPR is to read character information in accurately, this has the same potential that any other user input data does - it's just ridiulously unlikely in this scenario. SQL injection is possible if poor security practices exist when constructing database queries, regardless of the source of data for those queries.
As far as knowing table names, etc.: yes this would have to be a targeted attack on a specific piece of LPR software, but that does not reduce the plausibility in any way.
I'd like to see a buffer overflow tried with some shellcode, but someone would have to rent a billboard for that...
Thanks for the idea Bri, I just ordered my new vanity from the DMV:
Pretty accurate vt-100 console emulation. Hopefully next time Smokey calls in my plate, the Automatic Voice Recognition system will just 'shell out'! Working on getting my ol' lady a plate with follow up commands...
P.S. I tried to get #!/bin/bash but apparently some bourne again hacker done got his mitts on it first :(
Jim,
That's too bad. Maybe see if you can find a valid fork bomb that will work. The classic ":(){ :|:& };:" is probably not valid in any state, though.
I've tested a few LPR solutions from really bad to really good, so to assume the developers know what they are doing and take security into consideration is a stretch for me. Heck, I recently had to develop a front end for a customer for LPR software from one of the larger companies to manage the plate list and actually when you do a search in my program, you could very well do the SQL injection mentioned. It's still in testing and there is only one or two people that will use this program. But here I stand, a former windows developer for a large oil company, well aware of security implications was too lazy to put in the checks on the input boxes needed to thwart this. Now I have to go back, look at the code and fixt it, dam this thread, LOL.
Newest Discussions
Discussion | Posts | Latest |
---|---|---|
Started by
John Honovich
|
4
|
less than a minute by Undisclosed Manufacturer #2 |
Started by
Thomas Kenney
|
17
|
5 minutes by Undisclosed #3 |
Started by
Undisclosed #1
|
1
|
less than a minute by Undisclosed #1 |
Started by
John Honovich
|
5
|
about 3 hours by Undisclosed #2 |
Started by
Jeffrey Hinckley
|
2
|
less than a minute by Sean Patton |