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?
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.
I remember when we first got Netscape at home. I found a chat room and said hello, politely introducing myself. Someone said hello back, and told me I would hear a cool sound if I hit Alt and F4 together. I did, and ever since then I've had trust issues.
...an SQL query, for example, typically needs to entered directly to the database's command processor; entering it into a field would do nothing...
Unfortunately internet server side code is replete with SQL that WILL do something in these cases. It's called dynamic SQL and its used far more than it needs to be, mainly because of the proliferation of free SQL servers meant unwashed hordes of coders were just trying to 'make it work' quick without knowing the implications of the method.
It is useful when truly creating on the fly sql, with table names and columns names that are not known until runtime. In this case though one would expect that the main license plate table would be known already. Then you would want to use parameter driven embedded sql (also hackable, though much harder) which would work as you say. This also allows sql to improve efficiency of the query by optimizing for it ahead of time.
If it was the coder herself who generated the license plate, she just outed herself as a sloppy programmer.
You may be assuming that the database used has the ability to process stored sql or has the ability to process parameterized SQL. Developers are always under pressure to deliver code, to expect them to care about security is a big assumption. That's why you typically have one QA guy for every two developers, but many projects are cash strapped so they alway shortchange QA. So yes, most SQL is dynamic and many products use free or real cheap open source products like Apache Derby, BSD PostgreSQL or GPL MariaDB.
You may be assuming that the database used has the ability to process stored sql or has the ability to process parameterized SQL
I continue to assume. What sqldbs don't have stored procs, besides maybe embedded ones like sqlite? All the ones you mention do. Perhaps your favorite script language is lacking the proper libraries to call them.
If you can at all get away from dynamic sql, do it. It's actually harder and slower unless you really need to create something unforseen. Even then you can usually prepare wih ?'s a statement that is a lot harder to hack.
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.
Maybe it could work if the coder of the backend system was in on it, but then agan what hack wouldn't? Anyway the SQL would have to be fully dynamic, needlessly since a simple count on a known table should be paramitized. But it looks to me like the beginning of the plate 'number' is the end of an insert statement or stored procedure call. Either way I don't understand the end quote there, you would think the sqlparser would reject it, Any ideas what the left hand of the expression could be?
P.S. Reminds me of a Unix sysadmin at a lab that I worked at: He kept telling us our systems were vulnerable to various attacks and that we needed to do various work to secure them, which we didn't of course. And then lo and behold our system was hacked, long story short it was the sysadmin trying to teach us a lesson. He did. He got one too.
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.
As far as the FOV, remember that not everyone's plates are in exactly the same location on the car, and not everyone generally drives in exactly the same car-width lane. The system would NEED to be able to photograph the entire width of the area that a plate MAY be in. Not all plate designs follow the same rectangular form factor of North American plates, either, so the system would need to be able to parse a variety of layouts to extract the actual license number.
There was an urban myth circulating around here about splitting lanes to beat the ALPR cameras used on a toll bridge, presumably putting you in a blind spot between the lane cameras. Problem with that theory is, each camera covers a good half a lane to either side of its own lane, and because of the perspective, actually sees more than a lane to eiether side as you proceed past it.
Not saying this makes it any more feasible in itself, but getting the entire sticker in the camera's FOV should NOT be a concern.
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
Undisclosed Manufacturer #1
|
2
|
less than a minute by Undisclosed End User #2 |
|
Started by
Undisclosed Integrator #1
|
4
|
about 2 hours by Ryan Karpilo |
|
Started by
John Honovich
|
5
|
less than a minute by Undisclosed Integrator #2 |
|
Started by
John Honovich
|
31
|
about 10 hours by Ramsey Burns |
|
Started by
Undisclosed #1
|
3
|
about 4 hours by Phillip Gauthier |
