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.

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

iBots? Mobile phone network 0wnage

From McAfee blog:

Some of the most interesting research on mobile botnets is being done in the lab.  Security researchers Collin Mulliner and Jean Pierre Seifert have put together a robust Proof-of-Concept (PoC) iPhone botnet. 

Their research was presented at the 5th International Conference on Malicious and Unwanted Software (MALWARE 2010) last week.  In a presentation titled “Rise of the iBots: 0wning a telco network”, Mulliner/Seifert look into various methods of establishing command and control (C&C) of a botnet over a mobile telephone company’s network.  Very timely, I added an overview of the research to my talk on Saturday at Toorcon. 

The researchers didn’t implement any spreading functionality so that there was no risk of the botnet escaping the lab. They instead concentrated on seeing which communication methods were best for maintaining a distributed computing network (like a botnet); SMS, http, or P2P.  Unlike general PC security researchers, these two have experience in the challenges and issues involved in developing for low powered, limited CPU/RAM devices with inconsistent network connectivity(EDGE, 3G, WiFi, etc.).

The SMS method, using text messages to send commands to the bots, is commonly used by other mobile spyware and botnets.  The more advanced malware will also intercept and delete any command SMS messages, so that the user never suspects that they’re infected.  Mulliner has previous experience with SMS interception, having presented his research on the topic at the Black Hat USA security conference in 2009. 

Instead of using straightforward text-based SMS messages like with other mobile malware, they use binary mode SMS. These are not system SMS messages or “flash” SMS messages that don’t leave a trail in the inbox.  They’re just SMS messages with about 140 bytes.  Sending in binary lets them encode commands in less space and also helps to make the C&C messages harder to detect.  They also determined that in addition to SMS, using a combination of P2P and http protocols could increase the robustness of the botnet. 

There’s a joke amongst malware researchers that sometimes it feels like we’re doing QA for the malware authors; calling them out on their bad code.  Malware authors aren’t generally known for following secure development or software testing processes.  Occasionally it takes a professional developer/researcher to do it right.  Mulliner’s research from Black Hat involved fuzzing SMS handlers, so it was amusing to see that they actually fuzzed their botnet’s SMS command handling code.  I guess when you’re getting ready to take over your telephone company’s network, you can’t have your botnet fail just because it gets a malformed command SMS. 

Since they used binary SMS messages, the botnet commands aren’t as easy to decode as a plain text protocol.  The table below shows the breakdown of a command SMS.  Mulliner/Seifert were careful in designing their communication protocol to insure that it was safe from replay attacks(responding only to packets with sequence numbers greater than the last command) or hijacking through command emulation(encrypting and digitally signing command messages).

Fig 1 - Binary command SMS messages are broken down into a few parts. 
Each command SMS is digitally signed to prevent hijacking of the botnet.
The sequence number helps to prevent a replay attack.
All packets can also be optionally encrypted to further evade detection. 

Below is a breakdown of the commands they implemented:

Fig 2 - A human-readable list of the binary commands used in the botnet.
Running a command can be used to DDOS a website

After seeing an attempt at a stable, fault resistant, mobile botnet, one might wonder how to protect against such a threat.  On that note, we may actually be better off taking a page from Mulliner and Seifert’s presentation:

“Mobile telcos need to think about monitoring and fighting SMS-based botnets”.

This works for threats on the network. On the individual level there are still a few ways to shut the door on attackers:

• Install the latest official OS/firmware patches for your smartphone
• Avoid pirated software or software from untrusted sources