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

Help on the horizon for Windows users!

[EmptyBuffalo]

Wow! Talk about a great opportunity to educate the masses - now we've just gotta pharm the www.microsoft.com/help website to www.slashdot.com!!! ;)

Re:Help on the horizon for Windows users!

[LMCBoy]

Slashdot.org...it's DOT COM!
</homestar>

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.

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.

Re:Just don't read emails from the bank

[log2.0]

I know for sure that everytime I log into my netbank, it warns me about "Do not give your password to anyone, even us...blah blah blah"

I think most banks do what you are saying its just that there are so many STUPID people out there who fall for these OBVIOUS (to us at least) scams.

It is very frustrating that people fall for things like this and those dodgy African "lottery" wins that you didn't even enter.

Re:Just don't read emails from the bank

[jagapen]

I get notification email messages from my credit union monthly. When I signed up for the account, I had to enter a 'security phrase', and every email they send includes that phrase. If it doesn't have the phrase, it's phish.
Simple. Effective. Can be defeated, but it would take orders of magnitude more effort.

Very confusing

[tyleroar]

I could see how this would be very confusing for most people. What one of the redirectors does, is actually load the normal bank page from the bank's server, and then load a pop up with a form to submit private details from the phisher's server. The site is down, so I can't check it, but I would imagine that the pop up window is made so that the Address bar is not showing and people can't easily see that it is a bad URL.

Re:Very confusing

[WGR]

The pipe shouldn't actually do anything but is mis-interpreted by Internet Explorer. It is the wildcard in the DNS of the phisher site that picks up everything before the last two parts of the domain name. Here is the actual DNS entries for one of those sites (http://barclays.co.uk|snc9d8ynusktl2wpqxzn1anes89 gi8z.dvdlinKs.at/pgcgc3p/):

#> dig *.dvdlinKs.at A

; <<>> DiG 9.2.1 <<>> *.dvdlinKs.at A
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;*.dvdlinKs.at. IN A

;; ANSWER SECTION:
*.dvdlinKs.at. 14400 IN CNAME kickme.to.
kickme.to. 3158 IN A 64.235.234.138

;; AUTHORITY SECTION:
kickme.to. 75158 IN NS ns2.lunarpages.com.
kickme.to. 75158 IN NS ns1.lunarpages.com.

;; ADDITIONAL SECTION:
ns1.lunarpages.com. 164430 IN A 216.193.194.212

;; Query time: 390 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Mon Mar 07 23:05:51 2005
;; MSG SIZE rcvd: 136

This says that http://barclays.co.uk|snc9d8ynusktl2wpqxzn1anes89g i8z.dvdlinKs.at/pgcgc3p/
goes to the kickme.to web site. THis applies to anything replacing the *.

Internet Explorer misreads the | as a network redirect (from NT4) and ignores the rest in URL so people think that they are going to Barclays Bank since that is what shows up in information windows.

Its very simple...

[scsscs]

Don't enter sensitive information into a form linked from an email.

Re:Its very simple...

[bsharitt]

I wonder how that affects https connection. Even if they steal the DNS, they shouldn't be able to get their certificate.

That's it

[Anonymous Crowhead]

Time to scrap this whole "DNS" thing. I don't know what it is, but it sounds dangerous.

Re:That's it

[ScrewMaster]

It stands for "Defensive Nuclear Strike". What that has to do with the Internet and email fraud I don't know.

Remember when...

[Anonymous Coward]

Just a little while ago Network Solutions thought it would be cool to redirect all nonexistent domains to a valid host in the form of website?

Remember when ICANN even thought of listening to Network Solutions?

Hope you do. Mental Bookmark.

Who has money any more?

[bigtallmofo]

After sending all my money to various Nigerian organizations, I wish I had some money for someone to siphon in a phishing scam!

The problem with simple rules to avoid Phisers

[soft_guy]

