Google Wallet Security: PIN Exposure Vulnerability

Google Wallet Security: PIN Exposure Vulnerability

Near Field Communication (NFC) Payment System Overview

The NFC payment system works with existing “contact-less” readers like MasterCard’s PayPass. It shouldn’t come as a surprise if most next generation smartphones include this capability. People will likely use cell phones instead of physical credit cards to make in-person purchases within the next two years.

There are many benefits to using smartphone payment systems as opposed to a physical credit card – not the least of which is the potential for much better security. Credit cards traditionally have no security. It is up to the owner to report theft and unauthorized transactions.

So far, the only publicly available NFC-based payment system in the U.S. is “Google Wallet.” It is only officially available for one smartphone and on one wireless service provider – the Samsung Nexus S 4G on Sprint. There have been many discussions of the fact that the other three major networks (Verizon, AT&T and T-Mobile) disallow the Google Wallet app on their networks. One possible reason for this is that these three networks are engaged in a joint venture called ISIS that is a direct competitor of Google Wallet. Also of note is that very few cell phones have NFC capability today, but that is rapidly changing with the advent of smartphones like the Samsung Galaxy Nexus. Furthermore, it seems that very recently some carriers like AT&T may be changing their tune and may eventually allow Google Wallet on devices on their network.

NFC Security Overview

As Google Wallet is the only system released to the public, its security has just begun to be vetted by such reputable organizations as viaForensics. However, their analysis has only scratched the surface. NFC is based on Radio Frequency Identification (RFID) to communicate wirelessly. In order to facilitate secure communication, a device, similar to a Smart Card, called a Secure Element (SE), is used to store and encrypt, for broadcast, the most sensitive data such as the complete credit card number. Access to the SE is highly regulated and it is designed to resist tampering, possibly even engaging a self-destruct mechanism to protect its data. This is the core security layer of NFC payment systems.

In order to authenticate users and grant access to the SE, Google Wallet requires a 4-digit, numeric PIN (Personal Identification Number) when first launching the app. This is the additional security that traditional physical credit cards do not have and is what the NFC providers are proclaiming makes the security of their system so much better. If a thief steals a smartphone, and tries to reveal the credit card information, Google Wallet will lock up completely after a few failed PIN attempts.

There are competing priorities regarding security in any NFC payment system. First of all, it must work even when there is no data network available. Imagine being unable to use a credit card, because service is not available in the store where the purchase is being made. Second, it has to be secured with a mechanism that will not discourage its use. This means that a 10-character password with uppercase, lowercase, numeric and symbol characters is absolutely out of the question because it would frustrate users to have to enter this every time they want to make a purchase. Anything that frustrates users would prevent market uptake and hurt the bottom line.

Discovering the Google Wallet PIN Vulnerability

viaForensics recently came out with a report about the security of Google Wallet. In it, they concluded that due to the unencrypted personal information and payment history, users might be subject to social engineering attacks.
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 3 rows but a large “blob” of binary data in each. The name alone, “metadata,” just seemed like a poor attempt at “security by obscurity” which as we already know, “is no security at all.”

One row in this table has id ‘gmad_bytes_are_fun’ and this appears to be a sort of encrypted file system used for storing data via the SE. The contents of the binary data in this row likely includes the complete credit card information and certainly needs further vetting, but it was not this row that interested us.

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 realized that this data was compiled using Google’s own “Protocol Buffers.” This is an open library for serializing data for messages passing between systems. In order to use this data, we had to define a “message format” in a “.proto” file (Protocol Buffer Basics: Java). 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, “TSA” (this is probably related to “Trusted Services” not the “Transportation Security Administration”) status, SE status and most notably “Card Production Lifecycle” (CPLC) data and PIN information.

The CPLC data is a vital part of the communication with the SE. However, it was yet another binary blob that would have to be deciphered, or perhaps it just acts like a “key” to unlock the SE and has no decipherable data within.

The lynch-pin, however, was that within the PIN information section was a long integer “salt” and a SHA256 hex encoded string “hash”. Knowing that the PIN can only be a 4-digit numeric value, it dawned on us that a brute-force attack would only require calculating, at most, 10,000 SHA256 hashes. This is trivial even on a platform as limited as a smartphone. Proving this hypothesis took little time.

Google Wallet allows only five invalid PIN entry attempts before locking the user out. 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.

Disclosure to Google

Upon this realization, we immediately disclosed our findings to Google who was able to confirm the issue and agreed to work quickly to resolve it.

Google was able to recognize that the only way to properly solve this issue would be to move the PIN verification into the SE itself and to no longer store the PIN hash and salt outside the SE. Google was extremely responsive to the issue, but ran into several obstacles preventing them from releasing the fixed app.

The first issue related to the SE. The SE can only run code that is digitally signed by the manufacturer. Google had to update the code that would run inside the SE and get it approved and signed by the SE manufacturers. This obviously takes some time, but was not a significant hurdle.

The next issue was much more significant. 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.

Where We Are Today

At present, the decision is in the banks’ hands. They may actually choose to accept the risk imposed by this vulnerability rather than incur the financial and administrative overhead of allowing Google to release a proper fix (and thereby potentially put the banks on the hook for the PIN security).

zvelo feels that this would be a grave mistake and would expose users to undue risk. In the meantime, the only solace is that this attack requires “root” privileges to succeed. Android has been designed such that each app runs in a “sandbox” and one app cannot access the data of another app due to the constraints imposed by kernel segregation of the “user ids” under which each app runs. In order for another app to access the data in the Google Wallet database, the device would already have to be “rooted” or it would have to exploit another vulnerability in Android, or the Linux subsystem, to read the files. This makes a remote attack very unlikely. However, a thief with this knowledge and physical access to the device could easily gain access to the PIN.

The only devices that can run Google Wallet at present are Google’s own flagship Nexus devices, the Nexus S and Galaxy Nexus. These devices are sold as “developer” smartphones and are more likely to be rooted by the user (before a theft) than nearly any other device on the market. Furthermore, virtually every single Android device on the market can be rooted with simple tools and this is unlikely to change in the future.

What Wallet Users Can Do Today

There are some steps that Google Wallet users can take today to help mitigate the risk of this vulnerability.

1. Do Not “Root” the Cell Phone – Doing so will be one less step for a thief.
2. Enable Lock Screens – “Face Unlock,” “Pattern,” “PIN” and “Password” all increase physical security to the device. “Slide,” however, does not.
3. Disable USB Debugging – When enabled, the data on mobile devices can be accessed without first passing a lock screen challenge unless Full Disk Encryption is also enabled.
4. Enable Full Disk Encryption – This will prevent even USB Debugging from bypassing the lock screen.
5. Maintain Device Up-To-Date – Ensure the device is current with the latest official software. Unfortunately, users are largely at the behest of their carrier and cell phone manufacturer for this. Using only official software and keeping devices up-to-date is the best way to minimize vulnerabilities and increase security overall.

Conclusion

zvelo feels that the fact that this attack requires root permissions does not in the least bit diminish the risk it imposes on users of Google Wallet. Our reasoning is simple: Presently, the PIN is easily revealed, but with the proper fix in place, the PIN will be nearly impossible to crack. It is as simple as that.

The following video shows how simple it is to reveal a user’s Google Wallet PIN:
Google Wallet Security: Demo of PIN Exposure Vulnerability