[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Sat, 26 May 2007 18:48:48 +0100 Julian Hall <lists@xxxxxxxxxxxx> wrote: > Neil Williams wrote: > > http://www.theregister.co.uk/2007/05/25/strange_spoofing_technique/ > PayPal, Ebay etc address me by my name in emails - a phisher doesn't > know it so can't do that. This attack doesn't rely on phishing - it intercepts a VALID request for the site within the vulnerable browser. You type www.paypal.com and the malware injects HTML into the VALID paypal site code that changes the POST URL of the forms within the page and adds entry fields for information that the genuine paypal site never requires. The malware simply sits in memory and raids all communication between IE and the site - checks for the URL and remaps whatever it feels it can handle. Update or upgrade the malware and *any* site can be remapped. There is nothing the site can do to protect the user, there is nothing the user can do to prevent the attack once the malware is installed - it cannot currently be detected. It's a new form of man-in-the-middle. It is possible that the malware itself (a .dll) is installed via an <iframe> or similar "hidden content" method which has been known to be operated from GENUINE sites by compromising the server that provides the adverts. This allows the attacker to spread the malware via ALL genuine servers that use those ads without the hassle of compromising those servers directly. Another reason to use adblock - but even if adblock was available for IE7 it might not be enough. You can avoid all the phishing attacks you like, you will not be protected from this attack if you are using IE7. For once, there doesn't have to be any email involvement for the attack to succeed. It appears to be specific to IE7 - current security tools cannot prevent infection, cannot detect infection and therefore cannot remove the malware - once infected you might as well have a keylogger installed, the attacker can read whatever data can be handled by the HTML injector code, it is all sent to him by email. Theoretically, any site security can be utterly bypassed and without the source code for the malware, you cannot reliably determine WHICH sites can be handled by the injector. Yes, if the injector makes obvious changes to the page you may be able to spot it but with a little optimisation, the injected code could be made to be completely invisible. You would have to read *and validate* the site source code to ensure that the POST arguments are correct. The quickest way of doing that is to have some way of comparing the HTML available to Firefox with the HTML produced for IE but with varying levels of "browser-detection" junk Javascript in sites, that may not be reliable. I'm not sure if the padlock is even reliable in this scenario - it depends how IE handles the padlock issue. I'm not sure, but I doubt that the padlock process attempts to validate the incoming HTML data stream against some md5sum sent from the site - it authenticates the connection, not the data. The problem here is simple: MyMoney.com -> HTTPS -> Internet -> HTTPS -> IE render engine. The malware is likely to be injecting code ^^^^ here - AFTER HTTPS has authenticated the connection. By compromising the data stream AFTER the data has been handed from TCP/IP to the internal Windows/IE codebase, protocols that validate TCP/IP connections are useless when trying to detect the effects of the malware. It's reason enough never to use IE7 for ANY site. > Never click any links unless the sender has authenticated themselves. Good advice but it won't protect IE7 users from this attack. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpryNBysikvN.pgp
Description: PGP signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html