Google Wallet PIN Vulnerability

Search This thread

miasma

Senior Member
Sep 22, 2009
80
31
I am finally able to disclose a major vulnerability I found in Google Wallet.

The vulnerability is that the Google Wallet PIN can be exposed without a single invalid attempt. This renders all the security of the secure element void.

Please see below for our press release, detailed blog posting, demonstration app and source code.

Feel free to ask me any questions or report any issues.

The app is also able to give you some useful information about the state of your secure element. This may be helpful for people with SE issues.

https://zvelo.com/news/press-releas...vers-google-wallet-pin-security-vulnerability
https://zvelo.com/blog/entry/google-wallet-security-pin-exposure-vulnerability
http://dl.dropbox.com/u/10770509/WalletCracker.apk
https://github.com/rubixconsulting/WalletCracker

Here is a video demonstration of the vulnerability:

We reported this issue to Google on December 21.

Google has a fix, but it is up to the banks to decide if it will be released. We are hoping the publicity will cause the banks to make the right decision.
Right now, there is a possibility that the fix will never be released.

Google believes that the change required may constitute a "change of agency" regarding who does the PIN verification (if it is done inside the secure element). If the banks then become responsible for the PIN verification, the PIN becomes subject to the same regulations and procedures as an ATM PIN. The banks may choose to accept the risk as is rather than take on the increased cost and overhead associated with the change. Please spread the word so that we might be able to leverage them to make the correct decision.

