Phishers Build Deceptive Links with DNS Wildcards 245
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)."
Re:Its very simple... (Score:1, Insightful)
Unfortunately if DNS poisoning takes off it might not be wise to even go to the website either
Just don't read emails from the bank-Digital Faith (Score:2, Insightful)
Were's a technical solution when you need it?
Re:Just don't read emails from the bank (Score:4, Insightful)
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-Digital Fa (Score:4, Insightful)
It takes some evangelizing (Score:4, Insightful)
Re:Just don't read emails from the bank-Digital Fa (Score:5, Insightful)
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/
Thank you for your time,
Bank of America.
The ambiguities of trust (Score:3, Insightful)
I think this is already in place and widely used, although the present implementation seems quite hypocritical to me.
Supposedly at least, and someone might correct me on this, my understanding is that this is what protocols such as https are supposed to do already. (I'm not an expert on which protocol does what, so apologies if I have my terminology mixed up.) The bank verifies itself via a certificate issued by a third party (such as Verisign) that your web browser's distributor has decided to trust. (You, in theory.)
Much of it is idealism and I'm sure the usefulness of this is all quite challengable, of course. I personally doubt that most people actively decide which third parties they want to trust for authentication, but simply accept whatever comes with their browser, wherever it came from. (eg. How many people out there have installed Firefox from a disk given to them by a friend?) I also suspect that many people simply install random certificates and "trust" whatever additional entities they're told they need by anonymous distributors of software.
It's as if the trust model started out with good intentions, but it was scaled back once everyone realised that most people simply don't prioritise complicated decisions about who to trust. Now we have all those decisions made for us by entities who might as well be anonymous.
What you've suggested seems to enforce a much more active method of users authenticating their bank, and it might work better. It'd take some effort to get past that barrier of people not bothering with what they find irritating, however.
Why is this still an issue? (Score:2, Insightful)
I suppose it's a bit much to ask for for the general internet populace to get a clue, however. Still, a warning hardly seems necessary here considering I'm pretty sure most Slashdot readers understand not to click banking links in their email for any reason, even if the email isn't obviously a scam (which it always has been for me).
Re:Passwords should work both ways (Score:4, Insightful)
The SSL certificate that the bank's site presents to you when you connect is all the proof you need that your traffic is not being intercepted.
Unfortunatly, today's browsers hide the information about who the certificate was issued to away in a separate screen. IMO the subject of the certificate should be displayed in the status bar, where Firefox currently prints the hostname of the displayed site (needlessly, since that information is already in the address bar!)
But this isn't perfect. The certificate authorities treat the x509 dname as a unique block of text, rather than making sensible use of all the fields. Thus my bank presents a dname of "CN = www.ebank.hsbc.co.uk,OU = Terms of use at www.verisign.com/rpa (c)00,OU = Terms of use at www.verisign.com/rpa (c)00,O = HSBC Holdings plc,L = Sheffield,ST = South Yorkshire,C = GB".
IMHO our current CAs have buggered up the job, and deserve a good slapping. Instead of allowing a random company to buy its way into the CA market by paying off Netscape and Microsoft, we should ditch the present model for high-risk uses such as online banking.
Banks should issue their own (self-signed) certificates. When you open a bank account, you are supplied with the SHA1 and MD5 hashes of the certificate that the bank uses; the first time you visit the bank's web site, your browser throws up the "unidentified certificate" warning. You then eyeball the certificate, note that the hashes match those you have been provided with, and import the certificate into a store for future use.
The annoying thing is that we could do this *today*, if only people would start giving two shits about their security.
Maybe after a few thousand people get ripped off by identity thieves, people will start caring.
Re:Passwords should work both ways (Score:3, Insightful)
Then it doesn't matter who initiates future communication, because all messages can be authenticated against the sender's public key.
Re:Just don't read emails from the bank-Digital Fa (Score:3, Insightful)
Re:Just don't read emails from the bank-Digital Fa (Score:4, Insightful)
The easiest thing is to turn off html, turn off display of inline images, and turn on display of full headers.
People (and companies) send way too much garbage as html or attachments that would be just fine as text. I got into the habit of using text as much as possible when working on a proposal with a bunch of astronomers who don't use MSOffice except at gunpoint. It works great, especially if you use things like sentences, paragraphs, and punctuation.
Re:The ambiguities of trust (Score:1, Insightful)
furthermore the browser veondor thats really in control is ms (people WILL complain LOUDLY if IE recognises a cert and FF doesn't)
so we are basically being forced to trust MS to vet certification authorities yet MS has other motivations (money? antitrust issues?) that may rank higher than the trustworthyness of the certification authority in the decision of whether or not to add a cert to IE (which as i said pretty much forces other browsers to follow)
Related methods (Score:5, Insightful)
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 (Score:1, Insightful)
Once people get this into their heads, we might actually have secure software. Unfortunately many people think like you (apologies if you're just joking).
Can you write an HTML sanitizer that's guaranteed to work?
I can tell you how to write a text sanitizer in a few sentences:
1) remove all bytes outside of the valid ASCII range for printable characters (we won't support unicode or even 8-bit encodings like latin1, because they might confuse somebody's terminal)
2) convert all runs of whitespace that are not newlines to a single space. Leave newlines in place.
3) begin displaying characters and incrementing a counter for each character. once the counter reaches 68, begin watching for space characters. If you see one before the counter hits 78, print a newline instead of the space. If the counter hits 78, print a newline. Always reset the counter to 0 after a newline is printed.
Now.. what's the algorithm for parsing HTML? Hmmm.
DNS is the achilles heel (Score:4, Insightful)
DNS is the achilles heel of the web. Take down/redirect/spoof/molest DNS, and it doesn't matter how many redundant whatevers and caching whothingies you have.
Nobody's getting to you.
And they may be getting to somebody else.
But DNS isn't glorious, so we'll keep spending the time/money on other things...
No you can get e-mails and not worry (Score:4, Insightful)
Thus you don't need to worry about getting phished, but you don't need to exclude a convienent method of communication.
My bank actually doesn't do e-mail, they call me if they want my attentino, security reasons, however Paypal and eBay are both pretty much e-mail only. Not supprisingly, the phishes I do get are usually for those, not my bank.