One other purpose of access cards at work is a cashless payment system for the canteen and vending machines. There are clear advantages – cash requires keeping a float for change, cashing up, auditing, storing etc. There’s also less obvious benefits – in most food outlets staff aren’t allowed to handle cash and food, but this is no longer a problem with a cashless payment system where the card holder simply inserts the card in a reader whilst the member of staff operates a clean till.

Historically these systems have been pretty poor from a security standpoint. At school, a smartcard based system was introduced for school dinners and the tuckshop. The value was stored on the card, and it wasn’t long before one of the PS/2 card readers was liberated and drivers found. The card were simple memory cards, and it only took a few snapshots after making purchases to work out where the value was stored and to modify it. If I remember correctly, there wasn’t even a checksum, though the value was slightly obfuscated. The system was either missing backend auditing or no one was checking it.

That was 10 years ago though, and I would have hoped that the systems in use would have come on a long way. Contactless and contact cards with protected memory and microprocessors are now affordable and in common use in access control systems. For these reasons, it’s unlikely that you’ll find a card where you can just modify the stored value without having access to a private key. Several places I have worked at have such systems, though what I am going to describe here is purely theoretical, of course.

The system consists of ATM like machines for adding value the card – only debit/credit cards allowed, card readers in the shops and canteens, and card readers in all the vending machines.

If we assume that only genuine readers can modify the value on the card, then we need to somehow change the behaviour of one of these readers to our advantage. I’d rather not mess with the ATM like machines, and playing with the readers in front of staff also sounds like a bad idea. The vending machines are nice and hidden away though.

Most modern vending machines have a control board that operates the rotating springs, stores the value of items, operates the display and so on. Then there is some kind of payment module, most commonly a coin handler, sometimes a note handler, and sometimes a card reader. The modular design makes sense – it means you can sell your vending machine worldwide without having to worry about making one that deals in Zimbabwean Dollars as well as Kuwaity Dinar.

If we look at a coin handler, the operation is quite simple:

1. Insert coins
2. Value of coins is signalled to control board
3. User inputs selection
4. If value of item is lower than coins, vend item
5. If there is a problem, return coins

The coin return mechanism is simple. The coins are stored on a tray after being inserted. It is tipped one way to put the coins into the collection box, and tipped the other way to return them to the user. There’s no option to give change – it’s all or nothing.

This has important implications – there’s little need for any feedback from the coin handler to the control board. The control board says “return coins”, and the coin handler will do so. There’s no half-way house, no change or incremental payback. There is no need for any feedback from the coin handler to the control board.

Some units give change out. Generally this is a discrete coin hopper that can be instructed to give change. If you put in £1 and the product costs 60p, you should get 40p returned in change. If there is no change left in the hopper, you don’t get any change. Interestingly, you’d normally get this 40p as 2 x 20p coins. If there are no 20p coins left, but there are 10p coins, many machines won’t give you 4 x 10p coins instead. Yet if you bought something for 90p, you would still get a 10p coin returned. I suspect, again, that this is because there is no feedback from the coin hoppers to the control board – they are simply instructed to carry out an action.

So what would this mean if the payment module was swapped for a card reader? It turns out to be quite a lot.

The cards in this system are RFID cards, and the readers in the vending machine are manual insertion/removal type. Inserting the card presses a microswitch, enabling the field and reading the data off the card. I’m not sure why the field isn’t always enabled – I presume that they don’t want to have problems with long range cards being read by mistake.

One the balance is read from the card, any item lower than the value can be bought, and that amount is deducted from the card. This sounds very similar to the coin handler really – although in the example above, rather than say “give out 40p change”, the signal would more likely be “keep 60p”. What happens if the communication between the control board uses the same protocol for both payment modules?

Let’s try pulling out the RFID card just as the machine is starting to vend… nope, the machine debits the card before the vend starts, so I’ve still paid for the item.

So next step – let’s trick the reader. I’ll take my RFID card and slip a business card of the same size below it, and insert the two into the reader. The balance is read, at which point I pull out the RFID card, leaving just the business card which is still depressing the switch. I’d assumed that this attack mechanism would have been covered, but the machine vended the item fine, leaving me with the cash. I can only speculate to the cause:

