![[philiptellis]](https://en.gravatar.com/userimage/3079306/f13167d69aa4e1cb5e5f131af4e38e3e.jpeg)
https://secure.icicidirect.com/newsitetrading/customer/Logon.asp?errmsg=Invalid%20Login%20Id%20or%20Password:Please%20try%20again.Notice the error message showing up in the URL. Curiosity got the better of me and I tried playing around with the URL and found that it was open to an XSS. I sent the following message to their helpdesk:
Hi,and then tweeted about the existence of the XSS without providing any details. Pretty soon others figured it out as well.
I've found a security hole on your login page. Please put me in touch with someone responsible for the security of your page so I can explain the problem to them and get it fixed.
Thanks,
Now this was on Sunday the 26th, and no one at ICICI was checking emails, but on Monday I received a phone call from Abhishake Mathur, the head of customer service. He called on the phone number registered with my account. I tried to explain the concept of a cross-site-scripting bug to him and that an evil person could use it to steal a user's password, but it wasn't easy. He kept telling me that when I visit their site I should see the lock icon (referring to the SSL lock that some browsers display for sites served over HTTPS) and that as long as I saw that, no one could steal my password. I asked him to email me from his official address so that I could reply and demonstrate the problem along with screenshots and links.
I received no emails, however he called back a few times with questions from his technical team and someone who he called his senior, however these people were either not allowed to speak to me directly or did not want to speak to me directly. I can imagine that some companies only like PR or Customer Support to interact directly with users. We at Yahoo! have an official security contact and all security related communication is done through that channel, however the persons behind that channel are all highly technical and qualified in the security field.
In any event, I headed out early that evening, and was not home when they called a few more times. I left word at home that if they call to ask them to email me. That night I still hadn't received an email. The following morning they called while I was in the shower and my dad asked them to call back a little later. When I got out, there was an email in my inbox essentially asking me to describe the problem I was facing.
I replied with the following:
Hi Abhishake,I received a reply in under an hour saying that their technical team was looking into the matter and then three hours later another email saying that the issue was fixed and asking if I could verify.
Thank you for getting back to me. I'll explain the problem in detail. First let's define three entities.
1. The real user, we shall call this person Ashish
2. Your website, we shall refer to this as ICICIDirect
3. The attacker, we shall call this person Bala
Now, in this scenario, Bala sends an email to Ashish pretending to come from ICICIDirect. Note, this is similar, but different normal phishing email since in this email, he includes a real URL to ICICIDirect. It would look something like this:
================
Dear User,
Please log in to ICICIDirect here.
Thank you,
ICICIDirect
================
Of course, it might have more details to make it look authentic. Now if you check the link, you will see that it points to this URL:
https://secure.icicidirect.com/newsitetrading/customer/logon.asp?errmsg=%3Cscript%3EsetTimeout%28function%28%29%20{var%20e=document.getElementsByName%28%27FML_USR_USR_PSSWRD%27%29[0]; %20e.form.onsubmit=function%28%29 %20{alert%28%27password %20is %20%27 %20%2b %20e.value%29; %20return %20false;};}, 2000%29;%3C/script%3E
This is a link on the ICICIDirect website as you can see, it starts with https://secure.icicidirect.com/ and is running on your own servers. Now if you click on the link, it will show you a page that looks like this:
This page is exactly the same as your login page because it is your login page. However, if you try to login (for this example, please log in with a fake password since it will be displayed), then you will get something like this:
For this example, I have only displayed the password in a JavaScript popup, but a real attacker like Bala in our example would send this username and password to their own server using a beacon.
The reason this thing happens is because the "errmsg" parameter that is passed in the URL of the page is not sanitized to make sure it is safe. By default you pass in error messages like "Invalid User Name or Password", but an attacker can change this message to anything exactly like I have done in this example. They can add JavaScript to this parameter and get it inserted into your page.
If you do a view source on the link that I sent you, you will see the following code in there:
<script> setTimeout(function() {var e=document.getElementsByName('FML_USR_USR_PSSWRD')[0]; e.form.onsubmit=function() {alert('password is ' + e.value); return false;};},2000); </script>
This was added by manipulating the "errmsg" parameter.
Although there are better ways to accomplish what you need to do, the immediate way to fix this is to validate the errmsg parameter to make sure it only contains safe values. This means that there should be no <, > &, " or ' characters in this parameter. In ASP you can do this using the Server.HtmlEncode method to clean the errstr parameter. For a more detailed analysis of cross site scripting in ASP, have a look at this document: http://www.4guysfromrolla.com/webtech/112702-1.2.shtml
I hope this explains the problem completely. The example I have shown is fairly benign, but a real bad person could do worse things. Feel free to get back to me if you have more questions. As a user of ICICIDirect, I am very interested in making sure it is secure.
Thank you,
I checked, and they had indeed fixed the immediate problem. They still weren't sanitizing the input, however they went one step further, they completely ignored the input. The initial problem was that they were echoing the value of the
errmsg parameter untreated. Their solution was to treat the errmsg parameter as a boolean and echo a fixed error message of Invalid Login Id or Password:Please try again. if the parameter was set to any value.This fixes the immediate issue, but given that they haven't considered input filtering, chances are that there are similar bugs elsewhere on the site that still exist.
27 comments :
Hi Philip,
This a clear and concise example of what cross site scripting is.I would like to congratulate you on putting this in clear terms for a laymen to understand as well.
As for ICICI websites it should be a clear pointer to the lack of security validation and clear process failures for the handling of such issues.
The good part is they have fixed it partially and this should initiate some proper actions.
Have you put this on cert-in as yet?
Regards
Kanti
http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications?pli=1
Have a look at this as well for more information about the javascript vulnerabilities.
I am utterly disgusted that a modern business with a reliance on online facilities would not fix this problem properly and perform a complete code review. For every XSS people like Blues find, there are probably many more lurking.
Kudos to you for explaining this problem clearly and concisely. To the bank I say: "you idiots".
Brilliant. You must have had to exercise a LOT of patience when dealing with the "technical" team at ICICI.
Good article Philip. Nice Job!
Well done, great job Philip.
Good job Philip. Else users like us will be screwed someaday and no one will ever have a clue.
way to go you just fixed a bug for someone who is getting paid to do this. I hate people like this jerk who gets paid to do make sure this does not happen.
In general it seems that the quality level of engineers, programmers and the like have gone down as more and more folks dive into the work 'pool'
I see clear evidence of this across many companies and engineering disciplines.
I liken it to a flat in Mubai during monsoon season. You fix one leak to find the bottom floor flooded the next day.
Instead of solving the problem.. you just move all your stuff to the second floor :)
While you did correctly find the XSS vulnerability, you did not correctly explain the general way to exploit it.
In this instance, exploitation would happen like this:
- a user logs in to their account
- the user opens an email containing an HTML message. The message contains an iframe tag with an URL pointing to the website. The URL contains the parameters for the XSS exploit. Using the exploit, javascript is put into the page. This javascript reads the cookies from the logged-in user and then adds a image tag with a URL pointing to the attackers server, with the contents of the cookie at the end.
- the users browser fetches the image
The users cookie is now in the attackers computers webserver log. Using this cookie, the attacker can pose as the user.
That's pretty sad that they were not so familiar with XSS.
There are many great commercial products that can automatically detect these types of security vulnerabilities such as IBM Rational AppScan.
Good article.
In my opinion, people developing sensitive applications such as a bank's self-service site must be of a higher caliber than the average run-of-the-mill programmer.
The bug that you've found is so blatantly obvious that I'd be hard pressed to be believe it's just a one-off. There's a good chance it's a dead canary reflecting the general quality of the dev team and their product.
All in all be glad the bank's service was positively responsive to your message, but I'd re-think about whether I'd want my money managed by that team.
The explanations are weak.
Try OWASP XSS Prevention Cheatsheet.
An informative post but I'm puzzled as to why you disclosed the issue on Twitter? What did that achieve?
Pressure on them to not ignore it.
You were very patient and helpful, good on you! Odd you never spoke directly with the developers. Kinda scary to think what security risks may exist on the backend given XSS is such a common and documented security hole.
A nice article, and a good read. I laughed a little bit at the "SSL means your password can't be stolen" quote.
Next time, use Alice and Bob?
http://en.wikipedia.org/wiki/Alice_and_Bob
"I can imagine that some companies only like PR or Customer Support to interact directly with users."
Probably because they want to control the message, which is fundamentally flawed.
Good show man and great patience!
They must be waiting for a 400 cr scam to happen.
Ok, answers to some of the questions above:
1. Alice and Bob -- I modified the names for cultural relevance.
2. No, I haven't put it on cert-in
3. Regarding explaining the cookie based vulnerability -- There were a few reasons I didn't explain it using cookies. The primary reason was based on how hard it was to explain the concept to the guy on the phone, he wasn't a technical person, and cookies may have been too technical for him, or not sacred enough. Usernames and passwords however are things that anyone can relate to. If I could demonstrate a problem there, they'd be more likely to pay attention.
@dre -- that would be useful if they'd been able to understand the concept of an XSS first.
Thanks for all the comments, here as well as on reddit and hackernews.
"Ashish and Bala" are "Alice and Bob" of India :D
Nice Explanation and post Philip!
Interesting read.
Though its surely a good thing that they did not decide to simply sanitize the input, as one can still use plain text for phishing scams and such.
Eg. "Sorry, our primary authentication server is down, please log in at http://malicious/login/page"
Good job.
All those technical experts, I have a question.
I like to create application that aggreates and create dashboard by retrieving different stocks held by user. User would be providing his/her userid/password to brokerage site (eg. icicidirect.com)
How would i go about login in using id/pwd provided by user and retrieve the stocks owned by user? i believe this is called screen scraping...let me know thoughts
@Anonymous: Getting the user to hand over their ICICIDirect credentials to a third party (you) is a bad security practice because it trains the users to get phished. Your site may be safe, but once users get used to giving their password to different sites, they might get tricked into giving up their passwords to evil sites as well.
The best way is to try and get the service provider to give you an API. Failing that, screen scraping is your only option, but it's not a very good option.
Post a Comment