Tag Archives: android

How to create the perfect REST API documentation #apicraft #api

Somehow I’m pretty pumped about the fact that I was able to just create a markdown file that describes my API (blueprint), adjust and run my integration tests driven by it (dredd), and once everything passed, simply ship it to my partners/users/contractors knowing that it will be a 100% up-to-date, readable and actionable documentation.

I’m also pretty sure that somehow, somewhere this totally breaks HATEOAS (of the “this ish documents itself” school of thought), and that maybe Swagger or something else might handle some use cases much better, but for now I’m just going to enjoy the fact that once the tests are done, I can just point all the parties involved to one file, followed, in full confidence, by the magic word – RTFM!

a way to slowly sunset the open source competition #android

One has to wonder about the future and the motivation for the open source Android anymore. Some conspiracy-theory-inclined folks have speculated that the master plan all along has been to attract people to the open-source Android, then slowly get the thought leaders/developers hooked on Google Play Services with proprietary lock-in i mean value add. Surprisingly, leaving gaping holes in what seems to be a poorly maintained open-source alternative codebase fits right into such hypothetical plan:

Currently, there is not much that users can do to avoid this problem. They can opt to use [mobile] browsers that are not affected by this vulnerability, such as Chrome or Firefox.

…and then just let FUD as well as real security fiascos put the open-source alternative to rest. Of course, personally I’m not into conspiracy theories, but it would be upsetting if the events took a turn in that direction. As a user, I chose Android because it’s very hackable in a good sense, and because it’s open. It would be really sad to see any of that change.

nth world problems

A pretty healthy number of downloads for an Android app on this planet (btw not the only app in the range)

Screen Shot 2014-08-27 at 11.05.14 PM

Bet that adds some motivation for an extra day or two of some independent pen testing. Also bet Google didn’t spend too much time sweating the impending int32 overflow when they first rolled out those counters.

An #Android SMS Trojan that’s apparently not #malware

So I’m looking at this ad network, and I notice that some of its ads lead up to an Android binary download. Shady, right? Just the fact that there is an ad leading to a sideloaded APK is already pretty disturbing. I look around, find a whole family of those apps. For each app, at least half of all Virustotal vendors mark it as an SMS trojan, and so does Lookout.

So we contact well-meaning people who might be interested in hearing about those apps. They tell us it’s a false positive. I go back saying there is no way this could be a false positive, these apps send paid SMS messages and are recognized by top vendors as an SMS trojan. They argue back and still claim it’s an FP. So I run one of the apps in a sandbox, it’s basically a bunch of porn, but the first thing that shows up is a warning saying if the user continues with this app, it will charge X dollars via paid SMS for each video viewed. So I guess if they warn the user upfront about this, then they are legit?

So it seems, in this particular industry, it’s one way to bill the users. So going back to the
definition of mobile malware, how on Earth were the AV scanners supposed to read that initial warning to the user? By all characteristics available to machines, this app looked and acted exactly like an SMS trojan. That’s more bad news for mobile antivirus: since a large part of apps’ functionality is hidden on the server side, unavailable for signature matching, you end up over-analyzing whatever is left accessible to you on the device and detection starts to fall apart.

So what is mobile #malware exactly?

Sifting through endless Virustotal scans, you realize that it’s not easy at all to define what exactly mobile malware is. Literally 90% of antivirus-reported malware APKs are nothing but trivial or repackaged apps with some annoying adware library slapped on top of it that doesn’t even do anything really bad. Why exactly is mobile malware so elusive and not as clear-cut as the good old desktop viruses? A couple of things come to mind:

  • The juicy parts often stay remote: unlike the classic desktop viruses and rootkits, a lot of mobile functionality remains on the server. So an app collects your banking password and sends it to server, that’s bad, right? Not if it’s a Bank of America server. What if it’s an Akamai or an EC2 server? What if it’s a Mint finance app server? This gets blurry really fast. Same with location apps – when an app constantly sends your location to a server, it’s cool if it’s your own account, and it’s suddenly not cool at all when someone else has access to that information on the server. Hard to automatically tell that just by looking at the mobile app tip of that iceberg. That’s why AV vendors came up with a euphemistic label “surveillanceware”, which means, “I have no idea if this app is bad or not, you have to look at it in your own context”.
  • No need to get sophisticated: most of what’s labeled as mobile malware are small-time scams. In the mobile world, there is no such thing as a multi-million dollar botnet industry commercially used for:
    • running spam
    • staging DOS attacks
    • collecting and laundering information

    I guess mobile can be useful only for the last point right now, we’ve yet to see the first two on mobile. So no need to build autonomous sophisticated botnet clients that pack tons of revealing functionality and patterns with them. Consequently, a lot of mobile scams look rather plain and not very different from regular apps.

  • No silent infections: it’s pointless to do port scanning and hard to use drive-by browser exploits on mobile. Combined with no incentive to make things complicated, the main vectors to get into someone’s phone are social engineering and brand abuse. Both of those are difficult to detect automatically, leaving a huge gray zone. Even the SMS scams: lots of legitimate apps have “share via SMS” functionality, good luck telling that from malware propagating itself via SMS, or sending messages to paid numbers that only become plaintext right before the message is sent.

