full-disclosure - Re: [HV-PAPER] Anti-Phishing Tips You Should NotFollow

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <442FAF23.14463.C106CB27@nick.virus-l.demon.co.uk>
Date: Sun Apr  2 00:02:12 2006
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Re: [HV-PAPER] Anti-Phishing Tips You Should
	NotFollow

Dave Korn to Jasper Bryant-Greene:

> > Phishing scams are public in nature. They aren't trying to avoid
> > detection :) ...

Actually, that depends on the scam.

Some phishers go to elaborate lengths to hide the real location of 
their phishing sites, using fast-changing DNS entries with multiple 
host (A) records for their bogus domains, quickly rotating the domain 
through sizable chunks of widely distributed IP address space across 
their vast botnets.  The bots at the business end of these setups act 
as HTTP proxies to the "real" phishing site, but are incredibly 
difficult to "catch in the act" and analyse (and doing so requires a 
level of inter-ISP, etc cooperation you're unlikely to find in 
practice).

Why they go to that much trouble unless they are trying to avoid 
detection of the real scam site's location I cannot imagine.

> > ... and the IP address would of course be spoofed.
> 
>   No it wouldn't.  IP address spoofing is easy over UDP but incredibly 
> difficult over TCP.

Exactly.

BUT, it can be "practically" implemented -- i.e. the same end result 
(the phisher's real location remaining unknown) can be achieved with 
readily available means...

There's nothing to prevent a phishmonger who is running a botnet much 
like that described above to also distribute the "check the supplied 
login credentials" effort across the botnet, rate-limiting the requests 
to a specific target banking site from each bot to "a few per hour", 
such that each bot might look, to any traffic or other pattern 
monitoring at the banking site, much like an "Internet cafe" or other 
similar public access node.  And don't forget that, unlike the actual 
spamming of such phishing schemes, the total traffic involved here 
would be quite small anyway, as normally only a very small proportion 
of the phishing scam recipients will actually get as far as visiting 
the phish site _and then_ entering login data (in fact, this response 
rate is probably so low that the checking could be done by the bot 
proxying the current victim's HTTP traffic to the real scam site).

Regards,

Nick FitzGerald