full-disclosure - Insecure http pages referencing https form-actions.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.50.0508101309370.5674-100000@kegger.national-security.net>
Date: Wed Aug 10 21:40:31 2005
From: fd at ew.nsci.us (fd@...nsci.us)
Subject: Insecure http pages referencing https
	form-actions.

On Wed, 10 Aug 2005 douglas.foster@...il.com wrote:

> > The victim would then be logged in to where they expected to be, complete
> > with padlock.  Except for the extra "please wait" page, this would not be
> > obvious to a user.  My issue is with the insecure location of the actual
> > <form> and I have seen many sites which do this (including major financial
> > institutions).
> 
> It appears the key part of the scenario is DNS poisoning. Anytime a
> user goes to a http page to click on a login link, DNS poisoning will
> work without regard to whether the login page is secure or unsecure. 
> (For example, I go to a FI's main page at http://www.fi.com, which DNS
> poisoning points to an evil server.  The evil server sends back a page
> that looks and acts like the FI's main page, but contains a link to an
> evil login page).  The same scenario can occur when any page in a
> click stream going to a login page is hijacked.
> 
> Are you suggesting that ALL FI pages that either contain login links
> or could be in a click stream to login pages be served https:??

Absolutely.  Assuming you trust the CA which issued the certificate for
the https server, this problem is resolved by forcing all click-stream
pages (especially login pages) to be under TLS.  Even if you dns poison an
https server, where would you point it?  Unless you have the issuing CA's
key it would be at least 128bits of NP-hard cracking to keep from getting
the "this server is not signed by a known CA bla bla bla" message from the
browser.

This isn't perfect, mind you.  Users will invariably click the go-dammit
button to get what they are looking for, even if the go-dammit button
warns them that their bank will melt down if they continue:  This web page
will self destruct in 27...26...

-Eric

-- 
Eric Wheeler 
Vice President 
National Security Concepts, Inc. PO Box
3567 Tualatin, OR 97062

http://www.nsci.us/
Voice: (503) 293-7656
Fax:   (503) 885-0770