Slashdot Mirror
BadBarcode Attack Forces Host System To Carry Out Commands (threatpost.com)
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.
Will this work in the ticket in ticket out system?
Time to print up an jackpot.
Or Skynet.
Without using that name, I have a QR code for my steam profile and had it on facebook - it went to youtube and rickroll'd people.
[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]
Nothing posted to
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"
Snowden and Manning are heroes.
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.
https://twitter.com/tombkeeper...
The problem is that in most cases there is no possible way to sanitize the input since Windows takes control of it.
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?
I was thinking free groceries
That won't work. Grocery store scanners are not keyboard wedges, and they are programmed to only read numeric barcodes, such as UPC, EIN, coupon codes, etc. They will ignore any Code128, Code39, or any other barcode that could contain non-numeric data.
https://xkcd.com/285/
Time to print up some nice CTRL-ALT-Del barcodes for the local evil-mart.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Um, that's totally not true. Most barcode scanners just show up as USB keyboards, and most places don't bother to change them out of their default config.
Also, most discount cards, if they aren't 2D barcodes, are 1D Code128 codes.
They just thought of this now?
Since many are USB devices, and programmed by special barcodes to enable and disable various symbologies, with enough info on the target scanner, you can reprogram the scanner with a barcode to enable a full ascii symbology, then scan in the attack code. Like many thumb drives, BIOS, etc, there is no write protect to prevent unauthorised alteration of the configuration.
The truth shall set you free!
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.
https://xkcd.com/327/
Website Just Down For Me? Find out
Remember when Scully scanned that mysterious alien doohicky at the grocery store cash register?
Windows! Cash tills are more likely to be running DOS. Thankfully, it's so old, nobody knows how to hack it anymore.
Sleep your way to a whiter smile...date a dentist!
The grocery store I go to uses alpha numeric bar codes for their points cards and USB hand scanners which they pull out for scanning phones.
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 using one of those and you can still disable that attack by editing the Windows scan code map (the same thing that you can use to change your Caps Lock into an F13).
There are also bar code scanners that can be reprogrammed by scanning bar codes (ADF enabled scanners) to send keys at scan time, but also to make it interpret future bar codes differently. If you cannot turn ADF off after you're done configuring it, you're hosed because then this becomes a DoS attack channel.
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.
I was wondering how someone could possibly screw up such a dead simple task, reading a number from a barcode and then passing it on to a computer. You would think there's no way that could go wrong, right? But then I underestimated the creativity of engineers going "hey, that's too boring, let's see what else we can add. Yeah, let's include functionality that lets you read and send any characters you like, including control characters, and let's include that into every friggin barcode reader on the off-chance that maybe somebody might one day want to use it, that will be so cool!".
I know, there might be a few, very few isolated cases where this kind of stuff is useful (as an ugly hack to work around some technical issue that would better be solved in a different way), but then let them use a special reader and leave the millions of cash register barcode readers alone, for crying out loud.
Right. And aircrew all know how to convert from gallons to litres.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Actually, we use Google calculator for that.
Actually, they used to work like keyboards.
I don't know if they still do.
But I remember a talk at a CCC conference in Germany where they took a sixpack of beer and put a different barcode on the bottom (the reason the sixpack is a good target is because it's heavier so cashier doesn't look at the bottom). The barcode instead of adding to the bill did the exact opposite: subtracted from the bill the same amount.
But to make these kinds of hack work at your local supermarket you first need to know at least a little bit about what systems they use and how the system work.
New things are always on the horizon
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.
"So long and thanks for all the fish."
Nam-shub.
Don't look at it!
Science fiction of yesterday is the science fact of today.
<blink>down the rabbit hole</blink>
Yeah but you can reprogram the thing using...barcodes!
So go to self checkout, whip out your "check" book and program it to think everything costs one cent. Put pennies in the coin slot. There, you didn't even actually steal anything.
Erm... The barcodes execute keypresses (No reprogramming) on the system they're connected to. If the system doesn't currently support the codes, you're not going to be able to make it using that method.
That said, the very next post below seems to suggest that my comment was wrong...
And to think I wasted my last Mod Point on something humorous. Thanks for that.
There is a whole range of barcodes. Some are simply enough to just encode 10 digits, others encode up to 43 characters, but the barcode Code128 encodes the entire ASCII character set. That's where the fun begins. A barcode reader vendor will probably design the system to read any barcode and return the type of barcode as well as its contents. Probably encode into Unicode as well. So then all sorts of mischief are possible with newline, return, backspace and delete characters.
http://www.scandit.com/2011/11/04/types-of-barcodes-choosing-the-right-barcode-type-ean-upc-code128-itf-14-or-code39/
For the record, GCHQ figured out a way of sending Unicode messages in SMS texts that control the actions of a smartphone.
Like many thumb drives, BIOS, etc, there is no write protect to prevent unauthorised alteration of the configuration.
100% true. I worked for a barcode company for quite a few years and there was never any write-protect switch or password needed to alter the device config. We simply had a book of barcodes that we scanned to set the device up however we wanted.
And now looking back on it, it seems we were all astoundingly naive not to realize that someone somewhere would take advantage of that. Of course at the time there wasn't anything terribly interesting you could get away with by fiddling with the config, but that's no longer true.
If nothing else one could do some very malicious things by mucking about with the configuration, in some cases possibly leading to injury and/or death. (For example, altering a printed "Max Pressure Allowed" label to read "500lbs" instead of "20lbs" or a hospital label printer to output "Recommended Dosage: 500mg" instead of "Recommended Dosage: 30mg".)
Just cruising through this digital world at 33 1/3 rpm...
businesses switched to windows XP. about the time windows 7 came out.
i thought once I was found, but it was only a dream.
I spent nearly 5 years developing laser based barcode scanners but wish to remain anonymous and have over 20 patents in the field. ... And begins to plug things in and out of that hole - his goal is to impress upon the young girl that he is great... Or the young lady wants to try new things.... yes it happens. If you goto the grocery store and look at the checkout counter barcode scanner - you will notice there are *ZERO* holes visible on top, the same with the cash register - you can get to them but you have to climb under the counter, or remove something (much like removing the girls pants) in order to access the hole. Otherwise the young kid will stick ball point pens, keys, tweezers, and countless other things into that hole - and with a 5V power supply there - it can short circuit something - hence even if the interface is present, it has been disabled.
.
Acronym: POS = Point of Sale
.
To correct some misconceptions: Most barcode scanners *CAN* emulate a keyboard that does not mean they do - however most large retail operations do not use this, instead they use what is called the "IBM SURE POS" usb interface - why? Because they have IBM based point of sale machines.
.
It is true that many barcode scanners ship with USB-HID-KEYBOARD as the default, why? Because that is what many low volume customers need need, and it makes the barcode scanner sort of work out of the box (otherwise you need windows drivers, and that sucks)
.
Many barcode scanners are 'locked down" by the retail operation, why? Well they deal with young boys and girls who like to screw around with things. Yes, you can defeat this but it not always easy, some of it is timing based (i.e.: Plug a new scanner in, and the POS system will reprogram the device. Why does this happen? Because the store manager is non-technical, corporate ships a new scanner because the old one broke - it has to work immediately. So the window of opportunity is very small.
.
For those that are not locked down, what matters next is the selected interface - barcode scanners can emulate: PS2 keyboards (yes, this is still around and will be for years), standard RS232-TTL, an RS485 protocol used on IBM systems, in the USB area they support IBM_SURE_POS(USB), USB_SERIAL, USB_BARCODE(class driver), and several vendor specific protocols.
.
The described vunerability / vector is exactly a keyboard interface - many POS systems have a PC keyboard, the human could - in theory type every one of these key sequences - so the attack vector is always present. The barcode scanner just makes it easier.
.
When you purchase a large flat screen TV the system often requires you to enter multiple barcodes, if the system is using keyboard emulation they often require a specific keyboard sequence before each barcode type, i.e.: The Serial Number might be Code-128 starting with XYZ - press CTRL_ALT_SHIFT_F1 then enter the barcode, The UPC code might start with CTRL_ALT_SHIFT_F2 then enter the UPC code, and so forth.
.
But truthfully - many POS systems prefer a different USB configuration (i.e.: the IBM Sure POS is an example) - the ones that do require a keyboard are often locked down for other reasons, and will only accept a single USB keyboard on a specific USB port. Why does this happen? Lets go back to the "boys and girls" problem the young man - is bored and has nothing to do. He finds a hole that he can insert something pointy
.
Yes, i am talking about the major types of retail systems - your mom and pop stores are quite another situation - but - seriously - in that situation using the barcode scanner is perhaps much harder because Mom & Pop stores have such simplistic security and it would be *FAR* easier to use a different attack vector.
.
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!
wow, thanks for the details.
I can tell you for sure that many bar code scanner systems are programmed using a sheet of bar codes to configure the device.
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.
Sleep your way to a whiter smile...date a dentist!
I don't think you've read this carefully enough. The example given says that if you scanned in these items - in order first then, that final bill would be 0 - regardless of what else you scanned.
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.
So, is "barcode injection" jargon now? Apparently. https://duckduckgo.com/?q=barc...
There's no time like the present. Well, the past used to be.
this form of attack is not that new..
In the 70s, whey teletypes had paper tapes, it was common to embed all sorts of stuff int a paper tape and get it into the system..
my favourite was (paraphrased because I cant actually remember the syntax:
Student: "I bet I can bring the DEC 10 down in 2 minutes with this paper tape".
Computer center manager: "I bet you can't. we fixed that problem last week"
student: "watch this"
[loads tape on asr33, hits 'read' button.....]
"send operator :
Hey could you mount my
**WARNING COOLING FAILURE. SHUT DOWN SYSTEM NOW TO AVOID DAMAGE **
tape, it is tape number 3242342 with a red label, thanks, bob"
*clunk* (system goes offline)
in the 80s there were many attacks that output escape sequences to vt100 (or similar) terminals, that reprogrammed the function keys to do nefarious things. In some models you could eve than trigger the function key from output.. so you could send someone a text file that would program up a function key to do something and then execute it while the user was just 'cat-ing' the file.