Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Businesses Input Devices IT

BadBarcode Attack Forces Host System To Carry Out Commands (threatpost.com) 79

msm1267 writes: Researchers at this week's PacSec 2015 conference in Tokyo demonstrated how they were able to inject special control characters into a barcode, so that a barcode reader will 'press' host system hotkeys, and activate a particular function. The attacks, called BadBarcode, can be used against any keyboard wedge barcode scanner that supports ASCII control characters--many do. An attacker than then use control commands to open or save files, launch a browser or execute commands. Here are the presentation slides.
This discussion has been archived. No new comments can be posted.

BadBarcode Attack Forces Host System To Carry Out Commands

Comments Filter:
  • Will this work in the ticket in ticket out system?

    Time to print up an jackpot.

    • by Lehk228 ( 705449 )
      it's really just causing the barcode reader to do what it was built for, the problem is the software is trusting uncontrolled user input (the barcode) without sanitizing it first, and also most of these units are set up with the barcode reader connected as a keyboard with access to do things it should not be allowed to do (i.e. if you unplug the scaner and hook a keyboard up you can do the same "BAD STUFF"
      • by gmack ( 197796 )

        The problem is that in most cases there is no possible way to sanitize the input since Windows takes control of it.

        • Windows! Cash tills are more likely to be running DOS. Thankfully, it's so old, nobody knows how to hack it anymore.

          • No - not really.

            Programs like quiken point of sale and many others run on Windows and use the Windows driver. Usually they require winxp or better but i know of several win95 and 98 pos still in use.

            • No, that's WAY too new. Think regular till, where you punch in amounts, maybe scan in items, and the display is a single or couple of lines of text. Prints out a paper tape.

              • I'm seeing modern systems where you scan items, maybe punch in amounts, with a display that has a single or a couple lines of text, that prints out a paper tape (thermal paper) but there is a color flat panel display and some Windows XP running underneath too.

          • businesses switched to windows XP. about the time windows 7 came out.

        • by Anonymous Coward

          In this case you are mistaken. Most bar code scanners represent ASCII control characters as a sequence of ‘press control’, ‘press X’, ‘release X’, ‘release control’, where X is in the set 2, A...Z, [, \, ], 6 and -. None of these get any special treatment from the operating system and they all get sent to control with the input focus.
          Now, I gather there are bar code scanners which allow arbitrary keys to be sent, but chances are your cashier station isn't usin

      • So, is "barcode injection" jargon now? Apparently. https://duckduckgo.com/?q=barc... [duckduckgo.com]
  • Derp (Score:5, Funny)

    by flopsquad ( 3518045 ) on Friday November 13, 2015 @11:55PM (#50928187)
    [STX]
    Did you implement all of ASCII in your barcode scanner?
    [ACK]
    Did you think to scrub out control characters?
    [NAK]
    Do you know what that means?
    [ENQ]
    I'll ask the questions, bub.
    [BS][BS][BS]
    Don't try to BS me.
    [SI][SO][ESC]
    Where are you going? You can't leave!
    [NUL] . . . [DC1]
    [BEL][BEL][BEL] Correct. Hackers have control of your device. Now go fix your shit.
    [ETX]
    • by cfalcon ( 779563 )

      God I hope you can spam 0x0C [Form Feed], and then the receipt printer throws a goddamned ticker tape parade.

  • Really, it's not that hard. The hard part is convincing developers and managers to remember that barcodes are not stone tablets graven by the Almighty.

    • Oh, and to whomever modded this "off-topic" -- don't you have some barcode input logic you're supposed to be working on?

    • by Anonymous Coward

      You're an idiot. The computer receives the barcode command as keyboard input. The attackers figured out how to send control characters down the line as well. So a specially crafted barcode could carry the payload Win+Rmaliciouscommand, or anything else. This is a hardware problem that affects the vast majority of existing barcode readers. There's really nothing any of the software can do to "sanitize" the input.

      • by Anonymous Coward

        "There's really nothing any of the software can do to "sanitize" the input."

        Why does the software need to re-transmit a Windows key button press unmolested? It seems like Barcodes should only contain A-Z a-z 0-9 and `~!@#$%^&*(){}|:"?[]\;'./" characters. Anything else should get dropped in transit by the embedded chip decoding the barcode don't you think?

        • Well, maybe. Evidently there is some case to be made for it being possible to use control characters in a barcode, else the standards wouldn't include them. It must be useful to someone, somewhere. So it shouldn't really be up to the scanner hardware to say "yeah nah, not passing that on, ever".

          And as others point out, it's not really within the scope of applications to decide whether or not certain keypresses go through to the OS. So what does that leave us? Really just the device driver for the barcode re

          • There thing is that these scanners can be programmed to accept only a number of characters but nobody bothers to do so. At my local grocery store they use Bluetooth scanners which are all using the same pin codes. The security in most of these places is laughable, the reason that nobody bothers to mess with the system and even if they did, the technical expertise would make it such a minority that it doesn't matter if one geek shoplifts their cart of groceries compared to the number of people that already j

            • There thing is that these scanners can be programmed to accept only a number of characters but nobody bothers to do so.

              It probably wouldn't make that much difference anyway. Typically the only way to program barcode readers is by using special barcodes from the manual or printed out from the manufacturer's software. An attack would just need to start with the special barcode for 'enable these characters'.

              • I have a barcode reader from a more professional place. It needs to be put in a programming mode to do that. Then you indeed use bar codes to program it. The point still is that these attacks are niche. It's cheaper and easier and less criminal to just walk out of the store with your groceries than to use technology to do it. If you get caught hacking it, you do 25y of time because you used a computer, walking out of the store nets you community service at best.

                • Well, that assumes a supermarket self-checkout. (Which, admittedly, is the most likely possible use for this kind of attack.) But there are other places where barcode readers are there for the general public to use.

                  As an aside, the barcode readers I've encountered at work do not need to be put into a programming mode. But on the other hand, my employer tends to go for inexpensive equipment...

        • Why does the software need to re-transmit a Windows key button press unmolested?

          The software doesn't need to re-transmit anything at all. In a keyboard wedge barcode reader, the OS will interpret these keypresses and run the malicious code before your software even sees it. Just like if you push the calculator key on your fancy keyboard, the calculator pops up. It doesn't require that the running application interpret that keypress and launch the calculator app for you. This is why sanitization won't help you at all: the damage is done before your software even gets any of the dat

        • Its because the barcode reader is really a fancy keyboard (when attaches via keyboard wedge). Software has nothing to do with it at that point. The software is more or less like a word processor in this sense. It recieved input from the keyboard but hit win+r cmd "enter" would open a command line and focus all input in it instead of the open document.

          In other words, The barcode simply inputs keystrokes and everything you can do with a keyboard can be done with a barcode if not limited by hardware or a keyb

  • If I'm not mistaken, most barcode readers, as far as a computer is concerned is just a keyboard. I have had limited time messing around with one that plugged in via a PS/2 port, although most, these days, plug in through USB. If you open a blank text doc and scan something, what would usually show up is the number that appeared below the barcode. I'm not sure if this would work on all retail POS, maybe those that run on some variant of Windows. But would it work on Linux, or proprietary systems?
    • One word: CueCat.
    • by _merlin ( 160982 )

      It will work on anything that supports a standard USB keyboard, assuming the keyboard layout selected on the host device matches what the barcode reader is generating key-presses for (e.g. if you have French keyboard but the barcode reader generates US key-presses selected you'll get A instead of Q).

    • by Anonymous Coward

      If I'm not mistaken, most barcode readers, as far as a computer is concerned is just a keyboard.

      Nope. Barcode readers are generally programmable to act as multiple different devices, requiring different cables depending on the mode selected. The barcode readers we use at work ZebraScan (Now part of Motorola, IIRC) come out of the box with USB cables and HID keyboard "wedge"*, but we reprogram them with the vendors control codes to work as USB ACM (serial) devices. The reason we do this, is not for security, but because UIs that rely on the correct text entry field being selected for a scan to perform

      • we reprogram them with the vendors control codes to work as USB ACM (serial)

        Yes, you do that, and I do that, because you're absolutely right: wedge mode is a kludge. Problem is, lots of existing deployments do have them set in dumb keyboard mode. Why ? Because the development of that POS appliance or software was farmed out to the lowest bidder (meaning China/India), where the product was made to "work", and the project manager(s) have no idea how barcode readers even work nor why wedge mode is a bad idea.

        The same is true of mag-stripe readers. I have seen countless setups in r

      • by plover ( 150551 )

        The problem is that scanners support multiple communications protocols so they can be sold to a wide variety of clients, and the scanners' configurations can be changed via barcode without first asking for permission.

        Your attacker can see that you're using a DS-6878 scanner with a USB cable, so he opens his phone's browser to this page of the manual, http://www.manualslib.com/manu... [manualslib.com] and displays the barcode to configure a North American keyboard. Once scanned, as far as Windows knows someone just plugged

    • by Osgeld ( 1900440 )

      most are setup as keyboards, others are ports that lead directly into software, which you wont see that much unless your using it in some industrial setting with automation

  • by penguinoid ( 724646 ) on Saturday November 14, 2015 @01:02AM (#50928505) Homepage Journal

    Time to print up some nice CTRL-ALT-Del barcodes for the local evil-mart.

  • They just thought of this now?
    • by xeno ( 2667 )

      No, this report is silly. We used this kind of vector as standard structured attack fare at @stake and foundstone a decade+ ago. It was in our basic reports to explore alt input -- you know, feeding stop-A in barcode to a manufacturing robot, or feeding a break and shellcode to a POS station, one re-labelled product at a time on the belt.

  • by Anonymous Coward on Saturday November 14, 2015 @01:44AM (#50928629)

    I remember fiddling around with exactly this back when we had barcode scanners that hooked up over an AT style 5 pin DIN connector.

    Traditionally, this has never been an issue because you've always had a cashier manning the point of sale terminal. If they want to do something nefarious, they'll just enter in the commands through the keyboard instead. If a customer was ever in a position to scan multiple barcodes to try and exploit the underlying system (99% of which are custom jobs, running on AIX, AS/400, SCO Unix, and implemented in a variety of different languages), then they could just use the keyboard since there's obviously nobody there to stop them.

    This exploit is only really an issue with the newer self checkout machines. These all implement various "hidden" menus for clerks and managers that let you override things like discount prices or zero out the weight on the bagging area sensor. Those menus are invoked by scanning a custom card with a barcode on the back, which causes the barcode scanner to press a specific key combination (this varies depending on the manufacture of the terminal and any site specific customizations).

    I have yet to hear about anyone successfully using these kinds of exploits in the wild, though. The moment you enter any of these menus, the menu usually takes over the whole LCD of the checkout terminal. It's very obvious to see someone doing something they shouldn't. So you still need to avoid the security cameras which are usually pointing at the checkout isle, as well as the gaze of whomever is operating the control booth (up here in Canada, we've always got one individual standing around who can help you with the self checkout machine should you have any troubles).

    That's not to say that I haven't heard of these machines being exploited, because I have.

    About a year ago there was an incident involving a particularly crafty fellow and a smart phone. Some of the "cutting edge" checkout terminals actually use CCD cameras to read barcodes, rather then a laser based system. Those cameras are quite capable of reading a barcode off an LCD screen, like a cell phone. Apparently the guy in question figured out an exploit similar to this one- he rigged up a series of barcodes that opened a command prompt, dumped some text to a VBS file, ran the resulting VBS file, dumped a whole bunch of hex data into that, then the VBS file converted the hex into a binary blob, dumped it to disk, and executed it.

    He encoded all these barcodes as a movie that he could play back on his cellphone. It took about 20 seconds to play through the entire movie and load up the executable code on the terminal. The same guy demonstrated some fairly scary exploits that could detect a sequence of scanned barcodes and override the payment subroutines so that you paid $0. That way your buddies could go and checkout, say, two boxes of Tic Tacs, one Oh Henry chocolate bar, and an avocado, and walk away paying nothing no matter how big the final bill was.

    As far as I know, that exploit was never made public knowledge because the companies who were experimenting with CCD based scanners decided to switch to an actual USB powered capture device so they could process the barcode data in software (rather then using an ASIC tied directly to the CCD sensor). That same software was integrated into the point of sale software so that it wasn't really emulating a keyboard per say, there was no way for the scanner input to escape the checkout software and interact with the actual operating system.

    • by KGIII ( 973947 )

      I love Slashdot. Thanks for taking the time to type that out. Nobody else said thanks so, I will. I suppose some would be like TL;DR but I appreciated it.

      My own 'complaint' isn't really a complaint but just an FYI. It's "per se" and not "per say." Why do I know this? Someone on Slashdot corrected me.

    • And to think I wasted my last Mod Point on something humorous. Thanks for that.
    • by ljw1004 ( 764174 )

      The same guy demonstrated some fairly scary exploits that could detect a sequence of scanned barcodes and override the payment subroutines so that you paid $0. That way your buddies could go and checkout, say, two boxes of Tic Tacs, one Oh Henry chocolate bar, and an avocado, and walk away paying nothing no matter how big the final bill was.

      The final bill was $2.52 for the tic-tacs, $1.29 for the Oh Henry, $2 for the avocado -- $5.81 in total.

      If I could get stuff for free no matter the size of the final bill I'd get WAY more than that! Like, maybe five Oh Henry bars!

  • by Anonymous Coward

    All weak point with no validation and so on.

    This is what annoys me, these so called "security experts" are NOT what they pretend to be, they are just picking OBVIOUSLY WEAK systems with OBVIOUS attacks that were NOT DESIGNED to be secure.

    No news here, we have known this for decades.

  • Meaning that it connects through the ps/2 keyboard port of a computer. I had to google that.
  • Nam-shub.
    Don't look at it!

    Science fiction of yesterday is the science fact of today.

If all else fails, lower your standards.

Working...