Flaw Found in Barclays Contactless Card

ViaForensics recently discovered that user data can be stolen from NFC chips in Barclays Visa card without users even knowing about it. The investigation was done in conjunction with Channel 4 News. 

"All I did was I tapped my phone over your wallet and using the wireless reader on the phone I was able to lift out the details from your card," Thomas Cannon of ViaForensics told Channel 4 News. "That includes the long card number, the expiry date and your name. None of it was encrypted, it was simply a case of the details coming out through the air." 

Typically, this would not be enough information to perform "cardholder not present" transactions over the internet or the phone, because most retailers require the three-digit signature (CVV) code from the back of the card and a valid address. However, during the course of the research it was found that there are some major online retailers that do not require this information. 

For example, Channel 4 News was able to create a new account on Amazon's website, with a different name and billing and delivery address to the card they scanned, and was able to order and receive products without any link to the cardholder. Amazon does not require the CVV code on the back of the card to process purchases.

For more information, click here to find out more information. 

Google Patched the Security Bug

We reported the news about the security hole in Google Wallet last Thursday. Within a few days, Google provided the fix. Osama Bedier, Vice President, Google Wallet and Payments, announced yesterday that they patched the security hole in the Google Wallet. Here is the statement from Google:

First, Google Wallet is protected by a PIN — as well as the phone’s lock screen, if a user sets that option. But sometimes users choose to disable important security mechanisms in order to gain system-level “root” access to their phone; we strongly discourage doing so if you plan to use Google Wallet because the product is not supported on rooted phones. That’s why in most cases, rooting your phone will cause your Google Wallet data to be automatically wiped from the device. 

Second, we also take concrete actions to help protect our users. For example, to address an issue that could have allowed unauthorized use of an existing prepaid card balance if someone recovered a lost phone without a screen lock, tonight we temporarily disabled provisioning of prepaid cards. We took this step as a precaution until we issue a permanent fix soon.

 And just like with any other credit card, you can get support when you need it. We provide toll-free assistance in case you lose your phone or someone manages to make an unauthorized transaction.  

Mobile payments are going to become more common in the coming years, and we will learn much more as we continue to develop Google Wallet. In the meantime, you can be confident that the digital wallet you carry provides defenses that plastic and leather simply don’t.

In addition, the company also announced the ability to issue new prepaid cards to the wallet. If you have issues, call google from here. 

Good Job, Google!

Security Vulnerability Found in Google Wallet

Joshua Rubin of zvelo recently explained his research in the security of Google Wallet. Rubin discovers that a lost or stolen Android phone with Google Wallet configured could be as bad as lost a credit card.

Google Wallet is currently the only public available NFC-based payment system. It's officially available in Samsung Nexus S 4G on Sprint network. NFC is using Secure Element (SE) to store/encrypt the sensitive data, such as credit card number. It's designed to resist hacking and protect stored data.

To access SE, Google Wallet requires a 4-digit PIN at the first time launching the application. By design, if the phone is stolen, Google Wallet can lock it up completely after a few failed PIN attempts.

viaForensics first came out with a report questioning the security of Google Wallet. Then zevelo researched more in this topic and indeed found the security flaw in the Google Wallet.

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.

I am surprised to hear that Google Wallet is using sqlite db as the storage engine to save data, instead of their own db engine. Sqlite is a very good, light weight relational database, but just not strong enough to be as the base for secure database. Sqlite is open source database and all data is in one data file. It's both good and bad. Here's the link for the report from zevelo.