22

I am developing a vending machine and want to make it secure.

In a comment to my previous question, @Polynomial said "Vending machines (and similar devices) can often be pwned via buffer overflows on all sorts of easily accessible interfaces."

  1. I thought that buffer-overruns were the result of user input, and I certainly don't plan to have any in my vending machine (well, cash of course and the keypad to select a vend, but otherwise ... I will update the firmware and the pricing data from files on an SD card, but that is being discussed in my previous question).
  2. I quibble over "easily accessible interfaces" since all interfaces are inside a physically locked cabinet and, as was pointed out in the previous question, once the door is open it's easy enough to take the cash and run.

But, I freely confess that am a total n0b at this security thing. Please advise me of what I need to watch out for. How would you - theoretically - hack or otherwise steal from a vending machine? What could cause me the greatest loss? And what can I do to prevent it?


[Update] v1.0 is a soft-drinks vending machine, but we could use it for other porpoises - maybe even ticketing. V1.0 is not networked, but I hope that v2 will be (at which point, I plan to encrypt all network traffic).

I am thinking about @tylerl saying that most attacks would be physical and am doing a lot of testing on pulling the power during vend/refund, to see if I can get both the soda and the cash. It doesn't sound much, but if it can be done consistently and word gets around ...

I also think a tilt sensor would be a good idea and cheap to include.

3 Answers3

31