So this leaves the traditional antivirus vendors especially helpless on mobile, best they can do so far is to report noisy adware or a few true malicious outliers that get outside the gray zone.

auto-clicking on things with #monkey #android

Android is nice because you can script the hell out of any part of it, and mess with the apps dynamically in any number of ways. For scripting the inputs, there are at least three ways to do it.

The good ol’ monkey with its monkeyrunner is the first thing that comes to mind: device.touch(x, y, ‘DOWN_AND_UP’) Sadly though, only some elements in a real app will honor monkey requests. After some logcatting we see how a monkey goes about generating a click:

D/MonkeyStub(12294): translateCommand: tap 551 1812
I/InputDispatcher(  714): Delivering touch to: action: 0x0
D/lights  (  714): button : 1 +
D/lights  (  714): button : 1 -
I/InputDispatcher(  714): Delivering touch to: action: 0x1

compared to a real tap on a screen:

D/InputReader(  714): Input event: value=1 when=2124062362000
I/InputReader(  714): Touch event's action is 0x0 (deviceType=0) [pCnt=1, s=0.122 ] when=2124062423000
I/InputDispatcher(  714): Delivering touch to: action: 0x0
D/lights  (  714): button : 1 +
D/lights  (  714): button : 1 -
D/InputReader(  714): Input event: value=0 when=2124153701000
I/InputReader(  714): Touch event's action is 0x1 (deviceType=0) [pCnt=1, s=] when=2124153701000
I/InputDispatcher(  714): Delivering touch to: action: 0x1

For those app UI elements that refuse to be monkeyed with, we can work with lower-level input events. One approach is to record a real tap (or any input sequence for that matter) with adb shell getevent and replay the same sequence with setevent like shown here. An easier approach is to simply use adb shell input with x and y:

adb shell input touchscreen tap 500 800

which gives us apparently a more palatable tap, and the following logcat output:

D/AndroidRuntime(16262): Calling main entry com.android.commands.input.Input
I/Input   (16262): injectMotionEvent: MotionEvent { action=ACTION_DOWN, id[0]=0, x[0]=500.0, y[0]=1870.0, toolType[0]=TOOL_TYPE_UNKNOWN, buttonState=0, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=3300706, downTime=3300706, deviceId=0, source=0x1002 }
I/InputDispatcher(  714): Delivering touch to: action: 0x0
D/lights  (  714): button : 1 +
D/lights  (  714): button : 1 -
I/Input   (16262): injectMotionEvent: MotionEvent { action=ACTION_UP, id[0]=0, x[0]=500.0, y[0]=1870.0, toolType[0]=TOOL_TYPE_UNKNOWN, buttonState=0, metaState=0, flags=0x0, edgeFlags=0x0, pointerCount=1, historySize=0, eventTime=3300706, downTime=3300706, deviceId=0, source=0x1002 }
I/InputDispatcher(  714): Delivering touch to: action: 0x1

Happy clicking!

Brand-stealing apps

With Google Play tightening the security side with Virustotal and Bouncer (when the latter doesn’t crash, that is), you don’t see as much outright malware in that store anymore. However, one type of scammy apps that I still run into every week or so on Play are the ones that wrap some popular service, trying to get a cent or two from Admob.

Basically, it takes about 15 minutes to wrap any popular bank’s or web service’s mobile version in a WebView, stuff it with official-looking keywords, logos and descriptions, and publish on Play. Google can’t really do anything about it short of manual review of every single app. So anyone in the world (including some really not-so-well-off countries) who can write “hello world” for Android and subscribe to Admob, can then whip up a fully functional wrapper of a bank’s website, publish it in the US on Play, get a few hundred downloads from searches, and start collecting the Admob revenue.
For an extra bonus, they can also resell their install base to the real bad guys who can push a small update to the app and start stealing the actual credentials of the bank’s users. I don’t see an easy solution to this except the brands monitoring popular stores, and also trying to limit access to their services via WebView-like clients to at least raise the bar a bit for scammy developers. Because right now publishing a legit-looking service clone is ridiculously easy.