zveloBLOG™ - alerts, discussions, studies, articles, white papers about the latest malware, spam, phishing scams, and other Web threats researched or detected by zveloLABS™.

zveloBLOG

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
Posted by on in Security
  • Font size: Larger Smaller
  • Hits: 183368
  • 16 Comments

Google Wallet Security: PIN Exposure Vulnerability

Cell phone-based credit card payments are a burgeoning industry. There is a great deal of backroom negotiation going on today among players like Google, Verizon, AT&T and T-Mobile. They each want to establish themselves as a middleman in what they are betting will be a trillion dollar a year industry. The stakes are very high.

 

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

 

Trackback URL for this blog entry.
  • Coldwell Banker Mid-America Group, REALTORS

    Posted by Coldwell Banker Mid-America Group, REALTORS on 24 Aug 2012
    Thanks for this exciting post. It is well written and has some great content. Do you have any others that I can go to about this subject? ...
  • Holland Roofing

    Posted by Holland Roofing on 17 Aug 2012
    I am currently working on an assignment and I have been exploring your blog for a few hours. Thank you for your post it proved helpful for me. ...
  • www.ptnet.co.uk

    Posted by www.ptnet.co.uk on 16 Aug 2012
    Part of my job requires me to stay on top of this subject. The article you have written has been beneficial in my research. Thanks a lot ...
  • drmeger.com

    Posted by drmeger.com on 16 Aug 2012
    There are so many aspects to this, and you have opened up another train of thought for me to examine. Thank you for your insight. ...
  • profitagent

    Posted by profitagent on 16 Aug 2012
    I have been interested in this topic for quite some time. I have been researching it for a couple of hours and found your post to be very interesting. Cheers. ...
  • Pons Daniel

    Posted by Pons Daniel on 11 Aug 2012
    Your post had provided me with another point of view on this topic. I had no idea that things can work in this manner as well. Thank you for sharing your perspective. ...
  • mode paris

    Posted by mode paris on 11 Aug 2012
    There are a lot of sites and articles out there on this particular point, but you have captured another side of the subject. This is good content thank you for adding it here. ...
  • clinique dentaire montreal

    Posted by clinique dentaire montreal on 10 Aug 2012
    I have to do a report for our school magazine on this topic, and your blog has been beneficial. Can you please add more reference to this point, thanks. ...
  • Website Tutorials

    Posted by Website Tutorials on 08 Aug 2012
    Your article has a lot of great information and it has really helped me with my paper for a class I am taking. Do you have any other posts about this topic? ...
  • bmoonline.org

    Posted by bmoonline.org on 06 Aug 2012
    Your article tells me you must have a lot of background in this topic. Can you direct me to other articles about this? I will recommend this article to my friends as well. Thanks ...
  • emedicalbillingandcoding.com

    Posted by emedicalbillingandcoding.com on 04 Aug 2012
    Your article shows you have a lot of background in this topic. Can you direct me to other articles about this? I will recommend this article to my friends as well. Thanks ...
  • fat loss factor

    Posted by fat loss factor on 04 Aug 2012
    This post has helped me to have another perspective. I am researching this topic for a paper I am writing. Your article provided me great insight of my topic. ...
  • orange county house cleaning

    Posted by orange county house cleaning on 02 Aug 2012
    Sometimes it is very difficult to find good content on this topic. But your post is my way to desired information, my problem is solved now. Thanks for posting something worth knowledge. ...
  • Sweetspot

    Posted by Sweetspot on 01 Aug 2012
    There are so many aspects to this, and you have opened up another train of thought for me to examine. Thank you for your insight. ...
  • guy enjoying indian trip

    Posted by guy enjoying indian trip on 01 Aug 2012
    This is a well written article on this subject. I have been looking at starting a new business and this is valuable information to help me in my decision. Thank you. ...

