Analysing a phishing email
I've been hit by several phishing emails in a short time the last week. Having time this morning I took the initiative to look at the headers from one email and the phishing location.The hosting server
The domains DNS zone is hosted on a particular network just like its website. Two different servers actually, but behind it seems to be a lucrative webhosting service where you can get your domain registered although it's not a registrar. All of this is hosted in Texas.
The email server
The email is originating from Italy. The FROM address is set up to show a truthful email (usually where you put the surname) with an inexistant email address behind that. The email address' domain name exists however and is hosted in France, but has no relation to the scam, at least the owner of this domain can't do anything about it.
The Return-Path shows a real email address with a different domain name but same network anyway. The domain name shows a dummy webpage "Under construction".
Who to contact?
All of them if you care, otherwise just let it go, because phishing pages are set up and down daily...
To contact the webhosting or email server, request the Whois information of the IP address and contact the abuse department, there is always an abuse section in the Whois of an IP address. You can also contact the domain name holder and/or look if the registrar or webhosting sevice has a dedicated abuse website page.
Of course it happens that an abuse email address forwards everything to the trash can. In order to have a chance to stop the scam, it is good to contact as many services as possible.
Analysing a phishing email
I've been hit by several phishing emails in a short time the last week. Having time this morning I took the initiative to look at the headers from one email and the phishing location.The hosting server
The domains DNS zone is hosted on a particular network just like its website. Two different servers actually, but behind it seems to be a lucrative webhosting service where you can get your domain registered although it's not a registrar. All of this is hosted in Texas.
The email server
The email is originating from Italy. The FROM address is set up to show a truthful email (usually where you put the surname) with an inexistant email address behind that. The email address' domain name exists however and is hosted in France, but has no relation to the scam, at least the owner of this domain can't do anything about it.
The Return-Path shows a real email address with a different domain name but same network anyway. The domain name shows a dummy webpage "Under construction".
Who to contact?
All of them if you care, otherwise just let it go, because phishing pages are set up and down daily...
To contact the webhosting or email server, request the Whois information of the IP address and contact the abuse department, there is always an abuse section in the Whois of an IP address. You can also contact the domain name holder and/or look if the registrar or webhosting sevice has a dedicated abuse website page.
Of course it happens that an abuse email address forwards everything to the trash can. In order to have a chance to stop the scam, it is good to contact as many services as possible.
More Firefox 3 SSL Junk
Lately I’ve noticed a flood of Firefox 3-related posts regarding the new SSL error handling on Planet GNOME. It’s a little funny, as I was writing about this myself a little under two months ago.
Chris Blizzard posts in favor of the new arrangement, and points to an interesting post by Johnathan Nightingale explaining Mozilla’s position. Yes, agreed, Jonathan’s post is a good read, but the salient point is that the new UI is just awful from an average non-technical user’s perspective.
The extra clicks and somewhat abnormal flow (e.g. the need to click a button in the dialog to fetch the certificate) make it harder for the user to understand how to successfully add the exception. You might say that some false positives (i.e., users who fail to access a site that they really actually do want to access) is better than a user succumbing to a MITM attack, but I’m not sure I’d agree.
Equally importantly, the error messages make no distinction between the potential severity of the various SSL errors. For example, I’d say a self-signed cert on a site that you’ve never visited before is fairly low-risk. But a self-signed cert on a site that used to have a trusted cert would be a huge red flag. Domain mismatches and expired certs would fall somewhere in between. It’s hard for the average user to make an informed decision on risk/severity if they were to encounter both of these situations because the error messages and dialogs look exactly the same.
Addressing Johnathan’s main point about self-signed certs and level of security: as a highly technical/advanced user, I personally can say that, in the vast majority of instances where I encounter a self-signed cert, I really do just care about the encryption, and I don’t particularly care about the identity verification of the site that a trusted cert could offer. Now, Firefox probably shouldn’t use me as an example as a target user that needs protection, but that’s a data point nonetheless. I don’t care for things like: Bugzilla installations, my blog, accounts at sites like identi.ca, Twitter, Slashdot (they don’t offer SSL at present, but if they did…), etc.
Pretty much the only time I do care are for financial institutions. And guess what? They’ve already decided that SSL as used for identity verification is useless! Most of them (I can only think of one that I use that hasn’t) have already implemented a “security image” system wherein I pick a random image that gets shown to me every time I log in. If a site claiming to be the site I want shows me an image I don’t recognise, I’ll know that the site is a fraud. Is it perfect? Probably not. But it’s orders of magnitude better then what SSL error dialogs offer.
And I guess that’s really it: as much as I hate the phrase, I really think that the SSL error dialogs are “a solution in search of a problem.” In the cases where I care about site spoofing, the sites themselves have already implemented a better solution. In the cases where I don’t care, well… I don’t care.