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.