Tracking Mobile Malware Groups at Google

I ran across this opportunity at Google: Analyst, Android Security
https://www.google.com/about/careers/search#!t=jo&jid=66345001&

It piques my interest as one of the stated goals of the job is "[becoming] an expert in the workings of mobile malware campaigns".  A few years ago(2011) I was able to momentarily take a step back from analyzing individual samples to take a look at the state of mobile malware and how criminals and their networks profit.

The 'Mobile App Moolah' presentation was based off a number of years of data we had amassed on malware sources(e.g. geography and authors) as well as intelligence shared between other Antivirus researchers.  My strengths lay in analyzing the samples, identifying characteristics that would hint at possible origins and apparent motives of malware authors.  Other colleagues provided insight on how malware authors and organized crime set up infrastructure(i.e. monetization methods, advertising, acquisition of targets) for  turning what used to be a hobby into profitable enterprises.

How Criminals profit from mobile malware infections

From the collection of metadata I had on in the wild samples I could see how criminals operated in two large geographical regions; for ease of reference, Russian and Chinese speaking regions.  Based off of the code we were seeing the Russian zone employed simpler(though still highly successful) attacks and the Chinese zone using complex and multistage attacks.

I still had only half the picture. I could see the tactics used against victims on their smartphones, but the shared intelligence on crime networks filled in the rest. With Russian SMS sending trojans the profit turned on having easy access to vendors that provided relatively anonymous Premium Rate SMS short codes("Text 'Ring' to 12345 for the latest ringtones"). The ability to acquire a short code quickly and run a campaign(paid for by unaware victims through mobile billing) made it difficult for the perpetrators to get caught while still earning a return on their investment in developing the malware.

The Chinese attacks were complex with anti-evasion and encrypted Command and Control(C&C) channels, due mainly to competition. Competition equally from Security/Antivirus vendors and from rival organized crime. While one could easily steal 1 Yuan from a million victims and net a profit, keeping your enemies from hijacking your mobile botnet still requires a larger R&D investment(e.g. code protection, encryption, etc). The back end, or how the criminals profited also varied. Personally Identifiable Information(PII) and various chat accounts with associated wallets provided alternate streams of income versus Premium Rate SMS fraud.  Organized crime provided multiple service providers to facilitate the passage of virtual funds(QQ coins) to physical/electronic money. Resellers and fences add value to stolen data(social network accounts, credit card numbers).

This Google position appeals as they have access to a significantly larger pool of data on both malware developers and sources for malware. The first step to having victims find your new mobile malware tends to involve Google(i.e. the Play store, Google ads, getting indexed by Google, etc.). Never mind that the Android Security Team receives intelligence, samples and Proof of Concepts from researchers and the public. Whoever eventually gets the role will get some amazing insight into the Android malware underground.
----------------------

If one is interested, a video of the 'Mobile Moolah Presentation' and the slides are available. The geographic portion starts at 4:17, the 'How they profit' portion starts at 6:27.

On the Mobile Malware Lifecycle

A number of factors drive malware on new platforms. The chance for pure discovery and experimentation, the desire to be the first, a need to make an income. Truthfully these are the same reasons that drive legitimate software development. This is no surprise as malware development is a form of software development.

The accelerated pace of new platforms entering the market also accounts for a rise in malware. This also leads to a shorter lifecycle for malware and malware development. The current lifecycle, bolstered by more means of revenue generation(ads, in-app purchasing, premium services, etc.), now results in malware chasing a user's money rather than their computer resources.

The mobile malware lifecycle can be seen below:

Stage 1: R&D
The initial stage is the Research and Development stage. Here due to the similarity of legitimate and malicious software development the processes followed are the same. A developer will acquire an SDK(Software Development Kit), other development tools, and as much documentation as they can find. After an initial 'Hello World" program is written, the developer will attempt to recreate functionality on the new platform that existed on a previous one. In the case of Android, one would attempt to launch a web browser with http://www.google.com; similar to how they were able to on Windows Mobile. A malware author skilled in developing worms, trojan horses and viruses will figure out ways to achieve the same with the new SDK.

This first stage is about the exploration of new capabilities and for acquiring knowledge. As with legitimate development, this is where malware authors also share their hard won knowledge with others. Unlike previous generations though, the need for revenue will sometimes encourage the authors to move straight to the Profit-Taking stage.

