2008-10-09

No longer confident.

This is something that has really started to annoy me ever since I realized it. It came to me while I was playing with ettercap filters. For those who don't know you can use ettercap to perform ARP spoofing and MiTM attacks. etterap filters give you the added functionality to modify any traffic going to and from the victim or victims that you are ARP Spoofing. This has been fun to do things like replace all the images in webpages that your co-worker has been viewing with your own image that you host. Like the following.


image


Thats fun and all but now I have noticed something that ALOT of websites including many financial institutions are doing. They are trying (i assume) to make their home pages load faster by not SSL'ing their home page but still providing login functionality on this page. They usually have a JavaScript fuction that actually submits your credentials over SSL or it could be in a form. So it occurred to me that anyone who happens to be on my same subnet can ARP spoof me and change the javascript . The javascript could be modified to intercept my credentials, send them to another server, and still log me in and I would never know it. In fact i'm not sure of anything that most users can do to know that they are not a victim.




This is a poor coding practice that takes away all the visual cues that browsers are putting in place to ensure that you are sending your credentials over a secure link and training users not too look for them. Its not that hard to have a button that says "click here to sign in" to redirect you to an SSL'd login page. I have seen some sites that are ssl's but load some of their javascript from non-ssl'd sources which could allow for session stealling from sites that do set their cookies securly. My recomendations to developers are:

1. Only allow your users to enter crendentials on an SSL'd page.

2. Once users are on a secure section of the site then load all your javascript, images, or any other included content from only ssl'd sources as well.


image

image

No comments: