This was both an amusing and frightening talk. [Sam Bowne] presented How to Trojan Financial Android Apps on Saturday afternoon at the LayerOne Conference. [Sam] calculates that 80-90% of the apps provided by major financial institutions like banks and investment companies are vulnerable and the ease with which trojans can be rolled into them is incredible.
Some Background
[Sam] did a great job of concisely describing the circumstances that make Android particularly vulnerable to the attacks which are the subject of the talk. Android programs are packaged as APK files which are easy to unpack. The “compiled” code itself is called smali and is readable in a similar way as Java. It’s super easy to unpack and search this byte code using grep. Once the interesting parts are located, the smali code can be altered and the entire thing can be repackaged. The app will need to be resigned but Google doesn’t control the signing keys so an attacker can simply generate a new key and use that to sign the app. The user still needs to install the file, but Android allows app installation from webpages, email, etc. so this isn’t a problem for the bad guys either.
The Attack
So what can be done? This is about information harvesting. [Sam’s] proof of concept uses a python script to insert logging for every local variable. The script looks at the start of every module in the smali code, grabs the number of local variables, increments it by one and uses this extra variable to write out the values through logcat.
He demonstrated live on the Bank of America app. From the user side of things it looks exactly like the official app, because it is the official app. However, when you register your account the log reports the card number as you can see here. Obviously this information could easily be phoned-home using a number of techniques.
As mentioned, the vast majority of banking and financial apps are vulnerable to this, but some have made an attempt to make it more difficult. He found the Bancorp app never exposes this information in local variables so it can’t just be logged out. However, the same trojan technique works as a keylogger since he found the same function kept getting called every time a key is pressed. The same was true of the Capital One app, but it echos out Google’s Android keymap values rather than ascii; easy enough to translate back into readable data though.
The Inability to Report Vulnerabilities
What is the most troubling is that none of these companies have a means of reporting security vulnerabilities. It was amusing to hear [Sam] recount his struggle to report these issues to Charles Schwab. Online contact forms were broken and wouldn’t post data and several publicly posted email addresses bounced email. When he finally got one to accept the email he later discovered another user reporting on a forum that nobody ever answers back on any of the Schwab accounts. He resorted to a trick he has used many times in the past… Tweeting to the CEO of Charles Schwab to start up a direct-message conversation. This itself is a security problem as @SwiftOnSecurity proves by pointing out that whenever @SamBowne Tweets a CEO it’s because he found a vulnerability in that company’s platform and can’t find a reasonable way to contact the company.
There is Hope
Although very rare, sometimes these apps do get patched. The Trade King app was updated after his report and when [Sam] tried the exploit again it crashes at start-up. The log reports a verification failure. This indicates that the injected code is being noticed, but [Sam] wonders if the verification is included in the app itself. If it is, then it will be possible to track it down and disable it.
This may sound like all of us Android users should despair but that’s not the case. Adding verification, even if it’s possible to defeat it, does make the apps safer; attackers may not want to invest the extra time to try to defeat it. Also, there are obsfucators available for a few thousand dollars that will make these attacks much more difficult by making variable names unreadable. The free obsfucator available now with the Android development suites doesn’t change names of everything… local variables are left unaltered and programmers have a habit of using descriptive names for variables. For instance, BofA used “CARDNUM” in the example above.
The Slides
[Sam Bowne’s] slides and testing results for the entire talk are available under the “Upcoming Events” part of his website.
It’s like copy/pasting the html of a bank, and adding three javascripts line to send back the informations somewhere else.
It’s just standard phishing.
The certificate will be wrong, as for a web browser.
And unlike a web browser, it’s harder to get phished, because by default (just an option to tick, but with a huge warning), you can install apps only from google’s play store, which is a bit checked.
So no, it’s not a security flaw at all. They just made some code to automatically create phishing apps. hackers can do that by hand easily.
“but Android allows app installation from webpages, email, etc. so this isn’t a problem for the bad guys either.”
Well, provided the user has jumped though the hopes needed to install 3rd party apps – and yet is naive enough to install a file sent to them from a dodgy email.
“” attacker can simply generate a new key and use that to sign the app”
Which would have a different identity to any official app.
What your effectively doing is making a new app that looks like the old one no ? Ultimately I am not really sure anything can be done at the client end to stop such a thing short of locking down all installations of unapproved apps “because users are all too stupid to know better” etc etc.
Sure, you can try to make a few things harder, but at the end of the day even with no official code whatsoever you could make a clone app that looks like the real deal.
Dont install apps from sources you don’t trust, basically.
Tell that to my 14 year old with a laptop and android smartphone that has to be “cleaned up” every 3 months or so…
Can’t make everything idiot proof.
*Can’t make ANYTHING idiot proof.
Hoops? Installing apps from web links only takes two steps.
1. Click on link
2. Click “Yes, I want to install this”
Android doesn’t require jailbreaking for installing custom software. It only requires it for obtaining root access for modifying system behavior.
The real lesson here is: don’t install software from untrusted sources.
No, but android does require a user to go into settings and check a little box that says it’s okay to install APKs from “unknown” sources, which also prompts you with a dialog making sure you know the risks of what you are doing.
One would assume that by hoops he means you have to navigate through three deferent screens confirm the option before you can install anything from third party sites. By default android wont allow you to install apps that did not come from the play store. So yes their are hoops involved in order to get your android system into an insecure state where this attack can happen.
I’ve modified Android apps before, injected smali code and disabled code verification inside the application because there was some protection. But I never considered (and still don’t) this as a security flaw. If people enable third-party installations on their device (and accept the danger warning) then it’s their fault if they install infected/trojaned apps.
The android app for Bluebird, American’s Express debt card has several flaws, and absolutely no way to contact them. Their only support offer is via a 800 number, where the 3rd world script readers are clueless how to escalate a problem. No email, no contact form, even corp. HQ doesn’t have a working contact address. Avoid Bluebird at all cost.
One way to get their attention (not the droids the real people) is to make those flaws public someplace.
You can still do this with compiled code easily enough as long as you can attach a debugger. The cross platform benefits outweigh the ease of reverse engineering IMO.
What you need is decent hardware backed security. It says something about our world when the media industry can get decent and widespread hardware backed security for their DRM through widevine before the banks get it to protect our money.
There’s no way to avoid malware installs but still maintain the openness of a platform. Since Apple’s inspection still doesn’t stop all the malware I don’t see anyone getting the walled garden thing right. Android’s system is a good compromise of the two IMO, locked down by default but the user can still do what they want.
Perhaps not allowing APKs to be installed on the device by a user, only installed by usb Debugging or by apps signed as SYSTEM or by a Google-backed certificate (to allow for third party app stores) would be better.
Not at all. It makes no difference whether it’s a native app or some script in a web browser, the server must never trust anything client side. Doesn’t matter what “security” is baked into the client, it should always be treated as if it were broken already.
Easy enough for the bank to know whether it’s talking to a legitimate client or web app. Something like: sever sends a random number, client hashes it together with itself and returns hash. If server doesn’t get an identical hash to one performed locally, then refuse to talk any further.
Now train user to reject app if it doesn’t present some user info known only to the bank (one of mine appears to do just this, a picture-phrase combination) and problem is mostly solved.
I’m sure the hacked client will dutifully perform the hash with it’s own binary, rather than the original one.
Some words have been obsfucated in the article!
this talks is the equivalent of click bait news articles from newsfeed! sorry.
it could very well read: the tiny computer in your pocket can have programs installed, and if you don’t know the author, you can install mallware.
what is the news here?
if anything, this article is a silly promotion of the walled garden that apple forces on its users.
Also, to everyone saying that idiots will install anything, well, google already solved that somehow. they have their own trojan on every version of android. it is an option called “verify app”. every time you install anything on your phone, it will phone home and tell google the signature of that apk you just installed.
with that google maybe can see if there is something odd going on, but it can surely can gather inteligence on things it care, such as how many people are installing firefox with ad blockers, etc.
please, stop the inflammatory crywolf tactics that promote walled garden, obfuscated binaries, and such.
Been a victim of cyber attacks many times.
Once had my whole pc infect via the windows update system.
None of my messages were sent, none of my skype messages would appear.
My sometimes my devices would lag for no apparent reason.
And I would access websites that were fake, all the updates I receive would receive would be fake.
My system would act like it was perfectly fine but there are small signs.