Slashdot Mirror
Mobile Banking Apps For iOS Woefully Insecure
msm1267 writes "Mobile banking applications fall short on their use of encryption, validation of digital certificates and two-factor authentication, putting financial transactions at risk worldwide. An examination of 40 iOS mobile banking apps from 60 leading banks worldwide revealed a slew of security shortcomings that also included hard-coded development credentials discovered during a static analysis of app binaries. It's a mess, and to date, most of the banks have been informed and none have provided feedback indicating the vulnerabilities were patched."
How long do you think it'll take them to come back with feedback? They'll need to work out whose fault it was, who they can blame, what they're going to do about it, the impact of blaming the people whose fault it wasn't, and all the time looking good to upper management. Lessons will be learnt, and this will definitely not happen again, just like always.
... to bank from your cellphone. Call me paranoid and old-fashioned (I admit to being both), but if I do on-line banking at all I do it from my own home computer on a wired LAN. OK, so I can't do all the wild-and-crazy things these mobile banking apps allow, but I also am likely to have my money in my bank in my account at the end of the day and not in a bank account in Siberia somewhere.
Banks are normally quite process oriented, so in this case I imagine the problem is that the technology is too new for the banks to have a good enough process to cope with the changes and the banks are very rigid about their process where it comes to allowing in new specialist vendors. I am dealing with this on daily basis, for a small company dealing with banks is extremely difficult. I am not even blaming anybody, it's the management necks that are on the line and more often than not, management is not in the position to make sound judgement calls about the technology side of the business, so going with the known quantities is always easier than taking a risk to go with someone new.
OTOH given the nature of the business, if I were in charge of a bank, in case where dealing with new technologies, I would hire at least two different companies to work out their solutions (pay them, by the way) and then hire an auditor company to check the solution and then based on the better solution keep the better vendor.
You can't handle the truth.
So, are these banks' websites just as bad, or did they actually manage to re-implement something worse than just wrapping their site in a suitable stylesheet and calling that 'an app'? If the latter, how do they look themselves in the mirror every morning?
The banking people made the glory of the 4 digit decimal PIN authentication a universal standard.
I am sure they know all about very secure systems and the public domain.
Fixed that for you.
TD Canada Trust appears to not use case sensitive passwords or allow special characters. Try it with your password using UPPER, lower and MiXEd case.
Trolling is a art,
I suggest that everyone look in to a terrible company called Fiserv. Their terrible products have brought the financial institution for which I work to its knees a number of times. Like the time when their mobile app update was so poorly tested that it hosed a relatively new, Enterprise Class System z mainframe with piles of unnecessary host calls.
But not surprising. Sadly.
20 years ago I got a C rather than an A in an assignment during my computing systems degree because I failed to fully validate a security in a 'secure' chat program (i did successfully encrypt and purge memory data, including not having page file info readable during unforeseen system power off - but certificate wise I only ensured compliance rather than check integrity iirc) . That was 20 years ago and I'm not a programmer.
Is this a case of young people being shit, management being shit, HR being shit or the industry as a whole now being shit ?
Mobile platforms do not have the AV protection that a full PC has not to mention the spyware installed by the OEMs disable many settings and shares all your data easily able to get your keystrokes.
I am too paranoid to do so on a phone not to mention Android has weak file system security and processes. It is not a full blown linux kernel you are used too on the desktop
http://saveie6.com/
They authenticate by sending an access code via text message to the phone.
Wait...
Which banks, please? Can we please have a list of which banks fail basic programming???
[End Of Line]
Banks doing something insecure? What's next? The government capturing all internet traffic in the name of stopping terrorism?
Try "yum install logkeys"
Maybe it's just me, but the article seems a little light on who they are referring to, aside from a vague reference to the countries of origin. While there's all sorts of legitimate ass-covering reasons not to mention any bank specifically, it makes it useless as a starting point for how we would do anything about it, such as demand improvements of these institutions.
At the least, I hope some private communication to the banks has taken place, though I'd understand if that hasn't happened. Some organizations tend to shoot the messenger.
I agree with all of them, except:
- Improve additional checks to detect jailbroken devices
- Obfuscate the assembly code and use anti-debugging tricks to slow the progress of attackers when they try to reverse engineer the binary
These two will be useless, and easily defeated. "Slowing the progress of attackers" is a meaningless statement in this context. Jailbreak detection is easily tricked, or removed from the code by a jailbroken phone.
Aside from that, if you do all of the other things they suggest correctly (as should have been suggested to the programmers in CS 101), you shouldn't need these two.
It is all of the above.
Technology may be created by geniuses, but implemented by fools.
As an iOS programmer (not at a financial company but we do ecommerce) I would be surprised that the banks did not use Veracode to analyze their binaries. Veracode isn't perfect but even for us it finds a number of these issues. But statically analyzed security issues found by a researcher are not always exploitable in real life. It's very likely that the bank could have security on the API side that would validate anything the client did that would not be visible on a client only analysis. As with Veracode where we get a lot of red herrings, what looks wrong statically might not actual be an issue. Then again I worked at a banking company once before the mobile era and their software truly sucked.
I smell the packets of a mobile banking app!
Brought to you by Carl's Junior.
Can someone please explain to me why someone needs a separate app to do their banking? As a matter of fact, can anyone explain why we need most of the apps that are just poor rewrites of web sites? Why not make a good mobile version of the web site that users can bookmark as icons on their home screen and call it a day?
That's terrible: mobile banking apps for iOS are woefully insecure, yet you folks are making fun of them. Poor little things, you're gonna make 'em cry. Is that really what you want? Can't you just leave 'em alone, you big bullies...?
If may be hard to believe but banks actually estimate losses due to poorly designed software versus say internal frauds and allocate development funds accordingly. Theft, inventory shrinkage, old fashioned embezzlement are commonplace occurrences so it is a mistake to imagine insecure software is the center of banking crimes. While programmers imagine software is the center of the universe, in finance it is the employees who rob the banks blind
Considering that banks are shedding employees like mad and only hiring temps, why is this surprising?
-- Tigger warning: This post may contain tiggers! --
My bank allows alpha numerics only. No special characters.
And I discovered that it disregards case. I can type it with any of the letters capital or lowercase however I want, it accepts it all the same.
Then there was my previous bank. If you wanted to log in to your credit card account from a computer that didn't have the authentication cookie already you were sent to a single page that asked for: Full account number, verification code from the back of the card, expiration date, full social security number, and a few other things I'm forgetting now. I thought for sure I had been forwarded to a hacked page and called them to verify. The person sighed and went "yeah, that's our real page..."
The shit some alleged jour^h^h^h^h resear^h^h^h^h^h^h overpriced snake-oil salesmen and consultants keep spreading about the "risks" of allowing banking apps to run on jailbroken devices is getting old.
It's wrong, it's a lie, AND it's actively-harmful to the ultimate goal of banking security (fraud-prevention and losses).
There are exactly two things that would happen almost immediately if any major bank in the US with millions of customers tried to prevent customers from running its consumer banking app on jailbroken/rooted hardware:
1. It'll be treated like copy protection, cracked within days, and released online almost immediately... and 15 minutes later, copies with injected malware will be getting aggressively posted online in ways that will make Google rank them high in the search results.
2. Depending on the size of the bank, there will be one or more open-source reverse-engineered banking apps (probably spoofing a desktop browser and doing screen-scraping if necessary) on Github, Sourceforge, and other sites... until the bank tries to get them taken them down at lawyerpoint, they go underground (or get modularized in ways that make them impossible for lawyers to attack directly), and someone manages to slip a subtle trojan into it somehow, or malware authors start distributing precompiled copies with their own special payloads.
Just wait until some major American bank decides to try blocking their app from jailbroken/rooted devices. When it happens, grab a big bowl 'o popcorn, and watch the fun at XDA & Github.
A banking app running on a jailbroken/rooted device is NO LESS SECURE than the same bank's webapp would be if the same user went to it with the same phone (possibly setting it to spoof a desktop browser).
Any app that genuinely depends upon not being able to install from iTunes/Google Play on jailbroken/rooted hardware for security DESERVES to get pwn3d in the worst and most publicly-humiliating way possible.
Pin the certificates? Sure. The only people who'll notice or care are attackers, and they're going to decompile the program and rip it apart anyway. Obfuscate the code? Sure, have fun. Once again, nobody besides attackers will notice or care.
The moment you try to exclude users with jailbroken/rooted phones, you've instantly broken the app for a small, but very loud & opinion-influencing group of users who aren't the least bit shy about taking matters into their own hands AND have the technical skills to pull it off. If you're a major American bank with tens of millions of customers, the LAST thing you want to do unless you're completely insane is motivate a few thousand of them to become casual weekend hackers so they can check their bank account balance on their phone.
TFA was interesting; the shit-blog that was also linked can eat a dick. Yes, Michael Mimoso sucks cock.
I'm sorry but you clearly have no idea what you're talking about. I'm going to talk about iOS jailbreak because that's what's interesting, Android devices are inherently less secure than iOS out of the gate so the conversation there is different.
The jailbreak defeats two primary security measures - the barriers protecting one app from another and the signature checking on the binary to confirm it hasn't been tampered with. If you are running on a jailbroken device it's trivially easy to hook the binary and essentially make it do whatever you want, and it's doing so with the credentials of the legitimate user. So as a simple example for a banking app, I could modify the binary to wait for you to login successfully, then email me your credentials and transfer a couple thousand $ to my account. If I can get physical access to your device I can install it in seconds, if not maybe I can persuade you to download it from Cydia. The server side would not know this wasn't legit, and you wouldn't know it was happening and the device wouldn't have any way to prevent it. That entire class of attack is made basically impossible on a stock device - the app is signed by the publisher and if you start tinkering it'll fail to execute.
Now as you mention I could obfuscate the code, that'll slow down someone trying to hook it but it won't stop a determined attacker. I could pin certs, but again if the device is jailbroken I can just replace the certs with my own. For the same reason it's impossible to really secure a general purpose computer that doesn't use something like secure boot it's impossible to guard against attackers if you're app is running on a jailbroken device - you can't trust the underlying OS and you can't even trust your own binary - you're screwed.
The very first thing anyone writing an app which has security concerns needs to do is figure out an effective jailbreak detect. It's not an exact science, and no detection routine will be perfect, but it's the number one most significant defense.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
My employer is considering offering our customers (banks) the option of turning on code in our apps that attempts to detect a jail broken devices and causes the app not to run. Our customers are all small, regional outfits, though; probably not big enough to merit much outrage.
If you're capable of inserting code to intercept credentials and email them somewhere then why can't you just excise the jail break detection code? Seems like this probably isn't the sort of attack jailbreak detection is designed to prevent. I'm instead imagining a scenario where a user's OS has been modified w/o his or her knowledge in such a way that it snoops on legitimate unmodified apps. Maybe the user bought the device used from "some guy at the car wash". He then proceeds to install his banking app. If the app doesn't detect the jail break and happily runs as normal then the user gets snooped on by the modified OS code. If the app instead detects the jail break and exits immediately then the snoop code never gets the chance to do its thing.
Don't use your normal PC for banking. Get a second machine, or re-use an old machine. Wipe it, reinstall the OS, patch it, and use it **only** for your banking, never anything else. Or get a cheap chromebook and use as just described.
That is why you use a second computer for banking and never do anything else on this machine. Take an old machine and wipe, reinstall OS, patch, ...
I worked for some time at a subcontractor for a couple of banks, developing software for them. During this time it became obvious that not all banks are as strict with information security as they try to present. For example all our developers had access to "demo data" that was a copy from production with only names and ssns mangled. Software that the subcontractors did were utter crap and banks didn't make any code audits or testing for security. At least I found out what banks not to use, only if the others were any better.
The original poster was basically correct.
Jailbreak detection in any public App can be subverted - pretty much every MDM who offers an SDK that does jailbreak detection, and pretty much every container vendor, has had their jailbreak detection bypassed in widely available patches.
The same is the case for rooting of Android devices.
Mobile Iron, Air-watch, Good, Blackberry, etc and most of the banks who do jailbreak detection & do something pro-active etc have all had their rooting/jailbreak detection repeatedly bypassed in multiple versions.
The difference is real this :
jailbreaking on iOS is enabled by bugs/logic errors etc. Apple hasn't had a hostile (no knowledge of the device passcode) jailbreak since the iPhone 4S, and usually patches the other stuff that comes up stuff pretty quickly.
rooting on Android is almost always by design (very few Android vendors ship locked boot loaders, and even of those that do, many screw it up - e.g. Samsung, to the extend that rooting most Android devices even when locked, often isn't very hard)
Once you've subverted the underlying OS, Apps don't stand much of a chance. They best you can likely do is identify instances of jailbreaking after it comes out. I'd argue, that your best approach here is merely to log that the device is rooted/jailbroken, and not disable functionality. If you do the former, you at least gather data on the scope of the problem. If you do the latter, people have incentive to patch it, and you are blind to the scale/scope of the issue.
The only viable defence thats been demonstrated is to have a hardware root of trust and a locked bootloader, and prevent jailbreaking/rooting. Whilst that isn't perfect, its far more reliable than jailbreak detection code in public Apps.
(internally developed/distributed Apps, on locked down devices - such as Enterprise Apps and supervised mode in iOS, or General Dynamics SE Android CAN and should reasonably do jailbreak/rooting detection as part of a defence in depth strategy, because building the jailbreak/root kit for these devices is much much harder )
All Bitcoin wallets submitted to Apple for inclusion in the App store make very good use of real security features. These apps are routinely blocked by Apple in the interests of protecting the consumer.
I learned this lesson the hard way, back a couple revisions with the iPhone. I downloaded Paypal and logged in once, logged out. The very next day, someone stole a couple hundred $$. Clearly, one of the apps I had on the phone had a clever keylogger or other monitoring scheme that was running. Apple did everything to divest themselves of any liability or interest. So we have to be concerned about other apps' behavior and have "failth" (in the case of Apple) in the ability of organizations to properly audit code before allowed in the App Store. It's an imperfect process. Android's platform being more open, having more malware on record, as I have read.
I hesitate to use mobile devices for financial operations. Not worth it, not yet, IMHO.
Who's writing keylogging malware for CentOS?
I've been looking for some usable Linux keylogger. I've never been able to find one so I just use a USB keyboard interceptor.
Perhaps this is related to the fact that Apple force developers submitting apps to go through "export compliance" procedures on behalf of the US government, which apparently doesn't like people to use encryption.
I'm not aware that this North Korea style insanity is necessary when submitting Android apps in the Play Store - if not, perhaps apps tend to have better encryption support on Android?