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: <00a101c48b1f$3b086730$08c8b43e@netvision.ads>
Date: Thu, 26 Aug 2004 05:46:10 +0200
From: "mikx" <mikx@...x.de>
To: <bugtraq@...urityfocus.com>
Subject: Alpha Phising [IE 6 WinXP SP2]


Tonight i got about 20 - awfully translated - german speaking phising mails. 
Therefore i thought a bit about phishing attacks and which of them are 
blocked in WinXP SP2.

After a while i created some proof-of-concept code that is capable of 
phishing data from any html form based login screen, even if SP2 is 
installed and Active Scripting is disabled. It runs without the need for 
cross site scripting or spoofing entire websites. It can display any real 
login website in a frameset (that looks like a frameless page) and works as 
a "man-in-the-middle" attack when the user submits his login data. It is in 
most cases transparent, meaning the login process isn't interrupted at all 
(if the server accepts the form data as GET).

This demo shows a typical, password protected website (it's just a fake for 
demonstration). Type in any login/password combination and click "login" or 
hit return in the form. If the phishing works, you will see a javascript 
alert displaying the login data you typed in - this alert comes from the 
site hosting the iframe! When you close the alert, the script forwards the 
data to the server and performs the login. In a real attack the alert would 
be replaced by mechanism to store the data, of course.

The NoScript Version is a little limited: you can focus the underlying 
 "real" login forms when clicking exactly on their border and there is 
currently no forward to do the login after the data got phished (it's 
possible using a server side header redirect but not implemented). The 
intercepted data is displayed as a get request in a new window in this demo. 
This could also be done in a hidden frame of course.

1. JavaScript Version (inside Phishing frame, alerts on post)
http://www.mikx.de/alpha/index.php

2. NoScript Version (inside Phishing frame, opens new window on post)
http://www.mikx.de/alpha/index2.php

3. Login Website (just to compare)
http://www.mikx.de/alpha/login.php

4. Blog
http://www.mikx.de/index.php?p=2

I tried this script across multiple webservers/domains and even on my 
personal bank account login page - it would work. I will not release any 
"real world" samples for obvious reasons. Anyway, i assume there are already 
phising attacks like this out in the wild.

Technically the script is based on an iframe, forms and absolute positioned 
divs - it does not require Active Scripting! Therefore it triggers no cross 
site scripting protections, the hidden form fields intercepting the login 
data are only "hovering" above the iframe and there is no real script 
interaction.

Currently i can only try this using IE 6 on WinXP pro SP2 (all security 
settings to default). Feedback about other OS versions is appreciated.

To work around this vulnerability client side never click on links to open 
login pages and risk opening a framed website this way. Type URLs by hand or 
use Bookmarks. On server side use scripts that let a login page "break out" 
of framesets or warns when embedded in a frame. You could also try to detect 
those man-in-the-middle stuff by checking if the referrer of a form post 
comes from your server. This wouldn't stop the phising but at least would it 
break the "transparency" of the attack.

mikx




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