2

Recently I came across a tool which can inject payloads into a barcode. How can I prevent myself from this kind of attacks?

Attack scenario:

  • The attacker prints vulnerable barcode / sends vulnerable barcode to me
  • I scan the vulnerable barcode and the payload attacks my system
  • The attacker gains access

Possible preventive scenarios:

  • Never scan barcodes - but it's not easy in terms of departmental stores or any company storage areas (where barcode scanning is important)

Apart from the above any possible preventive solutions in order to prevent this type of attacks?

  • 2
    Fix your barcode scanners? I don't know how a barcode could exploit your system but such a simple thing as a barcode scanner can be built to only parse valid barcodes, right? – Silver Jun 23 '16 at 12:32
  • 2
    It's hard to know how to defend when it does not describe what vulnerability it is exploiting.... – schroeder Jun 23 '16 at 12:36
  • I think the attack you want to mitigate is called "BadBarcode" : slideshare.net/PacSecJP/… – schroeder Jun 23 '16 at 12:52
  • 2
    Don't know why you're getting downvotes, question looks good to me – paj28 Jun 23 '16 at 12:57
  • @paj28 Let me take a guess, why people downvoted. The situation is: someone takes a barcode library, writes a few lines of code and calls it an "armed exploit", another person gets concerned. A question "is it a hoax or is there any merit to it?" sounds reasonable. However adding a dramatic attack scenario "someone sends me barcode, I scan it, my device is owned, what can I do?" looks suspiciously close to trolling. – techraf Jun 23 '16 at 23:17
8

After going through the code, I'm not sure that it is supposed to exploit or attack anything. It looks like its only purpose is to encode a payload using barcodes. It would be a nice way to import code into a system using a barcode reader when all other routes may be blocked. After you locate a vulnerability in a system, you can "upload" a payload using one of the these barcodes.

As such, there is nothing to defend against. It is getting the bar code scanner to do exactly what it is supposed to do: convert a barcode into text.

7

This is remarkably similar to attacks like SQLi, and the remediation is the same.

  • Wherever you allow a barcode to be scanned as input, validate it in the scanner and only allow input that matches the requirements.

If you expect a field of 20 digits, only allow 20 digits and strip off anything after 20. If you expect 8 alphanumerics, limit it to that.

This used to be an issue waaaaay back, but even in the early '90's we had this solved. (I used to do a lot of early testing for scanners from Telxon, Symbol etc., and this was before SQLi had really been addressed. We had to solve it for various use cases including 5250 and 3270 terminal codes too) - stripping them out before they hit the system they are designed to exploit removes the problem completely.

  • If I understand this paper correctly, if the barcode scanner behaves like a plug&play keyboard, it can be attacked: en.wooyun.io/2016/01/28/Barcode-attack-technique.html – hamena314 Jun 23 '16 at 12:40
  • No - that attack method has been around since the dawn of scanners. It is a solved issue. By the method I described. – Rory Alsop Jun 23 '16 at 12:51
  • How exactly do you do this? If we have a Windows application that takes barcodes, it's easy enough to check the input the application gets. But how do you stop a barcode injecting Windows-R which is handled by the system? – paj28 Jun 23 '16 at 12:54
  • You sort it at the scanner end. Scanners these days are very configurable (partly based on the testing work my team did in the nineties) - I'll clarify in my post. – Rory Alsop Jun 23 '16 at 12:55
2

Barcodes can be to exploited because of fact that most barcodes contain not only numeric and alphanumeric characters, but also full ASCII characters (special ones included) depending on the protocol being used.

Barcode scanners are essentially keyboard emulators and if they support protocols such as Code128 (which supports ASCII control characters), an attacker could create a barcode that when is read opens a shell prompt on the target computer to which the commands are sent.

Or, Ctrl+ commands can be send via ASCII code and can be used to trigger hotkeys, which register with the Ctrl+ prefix. Those in turn would launch common dialogues such as OpenFile, SaveFile, etc. An attacker could use those hotkeys to browse the computer’s file system, launch a browser, or execute target programs.

So if you want to protect yourself from this type of attack, make your readers read only standard characters and exclude all ASCII specials from being processed/interpreted. Many scanners support multiple protocols, so selecting one that is numeric and alphanumeric only will solve this issue.

  • 1
    You have described "BadBarcode": slideshare.net/PacSecJP/… – schroeder Jun 23 '16 at 12:53
  • How do you configure a scanner to only accept certain protocols? I realise this will depend on the scanner, but can you give an example? I've got a couple of USB scanners here, and neither offer any obvious way to do that. – paj28 Jun 23 '16 at 12:56
  • I have examples for a load of scanners. Still have a load of my kit upstairs (scanner vendors used to send me test kit for breaking :-) - each one is different, but you can set blacklists and whitelists, code types, passwords for control codes etc – Rory Alsop Jun 23 '16 at 12:57
  • Check the specific models in use and we can determine what protocols are supported and how to configure them. – Overmind Jun 24 '16 at 6:46

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.