Comments

  • Guest
    K. K. 09 Feb 2012

    Excuse me, sir, where are your SuperUser?

  • Guest
    Guillaume 24 Jan 2013

    I wonder if the moneto app has the same issue.

  • Guest
    prashantn 09 Feb 2012

    Good this vulnerability was identified and Google is working to provide a proper fix.
    Yes, the SE(Security Element) issue has to resolved before a proper fix in place.
    Will Banks take the risk of of moving SE onto themselves, if other cost effective options are available.
    However, a beginning has been made.

  • Guest
    Arshad Noor 09 Feb 2012

    I'm honestly surprised. A reading of the basics of programming for a secure chip (such as the JavaCard or equivalent) indicates that PIN verification MUST occur on the chip. Why bother having an SE on the phone and not use it for the single most important aspect of security: access control?

  • Guest
    Braden McGrath 09 Feb 2012

    This disclosure isn't completely clear on one point - on top of the device being rooted, the app itself that is trying to read from Wallet's SQLite DB needs to have root permissions, correct? Simply installing an app on a rooted device isn't enough, that app then needs to be able to set its UID to either 0 or that of Wallet itself so it can access that data, right?

    Most of us who are running a rooted phone are smart enough to not install suspicious apps. On top of that, with a correctly rooted phone, an attempt to elevate permissions generates a prompt to the user that they can cancel or allow.

    In short, while I see the possibility for a problem here, the user would have to be pretty stupid to have trouble here (assuming the phone is still in their possession).

  • Guest
    Wallacy 10 Feb 2012

    The PIM has 4 digits, but the SHA has not, no matter the size of the PIM! Still a SHA-256.

    And Wallet controls the handshake, brute force would not be possible directly into the PIM.

  • Guest
    Shobha 10 Feb 2012

    Thanks for writting this Up.
    Very informative and helps to handle risks !!

  • Guest
    Robin Hilliard 10 Feb 2012

    Good work on figuring out that Google (incredibly) store their PIN's so poorly. If the hash salt is static, as I assume it is from your article, then this should (a) have been vetted by a security professional; (b) fully documented in open standards for peer criticism and (c) never been let into production since neither (a) nor (b) happened.

    But with respect to your earlier claim that "Credit cards traditionally have no security"?? What on earth are you talking about?

    I work developing software which implements and tests EMV-based credit card security and I can assure you that there is an enormous amount of security built into the current credit cards standards, via a range of offline and online mechanisms.

  • Guest
    David Añez 14 Feb 2012

    "traditional physical credit cards" I do not think that this implies in anyway EMV credit cards

    Quite interesting the article and surprised at the feeble attempts of security of the whole system.

  • Guest
    hugo 10 Feb 2012

    I wonder if the moneto app has the same issue.

  • Guest
    bob 11 Feb 2012

    My research w/ Google wallet vs. Isis led me to one observation; Google's SE lies inside an NXP NFC controller chip, while ISIS puts the SE inside of a UICC. A UICC is a sophisticated SIM card. I am wondering if you are aware of any security advantages of placing the SE inside the UICC vs. the NXP chip?

  • Guest
    Bob 13 Feb 2012

    I understand Google Wallet (GW)uses the NFC controller chip (NXP) that contains the SE. Meanwhile, ISIS (AT&T & Verizon NFC partnership that will compete w/ GW) plans to put the SE inside the UICC, which is a sophisticated SIM card. Do you know if there is any opinion if overall security is better/worse/same placing the SE inside the NXP NFC controller (GW) vs. a UICC (ISIS)?

  • Guest
    you got nuttin' 14 Feb 2012

    Do you realize you're logged in when you do this? This is nothing... If it's a real hack, then you should be able to do it from another device that's sitting next to this one... sorry, you got nuttin'

  • Armando Carrillo Jr
    Armando Carrillo Jr 14 Feb 2012

    Fantastic work! I appreciate your hard work!:D

    Reply Cancel
  • Guest
    Keith 16 Feb 2012

    Great piece! I’m the editor of a price-comparison website in the UK, and transactional technology has always been an interesting topic – not just for the future of credit cards, but also because Brits appear reluctant to embrace the idea of mobile phone payments. Perhaps that’s because most of our physical credit cards now contain chip-and-PIN technology already. But even then, it’s not entirely secure. Skimming devices tend to be able to extract enough details from cards to make unauthorised payments where security is less robust. It’s of some reassurance that users can take reasonable precautions to protect themselves, but the criminal world is sophisticated and Google should not be taking chances under the presumption that users are security-savvy. Many will never be.

  • Guest
    Pete 17 Feb 2012

    @Bob - yes. UICC (like most smart card implementations) provides a secure means of storing sensitive data (keys, encryption algorithms) and are very tamper proof electronically and physically. Many offline stored value schemes (generally proprietary) use smart cards for this purpose and are fundamentally secure and proven (most failures have been through weak encryption and not exposure of keys).

    POS terminal PIN Entry Devices (PEDs) have specialist secure microprocessors which securely store this data in a similar manner.

    Problem is that the telco operator (generally) owns the UICC and therefore wants to partake (clip the fee ticket) in the transaction. Google appears to want to be independent and thus has relied on the (relatively) unsecured Android environment.

Leave your comment

Guest 25 Apr 2014