Another EUSecWest NFC Trick: Ride the Subway For Free

itwbennett writes "At the EUSecWest security conference in Amsterdam, researchers showed how their 'UltraReset' Android app can read the data from a subway fare card, store that information, and reset the card to its original fare balance. The researchers said that the application takes advantage of a flaw found in particular NFC-based fare cards that are used in New Jersey and San Francisco, although systems in other cities, including Boston, Seattle, Salt Lake City, Chicago and Philadelphia, could also be vulnerable."

Comments

Re:More like...

[snowraver1]

How would anyone ever catch you? These systems probably don't have network access, otherwise they would just read a token and then authenticate against a server, so all you have is log files. You could detect the fraud after the fact (if you somehow collected the log files), but to actually catch someone red handed would be pretty difficult.

Even if you did collect the log files, they may be useless. You would have to catch the same non-reloadable card bring used more than the maxumum number of times. To do that, you would probably have to analyse hundreds, if not thousands of .log files from different devices, unless the transactions are somehow manually collected and uploaded into a database. Even then, it would be an after-the-fact type thing.

Re:Balance on the card?

[swillden]

Why on earth would anyone store the balance on the card you give to customers? Isn't that kind of an open invitation to exploitation not to mention customer service headaches from people losing/damaging their cards?

There are lots of reasons that you might want to store the balance on the card. Increased reliability in the face of network outages, improved performance by eliminating the need for a network round trip and a database query, the ability to deploy in environments without network access at all, the ability to cross incompatible system boundaries... and many more.

Further, if you do it right, there's no reason not to store the balance on the card. Smart card chips like those used in these fare cards are designed to provide a fairly high degree of security. They can perform cryptographic operations to authenticate the commands they're given, and they can make decisions about whether or not they're going to honor the commands based on authentication and on the content of the request and its context (to the degree that they're aware of context).

But building smart card systems is hard, and making them secure adds another layer of complexity and frustration when things just don't work because the damned card keeps rejecting your -- you believe -- properly authenticated and formatted commands. It's normal for the early stages of development to disable security for ease of development and testing... and it's unfortunately pretty common for security to be left off, or at least not thoroughly validated, for deployment. And it mostly works, because contactless smart card readers are relatively rare -- they're not expensive, mind you, haven't been for many years, but they have been uncommon. Except now there's one embedded in every one of an increasing number of high-end smartphone models.

This isn't a fundamental architectural flaw, it's either a detailed design flaw or (very likely) a straight up implementation error. Most likely caused by simple laziness and incompetence (granted that finding competent people in this area of technology isn't trivial, and self-education is a multi-year process).