Stage 2: Reuse
Generally after the first stage is passed, a move is made to evade detection. On the most basic level, where script kiddies and under-skilled malware developers lay, evasion takes the form of simple cosmetic changes(strings, colors, filenames, etc.).  This can lead to a flood of very similar variants where only the message displayed to the user is altered("You are hacked by: Skr1pt K1dd1e!").

The Resue stage can benefit from source code developed and released during the R&D stage. One of the first mobile worms, SymbOS/Cabir, had its source released by its author in the computer virus zine 29A. Though this was a release of the worm's original source code it did not result in as many modified variants as would be expected. This was due to the timing of its release and a separate,earlier reverse engineering of the source code by developer Marcos Velasco. Malware developers were able to take the Velasco code and once again through primarily cosmetic changes, recompile and create dozens of Cabir-like variants,

In some cases, as with legitimate developers, malware authors may take the source code as a starting point or example for implementing new functionality for their own productions. As with the R & D stage, the Reuse stage can be affected by the monetary needs of malware authors. Instead of producing new variants, simply adding fucntionality that steals money from users(e.g. Premium Rate SMS, unauthorized in-app purchases,stealing bank account information, etc.) may be the priority for malware authors.

Stage 3: Profit-Taking
The Profit-Taking stage is the most mature stage and can lead to the most interesting(at least for malware analysts and reverse engineers) malware. Evasion of anti-virus/anti-malware software is still a priority but it's also more necessary for other opponents. As methods of earning revenue from victims increases, infected devices become more valuable. On prior Operating Systems a malware author only needed to defeat the Anti-Virus software to survive in the ecosystem. Now if a malware author is successful in running a botnet, they now face competition and attack from other malware authors and organized crime.

This stage has its low hanging fruit in the malware that sends out Premium Rate SMS. These trojans are simple and guarantee a smaller amunt of money to the attacker. Evasion here involves encrypting the SMS numbers and shortcodes from Antimalware software.

More complex attacks involving botnet infections that can deliver false ad-clicks(draining a competitor's ad budget) or fake reveiws(driving up installs for a client's buggy app) make tempting targets. An opponent can take over the command channel of a botnet from the botmaster and redirect the adclicks or re-transfer stolen money.

This competition then leads malware authors to invest funds in countering competition and Antivirus/Antimalware. Profits drive research into new evasion techniques and offensive capabilities(e.g. removing/deleting Antimalware from a device). It also drives attackers to investigate new platforms, which starts the malware lifecycle all over again.

Adding more bounce to Bouncer

It's said that one shouldn't complain about something unless one is prepared to/or ready to provide solutions. In the case of Google's Bouncer a number of security researchers have performed analyses of the defensive system and figured out where the weaknesses lie. Attackers can take advantage of discoveries like this, but usually one expects that the software publisher will try to fix these vulnerabilities.  In some cases this can be difficult, where the problem is just too difficult with current methods. when that happens one would need to develop new techniques to solve these existing problems. This week two groups of researchers have done just that, publishing their research on detecting Android threats. Both solutions would require changes(for the better) to Bouncer and Android.


(One way to) keep Flappy Bird from taking complete control over your phone: Finding Root Exploits

A common method to get users to install malicious code and malware is to exploit recent news or tragedies. In the days after the Flappy Bird developer pulled the game from the app stores, there was a demand for the original or at least a good replacement. Attackers took advantage of this and produced malware that pretended to be Flappy Bird but actually contained malicious code. These were all swiftly detected by anti-malware software, but there is sometimes a window through which the bad guys can slip through. If an attacker had decided to use a root exploit, rather than just make money from sending Premium Rate SMS, they could have gotten or expanded a botnet.

Detecting such root exploits before or as you install is the first layer of defense, but there hasn't been a way to handle them once they're already on the device. Preventing the exploits from effectively functioning or failing on device would make a good second layer.  A group of researchers from North Carolina State University have come up with PREC(Practical Root Exploit Containment) as this second layer of protection. 

Attackers include root exploits in legitimate apps to take over your devices.

Credit: Flickr user greyweed licensed under Creative Commons Attribution

PREC uses profiles of normal behavior to judge if an app is "breaking" the rules.  A malicious app under Bouncer would run for an relatively long period(5-10 minutes) before executing any malicious functions. The emulation stage would time out and give a passing score to the app, while on a real device the malware could run unimpeded. The PREC system would use that emulator run to create a profile of what the app should do, including what native code is called.

