September 27th, 2008
ICICI Bank’s iMobile website has some of the worst server side validations ever, which is what prompted me to download the mobile app’s JAR file, study it in detail and write this post. According to the website, until the Reserve Bank of India comes out with mobile banking guidelines and approves it, mobile banking is supposed to be halted. Technically, it means that, all existing users shouldn’t be able to use the service what-so-ever and new user signups should be prevented & a notification stating that they should retry later should be shown.
Therefore, in this scenario, I shouldn’t have been able to download the app to my mobile device. The website of ICICI fails in not enforcing this by providing the following ways:
- Existing users who have already installed the app are given an option to ‘Upgrade’ from within the mobile app itself. This opens up a webpage in the phone’s native browser, whose URL is http://mobile.icicibank.com/upgrade?version=null.
Which brings me to explain Step 2 in detail:
document.jump1.action="https://infinity.icicibank.co.in/web/apps/"+fileName;. That line pretty much gives away everything. All you have to do is, navigate to the above mentioned URL and append a filename to it for download.
What filename do you have to give and How?
Where ICICI Bank failed?
- They should have disabled the link mentioned in #1 above and replaced it with some text that says, “RBI mobile banking guidelines blah blah…”. But some clever users will bookmark the link to the JAR file and try to access the JAR file by bypassing the link itself. When they do that, the web server should return a “404 – Resource Not Found” error. Got it? Implementing this is pretty simple.
- Ok. Leave aside #1 and #2. At least the mobile app should have thrown soft errors when users try to access mobile banking from the JavaME app. Any bank would store all activity data for a certain period of time. So when you access the bank’s service from a mobile device, the server software surely knows about it, which means, the server software should have returned errors to the user instead of allowing the user to do transactions.
- There’s one more bug in the app itself. When you launch the app, it will prompt you to sync the data on the device to its servers for faster access the next time. When you click “OK” to synchronize, it will wait for a few minutes and show a message as, “There is no data to synchronize”. When you proceed further and try to access your info, it will again prompt you to sync the data. That’s frustrating. Either you should sync the data properly or you should access the server every time over a secure channel. As simple as that. That’s not followed too.
That was a long post already We still have some more to go. Lets take a break.
Back? Ok 😀 Now, lets dissect the actual JAR file and look into the technical details of its implementation.
The Manifest File:
Another important item is, “MIDlet-Name” property in the manifest. This property determines what name the user sees after he installs the app on his mobile. Using the same name, when future upgrades are made available, the app is just replaced in place of the old one, which means, if you modify the “MIDlet-Name” property and install the app again, you will have 2 copies of the same app. THIS SHOULD NEVER BE ALLOWED FOR A HIGHLY CRITICAL FINANCIAL APPLICATION. Isn’t it? As an example, try changing the MIDlet-Name of the Yahoo! Go JAR file and try to install the app again on your mobile. My E51 shows an “Invalid JAR” error message because of MD5 sum checks etc.
Some more Holes:
What should the bank do here?
- Shouldn’t allow the installation of 2 apps of the same JAR with different names. Take this example of the Yahoo! Go JAR file.
- I guess these mobile providers’ socket URLs are used for a one time basis to send verification SMS. If that be the case, they shouldn’t be present in the manifest file for a variety of reasons that I won’t discuss here.
- There’s an interesting property named “WSCDomainName” in the manifest file. I guess it expands to “Web Service Client Domain Name”, though I’m not sure about it. Suggestion: Encrypt the name value pairs.
- Most importantly, sign the application using the Java Signed program. C’mon, users are doing financial transactions and a signed app will increase their confidence of using this application.
Suggestion for Users:
Thats about it !
Of course, this blog post can’t be termed as a full fledged security analysis. But most of what has been ignored by the bank are mere basics. They must have more secure systems in place.
If you liked this article, kindly do me a favour by digging it. Thanks for your time.