When I wrote that comment, I was referring to vending machines in a generalised sense - including things like ticket machines as well as the obvious food-dispensing ones. I was specifically thinking about a model of ticket vending machine at a place I frequent, which has the following interfaces:

  • Keypad
  • Credit / debit card terminal
  • RFID for contactless use of a customer loyalty card, but also for employee override.
  • Ethernet cable plugged in the back.
  • JTAG port behind the front panel (requires you to unlock the front panel, but it's only a tubular pin lock and can easily be defeated)

So, how might we own such a vending machine? Well, it's got enough interfaces for us to try...

Keypad

The keypad is an interesting vector, but it's unlikely to fall to any form of buffer overflow since there aren't really any buffers involved. At most we might be able to figure out some sort of back-door access code that gets us into a config screen, but it's doubtful.

Credit / debit card terminal

The one near me has an Ingenico i3300 card reader fixed into a recess in the side of the machine. I happen to have one to hand (yay eBay!) and can approach the reverse engineering of it in two ways:

  1. Attack the hardware. There's an FCC ID on the device, which I used to pull up the regulatory information from the Office of Engineering and Technology. The FCC deal with emissions testing and a bunch of other stuff, and as part of an application the company must provide detailed documentation of the product, internal and external photos (great for me, since opening the device myself would trip the tamper detect) and other test data. From there, I might discover a weakness in how the card reader detects intrusions, and find a way to open it and mess with the internal firmware. If I screw up, it's not a big deal - I can pick up another for less than £10 on eBay. Alternatively, I could remove the real board and replace it with my own, with an XBee / bluetooth / 802.11x device that transmits card info and pin numbers.
  2. Attack the software. There has been a lot of research into this (e.g. PinPadPwn) and many devices are vulnerable to buffer overflows from custom cards. It's possible to program the chips on chip & pin cards to install firmware mods onto a device, simply via putting them in the device as if you were a normal customer. It's then possible to come back later and download card numbers and pins onto another special card. Scary, eh?

RFID

This is a likely source of ownage. It's a bi-directional communications port that allows us to send and receive data that will be directly handled by code on the machine itself, rather than a separate module. A lot of RFID data contains strings and integers, so overflows are likely. We could also take a look at capturing the data from an employee override swipe, which could open up new possibilities to steal stuff from the machine. In order to actually fuzz the device, we'd need to have the vending machine in our possession. This time, I don't happen to have one to hand. The physical possession requirement with such a large bit of kit does give a barrier to entry, but it's possible to get them second hand. A discrete RFID sniffer should be able to record data from live transactions, though, which could be used to replay communications.

Ethernet

When I saw the ethernet cable, I giggled like a script kiddy finding an SQL injection hole. It's trivial to unplug one of these cables and insert a pass-through device to record and alter traffic going to and from the device. You could do this with an embedded device like a Wifi Pineapple. It's low cost and potentially high-yield, because you can monitor and fuzz live devices from a distance. I've got no idea what data is going down those lines, but it'd be fun to find out.

JTAG

If you can get the cover off, the JTAG port is the pinnacle of pwnage. The device is probably an embedded Linux system running on an ARM chip, so getting access to the JTAG gives you full control over the processor and RAM. You'd be able to pull out a memory image (probably containing firmware) and analyse it, and later go back and make changes. If the bad guys can get at your JTAG, you're owned.


So, how can you stop this from being attacked? For a large part you can't, but mitigation is an important thing. Here are a few tips:

  • Remember that you're dealing with money, and take security precautions as such. Tip sensors on food vending machines aren't useful if a bad guy can turn them off with a magnet, or change the software to avoid the alarm.
  • Choose card machine vendors that have a long track history of no security issues, and get some insurance against any failings in that department.
  • Lock communications ports down, and have a way to lock any ethernet cables into the device so that they can't be easily replaced.
  • Use transport security (e.g. SSL) if you're talking to external devices via TCP/IP.
  • If they're network-connected devices, segment them from your internal network. Plugging a device into an ethernet socket is so damn easy.
  • Have your software reviewed by a security consultant - especially if you've got RFID or NFC involved.
  • Don't use tubular pin locks that can be defeated with a damn pen. Use a proper lock.
  • Stay paranoid.
Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 2
    JTAG ports can be protected in software, requiring authentication. Which is not to say that this is always done, or that even when it is you can't easily pick up a diagnostic device that contains the key. – Gilles 'SO- stop being evil' Nov 08 '12 at 11:01
  • 2
    @Gilles That's true, but I've yet to see a single device that protects the JTAG debugger port in any way shape or form. It's usually a direct way to interfere with the CPU and memory of the device. – Polynomial Nov 08 '12 at 11:52
  • +1 both. @Polynomial, thank you *very* much for such a detailed analysis. You have given me much to worry about. I agree that a tube lock is easy to bypass and wonder if I should use somethign more robust (I am doing the s/w, but we will manufacture the h/w too). Once the door is open, I hope they woudl just take the cash, not look for a long term fleece (but...). Thanks for the tip about Ethernet; in V2 I want to use RJ45 or WiFi, and will encrypt all traffic. We don't intend to market to USA, only Asia, so don't need to worry about FCC. – Mawg says reinstate Monica Nov 09 '12 at 00:52
  • We will manufacture our own baord, but, yeah, currently an Atmel UC3. Maybe we had best remove all JTAG when designing the board. Thanks again for such a detailed feedback. Maybe I will fly you over here to try to crack one ;-) – Mawg says reinstate Monica Nov 09 '12 at 00:53
  • 1
    @Mawg I wouldn't remove the JTAG entirely (it's awesome for debugging on site) but instead put a key-switch onto the output enable pin of a [74125 quad buffer](http://www.ti.com/lit/ds/scls579a/scls579a.pdf) or similar, which you then use to block off the TDI, TDO, TCK and TMS pins of the JTAG port. That way you need a physical key to enable JTAG, and you can keep those keys in the hands of maintenance staff. And as far as flying me over to test one, it'd probably be cheaper to just ship me a unit! :P – Polynomial Nov 09 '12 at 06:55
  • Are touch screens vulnerable to any sort of attack like say through generating a electromagnetic field in close proximity? The vending machines around me have touchscreens instead of keypads. – JimmyJames Dec 07 '16 at 19:22
  • @JimmyJames Unlikely; at best they may leak information via a differential power analysis side-channel, due to them being powered on the same rail as the CPU, though I'd suspect that other noise, line impedance, decoupling caps, etc. would make it super difficult to get any reasonable results out. Then again I'm always impressed by the crazy things people pull off with EM emissions analysis. – Polynomial Dec 09 '16 at 15:12
  • @Polynomial I was thinking more along the lines of a buffer-overflow type attack. I took a cursory look at all the technologies used to build such displays and there are quite a few ways to go about it and a number rely on the electromagnetic properties of our fingers. Perhaps someone could simulate presses on the screen at a much higher rate and concurrency than was deemed possible from a human user, or something like that. The systems running the vending machines I'm familiar with seem very languid. – JimmyJames Dec 09 '16 at 15:29
  • @JimmyJames Very unlikely. That's not generally how buffer overflows work; at worst it'd be a memory exhaustion DoS, unless they implemented an input queue and did so incredibly horribly, and even then I highly doubt it'd be exploitable. – Polynomial Dec 11 '16 at 16:20
6

Vending machine hacks, like attacks against any hardware device, are specific to a given manufacturer and model.

As for buffer overflows: any input device (including keypads, etc.) could theoretically be leveraged in such an attack. Whether or not a given model is susceptible would depend on how the machine was built. But older vending machines are simple state machines with no concept of a buffer (or even a CPU), so attacks against that style would probably leverage some other corner case.

The most common attacks against a vending machine involve more physics than computer skills to physically circumvent security measures. Another type of attack leverages certain sensing features to "confuse" the machine as to whether product has been delivered or how many are being delivered. Another type of attack takes advantage of normally-hidden administration features or interfaces to steal product.

tylerl
  • 82,225
  • 25
  • 148
  • 226
1

Everything everybody has said is good but one thing I would add is that this type of vending machine that is for public has to be well program orientated and when planning you have to put first the hacker attacking both physical and software aspects.

Starting from physical attack there should not be any physical cable outside. Every cable must come through the underground into the machine. There should be no physical lock with key. Locking the machine should be done by program through software engineering by infrared from outside the computer to the machine and at the back panel there should be a door that will be locked with magnet inside the machine, only the operator can open it with password and user name from his or her laptop brought to the place of the vending machine for loading and taking the money.

I'm only talking about physical aspect of it today next time I will talk about the software engineering aspect of it.

Xander
  • 35,525
  • 27
  • 113
  • 141
julius
  • 11
  • 1