These profiles would be downloaded to a user's phone or tablet when they install from the app store. A PREC client or system library would then use the profile to see if the app is sticking to the contract. An app will start running and then all calls to native code will result in that code running in a monitored thread. If it looks like the native code using a rarely used sequence(e.g. calling a root exploit binary vs. calling a game library) the system will implement a delay in the thread. The delay is increased in suspicious calls(native code that has not been or very rarely executed during the profile stage) which effectively creates a tarpit, eventually causing the exploits to fail.

The overhead from PREC is relatively low and appears to be very effective against root exploits. Since it's a behavioral method of detection, false positives can be an issue. As PREC only looks at calls to native code that isn't called very often the risk of detecting a legitimate app is quite low.

Verifying dynamically loaded code
Root exploits aren't the only native code to worry about on Android. An app can dynamically load native code and Android does not verify it. There are a number of native binaries and code that are used legitimately to speed up execution or gain access to hardware(e.g. accelerated graphics).

Researchers with iSecLab have developed methods to determine if dynamically loaded code is legitimate. Their solution offers a different way of solving the problem of unsigned code.

Android is a very open OS, similar in some way to MS-DOS. DOS due to its openness had quite a bit of malware, but its openness also allowed for the creation and addition of antivirus and other security software. Overall being open allowed thrid party developers to increase the overall safety of the DOS ecosystem. Android gives us the same opportunity.

The iSecLab answer is to provide verification or whitelisting of apps on a device. A trusted verifier or server will provide a hash for an application that passes its checks. Since Android is very open there would not be a single central server, instead users and enterprises could choose the verification servers that they trust.

Users would download a whitelist from a verification server or servers. Any loaded native code will be checked against these whitelists and unknown code would never run. Developers would just need to submit their native code files to various trusted servers


Bulking up the Bouncer
When it was first put into production Bouncer was quite effective, especially since it was a server side protection making its code harder to get to than locally stored files.. Other security researchers have shown that this is only a roadblock and not an impassable barrier.

Now that attackers have an idea what the original limitations of Bouncer were, they have developed methods to bypass detection. The methods presented by these two groups of researchers give us viable means to counter the threat posed by malware authors.  Android will need to be modified on the OS level to support these methods but that is a small price to pay for increasing the overall security of the ecosystem.

On Mobile Malware counts, detections, and similarly confused creatures

There was a fascinating article about "10 million" malicious Android apps today in The Inquirer. That certainly sounds like a large number of Android malware.  Especially with the Google Play store only having a bit more than a million apps. The good thing is that these are actually only unique infected apps(APKs), with a good portion infected by the same family or variant of a given malware(malware families consisting of multiple variants). Reading further, Kaspersky counts about 150,000 unique malware variants, an order of magnitude smaller. Still a lot of malware but not nearly as frightening. Do malware detections fluctuate that much? No they don't, in this case it's due to looking at the same threats from different viewpoints.

Polymorphic malware?
On Android, there are currently no file infecting viruses. These are the traditional viruses that infect legitimate programs. Run them and every program on your disk is infected. Over time file infectors , in order to avoid detection, modified or uniquely encrypted their code upon each infection leading to thousands of slightly different and unique samples. We refer to these varying, differently "shaped" samples as polymorphic viruses: one virus, many forms.  Antivirus firms learned to counter this, to see the underlying original code of the viruses and to detect them.

With Android most malware are Trojan Horse programs("trojans"), single apps that pretend to be legitimate but are really malicious. As each trojan is an individual threat, it would have a single detection. This explains the 150K number, but where do Kaspersky and other antivirus firms come up with these larger numbers in the millions?

That goes back to the tricks used by file infecting viruses and something that's more common today in PC malware: server-side polymorphism.

Crimeware(Zeus/Spyeye, Carberp, etc.) on the PC faces the threat of detection. If their component malware are detected they don't infect users, and they don't steal from user's bank accounts. Antivirus/antimalware companies are good about tracking down and detecting new samples of crimeware. Collect as many samples as possible and create an all encompassing detection. Crimeware authors try to counter this by only delivering one copy of their malware to one visitor/IP address. They also modify or encrypt the downloaded code, just like older viruses.

These millions of unique Android APKs come from the same sort of technique. The malware authors distribute a unique sample to each visitor/IP address. They also make minor almost cosmetic changes to APKs on the server. In a lot of cases the only thing changed are some strings in the AndroidManifest.xml(the app name and permissions requested are found in here) or one or two resources(images, config files, etc.). The malware code(within the classes.dex file) remains unchanged; meaning that while the hash of the APK has changed, the code that is the malicious app is still the same. This technique does inflate the number of unique samples(hashes), but it does nothing to prevent detection.