is that they aren't so simple. They are also not logical common sense rules either. The phishing site might look exactly like your real site. Plus, the url might look right if the Phisher used a trojan to install a hosts file on your box.

If this isn't solved definitively, it could destroy e-commerce.

DNS cache poison can be stopped

[Anonymous Coward]

DNS cache poison can be effectively stopped by using the correct DNS caching program. Basically, it is important to use a strong psudo-random number generator to determine the DNS query ID. Ideally, we have the same psudo-random number generator determine the source port of the DNS query.

To the extent of my knowledge, only two recursive DNS servers have this level of DNS poison protection: DjbDNS' dnscache and MaraDNS.

It is also important to have bailwick protection. Basically, the recursive DNS server needs to look at a DNS reply, and filter out any answers not in the bailwick. Older DNS servers (and possibly poorly written embedded DNS caches and recursive servers) will get a reply like "www.paypal.com has the ip 10.1.2.3" to the question "what is the ip for www.phisherscum.com?", and incorrectly cache the data for www.paypal.com instead of saying "I didn't ask for paypal.com's ip, so I'll ignore this data as being out of bailwick".

Additionally, it improves security to restrict which IP addresses are allowed to make remote DNS queries. This is best done at the firewall level (don't allow any UDP connections to port 53 from the internet at large unless you have some domains hosted by the machine in question). This stops malicious servers sending a large number of requests to your dns server for www.paypal.com, and a number of bogus answers "www.paypal.com has the IP of some phishing site in China; remember this until 2007", until one of the answers looks valid and fools your DNS server.

In summary, by using a secuirty aware DNS resolver, you can minimize, if not eliminate the chances of being vulnerable to bogus DNS data.

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.

Spoofstick

[Omniscientist]

Spoofstick is a Firefox extension that might help in avoiding phising scams. It displays "the most relevant domain information". Looks like its available for IE too.

Re:dns? links?

[Hoch]

Did you change your host file to get work done, only to end up memorizing the slashdot ip? Happens to the best of us.

It takes some evangelizing

[erick99]

I tell anybody who will listen - If you want to log in to your bank, then go to your banks URL yourself, manually, without the aid of a click-thru in an email or another website. Type in yourself. I doubt I am redundant enough but I try. We should be able to get to the point that nobody would ever click on an URL in an email to get to their bank or anything else on the web that has some connection to their money or wealth or whatever.

Re:Just don't read emails from the bank-Digital Fa

[The Amazing Fish Boy]

Hello,

This is an autmated letter from Bank of America. We need you to confirm your information. Please log in here by copying and pasting the link below:

http://bankofamerica.com|index.cfm|sid=1 00201952820932.slashdot.org/article.pl?sid=05/03/0 8/0052235&tid=95

Thank you for your time,
Bank of America.

Paypal got it right

[jdreed1024]

The site is down, so I can't check it, but I would imagine that the pop up window is made so that the Address bar is not showing and people can't easily see that it is a bad URL.

Paypal got this right. When the Phishers started going after them in earnest, they sent a bunch of e-mails to registered users saying "Paypal will never ask you to click on a link in e-mail". And all their e-mails about transactions or special offers say "If you would like to do this, enter www.paypal.com in your browser, and then click on tab $foo and then link $bar". It's a bit more effort for the consumer, but it eliminates the "Is this a real or fake e-mail" problem - if it contains any hyperlink at all, it's fake.

My credit card does the same thing. I get automated notifications that say "Your new statement is available online. To access it, go to www..com, and click on "My Statement".

Links

[ScrewMaster]

My solution to this problem (since I have a girlfriend that likes to click anything interesting) was to have my mail server redirect all links embedded in incoming messages to a local page that says "don't do that." I also strip all attachments, executable or otherwise, and stick them in a protected folder on the server. That way no-one can click on a link, or accidentally execute an attachment.

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:Phishing? Pharming?

[rob_au]

phucked (v. tr.): To be taken advantage, betrayed, cheated or victimised by a phishing scam.

Re:Flash-forward.

[Felinoid]

Going from 32 bits to 64 bits is a direct upgrade.
Going from Text to HTML is switching technologys.

If you rename a text file from hello.txt to hello.html and pull it up in your web browser you will lose all the formating as HTML expects you to do formating with HTML commands.

32 bits to 64 bits just means your computer can hold more information in one registar.

Also there is nothing stopping a kernel hacker from modifying Linux to store the time/date in two 32 bit regestars instead of one.

Text to HTML is like the diffrence between walking and riding a bike. To edit HTML you still need text. So if an issue were to crop up with Text (like the 32 bit time bug) not only could we not switch to HTML to fix it HTML would be screwed as well.

HTML is a good technology that (IMAO) has been been pushed too far too fast.
But it's not a replacement to text only a better choice when text won't do the job.

Kind of like how a desktop PC dosen't replace a pocket calculator.

And on that note I've been writing my documents mostly in HTML for 10 years now and using a PDA for the last 3.
And I still have a solar powered calculator and get all my e-mail in text.

Related methods

[photon317]

It would be trivial for the spyware which is rampant on the average user's wintel PC to alter their network settings to point the user at custom DNS servers run by the spyware companies. These could act as dns caching proxies for the most part, but then selectively fail to resolve sites the spyware companies don't want you to see, selectively redirect your queries to the webservers they do want you to see, and in the hands of the nefarious, spoof your bank site too. Until the massive gaping holes in the average user's wintel PC are closed, complex infrastructure exploits are really a waste of time. It's so much easier just to seize their PC and have your way with it.

Re:Just don't read emails from the bank-Digital Fa

[rs79]

"How do you tell bad bits of html from good bits?"

Check the evil bit in the TCP/IP header.

You missed the cache part

[highcon]

No. That is not cache poisoning, since it doesn't poison a cache. All DNS servers will cache records that they had to look up. It works like this: Someone queries a DNS server, asking what IP an address maps to. This DNS server doesn't know, and must query another server to find out. Our DNS server sends the query out to another DNS server that would know the answer (the authoritative server for that domain) and waits for a response. When it receives this response, it answers the original query and caches the response so the next time the same query is made it has the answer.

What the attacker does is sends out several (as in, a LOT of) queries to a DNS server for a name, say bank.com. Then, the same attacker sends out several (!) spoofed answers to this query, saying that bank.com maps to a certain address, which is actually some server the attacker controls. The goal is that your bogus response will beat the real response and be accepted by the target DNS server. If the attack is successful, this bogus answer is cached, so when someone else goes to look up bank.com from that particular DNS server, they get the IP of the attacker's server.

The trick is that a DNS server will pick a random number that it assigns to the query sent out to the next DNS server. The response must contain this number for it to be accepted as authentic. The attacker very rarely can know what that number is, hence the large amount of query and answer packets that must be sent out (you are essentially trying to get lucky and hope that one of your fake response packet's number matches one of the server's query packets). In a perfect world, these numbers would be truly random and an immense amount of bandwidth would be required to get enough packets to the server to have a shot at guessing correctly. However, many of the DNS servers pick random numbers out of a much smaller field than they should.

Re:DNS cache poisoning?

[swmccracken]

Serious yes, but been around a long time.

One example of a cache poisining attack is for a DNS server to provide 'extra answers' for a query.

eg: dns resolver (for an ISP) asks ns.network.net for the records for www.network.net, because some user wants to look at it. No problem it says, and gives back the address of www.network.net.

However, if ns.network.net was malicious, it might also give the address of www.bank.com. If the resolver then accepted this address of www.bank.com and entered it into its cache, well, www.network.net has just taken control of www.bank.com. :-)

(This is why various DNS resolvers have features to ignore additional answers to queries, or ignore answers outside the 'bailiwick' of the server, or things like that. Glue records do make the situation more complex than I've described.)