New Blog Address

I have decided to consolidate my two blogs into one. The posts here, as well as newer posts, can be found on my blog Sailing Sidways. Please come visit this new blog for up-to-date information and posts. Thank You!

A taste of things to come

A Taste of Things to Come

For the past few weeks, I've been pondering what the face of evolving malware in the coming months will be, particularly Android-based malware. As with all malware, the level of sophistication seems to be increasing but it seems the complexity seen in Android malware isn't really that, well, complex. In my opinion, it's only a matter of time until someone "gets it right" and builds a highly effective Trojan or rootkit for the platform.

Yesterday

As with any platform, Android has had it's share of malicious software but, in the grand scheme of things, it seems to be fairly ineffectual overall. That being said, some of these existing threats have compromised the security of thousands of user's devices, exposing sensitive information to attackers. My point is simply that in the arms race of the mobile security world, it seems things are poised to become much worse if someone commits more effort to building a comprehensive tool to commit such crimes.

The first example of such a piece of software that I want to bring up is actually the result of work between Indiana University and the U.S. Navy (yeah) that is presented as a proof of threat describing a new type of 'visual malware' called PlaceRaider. This inventive tool would aid a wise burglar by helping build a 3D view of the target location, recording sensitive information that the device's camera and microphone pick up. Scary, even if a little far fetched for the average burglar. In the whitepaper, they go into detail about some means to defend against such 'visual malware' but all of them require changes to the way Android operates in a fairly fundamental way and that are unlikely to happen. You can find a write up on PlaceRaider here and the whitepaper directly here.

The next concept is a tool that could monitor the keystrokes using the built in 3-axis accelerometer in most any Android device. This piece of hardware is responsible for detecting things like rotation, linear acceleration (shaking) and pitch. The concept was original conceived at Georgia Tech College and targeted the iPhone but the idea translates to pretty much any mobile device. Simply put, by detecting the subtitle pitch changes of the device whilst the keyboard is up, one can fairly accurately compute which key of the onscreen keyboard was pressed. To clarify, if you were to press a button on the screen, the X, Y and Z-axis values from the accelerometer would provide a fairly unique value that nearly identifies where on the screen the press occurred. Quite a novel use of a crucial sensor in my opinion. You can read more about the iPhone concept from GA Tech and here.

Today

Along with threats like this, there are a number of other examples of similar concepts as well as some that utilize things like the NFC functionality of devices equipped with such hardware.

What is troubling is that there seems to have been little to no response among the vendors in the security community. I presume mostly because there isn't much that can be done to mitigate these threats. Nevertheless, I seems paramount for mobile antivirus vendors to take this emerging landscape into account when they are designing their software. 

Tomorrow

I'm no psychic but it seems inevitable to me that emerging threats will start to increase in complexity and soon enough someone will create a piece of malicious software for Android that is both novel in implementation and design. The threats today seem to be poorly written and require the user to do clearly unsafe things (like permit the application to be a device administrator via the scary-looking dialog built into Android). Beyond that, they seem to lack any real decisive goal.

Here are a few things that occur to me as feasible and, to my knowledge, not in existence.

#1) The 4G botnet

Imagine, if you will, a distributed network of compromised Android devices. Given the specs of most devices today, along with the 4G speeds most have access too, it seems feasible to build a Android-based botnet or something distributed of the sort. Such a network of compromised hosts could provide a significant source for a large DDoS attack that might be launched across the cellular networks. To my knowledge, the high-speed cellular wireless networks haven't experienced being the intermediate path for a large denial of service attack. Thus, I'm not sure how well they would fair. Providers put a lot of work into handling such problems in traditional networks but I wonder how they would fair in the wake of the traffic produced by say, five thousand diversely located compromised phones launching an attack. Now, I'm not suggesting to build such a tool to test it, simply pointing out a possibly overlooked weakness. I say 'possibly' because I don't have any real information about what capacity and stress testing has been done across these networks, though I would love to hear from someone who does.

#2) Sensor Thief

Given the diverse number of interesting (well, for graphing junkies such as myself) sensors available on different devices it seems plausible for one to build a rootkit which monitors and reports back all sorts of information from the GPS, accelerometer and many other sensors available on the Android platform. Some of these values include barometric pressure, temperature, magnetic field levels, proximity, light levels and even humidity. For the most part these are probably of little concern to most users who might discover they are the victim of such a rootkit but even something like the barometer, depending on it's sensitivity and the physical location, might be able to be used to detect when the user has placed their phone down and left the room- giving a would be thief the location of the device as well as some assurance the owner isn't around. It's more theoretical but technically when a door is opened or closed in most environments there is a slight change in air pressure. Even if the sensor isn't able to detect such a change, it can certainly provide an indication if the device is inside or outside since there is a large enough variance between the outside air pressure and that inside a building.