Unique APKs vs. Unique detections
The key here might be that it all comes down to whether the user has protection on their device(e.g. phone, tablet). Without protection(antimalware, app whitelisting, app reputation, URL reputation), the total numbers of unique APKs makes a difference.  In that situation a user would need to be able to figure out for themselves if these millions of apps are malicious.

With protection and knowing that most of these "unique" APKs effectively contain the same malware, the smaller number of detections gives users a better idea of the scope of the threat. The number of total Android malware(families and variants) is outsized by the number of legitimate applications.

Given all this, if you asked three Antivirus Researchers for the total numbers of Android malware you might get four answers and they would all be right.

"Mobile Malware Plays Hide and Seek"

From McAfee blog:

Android/Obad.A is mobile malware that has been described as very complex. Truly it is one of the most complex we’ve seen because it:

• Uses Bluetooth to infect other Android devices
• Accepts commands from the attacker
• Hides from the Device Administration list

This is a good collection of malicious activities for a modern piece of malware. Is it unique, though? No, other mobile malware has propagated via Bluetooth, as early as SymbOS/Cabir. Earlier mobile botnets on Symbian, Windows Mobile, and even Android have also accepted commands from attackers’ control servers. That last item, though, disappearing from a standard listing makes Android/Obad a bit more insidious.

Hidden apps: unwelcome guests?

If you can’t find it, you can’t remove it. Nearly every other piece of Android malware that doesn’t have root access can be found and discovered. Android/Obad uses a vulnerability that keeps it off the standard Device Administration list. The vulnerability isn’t yet closed, so it’s very likely we’ll see other malware authors start to exploit it.

Peek-a-boo, I see you

Fortunately, we have added hidden-app detection capabilities to the latest edition of our McAfee Mobile Innovations app (MMI). The MMI app hosts a bunch of our other new beta features as well. Protecting private data (Data Vault), letting your devices warn you before you lose them (Smart Perimeter), and a tool to avoid dangerous QR codes (Safe QR Reader).

Select “Hidden Device Administrator Applications”
from McAfee Mobile Innovations menu.

The Hidden Device Administrator Detector searches and finds all apps that have Device Admin access, even if they’re using the vulnerability to hide from the Android OS. Once you run it, it will give you a list of all hidden Device Admin apps and the option to deactivate or remove them.

A list of all detected Administrator Apps.

Malware attempting to hide via vulnerabilities face a short life. As soon as software publishers fix the bugs in their software or antimalware apps add detection and removal, their time is up.

"House Keys Under the Doormat? Nope, in Your Phone"

From McAfee blog:

One of my friends recently locked himself out of his apartment. I found this out when I called him because although he didn't have his keys, he did have his smartphone. This was one of those times he wished he lived in one of those hotels with the Assa Abloy NFC-enabled locks.

It turns out he doesn't need to go to a hotel to open his door with a phone. Kwikset will soon be selling Kevo, a new deadbolt that can be unlocked with a Bluetooth-enabled phone. You can replace your old door locks with one of these new models. 

The Kwikset/Unikey Kevo deadbolt is controlled via a Bluetooth-enabled smartphone app. 

The Kevo lock [see demo video] is based on technology from Unikey, a winning company on the ABC TV show Shark Tank. Unikey’s background is in developing biometrics-access controls. Those controls are the ones you see on TV or in movies when a character places a palm or finger on a pad to open a door. With these locks we can all have similar technology guarding our homes.

Security Concerns
Another thing that you would notice from those same shows and movies is that the bad guys are always trying to break these high-security locks and access controls. The difficulty facing the average computer crook when facing a government high-tech lock is that there are so few of these locks to test against. Contrast those to millions of Bluetooth locks that one can buy off the shelf. The bar is much lower with Bluetooth because if they damage one lock during testing, the criminals can easily buy another one and try again.

The biggest payoff for technical attackers against a lock like this is to duplicate your keys or introduce a new one of their own. With physical keys they would need to get possession of them to make copies; with digital keys they need to break encryption and/or bypass security on the device that holds the keys (smartphone or key fob).