1. The control board tells the reader to charge the card
2. The card reader has successfully read the card previously, and the switch hasn’t changed state, so it must be the same valid card.
3. The card reader fails to update the balance on the card as a result.
4. There is no feedback between the reader and control board, so the vend continues

This is completely in line with idea that the communication between the control board and payment module is always the same, regardless of the type. It’s treating it like coins, where the coin handler will always successfully perform the action requested. This highlights another difference between the coin handler and card reader. You relinquish control of the cash with the coin handler, but remain in control of the card with the coin handler.

So, I’ve worked out how to get free stuff from the vending machine. There have to be other ways though.

I’m sure everyone has used a vending machine and the item has hung up on the spring, resulting in the money being lost and you having no Mars Bar. Sometimes a shoulder to the machine sorts it out, but often not. These guys have thought of that though. There is a lightly sprung flap which detects the falling item. This is then used to decide if you should be charged or not.

How can this help me get free stuff? I get my money back if the flap isn’t moved by the falling item. So, if I hold the flap where it is, the item will land on it, and I won’t be charged. All vending machines have a tray which stops you putting your arm up into the product space to steal things, so I can’t just hold the flap up with my hand. But it’s easy enough to form a couple of pieces of wire which will hold the flap up with the tray shut.

This works perfectly – the card isn’t charged and we get the product. Brilliant. Yet it’s still just a free Mars Bar. Let’s take this up a notch.

Let’s think about this a bit more. How exactly does this process work? Here’s one idea:

1. Read balance.
2. Ask for product.
3. Start vending product (if product costs less than the balance).
4. If vend is successful, charge the card for the product.

There’s a problem here though – the card read is manual insertion/removal. If we remove the card between step 3 and 4, then the card never gets charged! I’ve already tried this though, and it doesn’t work – the card is charged before the vend starts.

So, how else could it work?

1. Read balance
2. Ask for the product
3. Charge the card for the product (if product costs less than the balance).
4. Start vending product
5. If vend is unsuccessful, credit the card for the product.

This is much more secure. If we assume that most vends are successful and most people leave the card in the machine until the end, nearly everyone ends up happy. Even when there is an unsuccessful vend and the card is removed, the user loses the cash but the vending machine gains it – which sounds like something a profit making company would go for.

So far, we have two working attacks:

1. Using a business card to trick the card reader into thinking the card is still there.
2. Holding up the flap so that although the product is vended we don’t get charged.

What happens if we combine the two?

First, the flap is rigged so that the machine won’t register a successful vend. Next, I insert both cards, let the balance be read, and remove the RFID card. I chose the product, which starts to vend. I re-insert the RFID card, just in time for the machine to decide the vend was unsuccessful. The machine then credits my card for the value of the item. I remove the card and release the item.

Now I have the item and I have been refunded the value of the item. This is brilliant. It’s just a bit of a shame that Mars Bars only cost 40p.

It exposes something about the internal mechanism of the card reader, and again makes me think that the communication is exactly the same as with a coin handler. There are two different ways of signalling the changes to the balance.

One is with increment/decrement signals (in line with the coin handler). This is what would happen in the refund situation:

1. Read balance – £10.20
2. Deduct 60p (balance should be £9.60)
3. Increment 60p (balance should be £10.20)

If we skip step 2, the balance will end up at £10.80 instead!

The other is with absolute values:

1. Read balance – £10.20
2. Set balance to £9.60
3. Set balance to £10.20

If we skip step 2 here, we don’t gain anything!

So, there are a number of serious flaws here.

What could they do to prevent this from happening?

• Use a motorised card reader – this means that I can’t remove the card when I want.
• Use a read that detects card presence using the RF field rather than a microswitch – this means I couldn’t remove the card.
• Send a confirmation signal from the card reader to the control board so the vend can be stopped when something is amiss.
• Change the balance using absolute rather than increment/decrement signals.
• Use a breakbeam detector rather than the sprung flap to detect the falling item – this would be much harder to trick.

Of course, backend auditing would quickly catch issues like this. But then, would they bother?

Like I say, all purely theoretical, but is it beyond belief?