X
Business

Hack exposes Google Wallet PIN

A vulnerability within Google's NFC-based payment system, Wallet, has been exploited by a piece of proof-of-concept software that can expose a user's PIN in a matter of seconds, giving unauthorised persons potential access to a user's mobile-banking hub.
Written by Luke Hopewell, Contributor

A vulnerability within Google's NFC-based payment system, Wallet, has been exploited by a piece of proof-of-concept software that can expose a user's PIN in a matter of seconds, giving unauthorised persons potential access to a user's mobile-banking hub.

Google Wallet is an app developed by the web giant, which, in tandem with Citibank, stores payment card information for users to make purchases using their mobile phone instead of a traditional transaction card. The app requires a PIN code to gain access to the secure element. If a thief steals the device, they won't be able to see the card or the personal data without this four-digit PIN.

Security firm Zvelo did some digging into the security of Google Wallet after a report from viaForensics revealed that users may be at risk from social-engineering attacks that could see their personal information and payment histories exposed. Zvelo found that the app's metadata has some interesting stories to tell.

We were intrigued by the findings from viaForensics, and decided to do a bit of digging of our own. We were quickly able to independently confirm the findings of viaForensics. As we investigated the data stored in the per-app (sqlite3) database used by Google Wallet, we became intrigued by the contents of the "metadata" table that contained only three rows, but a large "blob" of binary data in each.

Another row had an ID of "deviceInfo", and appeared to have much more non-null data. However, this binary data had to be parsed somehow to uncover its contents. After some more digging, we realised that this data was compiled using Google's own "Protocol Buffers". This is an open library for serialising data for messages passing between systems. In order to use this data, we had to define a "message format" in a ".proto" file.

With our custom ".proto" file in hand, we were able to uncover the contents of the binary data, and were shocked at what we found. Unique User IDs (UUID), Google (GAIA) account information, Cloud to Device Messaging (C2DM, also known as "push notification") account information, Google Wallet Setup status ... and PIN information.

Zvelo developed a piece of software designed to run on rooted Android devices that would take advantage of the hole in the Wallet app, and produce the user's PIN in a matter of seconds. Zvelo demonstrated the capability of the app, and advised users that it would only work on rooted devices for the moment.

The security firm took its findings to Google, which responded to the problem immediately.

Google sought to move the PIN from its unsecured location in the metadata hash, and inside the secure element itself. This, however, presented new problems involving Google's relationship with the US banks that had partnered with Google.

"Basically, by moving the PIN verification into the SE itself, this might constitute a 'change of agency' responsible for keeping the PIN secure. The fear is that Google might no longer be responsible for the security of the PIN, but rather the banks themselves. If this is in fact the case, then the banks may need to follow their own policies and regulations regarding ATM PIN security, which, obviously, and rightly, receive a great deal of scrutiny," Zvelo wrote in its blog post.

At the time of publication, banks have not made a decision as to where they would have the PIN stored in Google Wallet. In the meantime, Zvelo encourages users to employ the in-built security features of Google's Ice Cream Sandwich version of Android, and disable USB Debugging, as it can give a thief access to a device without having to pass a lock-screen challenge. The security researchers also recommend that users do not to root their devices, saying that "doing so will be one less step for a thief".

Editorial standards