The deadbolts come with a single key fob, similar to car keys with transponders in them, and more can be purchased. It’s not clear yet whether, as with transponder keys, one needs to go through a complex process to activate additional fobs. The security of the fobs makes the smartphone a relatively easier target to go after.

There is an iPhone app that lets you manage both your own door key plus those of other residents (e.g., friends, house sitters, etc.) and temporary keys. Android phones also support Bluetooth. So the choice to produce the iPhone app first may have to do with the relative ease of decompiling Android apps.

iPhones are not necessarily more secure, as a knowledgeable attacker can jailbreak a phone and gain access to a decrypted version of the Kevo key app. Using tools like disassemblers, they can then seek out the methods used to secure the keys within the app and potentially reverse-engineer the protection or discover a method of creating new keys. They may also be able to force the app to accept new keys, essentially adding a master key to every one of these Bluetooth-enabled locks. That is actually not as likely as the criminal’s finding a way to attack a single target’s locks.

Future of Physical Security?
Locks are not invincible, not even high-tech locks. The more such locks are installed, the greater the incentive for robbers to break in through technical means. Why steal one set of keys if they can attack a smartphone app and steal all the keys? Fortunately, as the crooks start to take notice of such devices, so will security researchers. Unlike the bad guys, security folks will test these locks and help them improve. I’m sure my smartphone-toting, key-forgetting friend will appreciate that.

"Developer’s Root Exploit Opens Door to Some Samsung Phones"

From McAfee blog:

In the past few days, developers on the XDA-Developers forum have discovered a new root exploit for recent Samsung phones. Normally a root exploit is a good thing for advanced users; they can modify their OS to improve performance, install new and rare apps, or even patch bugs. On the other hand, novice and uninformed users can have their phones targeted by attackers looking to reduce security and steal money or personal data. Malware writers have previously taken exploits written by the legitimate rooting community and repackaged them along with their malware to gain absolute control of a victim’s device. 

XDA-Developers member alephzain discovered the vulnerability and created an exploit. A second forum member, Chainfire, packaged the exploit into an app that installed the exploit and rooted vulnerable phones. The app was later modified to disable the vulnerability to prevent an attacker from entering your phone. 

[...] 

Already exploited? Not maliciouslyWith such an open vulnerability in the wild, one might think that malware authors would be rushing to weaponize the exploit. Fortunately only Chainfire has done so, with this mobile rooting app. Currently knowledgeable phone “modders” can download and install this app to root their phones. And so can attackers, intent on stealing your personal data or money. 

To protect against the latter situation, we detect the most recent versions of Chainfire’s tool as Android/ExynosToor.A-B, and alephzain’s exploit as Exploit/ExymemBrk.A.

"Mobile Crime Doesn’t Pay–in Japan"

From McAfee Blog:

Writing Android malware can be a lucrative business for a criminal. One can create an SMS-sending Trojan horse or a botnet client and sit back to collect the money. It can also be a very brief business, leading one directly to jail. The crooks behind Android/OneClickFraud (malware that extorts users) and Android/DougaLeaker (malware that steals and forwards user data to the attacker) recently ran afoul of Japanese laws against malware and protecting personally identifiable information. 

I already paid, why doesn’t this app work?Android/OneClickFraud is a malware that pretends to be an adult entertainment app. Users fooled into downloading it expect that they’ll be able to view adult content but instead they’re presented with a request for payment. They get a pop-up every five minutes that says essentially that their payment has not yet been received. 

 [...] 

A positive signIt’s good to know that the authorities are going after the villains behind mobile malware. The work of Japanese law enforcement in finding and prosecuting the people behind these mobile threats is commendable. Although this is a good start, it’s unlikely that we’ll see all mobile malware disappear. We still see a majority of new malware coming from unregulated third-party app markets and from servers offering drive-by downloads of malware. As long as criminals can make a profit from mobile botnets and malware that can buy apps without user permission, it may be some time before we see a slowdown in such attacks.

"Android Phones Vulnerable to Loss of Data, Apps"

From McAfee blog:

Recently security researcher Ravi Borgaonkar discussed a vulnerability that caused a Samsung Galaxy SIII to return to a factory reset just by visiting a special website. Mobile phones have a number of useful codes (USSD/MMI) that can be typed on the dialer screen to bring up system information (IMEI, firmware version, etc.). Usually they are used by a phone technician to verify settings on your phone. In this case, a special code that you can type into your phone to wipe all the information off your device can also be entered by a malicious web site. Visit it with your Android phone and you end up with a factory reset. 