What can you do to lower your risk profile?
Reset Google Wallet from within the wallet app itself, then uninstall it (this wipes everything from the device)
-- OR -- (any one of these will help, but #1 is the most important)
1. Add a screen lock (not the slide lock)
2. Disable USB debugging
3. Enable full disk encryption
4. Unroot if rooted
5. Use only the stock ROM and ensure it is up to date
6. Install an app that gives you the ability to "remotely wipe" the device if it is lost (lookout is one example)

EDIT: DETAILS OF SECOND VULNERABILITY

Regarding the second vulnerability announced today. This is the issue where, by uninstalling or resetting the Wallet App, and then re-configuring it for the same user, they are given the chance to enter a new PIN and will gain access to the previous user's prepaid card.

We had planned on not disclosing this vulnerability until later, but since it is already public, I can report that we were aware of it as well.

We reported it to Google on January 4th and they are presently working on a fix for it.

The fix involves, partially, linking the prepaid account to the users GAIA (Google account) instead of the hardware device ID. But they still have not confirmed to me how they will challenge a user to prove their identity before re-activating a previously activated prepaid card.

Please note that this issue ONLY affects people's pre-paid accounts, not Citi MasterCard or any other type of account in Google Wallet.

EDIT 2: CLARIFICATION ON WHO IS AT RISK

We have just added a new post that details why users who have not already rooted their phones are still at risk from these Google Wallet issues. We believe there was a lot of confusion about what it means to be rooted as compared to just attaining root privileges.

The issues we bring up, surrounding privilege escalation vulnerabilities, have grave consequences for android (and all mobile device) security, not just Google Wallet.

Hopefully our discussion of these issues will make developers more aware of them before they are written into new apps.

https://zvelo.com/blog/entry/google-wallet-security-about-that-rooted-device-requirement
 
Last edited:

miasma

Senior Member
Sep 22, 2009
80
31
Google has a fix, but it is up to the banks to decide if it will be released. We are hoping the publicity will cause the banks to make the right decision.

Right now, there is a possibility that the fix will never be released.

Please see the blog article for tips on how you can lower your exposure profile.
 
  • Like
Reactions: xHausx

dmmarck

Senior Member
Apr 11, 2011
467
78
Google has a fix, but it is up to the banks to decide if it will be released. We are hoping the publicity will cause the banks to make the right decision.

Right now, there is a possibility that the fix will never be released.

Please see the blog article for tips on how you can lower your exposure profile.

Can you please clarify: why is it up to the banks? Is this not Google's application?

Regardless, I can't see why banks would not want to fix this. And really, it's just Citi/Mastercard, right?
 

miasma

Senior Member
Sep 22, 2009
80
31
Google believes that the change required may constitute a "change of agency" regarding who does the PIN verification (if it is done inside the secure element). If the banks then become responsible for the PIN verification, the PIN becomes subject to the same regulations and procedures as an ATM PIN. The banks may choose to accept the risk as is rather than take on the increased cost and overhead associated with the change. Please spread the word so that we might be able to leverage them to make the correct decision.
 
  • Like
Reactions: dmmarck

dmmarck

Senior Member
Apr 11, 2011
467
78
Google believes that the change required may constitute a "change of agency" regarding who does the PIN verification (if it is done inside the secure element). If the banks then become responsible for the PIN verification, the PIN becomes subject to the same regulations and procedures as an ATM PIN. The banks may choose to accept the risk as is rather than take on the increased cost and overhead associated with the change. Please spread the word so that we might be able to leverage them to make the correct decision.

Legally speaking, that makes perfect sense.

Thanks for the clarification, and I will spread it.
 

McDeadagain

Senior Member
Dec 22, 2011
91
26
Roswell
Thank you to the OP.

I found your article, thorough, well written, and serious without being alarmist.

I'll follow the limited steps I can take right now.

Just thinking of my phone in terms of my wallet - if I do lose it and want to prevent someone accessing anything on my phone, is there something I can do? Does Google offer a remote wipe?

I guess I can look this up on my own was just wondering how people handle it. I figure even with the pin vulnerability, the phone is still more secure than the credit cards in my wallet. I've had the numbers on those stolen without them ever leaving my possession. In fact they got my pin too - must've had a spotter at an atm or used one of the swipe readers.
 
  • Like
Reactions: Frosty666

lukegb

Senior Member
Jul 8, 2010
106
210
Portsmouth
Quick response to your bit about the CPLC:

The CPLC is checked by the Wallet start-up system and is retrieved from the SE and compared to the value stored in the Wallet database. If, at launch, this value doesn't match up, then an exception is thrown.

It doesn't appear to be parsed anywhere within Wallet itself, so the actual SE applet would need analysis.
 

krichek

Senior Member
Oct 1, 2008
204
23
"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."

That is a direct quote from one of the linked articles and I have a question. Is there anyplace where this is stated as a mandatory part of the system?

I ask because I have been working with the Wallet folks on a bug I discovered and I have been told on several occasions by several different people there that the phone must have connectivity at the time of payment for the transaction to process. Which is what has been my experience as well.
 

lukegb

Senior Member
Jul 8, 2010
106
210
Portsmouth
I am pretty certain it doesn't - I used Wallet today in a location with no mobile connectivity and the transaction went through fine, but the transaction details did not appear in the app itself until it had refreshed its data from First Data later on. Until that time, it displayed the merchant as 'PayPass Merchant' and the amount as 'Sent'.

Sent from my Galaxy Nexus
 

krichek

Senior Member
Oct 1, 2008
204
23
I am pretty certain it doesn't - I used Wallet today in a location with no mobile connectivity and the transaction went through fine, but the transaction details did not appear in the app itself until it had refreshed its data from First Data later on. Until that time, it displayed the merchant as 'PayPass Merchant' and the amount as 'Sent'.

Sent from my Galaxy Nexus

Were you using the google prepaid card or a citibank card? Also, was it you that had no connectivity or the merchant?
 
W

WiredPirate

Guest
I think it's extremely irresponsible of you to release this to the public.

Agreed.

I am reporting this thread as malicious and I hope others will do the same. It's one thing to point out the flaw, it's a completely different thing to release the apk to the public.
 

Natolx

Senior Member
Sep 1, 2010
188
20
Note sure what this is supposed to tell me about my frozen secure element. My problem is a little different in that Google Wallet freezes my NFC chip function(no NFC tags etc) until I uninstall and do a master_clear, it doesn't just throw an error in the program, the program won't even start.

Wallet Unlocker just force closes on step 4. Here's the logcat

Code:
I/WalletCrackerMain(12368): onCreateOptionsMenu
I/BGLoader(12368): publishing progress LOADING to 3 listeners
I/PinFragment(12368): got progress: LOADING
D/WalletCrackerMain(12368): creating new progress dialog
I/BGLoader(12368): publishing progress LOADING to 3 listeners
I/PinFragment(12368): got progress: LOADING
D/WalletCrackerMain(12368): updating existing progress dialog
W/InputManagerService(  191): Starting input on non-focused client com.android.i
[email protected] (uid=10019 pid=462)
D/su      (12388): 10133 com.rubixconsulting.walletcracker executing 0 /system/b
in/sh using shell /system/bin/sh : sh
D/canRunRootCommands(12368): Root access granted
D/WalletCopier(12368): installing shell scripts
D/WalletCopier(12368): making database directory: /data/data/com.rubixconsulting
.walletcracker/databases/
I/BGLoader(12368): publishing progress WALLET to 3 listeners
I/PinFragment(12368): got progress: WALLET
D/WalletCrackerMain(12368): updating existing progress dialog
I/BGLoader(12368): publishing progress ROOT to 3 listeners
I/PinFragment(12368): got progress: ROOT
D/WalletCrackerMain(12368): updating existing progress dialog
I/BGLoader(12368): publishing progress COPYING to 3 listeners
I/PinFragment(12368): got progress: COPYING
D/WalletCrackerMain(12368): updating existing progress dialog
D/WalletCopier(12368): found wallet data dir: /data/data/com.google.android.apps
.walletnfcrel
D/WalletCopier(12368): running as root: sh /data/data/com.rubixconsulting.wallet
cracker/files/rootcopy.sh /data/data/com.google.android.apps.walletnfcrel/databa
ses/walletDatastore /data/data/com.rubixconsulting.walletcracker/databases/walle
tDatastoreCopy 10133
D/dalvikvm(  191): GC_EXPLICIT freed 1371K, 17% free 25045K/30023K, paused 2ms+1
1ms
I/ActivityManager(  191): Displayed com.rubixconsulting.walletcracker/.WalletCra
ckerMain: +896ms
D/su      (12393): 10133 com.rubixconsulting.walletcracker executing 0 /system/b
in/sh using shell /system/bin/sh : sh
I/SqliteDatabaseCpp(12368): sqlite returned: error code = 1, msg = no such table
: metadata, db=/data/data/com.rubixconsulting.walletcracker/databases/google_ana
lytics.db
W/dalvikvm(12368): threadid=13: thread exiting with uncaught exception (group=0x
40a1d1f8)
E/ACRA    (12368): ACRA caught a RuntimeException exception for com.rubixconsult
ing.walletcracker. Building report.
D/ACRA    (12368): Retrieve application default SharedPreferences.
I/BGLoader(12368): publishing progress CRACKING to 3 listeners
I/PinFragment(12368): got progress: CRACKING
D/WalletCrackerMain(12368): updating existing progress dialog
I/ACRA    (12368): READ_LOGS granted! ACRA can include LogCat and DropBox data.
D/ACRA    (12368): Retrieving logcat output...
D/ACRA    (12368): Retrieving logcat output...
D/dalvikvm(12368): GC_CONCURRENT freed 1892K, 11% free 16451K/18439K, paused 3ms
+2ms
D/ACRA    (12368): Retrieving logcat output...
D/ACRA    (12368): Writing crash report file.
D/dalvikvm(12368): GC_CONCURRENT freed 1072K, 10% free 16627K/18439K, paused 1ms
+2ms
D/ACRA    (12368): Mark all pending reports as approved.
D/ACRA    (12368): Looking for error files in /data/data/com.rubixconsulting.wal
letcracker/files
V/ACRA    (12368): About to start ReportSenderWorker from #handleException
D/ACRA    (12368): Add user comment to null
D/ACRA    (12368): #checkAndSendReports - start
D/ACRA    (12368): Looking for error files in /data/data/com.rubixconsulting.wal
letcracker/files
I/ACRA    (12368): Sending file 1328751354000-approved.stacktrace
D/ACRA    (12368): Sending report 9ab7a38e-ea7f-4f53-890b-be5f576a4623
D/ACRA    (12368): Connect to https://spreadsheets.google.com/formResponse?formk
ey=dGFJR0hPMFBnVmhpTHpYbVEzVW9vT0E6MQ&ifq
D/dalvikvm(12368): GC_CONCURRENT freed 1218K, 10% free 16737K/18439K, paused 1ms
+2ms
D/dalvikvm(12368): GC_FOR_ALLOC freed 968K, 10% free 16761K/18439K, paused 17ms
D/ACRA    (12368): Setting httpPost headers
D/ACRA    (12368): Sending request to https://spreadsheets.google.com/formRespon
se?formkey=dGFJR0hPMFBnVmhpTHpYbVEzVW9vT0E6MQ&ifq
D/ACRA    (12368): #checkAndSendReports - finish
E/AndroidRuntime(12368): FATAL EXCEPTION: AsyncTask #1
E/AndroidRuntime(12368): java.lang.RuntimeException: An error occured while exec
uting doInBackground()
E/AndroidRuntime(12368):        at android.os.AsyncTask$3.done(AsyncTask.java:27
8)
E/AndroidRuntime(12368):        at java.util.concurrent.FutureTask$Sync.innerSet
Exception(FutureTask.java:273)
E/AndroidRuntime(12368):        at java.util.concurrent.FutureTask.setException(
FutureTask.java:124)
E/AndroidRuntime(12368):        at java.util.concurrent.FutureTask$Sync.innerRun
(FutureTask.java:307)
E/AndroidRuntime(12368):        at java.util.concurrent.FutureTask.run(FutureTas
k.java:137)
E/AndroidRuntime(12368):        at java.util.concurrent.ThreadPoolExecutor.runWo
rker(ThreadPoolExecutor.java:1076)
E/AndroidRuntime(12368):        at java.util.concurrent.ThreadPoolExecutor$Worke
r.run(ThreadPoolExecutor.java:569)
E/AndroidRuntime(12368):        at java.lang.Thread.run(Thread.java:856)
E/AndroidRuntime(12368): Caused by: android.database.sqlite.SQLiteException: no
such table: metadata: , while compiling: SELECT id, proto FROM metadata WHERE id
 = 'deviceInfo'
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteCompiledSql.nat
ive_compile(Native Method)
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteCompiledSql.<in
it>(SQLiteCompiledSql.java:68)
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteProgram.compile
Sql(SQLiteProgram.java:143)
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteProgram.compile
AndbindAllArgs(SQLiteProgram.java:361)
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteProgram.<init>(
SQLiteProgram.java:127)
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteProgram.<init>(
SQLiteProgram.java:94)
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteQuery.<init>(SQ
LiteQuery.java:53)
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteDirectCursorDri
ver.query(SQLiteDirectCursorDriver.java:47)
E/AndroidRuntime(12368):        at android.database.sqlite.SQLiteDatabase.rawQue
ryWithFactory(SQLiteDatabase.java:1564)
E/AndroidRuntime(12368):        at com.rubixconsulting.walletcracker.WalletDatas
toreCopyDbHelper.getDeviceInfo(WalletDatastoreCopyDbHelper.java:54)
E/AndroidRuntime(12368):        at com.rubixconsulting.walletcracker.BGLoader.do
InBackground(BGLoader.java:142)
E/AndroidRuntime(12368):        at com.rubixconsulting.walletcracker.BGLoader.do
InBackground(BGLoader.java:1)
E/AndroidRuntime(12368):        at android.os.AsyncTask$2.call(AsyncTask.java:26
4)
E/AndroidRuntime(12368):        at java.util.concurrent.FutureTask$Sync.innerRun
(FutureTask.java:305)
E/AndroidRuntime(12368):        ... 4 more
W/ActivityManager(  191):   Force finishing activity com.rubixconsulting.walletc
racker/.WalletCrackerMain
I/PinFragment(12368): onPauseFinishing
I/DataFragment(12368): onPauseFinishing
I/WalletCrackerMain(12368): onPauseFinishing
D/WalletCrackerMain(12368): dismissing ProgressDialogFragment
D/dalvikvm(  462): GC_FOR_ALLOC freed 4325K, 26% free 24261K/32455K, paused 46ms

D/dalvikvm(  462): GC_CONCURRENT freed 1832K, 25% free 24404K/32455K, paused 2ms
+9ms
D/dalvikvm(  462): GC_FOR_ALLOC freed 730K, 23% free 25147K/32455K, paused 37ms
D/dalvikvm(  462): GC_CONCURRENT freed 1313K, 21% free 25861K/32455K, paused 3ms
+15ms
D/OpenGLRenderer(12368): Flushing caches (mode 0)
D/dalvikvm(  462): GC_FOR_ALLOC freed 2028K, 24% free 24743K/32455K, paused 63ms

D/dalvikvm(  462): GC_FOR_ALLOC freed 730K, 22% free 25486K/32455K, paused 42ms
D/dalvikvm(  462): GC_CONCURRENT freed 1299K, 20% free 26170K/32455K, paused 2ms
+10ms
D/dalvikvm(  462): GC_FOR_ALLOC freed 1803K, 23% free 25187K/32455K, paused 55ms

D/dalvikvm(  462): GC_FOR_ALLOC freed 730K, 21% free 25931K/32455K, paused 40ms
D/dalvikvm(  462): GC_CONCURRENT freed 1297K, 18% free 26663K/32455K, paused 2ms
+7ms
I/ActivityManager(  191): No longer want com.android.gallery3d (pid 12001): hidd
en #16
D/OpenGLRenderer(12368): Flushing caches (mode 1)
D/dalvikvm(  462): GC_FOR_ALLOC freed 2930K, 22% free 25637K/32455K, paused 38ms

D/dalvikvm(  462): GC_FOR_ALLOC freed 2028K, 23% free 25084K/32455K, paused 36ms

D/dalvikvm(  462): GC_CONCURRENT freed <1K, 17% free 27110K/32455K, paused 2ms+3
ms
I/Process (12368): Sending signal. PID: 12368 SIG: 9
I/ActivityManager(  191): Process com.rubixconsulting.walletcracker (pid 12368)
has died.
 
W

WiredPirate

Guest
So you would rather not know that an app you may use has a vulnerability?

That's not what the thread offers, it offers the apk for people to steal from others. I would thank him for pointing out the flaw. However, he is providing an extremely malicious app to the public, he needs to be perma-banned for providing a way to STEAL from others imo.
 
Last edited:

virtualcertainty

Senior Member
Jun 16, 2011
92
21
Halifax
Agreed.

I am reporting this thread as malicious and I hope others will do the same. It's one thing to point out the flaw, it's a completely different thing to release the apk to the public.

Seconded. There are ways to be a responsible citizen and deal with this through proper channels, even publically, without releasing code that can be used to commit fraud.

OP, I hope you do well cashing in on the publicity, and I hope it doesn't cost some poor kid a pay cheque.
 
Last edited:
  • Like
Reactions: 4278

xHausx

Inactive Recognized Developer
Jul 5, 2010
6,782
4,521
Central Florida
A major step in outing a vulnerability is to create a proof of concept to show it can be compromised. Sure someone could take advantage of it, but if it was really intended to be used maliciously I can promise you that you never would have found out about it like this. It's considered a courtesy to let the company know prior to a vulnerability being outed but sometimes it's needed to motivate them to fix it.
 
  • Like
Reactions: Valynor and miasma

Top Liked Posts

  • There are no posts matching your filters.
  • 6
    I am finally able to disclose a major vulnerability I found in Google Wallet.

    The vulnerability is that the Google Wallet PIN can be exposed without a single invalid attempt. This renders all the security of the secure element void.

    Please see below for our press release, detailed blog posting, demonstration app and source code.

    Feel free to ask me any questions or report any issues.

    The app is also able to give you some useful information about the state of your secure element. This may be helpful for people with SE issues.

    https://zvelo.com/news/press-releas...vers-google-wallet-pin-security-vulnerability
    https://zvelo.com/blog/entry/google-wallet-security-pin-exposure-vulnerability
    http://dl.dropbox.com/u/10770509/WalletCracker.apk
    https://github.com/rubixconsulting/WalletCracker

    Here is a video demonstration of the vulnerability:

    We reported this issue to Google on December 21.

    Google has a fix, but it is up to the banks to decide if it will be released. We are hoping the publicity will cause the banks to make the right decision.
    Right now, there is a possibility that the fix will never be released.

    Google believes that the change required may constitute a "change of agency" regarding who does the PIN verification (if it is done inside the secure element). If the banks then become responsible for the PIN verification, the PIN becomes subject to the same regulations and procedures as an ATM PIN. The banks may choose to accept the risk as is rather than take on the increased cost and overhead associated with the change. Please spread the word so that we might be able to leverage them to make the correct decision.

    What can you do to lower your risk profile?
    Reset Google Wallet from within the wallet app itself, then uninstall it (this wipes everything from the device)
    -- OR -- (any one of these will help, but #1 is the most important)
    1. Add a screen lock (not the slide lock)
    2. Disable USB debugging
    3. Enable full disk encryption
    4. Unroot if rooted
    5. Use only the stock ROM and ensure it is up to date
    6. Install an app that gives you the ability to "remotely wipe" the device if it is lost (lookout is one example)

    EDIT: DETAILS OF SECOND VULNERABILITY

    Regarding the second vulnerability announced today. This is the issue where, by uninstalling or resetting the Wallet App, and then re-configuring it for the same user, they are given the chance to enter a new PIN and will gain access to the previous user's prepaid card.

    We had planned on not disclosing this vulnerability until later, but since it is already public, I can report that we were aware of it as well.

    We reported it to Google on January 4th and they are presently working on a fix for it.

    The fix involves, partially, linking the prepaid account to the users GAIA (Google account) instead of the hardware device ID. But they still have not confirmed to me how they will challenge a user to prove their identity before re-activating a previously activated prepaid card.

    Please note that this issue ONLY affects people's pre-paid accounts, not Citi MasterCard or any other type of account in Google Wallet.

    EDIT 2: CLARIFICATION ON WHO IS AT RISK

    We have just added a new post that details why users who have not already rooted their phones are still at risk from these Google Wallet issues. We believe there was a lot of confusion about what it means to be rooted as compared to just attaining root privileges.

    The issues we bring up, surrounding privilege escalation vulnerabilities, have grave consequences for android (and all mobile device) security, not just Google Wallet.

    Hopefully our discussion of these issues will make developers more aware of them before they are written into new apps.

    https://zvelo.com/blog/entry/google-wallet-security-about-that-rooted-device-requirement
    6
    If you guys don't want to find out just how insecure your data really is you probably shouldn't be using any apps that require root and spending time on a forum dedicated to hacking phones. If you haven't noticed finding security weaknesses like this is what we do here.

    If you don't like it then leave.

    Edit: Do NOT report this thread anymore. We are well aware of it and repeatedly reporting it is abusing the report system.

    Sent from my PG86100 using xda premium
    3
    Agreed.

    I am reporting this thread as malicious and I hope others will do the same. It's one thing to point out the flaw, it's a completely different thing to release the apk to the public.
    I understand why you would think this. We reached an impasse with Google and presently the banks are still deciding if this issue will be fixed at all or left as is.

    Google knew that we were making the announcement and was not opposed.

    Google already has a fix for the issue but is being prevented from releasing it.

    We felt that by leveraging the power of the internet, we could help influence the decision of the banks so that this issue is resolved properly and not pushed under the rug.

    Please make your opinion known to google and hopefully the fix will be released shortly.
    3
    I think it's extremely irresponsible of you to release this to the public.
    2
    Quick response to your bit about the CPLC:

    The CPLC is checked by the Wallet start-up system and is retrieved from the SE and compared to the value stored in the Wallet database. If, at launch, this value doesn't match up, then an exception is thrown.

    It doesn't appear to be parsed anywhere within Wallet itself, so the actual SE applet would need analysis.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone