Will This Hack LPR Cameras?

I seriously doubt that would work, but the xkcd reference made my day.

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...

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.