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.

"Mobile ‘Wallets’ Attract Greater Interest From Thieves, Researchers"

From McAfee blog:

As mobile phones allow us to carry our money in an electronic “wallet,” they will also become a greater target for crooks. Picking a pocket is a risky endeavor for a thieves, but it will be much less so if all they need to do is bump into their victims or brush by them with a mobile phone.  Thieves are now more likely to go after both mobile payment software and phones enabled with near-field communications (NFC). However, things are not so bad; security researchers proof-of-concept (PoC) attacks against Google Wallet and Square’s credit card readers have prompted improvements in security.

Square's credit card readers recently added encryption for credit card data. 

[...] 

These latest phone enhancements have inspired an increasing interest in mobile payment security from both the bad guys and security researchers.

"Cracking Open Your (Google) Wallet"

From McAfee blog:

We suggested earlier that instead of going after the Secure Element chip and the information it keeps safe, attackers would go after the weaker point of the Google Wallet app. Security researcher Joshua Rubin has now created a proof-of-concept app, Google Wallet Cracker, that can recover the Google Wallet PIN on a rooted phone. 

Once attackers get your PIN, they have full access to any credit card information stored in the app and they can use your phone to make purchases. As a user of Google Wallet, the main security you see is the PIN. What makes Wallet easy for you to use now makes it easy for attackers to use; they can now spend your money and credit just as if your phone were an ATM card. 

How It WorksThe vulnerability involves storing an encrypted hash of the Google Wallet PIN in a database that belongs to the app. Because it’s not stored in the Secure Element chip, the only protection is Android’s user ID-based “sandboxing.” Normally malicious apps can’t access files belonging to another app, but once the phone is rooted that protection and any others are gone.

Google Wallet Cracker app checks whether the phone is rooted.

[...]

How Do We Stay Safe?Currently only Nexus S or Galaxy Nexus users can run Google Wallet. Rubin has responsibly disclosed the vulnerability to Google and the company is now working on patching Android to prevent such attacks. The Google Wallet Cracker is not publicly available. 

Google Wallet users can take a number of steps to protect themselves:

• Use a lock code/password, swipe pattern, or face unlock

• Keep your phone close and in your possession. If attackers don’t have physical access to your phone, they can’t install malicious apps or spyware.

• Install antivirus software on the phone to protect against unwanted root exploits and spyware