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)."
They use the it. subdomain for their really ugly phishing schemes.
Coral Cache (get the firefox plugin !)
0 05/03/07/phishers_use_wildcard_dns_to_build_convin cing_bait_urls.html 0 05/03/07/dns_poisoning_scam_raises_wariness_of_pha rming.html
http://news.netcraft.com.nyud.net:8090/archives/2
http://news.netcraft.com.nyud.net:8090/archives/2
enjoy !
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!!! ;)
cat life | grep joy >> memory
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.
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.
This is just stupid. An IP address isn't that much longer than a phone number. Get the bank's phone number on a card from the teller. Get the bank's IP by calling the teller. Use the IP instead of the domain name, and don't fucking worry about it.
Also, don't we have encryption to stop this shit? (That's rhetorical, I know we do.) Why isn't it being used?
Time to scrap this whole "DNS" thing. I don't know what it is, but it sounds dangerous.
I was kinda worried that I haven't read much with dns poisoning and phishing.
It's a rather obvious way in if you think about it.
I suspect it has happened before, but what the public doesn't know won't hurt them? Up until now anywya.
What about BGP poisoning! Oh the humanity.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
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.
After sending all my money to various Nigerian organizations, I wish I had some money for someone to siphon in a phishing scam!
I'm a big tall mofo.
How many other f words can we change the spelling of and adopt as descriptions of security hazards?
who needs all that fancy stuff, i never go to slashdot.org, it's always 66.35.250.150
For convenience, please post all Netcraft jokes here.
Ladies and GentleGeeks. Welcome to a perfect example of a society without laws.
You all wanted freedom without limits? Well here you go. Enjoy yourselves.
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.
Avoid Missing Ball for High Score
"After sending all my money to various Nigerian organizations, I wish I had some money for someone to siphon in a phishing scam!"
You're an unemployed, outsourced, downsized geek. Blood from a stone I tell ya.
it's http://slashdot.org (.ORG...the .com is purely coincidental and used because n00bs type in .com by default.
I see how the first and third examples are encoded, but I don't see the trick in the second one. How is that a valid URL in even the loosest sense of the acronym? It looks like a broken example to me.
So I guess all that GPG, Digital certificates, Digital Documents, S/MIME thing isn't working out.
Were's a technical solution when you need it?
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.
The problem is this: there shouldn't be a link in the email. The user shouldn't even be able to copy and paste a URL from the email.
It seems, then, that the safest way of ensuring this is just to request no emails. Or, manually type in the URL of the bank. (But then you have to *remember* to do that.)
"If this isn't solved definitively, it could destroy e-commerce."
Let's put ChoicePoint in charge of a solution. That'll inspire confidence.
No, the problem is this: html email. What's wrong with plain text? I'm serious.
"No, the problem is this: html email. What's wrong with plain text? I'm serious."
And 32bit CPU's are good enough for everybody.
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?
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?
The recommended solution to this problem is to bypass DNS and type in all IP addresses by hand.
I can sell you attractive hand made table of domain to IP mappings for the top 25 sites on the internet for just $5!
"Don't enter sensitive information into a form linked from an email."
So what about the latest editable PDF's?
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.
For context, click Parent.
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.
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.
http://www.busyweather.com/
"Thoughts?"
How do we know you really are kebes (861706)?
Hello,
0 8/0052235&tid=95
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.
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".
There is no sig, there is only Zuul.
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.
The higher the technology, the sharper that two-edged sword.
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.
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
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.
Part of the solution is the fact that there already is a pre-established relationship between the two entities. Smart-cards, or read-only USB sticks with a challenge-response built in. Hit all the "fake" sites you want. Only the real ones know what questions to ask. What the proper responses are. Port-knocking could even be part of this.
I can't believe that these kind of tactics still cause problems when any and all 'phishing' (I hate that word) tactics would fall flat if people simply got a clue and stopped clicking links in their email. That's been the common thread of every method so far.
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).
No, the problem is this: html email. What's wrong with plain text? I'm serious.
I dunno. I still use pine for my email, and I love it.
My boss however, would throw a fit if they weren't able to send email with big red fonts, inline images and other crap.
The Phishing scam outlined in the article is why Firefox1.0 became Firefox1.01. The Internet Exploder crowd said "See, Firefox has problems too", and while not invulnerable, Firefox came out with this real quick. Cryllic characters are not shown as english equivalents, but as Phishy characters, letting the user know that the site isn't quite what they expect. Internet Exploder and others have the exact same problem, and an industry-wide technical solution to this scam is really required (although the method Firefox1.01 uses seems to be one of the better solutions).
can anyone provide more information about this 'DNS cache poisoning' thing? the article and wikipedia (and several other pages I got from google) don't explay how this 'attack' is done.. it sounds serious.
--
Stay tuned for some shock and awe coming right up after this messages!
That isn't horrible, but you still have typo risks, that and the response rates suck. Besides most sites simply aren't well enough designed to provide messages (i.e. log in, and get the message). The easy way (since getting large numbers of people to use s/mime or gpg is probably out) is to have a complimentary safe word that you provide the bank to use on email communications to you.
Then assuming they remember the rules, they can only be phised if the scammer knows/guess their name(there is no reason in this modern age to have a dear members letter ever, it should have the full name). and the safe word.
Phishing is a real problem, it went from don't click on anything that isn't profesional looking and sounding to make sure the site really is the banks to if they really want it so bad they will pester you the next time you log in.
I'd do something interesting, but my server can't handle a slashdotting.
Does your bosses always use the royal "we"? :)
"As far as I'm concerned, if you don't take the necessary measures to protect yourself, you deserve whatever you get."
And hence the AIDS Epidemic, and terrorists attacks are exlained.
As long as "BEGIN PGP SIGNATURE" is in that text somewhere.
No, the problem is this: Mail readers that execute bad bits in html email. What's wrong with sterile HTML? I'm serious. HTML is text.
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
How do you tell bad bits of html from good bits? As long as there are links, it's possible to phish. Some of the phishers use fairly obviously bad urls if you read as plain text, but if you let them display their image and link it's a faked Sunbank link (or somefink).
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.
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.
11*43+456^2
"How do you tell bad bits of html from good bits?"
Check the evil bit in the TCP/IP header.
Need Mercedes parts ?
SRP (Secure Remote Passwords) is a protocol that authenticates both the user and the server. Essentially, it makes sure that the server knows your password. Unless the protocol has unknown weaknesses, the security is essentially the best you can get:
Eavesdropper gets nothing.
Guy pretending to be client gets one guess per login attempt; if he's wrong, he can't log in.
Guy pretending to be server gets one guess per time he can get the client to type his password; if he's wrong, he can't log the client in. If the implementation caches passwords, this is exactly one guess.
Man in the middle gets nothing other than his two guesses (for pretending to be the client, and pretending to be the server), and can't snoop on the connection.
Guy who steals the password database on the server gets a dictionary attack, and can impersonate the server successfully.
All this without SSL certificates or anything. Unfortunately this is not implemented in most browsers or websites; there is a patch for SSH to use it though.
I hereby place the above post in the public domain.
Oddly enough, I just recievedd my first phishing attempt recently. It might have worked, but for two things. The page looked totally legit, right down to the avoid online fraud bit. The things that made me think it was a phishing attempt were the fact that I don't have a Washington Mutual account, so they wouldnt send me an email, and the fact that it went to 211.121.x.x, rather than the URL. I recently got online checking with my new bank, but I wont ever click a link to get there.
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.
"Looks like our site has been 66.35.250.150'ed!"
One line blog. I hear that they're called Twitters now.
Except, burn that hydrogen.
Is a society without laws worse than a society with laws made by Bill Gates and his friends?
There are schemes which allow two parties to validate to one another (as opposed to one-way) without either revealing their secret. Effectively:
What part of "gestalt" don't you understand?
That's one question. Perhaps the bank is a subsidiary and doesn't (isn't supposed to) have its own site. That would be an ideal bate for a phish. (Well, ideal for the phishers, anyway.)
(Hmm. at Google, "coamerica bank". Hmm.)
Maybe I should an e-mail to barrister-suites.com and encourage them to warn their customer that they may have suddenly and unintentionally gained a web site.
Plain text is simpler to parse and display. If you have two things and one is simpler, I bet you the simpler one is more secure.
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.
??? Let's DOS the bank, while it's down, we'll do them a little favor and back their site up. If you need to go to the bank, get on your bike and go.
maybe I'm just high. But that is some funny shit.
because they're dirty yet clever.
Suppose through spyware/malware/trojans/virus/whatever, a virus writer were to scan your web browser history, find out what bank in particular you visit, then simply modify the local HOSTS file buried under the system32 directory to point to a specific IP address.
They could then design a login page that doesn't even have to be encrypted (I'm sure most people wouldn't bother to notice) which mimics the real bank's login page. They give one or two "failed" login attempts before redirecting the browser to the real site.
Instead of hijacking dns in some weird way, it simply instructs the local computer to resolve certain DNS entries to something defined locally. After the user thinks they got their password wrong, the phisher's web server redirects the user to the real bank's login page.
This would be something that is entirely possible (virus spread by active x, email, whatnot) and monitors the web browser history for recent activity for a list of known banks, and once that user does their online banking, spoofs the local machine to go elsewhere for subsequent banking. The user doesn't know what happened, and in the meantime types in their banking information that would reveal bank accounts, etc.
Once successfully mined, the bad guys might send an 'abort' sequence to remove all evidence of what happened and move on to the next guy, thus making it hard to track what really happened. Since that entry would be removed from the HOSTS file when that happens, most people would assume they got a string of bad luck for a few login attempts and all seems to be well again (only it's not, since that personal information is now made not quite so personal anymore).
Just suppose this virus created keeps a low enough profile for long enough, even having a firewall antispyware and virus scanner might not help you out.And DNS wildcards are totally sidestepped.
moran
I've said it before...
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...
vk.
I think spammers/phishers deseerve a special place in hell. I got an email supposedly from first ebay then a different one from paypal and yet another from washington mutual bank(?) concerning my account information. Since I've never set up an account with any of these, I knew instantly it was a phishing scam.
Not only that but when I hover the mouse on the link, it shows the target URL at the bottom and resolved to a fixed IP address (e.g. http://219.44.99.123/ as an example. I just made this address up) rather than point to their respective DNS names.
So (this is the sick and sadistic part comes in), I figured I'd fill out their forms with my "personal" information which is entirely made up. Everything on the form was invented. The name, the address, everything, including the credit card number. After doing that, I sent a copy to abuse@ebay.com, etc.
On one occasion, I got a response email stating there was a problem with my credit card information and I needed to reenter it.
The probem here was that I use the first 4 legitimate digits for visa, but the other 12 digits were entirely fictional and the checksum digit did not match.
I've been toying with the idea of using a credit card number generator and getting past that specific problem, but what if the number that the cc generator picks happens to be a legitimate credit card number and some poor shmuck gets charged? I'm not quite that sadistic.
I wonder if my bank would be gracious enough to issue me a defunct credit card that I could use specifically for this purpose. Failing that, what we need is a list of banned credit card numbers, so when these scammers try to use them, there's a trail that leads the authorities right to their door to haul them away and give them what they deserve.
The way I see it, they took the time to write me for my information which they'd use to screw me, and the least I should do is to return the favor and give them just enough to make them think they got away with it but in fact they expose themselves to getting caught.
Plus, the url might look right if the Phisher used a trojan to install a hosts file on your box.
If a trojan is installed on your box, it could be keylogging or any number of other things anyways. At that point I think you're past worry about being phished, you've already been landed.
Just log in as normal. If any company that I do bussiness with apparantly sends me an e-mail, I don't bother to check if it's real or not, I also don't bother to grab the link, not as much for security but out of laziness (I use pine). I just go and log in to their site as normal. If there is something they need, it'll get my attention.
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.
It's not a problem of openess, but one of trust. You can still have open interchange of information on the net, you just can't have any trust, at least not for most things.
ARPAnet was designed assuming that everyone on it would be government/research. There wasn't any worry about jackasses, if you were, you'd just get your access yanked. The Internet is open to all, thus lots and lots of assholes (espically anonymity beings out the worst in assholes). So some assumptions that were orignally made aren't valid.
I mean look at how UNIX used to be, servers had all you needed to DoS their link right on them, services like chargen, that would just send you random characters for testing and so on. It was a very trusting environment.
Well now we've just had to move to an untrusting one, and will have to move further towards that. Doesn't mean we can't still have infromation exchange, and have it free of any controling body, just means that people who participate have to get careful.
I advice people not to click inlined url's and search their bank's link via google.
h tm
You type less, and google shows just the relevant url's, so it's safe to click them.
http://www.seguridaddelainformacion.com/seg_0e.
I can 1 up that:
1 95 2820932.%73%6c%61%73%68%64%6f%74%2e%6f%72%67/%61%7 2%74%69%63%6C%65.pl?sid=05/03/0%208/0052235&tid=95
http://bankofamerica.com|index.cfm|sid=1%200020
Err... In Soviet Russia, you report Netcraft is dying?
...we're all phucked then!
Gentoo Linux - another day, another USE flag.
-and flag as spam/autodelete any and all HTML email. That is how I deal with phishers. I got tired of dealing with their (ultimately pathetic) subterfuge which is OBVIOUS by simply comparing the domains in the bogus href link in the underlying HTML to the link text that is displayed to the user -- they aren't the 'same'.
As has been mentioned earlier: Do not click emailed links to sensitive websites--type the URLs to them into a new browser window instead.
Of course, if the HOSTS file gets 0wned by malware, the above advice is pointless....
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)
Yeah, I'm sure Russian speakers who want Cryllic or Japanese speakers would really like that feature. There is, interestingly enough, an attitude among Spanish speakers to remove non-ASCII from IMs and other casual Spanish-language conversations. When I was chatting one day with this pretty Chilean girl, using proper Spanish complete with accents (Comó estas? and what not), she corrected me, telling me I sounded too formal when I used the accents.
One of the many nice things about Gmail is that, whenever you receive one of these dodgy phishing e-mails, it puts a big red banner above it saying "Danger! This may not be from whom you think it is", or words to that effect.
I'm not sure if anyone will read this warning, but it seems like a step in the right direction. And one interesting way in which webmail can provide a feature that's not feasible for normal e-mail clients.
Easy to fix. A good mail reader would:
* Have scripting
* Expose all links as their real address, with the link name in parens
* No embedded objects
* Remote images wouldn't load unless toggled
HTML isn't that much more complex than text. Why don't we just revert back to gopher? It's way more simple than HTTP and more secure. And text could conceivably be insecure also... For instance, a naive user who would even cut an paste a bogus URL, or some buffer overflow from a finely crafted text file (a la Microsoft's JPEG issue).
LS
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie
MOD
That won't work if your bank is using $7.95/mo hosting at somewhere like iPowerWeb/Globat/PowWeb.
None. Or use Eudora Pro (invented antiphishing), Thunderbird (I guess they added?).
If you detect, no need to war with console etc. Use http://www.spamcop.net to do the job for you, find required contacts. Don't forget to add "phishing" "against law" etc to reports so ISP's can give more time to them. Its basically much more important then a Korean or Sex spam.
I use Eudora Pro on mac. Of course Apple mail is great too but I like the advanced attitude of Eudora.
I guess it does what you need. It shows advanced stuff in plain text only rendering inline images and plain HTML.
As a result of this, they get flamed at versiontracker as "they can't render html correct even! Lamers! Paying for a mail client!" type feedback. Don'T forget its in fact free for showing banner (opt in secure type, like 5.x opera days)
No wonder companies are staying away from your insightful idea.
Its good to see that on the final redirection on the article (from kickme.to going to pochta.ru) the server is running FreeBSD - at least it is probably a fairly secure server :)
Neither of these actually work in Firefox.
Follow me
I got a near similar one from my bank...and being as leet as I can, I almost fell for it. The i realized there was a floating URL on the top portion of the page...weird. and the over feel of the fake page wasnt what it should be. Funny thing is, for customer care at the bottom of the page, they put the real bank customer help phonenumber.a tion.asp?d =1m er/logo n/
i followed the link provided
https://login.personal.wamu.com/verific
which brought me to here.
http://www.mobiuscreative.com/secure/custo
3 Melody
I think now with SP2 (XP) Outlook Express, by default, blocks images and URL's until you enable them via the 'information bar'.
It's funny I used to hate HTML email back in the day,*cough*14.4bps*cough*
Been down this road with the spoofed HOSTS file and went ten rounds with the hosting provider on this matter, until I dropped the hammer on them with a nice note to the banks in question.. Now I doubt that any hosting provider would want a International Incident for not pulling a phishing site in a timely manner, don't you think? Or are they simply too mercenary to ignore the risks or getting their root DNS blocklisted by the big boys?
First rule of holes; When in one, stop digging.
Jesus, this has been going on for years! cache poisoning
Yeah, I'm sure Russian speakers who want Cryllic
Cryllic? is that like a language for Crayola crayons?
I was chatting one day with this pretty Chilean girl
how do you know she was pretty if you were IM'ing her? prolly some fat hairy latin-type guy
That's just the lameness filter. Remove extra spaces and try again.
With Phishing so much in the news http://yro.slashdot.org/article.pl?sid=05/03/05/00 42226&tid=158&tid=218, http://slashdot.org/article.pl?sid=05/03/08/005223 5&tid=95, and the difficulty that most users have in detected a phishing url without tools like http://toolbar.netcraft.com/, http://www.corestreet.com/spoofstick/ it occurred to me that maybe a solution lies in creating a exclusive Top Level Domain(TLD) for banking. Many of the current problems reside in the free-for-all nature of registering a .com domain name which allows anyone with a credit card, forged or real, to create a domain name convincing enough to phish people. For example my email from Saturday contained an email with these two links purporting to be from Washington Mutal, https://login.personal.wamu.com/logon/logon.asp?dd =1> and http://login.personal.wamuecare.com/%20/logon/logo n.asp/dd=1/login.php in it. One is Washington Mutual's one is a phish.
.bank TLD, but making it exclusive to banking and financial isituditons with heavy checking of the business records of the applicatnt and even requiring a bond be posted in the range of $100,000 to $1,000,000. This high a level of entry to registering a domain in .bank would prevent all but the most dedicated phishers from registering say, wamuecare.bank since they would lose their bond if any fraud was found. While your typical user would have no trouble with seeing the .bank at the end of the domain name, and would have confidence in the web site he/she was visting. The cavaet being that the current round of url line spoofing attacks need to be solved, as Opera has http://it.slashdot.org/article.pl?sid=05/02/25/155 3236&tid=172&tid=218 . Of course International Domain Name (IDN) characters would have to be disallowed in .bank as well.
.bank domains but no one else. Lastly perhaps our govenments can mandate the use of this .bank TLD as a consumer protection keeping banks from trying to be cheap and stick with the .com domains they currently have.
./ community thinks of this as well as what we think the defintion of a "bank" would have to be for this to work.
I propose setting up a new
In my mind any organization that has real or "credit" monies that is keeps for it's customers, PayPal comes to mind, could apply for
I'm interested in what the
Netcraft confirms DNS is dying!
Slashdot trolling phenomena
Really, why would anyone bother with fixing the banking systems ? Same goes for Western Union / Money Gram and other systems that are used for mass fraud. They get paid for transactions, legit or fraud... why bother ? They make good money out of it and everybody is doing it so if you're losing a customer, you'll get another one that got "burned" with the same thing at another bank.
I, for one, wouldn't help too much to find fraudsters because I get paid, too.
but they work in IE...
for what should be "-1 too obvious".
Oh great...now all the phishers out there know exactly what to do. *D'oh!*
I had another idea, even easier than all this trickery. Just install a keylogger that sends off keystrokes...then they know which bank (without guessing) and what your acct no. and password is. Ugh.
Sad thing is, I've seen so many trojans on so many computers. 2 on one computer, 3 on another just today...too many to list in all. Any one of them could have logged keystrokes and sent 'em off to an IRC channel without a problem.
As for the HOSTS file trick, read-only means nothing...and I've seen spyware that is so aggressive that it re-writes the HOSTS file every 5 seconds if it's own search URL/IP's are touched! Remarked, removed, altered...anything. It could have easily been a list of all known banks, securities, trading sites.
Ah well, keeps me in business.
Do you think any one of these users would consider Linux? -- Nope.
Inject.
The little padlock has always been a rather weak bit of UI thinking. From the start, EVIL.COM could get a certificate confirming that they were EVIL.COM, and then put up a fake bank login screen. Look, a padlock! You must be safe.
Then it turned out that Verisign would happily issue certificates to THEB4NK.COM, or even less noticeable internationalized domain look-alikes. An untrustworthy CA is trusted.
If as you suggest it is possible to add trusted CAs to the browser's list (and in the case of Windows, this could go for the whole OS), actually verifying a certificate is going to be beyond the capacity of most regular users.
Three quarters of those questions ask if something "seems" correct -- there's a great deal of subjective judgement involved in verifying this sort of thing, and we all know how terrible many users are at making these sorts of judgements.
And it's not even a complete list.
Don't forget to sign it with a certificate from your spurious CA: you've told Windows to trust your evil CA for code signing, surely?
Mind the Gap