Google wallet forensics

From: Elizabeth M.
Sent on: Wednesday, December 14, 2011 11:02 AM
Hi all,

Since we spent a good amount of time talking about NFC and Google Wallet in this week's informal meet-up, I am posting a summary from an article published that very same day about a quick and incomplete security audit of Google Wallet.

http://viaforensics.com/mobile-security/forensics-security-analysis-google-wallet.html

I question the conclusions of insecurity that they draw with regards to unencrypted data in the SQLite database because it is not an easy thing to pull an app's database off a phone unless that phone is rooted.  Most consumers do not unlock and root their Android phones.

I will also take this opportunity to wish you all a happy holiday and a prosperous 2012.

Best regards,
Elizabeth

Summary of Google Wallet security findings

So, in summary, here are the items of note from my high level analysis.  Bear in mind this is nowhere near the level of testing an app like this deserves but since this is done on our own time, it’s all I could manage thus far.  Anyway, here goes:

  1. A fair amount of data is stored in various SQLite databases including credit card balance, limits, expiration date, name on card, transaction dates and locations and more.
  2. The name on the card, the expiration date, last 4 card digits and email account are all recoverable
  3. [Fixed in Version 1.1-R41v8] When transactions are deleted or Google Wallet is reset, the data is still recoverable.
  4. The Google Analytic tracking provides insights into the Google Wallet activity.  While I know Google tracks what I do, it’s a little frustrating to find it scattered everywhere and perhaps in a way that can be intercepted on the wire (non-SSL GET request) or on the phone (logs, databases, etc.)
  5. [Fixed in Version 1.0-R33v6] The application created a recoverable image of my credit card which gave away a little more info than needed (name, expiration date and last 4 digits).  While this is not enough to use a card, it’s likely enough to launch a social engineering attack.

While Google Wallet does a decent job securing your full credit cards numbers (it is not insecurely stored and a PIN is needed to access the cards to authorize payments), the amount of data that Google Wallet stores unencrypted on the device is significant (pretty much everything except the first 12 digits of your credit card). Many consumers would not find it acceptable if people knew their credit card balance or limits. Further, the ability to use this data in a social engineering attack against the consumer directly or a provider is pretty high. For example, if I know your name, when you’ve used your card recently, last 4 digits and expiration date, I’m pretty confident I could use the information to my advantage. When you add data that is generally available online (such as someone’s address), an attacker is well armed for a successful social engineer attack.

And this testing was really only very high level. Far more sophisticated and comprehensive security analysis is needed to determine if other vulnerabilities are present.  In addition, privacy conscious consumers so understand that analyzing nearly everything you use Google Wallet for is basically the price you pay for the service. For a tech standpoint, it’s very exciting to see Google Wallet in production. However, it has consistently been viaForensics’ position that the largest security risk from apps using NFC do not stem from the core NFC technology but instead the apps that use the technology. In this case, the amount of unencrypted data store by Google Wallet surpasses what we believe most consumers find acceptable.


People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy