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)."

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.

Its very simple...

[scsscs]

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

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 [cr.yp.to] and MaraDNS [maradns.org].

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.

Re:Stupid

[Anonymous Coward]

There are secure DNS extensions that allow DNS records to be digitally signed. Alas, ICANN/Verisign have not put the infastructure in place to make this level of protection for DNS records a reality. :(

Interesting timing

[Anonymous Coward]

I jost got an e-mail from a phisher. Of course, I immediately knew it was bogus but I thought I'd check the URL they use just for fun. The URL it was using was similar to the bank they perported to represent. In fact I'm not familiar with the bank: comerica: anyone ever heard of them? The phisher's URL is bank.coamerica-banking.com:6180 but the URL www.coamerica.com looks legit. So, the idea is that the coameric-banking.com DNS entry is poison?

Spoofstick

[Omniscientist]

Spoofstick [corestreet.com] 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:My Anti-Phisher Scripts (attached)

[cjsnell]

Jeez, Slashdot really munged my indenting. I hope you guys can make sense of that. I have a bunch of variations on this script that I did not post. Here is a little snippet to generate real-looking credit card numbers, PINs, CVVs, and expiration dates and add them to the URL:

my $card = $rand->randregex('\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d ');
my $pin = $rand->randregex('\d\d\d\d');
my $cvv = $rand->randregex('\d\d\d');
my $zip = $rand->randregex('\d\d\d\d\d');
my $mo = $rand->randregex('0\d');
my $yr = $rand->randregex('0\d');

my $url_base = 'http://203.98.132.60/~temp/combinatie/yabe/ovy.ph p?subject=C
ard&redirect=success.htm&CardType=Vis aDebit&submitBtn=Continue';

$url_base .= '&Card=' . $card;
$url_base .= '&Pin=' . $pin;
$url_base .= '&CVV2=' . $cvv;
$url_base .= '&Zip=' . $zip;
$url_base .= '&LunaExpirare=' . $mo;
$url_base .= '&AnExpirare=' . $yr;

Re:It takes some evangelizing

[harrkev]

This still won't protect you if your hosts files is hosed.

Re:Passwords should work both ways

[ScrewMaster]

Because U.S. consumers are driven largely by convenience. The banking/credit system is a big part of the problem, sure ... but so are bank customers that get annoyed at security measures. I've seem people swear at a teller that asks them for an I.D. I'm the other way around: I get irritated if they don't make sure I'm who I say I am. In any event, both consumers and the banks are going to have to change if we don't want to go back to hiding our money beneath a loose floorboard, or stuffing it in our mattress.

Re:Passwords should work both ways

[DavidTC]

Or call you and your bank at the same time, passing messages back and forth. Aka, a man-in-the-middle attack.

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.

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.)

Re:Its very simple...

[goober1473]

Interestingly I got one of the mails yesterday and went looking, the SSL cert on the site I got to looked like this...

Common Name: ibank.barclays.co.uk
Organization: Barclays Bank Plc
OU: Enable

And was issued by Verisign, expires on 03/08/2005 (UK format).

Which all looks OK, but as I have never had a bank account at Barclays I went there and let them have some crap data.

Re:Call me sick and sadistic, but......

[Anonymous Coward]

You can use the below test card numbers, which will never charge anyone:

5473 0000 0000 0007 (Mastercard)
4111 1111 1111 1111 (Visa)
4444 3333 2222 1111 (Visa)
3434 343434 34343 (American Express)

Just make up a future expiry date.