[Report] Monthly Malware Statistics: February 2012
Vulnerabilities in the Google Wallet payment system
In autumn 2011, Google launched Google Wallet, an e-payment system that allows users to pay for goods and services using Android phones with Near Field Communication (NFC — contactless transactions). The Google Wallet app is installed on a smartphone and the user specifies which credit card to use. To process payments, the owner of the phone must enter a PIN in the Google Wallet app and put the phone in proximity to the scanning device. The phone will then transfer encrypted data to complete the transaction.
When Google announced this new service, data security professionals voiced some doubts about security if a phone were to be lost or stolen or otherwise fall into someone else’s hands. Then, in early February, two methods used to hack Google Wallet were detected.
At first, Joshua Rubin, an engineer at zVelo detected how a PIN can be chosen if a certain person gets access to the telephone. Bank account data is stored in a special, secured section (the Secure Element) of the NFC chip, but the PIN hash is stored on the phone’s file system. Root access is needed to read the hash, and that can be gained using well known hacker tactics. Since PIN codes are just four-digit numbers, malicious users don’t need to spend a lot of time trying combinations to get the proper sequence. Once the PIN is determined, a malicious user can purchase products using the phone owner’s Google Wallet account.
Just one day after this vulnerability was detected, new information emerged about another method for gaining access to someone’s Google Wallet account on a found or stolen phone — without even having to hack the system or obtain root access. This time a vulnerability in the Google Wallet app itself was exploited. If one uses the app properties menu and deletes all of the data pertaining to the Google Wallet app, the app will request that the user enter a new PIN code the next time it is launched, and it won’t require entry of the previous PIN.
These vulnerabilities were immediately reported to Google, which suspended Google Wallet operations for several days in order to fix the problems. Later, Google announced that the app’s vulnerabilities had been fixed and the service updated. However, on 1 March, there was still no information about any solutions for the vulnerability using a scan to determine the correct PIN. In order to prevent access to the PIN’s hash, it needs to be stored in the Secure Element just like other critical bank account and credit card data. But this is where certain legal issues come into play: in this case, the banks would be the ones responsible for PIN code security within the Secure Element, not Google.
Fake Google Analytics code redirects users to BlackHole Exploit Kit
Malicious users often hack websites in order to seed malicious programs — malicious code is planted in the hacked resource’s code. All kinds of techniques are used to prevent the owners of the compromised websites from noticing anything fishy. In early February, Kaspersky Lab followed a wave of infections involving the seeding of malicious code disguised as Google Analytics code.
The fake code has a few distinguishing features:
The malicious code uses a double-dash, unlike the real address (i.e. google--analytics.com vs. google-analytics.com).
In Google’s real code, the account ID is a unique string with numerals (e.g. UA-5902056-8) and serves as the website’s unique identification code. The malicious code uses the “UA-XXXXX-X” string instead.
The code seeded by malicious users is planted at the very start of the page’s code, even before the <html> tag, while the real Google Analytics code is typically located at the end of the page.
Currently, the fake site google--analytics.com is not operational. Some hacked websites still feature the fake Google Analytics code, but it is harmless (for now, at least).
Read more >>>>