Vending machines at my workplace got recently changed and the new ones support an hybrid NFC\BT system to pay through a dedicated application.

Looking for online, I found some articles about this app being cracked and how it was done. Being several months later, I expected some new security measure to have been added so I decided to have a try and see if I could bypass them and repeat the process.

Original crack consisted of manually changing the data stored locally on a DB with a weak password, but since I don't have a rooted phone and I have found traces of HTTPS requests being performed with checks on consistency on the credit, I decided to go another way.

Assumin vending machines do not connect online, I changed all the references to the remote REST endpoint (plain string constants) with a server of my own and I have successfully been able to login (or at least, make the app believe I logged in).

Now, assuming I fill the gaps and will be able to successfully buy stuff, is all this worth sharing with the developer, to have them take further security measures? Is there something serious they could do that would not require completely changing the infrastructure?

  • For your peace of mind, you should always responsibly disclose possible attacks. No need to carry out them first. – Marcel Sep 16 '19 at 5:13
  • Agree, but the question remains. Is there something that can be done against this kind of attack without changing deeply the infrastructure? – bracco23 Sep 16 '19 at 5:16

Now, assuming I fill the gaps and will be able to successfully buy stuff

That's a pretty big assumption. But if the app does have enough information locally to command a vending machine to dispense product, this suggests that the vending machine may not be performing any complex validation locally, and that the mobile phone has been left in charge of security. (Or that the vending machine is only validating the presence of the mobile app, not the involvement of the server.) If so, this may be hard to fix.

A reasonable security architecture for an application like this would run along the lines of:

  • The vending machine generates a nonce which includes its serial number and some random data, referred to as the "token".
  • The mobile phone retrieves this token from the vending machine and passes it on to the web server, possibly along with other data like payment information.
  • The web server verifies that the user has paid, then signs the challenge with its private key and returns it to the mobile phone.
  • The mobile phone passes the signed token on to the vending machine.
  • The vending machine verifies the signature on the token using the server's public key (which it has stored internally), verifies that it has not seen the token before, then dispenses product.

Since the vending machine will not accept a token which isn't signed with the server's private key, and it will not accept a token that came from another machine or which was already used on the same machine, there's no way to get it to dispense product without going through the intended workflow.

(The use of a nonce is required to prevent a user from reusing a token which was previously used, either for the same machine or another one.)

  • This would definitely be a secure architecture difficult to tamper with manipulating the app, didn't think of it! – bracco23 Sep 16 '19 at 6:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.