Joshua Rubin, senior engineer with Zvelo, yesterday posted his PoC that demonstrates how he cracked Google Wallet's four-digit PIN used to authorize and process mobile-phone payments. The PIN is considered the extra layer of security that a plain, old credit card wouldn't have. But Rubin poked a big hole in that strategy: "With this attack, the PIN can be revealed without even a single invalid attempt. This completely negates all of the security of this mobile phone payment system," Rubin said in a blog post today.
In December, researchers at viaForensics said they had found that the app locally stores some payment card data in plain text, such as the cardholder's name, transaction dates, email address, and account balance.
Google Wallet lets consumers transact credit-card charges, redeem gift cards, and use loyalty membership cards in stores from their phones. To run the app, the user must type in his or her four-digit PIN when they launch they app.
While Google Wallet hides the full credit-card account number, the last four digits reside in plain text in the app's local SQLite database, viaForensics found. viaForensics also found that the app repels man-in-the-middle attacks, and at the time gave the app credit for being protected by a PIN to conduct transactions with the cards.
Zvelo's Rubin, who posted details on the PoC as well as a video of it, was able to brute-force the PIN, which was a long-integer "salt" plus a SHA256 hash.
Wallet uses near field communication (NFC), based on RFID technology, and it communicates with a so-called Secure Element (SE) stored in a chip on the device. "It's like the chip and pin model in European credit cards," says Tyler Shields, a security researcher with Veracode.
But Zvelo's Rubin says Google actually has a fix for the issue. "They have a fix and they've had it for a while," he said today in an interview. "The code is in place that requires applets on SE to be updated, and those have be signed by the device manufacturers themselves ... But it's just sitting there."
That's because it's unclear where to go from here, since by moving PIN verification to the SE, it's likely now under the purview of banks, which then would be responsible for securing the PIN much like they do for payment cards. "It's a question of whose policies it falls under," Rubin says. "If it falls under the purview of the banks, the banks have to accept the risk of doing that."
Veracode's Shields concurs. "Google is running into [the fact that] it will go under a lot of bank scrutiny, how they want to store" the data, etc., he says.
[Developers are not applying secure development lifecycle practices in mobile app production. See Secure Coding Practices Out The Window With Mobile Apps.]
So what's the risk for Google Wallet users? Although Rubin tested the hack on a rooted Android, nonrooted smartphones are not immune to this attack, he says. "All an attacker needs is access to the device and he can root it himself," he says.
Veracode's Shields says the risk of a nonrooted phone getting hit by this Wallet attack is low, however, due to the sandboxing features in the Android OS. "There's no way to get to it without rooting the phone, and that's a huge deterrent," he says. "But there have been exploits in the past inside apps downloaded from the app store that exploit your phone and root it."
In a statement, Google maintained that rooting the device is unsafe: "The Zvelo study was conducted on their own phone on which they disabled the security mechanisms that protect Google Wallet by rooting the device. To date, there is no known vulnerability that enables someone to take a consumer phone and gain root access while preserving any Wallet information such as the PIN.
"We strongly encourage people to not install Google Wallet on rooted devices and to always set up a screen lock as an additional layer of security for their phone."
Meanwhile, Rubin has some recommendations for Wallet users to protect themselves and their transactions:
1. Don't "root" the phone. That gives the bad guys one less hoop to go through.
2. Enable lock screens such as "face unlock," "pattern," "PIN," and "password" rather than just "slide."
3. Disable USB debugging.
4. Enable full disk encryption.
5. Keep the device software up-to-date, and use only official software.
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.