One BadBarcode Spoils Whole Bunch

bad barcode badbarcode

At PacSec 2015, researchers demonstrated attacks using poisoned barcodes scanned by numerous keyboard wedge barcode scanners to open a shell on a machine and virtually type control commands.

Barcodes’ pervasiveness in retail, health care and other service industries notwithstanding, hackers really haven’t paid much attention to these tiny lines of data.

But like other technologies supporting the so-called Internet of Things, there are bound to be vulnerabilities and there are bound to be white hats and black hats poking about.

Case in point is this week’s PanSec 2015 Conference in Tokyo where researchers with Tencent’s Xuanwu Lab demonstrated a number of attacks using poisoned barcodes scanned by numerous keyboard wedge barcode scanners to open a shell on a machine and virtually type control commands. The attacks, dubbed BadBarcode, are relatively simple to carry out, and the researchers behind the project said it’s difficult to pinpoint whether the scanners or host systems need to be patched, or both—or neither.

“We do not know what the bad guys might do. BadBarcode can execute any commands in the host system, or [implant] a Trojan,” said Yang Yu, who collaborated with colleague Hyperchem Ma. Yu, last year, was rewarded with a $100,000 payout from Microsoft’s Mitigation Bypass Bounty for a trio of ASLR and DEP bypasses. “So basically you can do anything with BadBarcode.”

Yu said his team was able to exploit the fact that most barcodes contain not only numeric and alphanumeric characters, but also full ASCII characters depending on the protocol being used. Barcode scanners, meanwhile, are essentially keyboard emulators and if they support protocols such as Code128 which support ASCII control characters, an attacker could create a barcode that is read and opens a shell on the computer to which the commands are sent.

Yu and Ma said during their presentation that Ctrl+ commands map to ASCII code and can be used to trigger hotkeys, which registered with the Ctrl+ prefix, to launch common dialogues such as OpenFile, SaveFile, PrintDialog. An attacker could use those hotkeys to browse the computer’s file system, launch a browser, or execute programs.

“We designed several different attacks,” Yu told Threatpost. “The key principle is putting special control characters in the barcode, so that the barcode reader will ‘press’ host system hotkeys, and activate a particular function. Making a BadBarcode exploit is easy. You just need to generate some evil barcodes and print them on paper.”

Fixing this issue is a vexing one, Yu said, because it’s not limited to particular scanners, for example, which are manufactured by vendors that include Esky, Symbol, Honeywell, and TaoTronics.

“BadBarcode is not a vulnerability of a certain product,” Yu said. “It affects the entire barcode scanner-related industries. It’s even difficult to say that BadBarcode is the problem of scanners or host systems. So when we discovered BadBarcode, we even [did] not know which manufacturer should be reported.”

Yu suggest that barcode scanner manufacturers no enable additional features beyond standard protocols by default, nor should they transmit ASCII control characters to the host device by default. Hosts in IoT environments, meanwhile, should think twice about using barcode scanners that emulate keyboards, and should disable system hotkeys, Yu said.

Suggested articles


  • somebody on

    the problem is larger then this, in many cases the retail POS systems expect and require certain "key presses" before and after each barcode. For example, you purchase a high value item (big flat screen), the POS system often requires the user to scan a series of 1 to 5 barcodes to complete the sale, which include such things as SERIAL NUMBER and other tracking items. In order to identify each barcode the scanner is configured to output specific key sequences before and after each barcode. A simple example could be: CTRL-ALT-SHIFT-F1 then the serial number, CTRL-ALT-SHIFT-F2 - then the UPC code, and so forth. . The problem described is not a barcode scanner issue, it is a keyboard access issue - if the retail POS system has a keyboard (and many do) the human can type the same sequence of keys. The barcode scanner just makes it a lot easier to get the sequence correct and less error prone. . The correct solution is *NOT* in the barcode scanner, but in the retails system which should reject the key sequences. . The alternative is to use a different interface protocol, a typical barcode scanner can emulate about 5 to 6 different interfaces. Keyboard is just one interface. There is also serial port, IBM_SURE_POS (found on IBM based POS systems) the USB_BARCODE class (not many use this) and many other proprietary protocols that are specific to the scanner vendor.
    • Alberto Silva on

      Instead of depending on keyboard emulation, retail apps would benefit from using specific SDKs or libraries like OPOS:
    • TK on

      How can the "retail system" (a user-level application running on some operating system, I presume) reject keypresses? As I understand it, the keypresses are handled by the underlying operating system (OS) first, which is where the screw-up already happens. Only if the keypresses are insignificant to the OS (are not Ctrl+R or something else with special meaning), then they are passed on to the user-level application. The application running atop the operating system *might* try to prevent the problem by asking the OS to please give all control over keyboard input to the application without prior interpretation, if the OS has such a feature. This really shouldn't be the application's responsibility though. It's also prone to human error, since one may forget to activate the application before scanning something, so the keypresses land at the OS once again. The OS itself cannot really do anything either, when the scanner connected to it says "hey, I'm a keyboard" and proceeds to send arbitrary key sequences. There *might* be a way for the OS to try and find out that the device is really a scanner and not keyboard, but that in turn should not be the OS's responsibility. So the way I see it, the technical problem is with the scanner devices which claim to be keyboards when they are not, sending arbitrary key presses when they really meant to transmit application-level data. This isn't to say that the scanner device manufacturers are at fault (which is what I mean when I say it's just "the technical problem"). The overarching human problem is that we in the hardware and software industries are collectively cutting corners by abusing communication protocols for purposes they were never meant for, instead of defining new protocols dedicated to the task. So when the "researchers" behind the project say it's hard to pinpoint who to blame, they probably just find it hard to admit that the whole hardware and software industries --like most capitalist industries-- are in a very depressing state of carelessly cutting corners for cheap profit.
      • Alberto Silva on

        Again, most professional developers don't rely on keyboard emulation for barcode scanning. SDKs or COM port control prevents this hack, so there is no point blaming "the whole industry", just the lazy programmers.
        • TK on

          At the company I'm working at, I often see it first-hand how the concern of maximum profit dominates all other concerns. The security of our customers or other ethical concerns is only attractive insofar it's profitable. (We'll refrain from *outright* nastiness, since we're not *shameless*, but the underlying and overarching mentality is profit-driven.) Often a project manager will put pressure on the programmer to get a task done in the cheapest way possible, after the customer has agreed on a certain payment; or even before that, the programmers are pressured into drafting the cheapest possible solution for the customer (that still fulfills their specification) so the company wins in competition against other companies offering solutions to the customer. (And in turn, the customer which is often another company, is also profit-driven and probably doesn't care if the cheap solution they buy will screw up *their* customers.) This is business 101 from what I can tell. Profit dominates. I won't dispute that the laziness, carelessness, ignorance, etc. of individual programmers doesn't have an effect too, but I wouldn't put too much blame on them specifically, since their attitude is a reflection of the desires of the "higher-ups." My motivation to produce well-thought-out code with good design and lots of attention to following best practices was quickly drained out after I started programming occupationally for a company. (Also there's a point to be made against elitism among programmers, but that's a different topic.)
  • Nell on

    Some voting machine manufacturers are placing barcodes on our ballots. We should be very dubious of these barcodes.
  • Alberto Silva on

    Most manufacturers offer SDK to enable programatic control of their barcode readers, no matters if it's a mobile device built-in barcode reader or a USB/bluetooth model. Using the SDKs instead of keyboard emulation not only prevents this security issue, because apps would reject those malicious barcodes, but also enables a more effective control of the scanner.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.