However, some of these sensors, such as the barometer, are only available on a select number of devices. Of all of my Android devices, only my old Motorola Xoom has a barometer sensor and, sadly to my inner graphing geek, not my primary tablet an Asus Transformer Infinity TF700.

But I digress, that is a simple concept threat that seams pretty realistic to me.

Without building blueprints for the perfect Android nightmares, here are a few other general concepts that might be seen in the not to distant future:

• Makeing use of the generally unrecognized fact that Android is simply running on Linux
• Utilize a zero-day exploit to run code covertly whilst still providing some apparent 'value' to the user of the device (i.e. a game or simple content provider) -- This will provide validity to the otherwise nefarious activity generated by such a package
• With enough permissions or, worse yet, root access it could also subvert otherwise legitimate applications with on-the-fly modifications to the Application APK files or even the Dalvik interpreter or Java VM that provide application functionality for the whole system.

Prevention is the best defense

A lot of these sound fairly far-fetched given the landscape of malicious software out there for Android devices but I honestly think the bar has been set pretty low thus far. It seems new threats that come out require the user to grant the application administrative access then, with all that access, they poorly do rather mundane malicious activities. Given that, the 'antivirus' or 'anti-malware' utilities out there don't live up to the reputations of their desktop counterparts. That isn't to say there aren't decent products out there like avast Mobile Security but simply that even the good security tools don't expect to contend with threats like those described above.

Now I'm the type of guy who dumps the DEX file from an application and goes to town on it. However, short of manual reverse engineering efforts, it seems the security software out there for Android doesn't have much more than pretty basic heuristic-based analysis and definitions to go on. I don't think there are really any polymorphic variants of existing threats but it seems inevitable. Unless the authors of new malicious software kindly publish a whitepaper along with it, I'm not sure how or how long until antivirus vendors will get their hands on it if it is not as obtuse as today's malware. It seems like it might be difficult as a vendor to get a good picture of the evolving treat landscape and thus are forced to respond reactionary with new definitions. Most modern desktop antivirus products combat this problem by allowing the user to participate in some sort of 'community network' where new samples are anonymously shared with the vendor. This gives the vendors a real world view of new mobile threats and seems very valuable to me.

In Closing

Lastly, I would like to hear what others think about this. This is all just from my own perspective and, to anyone who might wish to provide some insight from the security vendor's perspective, I would love to hear about it!

The Android Developer vs. The One-Click Crackers

The Android Developer vs. The One-Click Cracker

As the developer sees it:

"I mean it's only 99 cents we're talking about. No one would go to the trouble... Would they?"

It seems simple enough, write a nifty app that does something novel put a few non-intrusive ads in it to entice regular users to upgrade to your 'ad free' version for a price that could easily be covered by the coins in most readers couches. This model has flourished despite there having been sites offering cracked or simply full copies of these pay applications for free to downloaders, from the beginning of the Android platform. But who is really going to go to all that trouble to break my application and release it for free if we are only talking about $0.99? I mean, would they?

As the cracker sees it:

"These developers pump out deceptively marketed applications that cost the user to basically load a web page in this 'application'.. what nerve."

I’m afraid it’s been happening since the dawn of paid computer applications and, will continue well beyond the Android platform. From my view, it appears there are two main types of application crackers: the well-read, creative and, to a certain extent, respectful cracker and the fly-by-night ‘one-click crackers’ who love using tools made by others that do processes they do not really understand for their own benefit. The latter has had little luck in the desktop cracking world due to the complexity of compiled binaries versus the android application which is, at best, a zipped up file (that is also a zip file) which contains instructions (Dalvik virtual machine opcodes) that can, more or less, be reversed back to a pretty readable version of the original Java source code. Yup, that easy most of the time.

Well that’s a shame but so what to do?

Not much there is to do. Users should use new technologies to keep their applications up to date with the most available software protection mechanisms and throwing a crafty trick or two in there to thwart the auto-magic tools seems like it’s enough to raise the challenge of cracking your application to the level it might just be worth the $0.99. That being said, that won’t stop it from showing up on www.downl0ad-st0len-apkz.biz. Even so, who cares? If you’re app is priced fairly, protected cleverly and often updated (requiring the pirates to go through this whole process again) it seems logical that would help any potential revenue impact. All in all, I can say for certain Google is not the correct group to blame here. Putting the responsibility of policing the internet to ensure crappy software licensing paradigms are enforced sounds absurd to me and, if you want to go all solder of fortune on these pirates, maybe the concerned developer should pursue these bandits.

I have a few ideas that might make the matter a bit more interesting for all involved that I will put up as I flesh them out but I really want to hear from both sides; I disagree that the pirate doesn’t have a voice in the matter. I mean, ultimately, they are the ones who spend most of their time dealing with any protection mechanism? What project sprint would be complete without their user stories? :)