Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: Defending users of unprotected login pages with TrustBar 0.4.9.93

Subject: Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
Date: Mon, 19 Sep 2005 13:53:03 +0000
Quite interestingly ...

Last week i posted a question to ask.slashdot (qot refused) on why my bank over 
here in Belgium is blocking non-microsoft-os to use the on-line banking 
software. 

(I got around this by using a netscape-with-java-4.77-browser)

There reply was it's just too insecure. 

Wich is quite baffling given the amount of exploits for MSW and MSIE over the 
years, on top of that the real life situation of 'uneducated' end-users wich 
'administer' their own computer connecting to a 'secure' server wich is ideal 
for any m-i-t-m attack.

How would trustbar avoid such an occurence ?

----- Oorspronkelijk bericht -----
Van: Amir Herzberg [mailto:herzbea@macs.biu.ac.il]
Verzonden: maandag, september 19, 2005 01:38 PM
Aan: webappsec@securityfocus.com
CC: herzbea@macs.biu.ac.il
Onderwerp: Defending users of unprotected login pages with TrustBar 0.4.9.93

Most financial and other sensitive web sites use SSL/TLS to authenticate 
the server and protect data from eavesdropping and from modification by 
a Man In The Middle (MITM) adversary.

However, quite a few of these sites invoke SSL/TLS only _after_ user has 
typed in her user name and pw, and clicked `submit`. This allows a MITM 
adversary to send a modified login page to the user, which sends the pw 
to the attacker (rather than encrypting it and sending to the site). See 
below link to a `Hall of Shame (HoS)` listing such sites.

There are few things we can do about this. We can try to convince these 
sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few 
fixed, but most did not. We can avoid using these sites, but this is a 
bit heavy penalty e.g. if it is your bank. We can also try to find an 
alternate login page which _is_ protected; in fact, we've found such 
alternate, protected sites for most ebanking login sites (see HoS). But 
this may be difficult for most (naive) users.

So, we decided to add support for users of these unprotected sites in 
TrustBar. As of the latest version (0.4.9.93), available off my site 
(below), we added two such mechanisms:

1. TrustBar will automatically download from our own server, 
periodically, a list of all of the unprotected login sites, including 
any alternate protected login pages we are aware of. By default, 
whenever a user accesses one of these unprotected pages, she will be 
automatically redirected to the alternate, protected login page.

2. TrustBar allows users to assign a name or a logo to sites, protected 
or not (to help users identify fake sites). We now added a mechanism 
computes a hash of every unprotected site for which the user has 
assigned name/logo. TrustBar compares this hash on subsequent accesses 
to the same site. If the site is not modified in five subsequent 
accesses, TrustBar begins displaying `Same since <date>`; and when the 
site changes, TrustBar displays a warning. This can help users notice a 
fake version of their login page. Unfortunately, this mechanism does not 
work very well on most real-life login pages, since most of them contain 
a tiny bit of frequently-changing data such as date or `random` 
identifiers (mostly to identify a cookie-less client, we think). We are 
working on improving the mechanism so it will be tolerant to such tiny 
changes, without exposing the user to malicious changes.

Please try it and tell us what you think of TrustBar in general and 
these features specifically. If you like it, please inform others, to 
protect them, help convince browsers to incorporate such features, and - 
last but not least for us - help us obtain more experimental data in our 
research on secure usability. Thanks!

BTW, TrustBar is an open-source project, so if some of you want to 
provide it to your customers, possibly customized (branded) etc., there 
is no licensing required.
-- 
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: 
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame





<Prev in Thread] Current Thread [Next in Thread>