Is there a way to protect a supporting app against changing the REST endpoint?

Question

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?

Answer 1

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.)