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.
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,
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 ?
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.
Not surprising, though my "bank" uses them for their online portal, it's somewhat robust, multiple factor authentication and such, though I haven't poked to hard, which is to say; at all.
Get up!
Security is layers. For all our firewalls, ids sensors, seim correlation, and other efforts it was the lowly endpoint security package and it's alerts in it's console that got our attention the last time we had an unannounced pen test.
A/v might not be the sexiest thing in computer security today, it might not even be very effective overall but it's one more shot at detecting and stopping the bad guys and it can be a shout worth taking.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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...?
Considering that banks are shedding employees like mad and only hiring temps, why is this surprising?
-- Tigger warning: This post may contain tiggers! --
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.
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.
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.