Slashdot Mirror
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)."
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.
Portland, North Dakota Puppies
Don't enter sensitive information into a form linked from an email.
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.
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. :(
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 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.
This still won't protect you if your hosts files is hosed.
"-1 Troll" is the apparently the same as "-1 I disagree with you."
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.
The higher the technology, the sharper that two-edged sword.
Or call you and your bank at the same time, passing messages back and forth. Aka, a man-in-the-middle attack.
If corporations are people, aren't stockholders guilty of slavery?
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.
You can either complain, or do nothing. You don't get both.
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.)
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.