Showing posts with label mobile malware. Show all posts
Showing posts with label mobile malware. Show all posts

Tuesday, September 30, 2014

Mobile Spyware: Finally criminal?

Commercial Mobile Spyware apps have been around for over a decade. They've been on every platform with the best(if one can call it that) support on the most popular Operating Systems. They're usually sold as tools to help one monitor their children or keep track of a spouse or significant other. Tracking the latter groups lean toward a gray or even a black/illegal area.

The FBI has come along to the idea that folks selling spyware(or at least mobile spyware) are committing a crime. Specifically since your phone is a telecommunications device, installing spyware on it is the same as wiretapping.  Also the CEO of Invocode(producers of StealthGenie spyware) and his employees are members of a "criminal conspiracy responsible for StealthGenie".  Fortunately, the FBI arrested the CEO in Los Angeles over the weekend.

StealthGenie is a spyware app that supports iOS, Android and Blackberry OS. Blackberry support only applies to pre Blackberry 10 devices so newer devices would not be vulnerable. The capabilities of the spyware is not breaking any new ground, we've seen all of this before and in software from their competitors.

StealthGenie's hompage - The World's Most Powerful Mobile Phone Spy Software"

Intriguingly from the Government's complaint, Invocode expected that the majority of their sales of the StealthGenie mobile spyware would be to "[s]pousal cheat: Husband/Wife of boyfriend/girlfriend suspecting their other half of cheating or any other suspicious behaviour or if they just want to monitor them.".  So mainly to monitor someone else's phone without their permission.  The FBI agents purchased a copy of StealthGenie and were able to immediately monitor the calls and text messages from another of their phones.  While investigating monitoring software from competitors of Invocode, I've also seen that they perform similarly or perform additional functions.

Speaking of Invocode's competitors, they don't seem to think highly of StealthGenie:

"...simply isn't worth the money!" - advice from other criminals?

This screenshot above is from a competitor that recommends two other mobile spyware packages in addition to itself that they prefer to StealthGenie. This implies that these are three other, possibly more powerful, mobile spyware and "wiretapping"/interception tools that are still available on the app markets. I applaud the US government going after Invocode in the "first-ever criminal case concerning the advertisement and sale of a mobile device spyware app".

Due to the gray-area uses of mobile spyware, Anti-malware and Anti-Spyware companies have had to come up with classifications to keep us from stepping on possibly legal  developers of spyware. This is mainly to avoid being sued for being anti-competitive or harming the business of legitimate monitoring software developers. It would certainly ease matters now that governments are starting to criminally prosecute producers of tools that can be used to intercept users calls and texts.

--------------

If you're curious about the legality of selling mobile spyware, the US Government cites the following sections of law:

Title 18, United States Code,
Section 2512(l)(b) (sale of an interception device)
Section 2512(l)(c)(i) (advertisement of a known interception device)
Section 2512(l)(c)(ii) (advertising a device as an interception device)

One can read the details themselves in the Federal complaint.

Thursday, August 28, 2014

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.

Mobile App Moolah - How malware authors and criminals profit


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.

Thursday, August 14, 2014

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.

Monday, February 10, 2014

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.

Tuesday, June 25, 2013

"Mobile Malware Plays Hide and Seek"


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

Saturday, November 24, 2012

"Mobile Crime Doesn’t Pay–in Japan"

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.

Wednesday, October 05, 2011

Why I don't play QR Code Roulette and you shouldn't either

From the McAfee blog:
Last year a friend had a bright idea for a party game that involved a series of QR codes in a circle on paper. He called it QR Code Roulette. Unlike the gambling game, selecting the right 2D barcode did not make you a winner. It turned out that every QR code contained a URL to an Internet shock site. As soon as I or our other friends scanned a QR code with our phones we witnessed things that probably can’t be unseen. This was a good prank, but fortunately due to my distrust of autoloading and autorunning code I had an app that previewed the URL. If the address were a risky site or malware download I could choose not to visit the URL.
 
McAfee Download URLs via QR codes arranged in a circle
These QR codes are safe. They point to McAfee mobile security downloads and our Virus Information Library. To verify, download one of the QR code apps mentioned and view the preview URL.

My friend’s little joke drove home the necessity of not blindly scanning every QR code I run across. Some of my colleagues aren’t as lucky. I was discussing a recent threat of malware distributed by QR codes with a couple of coworkers who are penetration testers. They test the security of their clients’ networks and systems nearly daily and are very skilled computer security professionals. Although both of them had QR code-scanning apps on their phone, neither had one that could provide a preview of the URL. I ended up suggesting a couple of free barcode-scanning apps that would keep them from being unpleasantly surprised.
Although distributing mobile malware through QR codes is becoming popular, it’s not a new idea. Security researcher Felix “FX” Lindner described similar attacks about three years ago at the 24th Chaos Communications Congress and DefCon 16. FX claimed that newspaper ads with QR codes are trusted implicitly by readers (“It’s in print; it must be true”) and would make a good vector for exploits and malware. The functionality that enabled the attacks was the automatic loading and following of URLs in QR codes. Point your phone at the QR code and you end up downloading mobile malware.
 
In 2007-2008 FX publicly painted a number of scenarios in which QR codes could be used maliciously. We have since seen malicious QR codes that link to mobile malware.




The risk from such downloaded malware is still relatively low, as these are not drive-by downloads. Users would still need to choose to install the JAR or APK files on their smartphones. The risk from exploits, though, is one to worry about. An attacker who places a link to a modified Apple iOS jailbreak exploit or an Android root exploit can take over a victim’s device or steal sensitive information (emails, social network credentials, credit card numbers, etc.). 
As I told my two colleagues, there are a number of free QR code- and barcode-scanning apps with preview functions for both Android and Apple iOS. The following are my suggestions for safer QR code scanners:
 
Google Android
App Author
Google Goggles Google
Barcode Scanner ZXing

Apple iOS
App Author
Red Laser Occipital/eBay
Bar-Code Roberto Sonzogni

Protecting yourself from malicious QR codes and avoiding shock sites, mobile malware, and exploits doesn’t have to be too difficult.
  • Use a mobile QR code-/barcode-scanning app that previews URLs
  • Avoid suspicious URLs (for example, domains that don’t match ads, shortened URLs)
  • Do not play “QR Code Roulette” :)

Thursday, October 28, 2010

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).
Breakdown of ibot command packet
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

 

Protecting the ‘Metaverse ecosystem’…: Openness is healthy

Meta’s Reality Labs has an opening for “Malware Reverse Engineer” . Not an uncommon role, but this particular one is a bit more specific whe...