Research points to Google Wallet security #fail

Attacking Google Wallet

There are many different ways we could attempt to exploit Google Wallet. However, in the interest of time, to date I have only done the following:

-Attempt Man In The Middle (MITM) attacks

-Forensically analyze data stored on the device

-Examine system logs

Network attacks against Google Wallet

While there are many different types of network attack we utilize in a full appSecure audit, for this test we only attempted the Man In The Middle attack over Wi-Fi. This was attempted at both account registration and when adding a new credit card and the Google Wallet successfully protected against the attack. Here are some screenshots of how Google Wallet handled a MITM attack.

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:

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.

The name on the card, the expiration date, last 4 card digits and email account are all recoverable.

[Fixed in Version 1.1-R41v8] When transactions are deleted or Google Wallet is reset, the data is still recoverable.

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

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

Data protection expert Mark Bower, VP at Voltage Security, read over the research and made the following observations:

“It appears that some important aspects of data security have been missed in the implementation of the Google Wallet if this report is correct. While Google Wallet presents an exciting new way for merchants to expand business, just because it’s new doesn’t make it secure.

Given the wallet is so new, the fact that they aren’t encrypting the data beyond the credit card is a real surprise in this day and age of exploits and data compromises- the risk here is not so much about the credit card number, it’s about the customer personal data – their transaction history – exactly the kind of data an attacker can use to mount a social attack on the consumer to get something even more valuable.

–Bill Brenner