There are really two parts to the remote wipe vulnerability: one is the existence of USSD codes that can erase all data on a phone; the other is the ability to enter those codes with a tel: URL, rather than typing them on the phone. This is not much more complicated than using the format command on Windows to erase the entire C: drive. We don’t normally call the existence of the format command a vulnerability. However, if a digital vandal comes along and remotely executes the same format command, it’s a different story. 

Abusing the ProtocolMisuse of the tel: URL protocol isn’t new. An older variation of the attack–known as the DoCoMo 110 Dialer–appeared in the spring of 2000. When NTT DoCoMo customers visited an i-mode website, they were confronted with an image of a bomb and challenged to click it to prove their courage. Once they clicked, the phone immediately dialed the number 110. In Japan, the 110 number is the emergency number for the police. It was reported that due to this attack, real calls to the police were delayed by 3 seconds. Fortunately, most of these inadvertent callers immediately hung up. Eventually, a 20-year-old vocational school student was arrested in August of that year for setting up the malicious i-mode site. 

[...] 

Is Your Phone Vulnerable?
Determining if you’re vulnerable isn’t always easy. You would not want to enter a factory reset code yourself just to see if it worked. Losing all your personal information is a rather high cost. On the other hand, because the vulnerability is really enabled by the Android dialer, McAfee offers a test page where you can try out a nonmalicious code. If the page tells you your phone is vulnerable, download and install McAfee’s Dialer Protection app from Google Play.

"Black Hat, Other Conferences to Dig Into Mobile Security"

From McAfee blog:

This week many security researchers will converge on Las Vegas for the annual Black Hat USA, Security B-Sides Las Vegas, and DefCon security conferences. As in previous years, we’ll present and discuss many new security techniques and methods used by computer criminals, attackers, and defenders. A good portion of the new research will be related to mobile phones and devices. 

[...] 

Android Malware and ExploitsGoogle introduced an interesting security service, Bouncer, for its app market (Google Play). The company left out details on implementation or what exactly will prevent bad apps from entering the market. While this sounds like a good step to make it more difficult for attackers, this move also makes it much more difficult for security researchers to defend against those same bad guys. Security through obscurity doesn’t work and is only a delaying tactic. 

[...] 

iOS Threats and SecurityApple’s iOS has been getting progressively more secure with each new update, closing holes and adding preventive measures. We’ll hear about improvements in platform security from the manger of Apple’s Platform Security Team.
[...]
Mobile Hardware ExploitationOther talks will involve OS specifics. Researchers Stephen Ridley and Stephen Lawler bring their experience on attacking ARM processor-based devices. They will cover the research process that enabled them to create their two-day ARM exploitation training. They will attack Linux-based devices and build a test lab of devices.
Sometimes attackers don’t want to restrict themselves to one OS. The Smartphone Pen Test Framework (SPF) makes Android and Apple iOS devices into targets of a penetration test. Previously when we wrote “pen test” and “smartphone” in the same sentence, it meant that someone was exploiting a PC from a phone. Now it’s the other way around.  The framework’s creator Georgia Weidman, an innovator in offensive security research on smartphones, will demonstrate the DARPA Cyber Fast Track-funded project throughout the week. The SPF tests for jailbroken or rooted phones and other security vulnerabilities.

The Smartphone Pen Test Framework can connect to an agent on the phone to execute further attacks.

"NFC Payment Test at Olympics Will Inspire Mobile Attackers to Go for the Gold"

From McAfee blog:

Visa is testing out its PayWave contactless payment service at the Summer Olympics in London. Every athlete will get a Samsung Galaxy SIII phone enabled with near-field communication (NFC) along with Visa’s payment app. Contactless payments aren’t new, and similar payments by mobile phone have been tested by Google with its Wallet app and other NFC smartphones. 

A Samsung Galaxy SIII will be given to every athlete competing at the 2012 Summer Olympics in London. 

[...] 

The Samsung Galaxy SIII goes on sale in North America and worldwide within the first two weeks of July. An attacker wishing to target the device can purchase one easily and use Mulliner’s research to help find vulnerabilities and eventually develop exploits to steal a victim’s credit card. The large number of readers at the Olympics will provide places where a successful attacker can use stolen credentials to make purchases. The Olympics will also provide a concentrated pool of targets (people and phones) to pilfer from–especially if everyone is busy watching who wins the medals and not worrying about where his or her phone is.