techblog 

Typo-squatting is the practice of registering a domain name with the intent to confuse it with the name of a trademark or a famous other domain name

In March, I presented the paper Typo-Squatting: The “Curse” of Popularity in the poster session of the first International Conference on Web Science in Athens. The paper, written together with co-authors David Duce and Faye Mitchell (Oxford Brookes University) and Stephen Morris (Nominet) can be downloaded here.

In the paper we study typo-squatting from a statistical point of view. The distribution of names in the co.uk registry is analysed using the concepts of syntactic and visual neighbourhoods of a domain name (the sets of all other domain names which are syntactically or visually similar to to it).  Our preliminary results show a strong correlation between the popularity of a domain name and the size of its syntactical and visual neighbourhoods although, counter-intuitively, the neighbourhood size does not depend on length.  This suggests anomalous activity “around” very popular domain names, as well as indicating that the size of the neighbourhood can be used as a reliable indicator for the likelihood of being typo-squatted.

Recently we have seen a marked increase in the number of .uk domain names being used for phishing purposes. One phishing syndicate seems to be particularly prolific. They register 40-60 domains at a time to run phishing sites.

Real individuals with genuine addresses were listed as the registrant and administrative contact. Based on past activity, it would appear that the registrant listed is the victim of identity theft.

Please make sure you have malware protection installed before you investigate one of these sites. These are highly sophisticated phishing sites and have been known to embed malware in them.

They are targeting more than just banking information. For example, we have seen them phish for accounts of a well known online auction service. They set up a site that checked in with this auction service to ensure the victim has entered valid username and password. If a valid user and password are entered, it will log the victim into the real auction service. The phishing victim would have no idea that they did not visit a legitimate log-in page for the online auction service.

They do not target domains with keywords that you may expect to see with phishing. Here is a sample list of domains that have been used:
loltech.co.uk
loltech.me.uk
loltech1.co.uk
loltech1.me.uk
loltech2.co.uk
loltech2.me.uk
loltech3.co.uk
loltech3.me.uk
modeisp.co.uk
modeisp.me.uk
modeisp.org.uk

The only pattern we have been able to identify to help you establish whether this group is attempting to register a domain with your company is the IP addresses behind the name servers. During registration, they will provide their own name server to host the domain on. The host name used will be random, but the host will resolve to one of the following four IP addresses:
81.16.131.40
88.16.131.40
200.72.139.67
202.44.71.149

We have been advised that these IP address will eventually change, but may be used for up to 3 months.

This is a follow up to my previous article, DomainKeys signing for nominet.org.uk e-mails… not just yet, which I wrote a month ago. Since then all I did was reading RFC4871 forsaking all my other duties, losing sleep and appetite.
After this I came up with the following findings:

• DomainKeys (rfc4870) is an obsolete standard for signing messages but still widely used (compared to DKIM)
• DKIM (rfc4871) is a current standard for signing messages
• DomainKeys defines signing policies but is vague about policies for subdomains
• DKIM doesn’t define policies. Policies, or rather Author Signing Practices(Sender Signing Practices), are separated from DKIM into a different standard which is still a draft and quite frequently revised: draft-ietf-dkim-ssp-03.txt
• If policies (practices) are not explicitly defined, Verifiers in both DomainKeys and DKIM assume that a Signing domain MAY sign messages and Verifiers should treat unsigned messages as if the domain supports neither DomainKeys nor DKIM.

After considering all this I came up with the following plan for rolling out of e-mails signing:

• Upgrade our mail servers to a version which supports both DomainKeys and DKIM signing
• Create DKIM and DomainKeys signing profiles on our mail servers
• Publish DKIM and DomainKeys selectors with public keys in nominet.org.uk zone
• Publish neither DomainKeys policies nor DKIM Author Signing Practices in nominet.org.uk zone effectively telling to Verifiers that Nominet messages MAY be signed
• Work out a correct Author Signing Practices (or whatever it’ll be called by that time) when it becomes a standard.

Having the plan I just followed it and as of today all outgoing @nominet.org.uk messages are signed both with DKIM and DomainKeys (subdomains originated messages, e.g. @lists.nominet.org.uk are not at the moment). One note though: for now we decided to publish the selectors with a “test mode” flag set but I think it’ll be removed very soon.

My appetite is back until I need to read another RFC.

I was set a task to deploy DomainKeys signing for @nominet.org.uk e-mails so that any messages, which appear to be coming from @nominet.org.uk but not signed with our key, would be treated as suspicious. At first glance it appeared to be quite simple:
1. Generate a private/public key pair.
2. Configure our mail servers to sign outgoing e-mails with the private key.
3. Publish the public key in the nominet.org.uk zone.
And that’s done! Not quite.

We have some auxiliary mail servers serving nominet.org.uk subdomains, e.g. lists.nominet.org.uk (which is not delegated), where we cannot deploy DomainKeys signing just yet. After reading rfc4870 I realized that a granular DomainKeys signing policy published in DNS would be just what we wanted. So my thought was to publish a policy like this:

1. any e-mails coming from @nominet.org.uk MUST be signed.
2. any e-mails coming from @subdomain.nominet.org.uk MAY be signed.

So real records in nominet.org.uk zone with lists.nominet.org.uk example would look like this:

_domainkey IN TXT “o=-”
_domainkey.lists IN TXT “o=~”

Here I bumped into a problem. Nowhere in rfc4870 it was specified that MTAs MUST look up a subdomain _domainkey policy so I was not sure that all MTA implementations wouldn’t just lookup _domainkey.nominet.org.uk policy for @lists.nominet.org.uk e-mails and would lookup _domainkey.lists.nominet.org.uk as well. As result I could not be sure that all MTAs would read our DomainKey policy correctly.
And at that point I was told that rfc4870 had been obsoleted by rfc4871 and something important about signing policies had changed.

So, as of now, nominet.org.uk e-mails are not being signed yet and I am back reading RFCs, i.e. rfc4871. I hope I read the right RFC this time.

Thanks to Mark Baker who showed me this little trick.

Whenever you display and email address in a web page there is a good chance a spambot will harvest that address and add it to a database. This technique allows you to publish email addresses in a way that browsers and email programs correctly understand but very few spambots do.

The way it works is to write out the email address using HTML character data - i.e. each letter is written like &#number; . So the email address jay@nominet.org.uk gets written in HTML as follows (line breaks added for clarity)

<a href=”mailto:&#106;&#097;&#121;&#064;&#110;
&#111;&#109;&#105;&#110;&#101;&#116;
&#046;&#111;&#114;&#103;&#046;&#117;
&#107;”>&#106;&#097;&#121;&#064;&#110;
&#111;&#109;&#105;&#110;&#101;&#116;
&#046;&#111;&#114;&#103;&#046;&#117;
&#107;</a>

which ends up looking like this:

jay@nominet.org.uk

Can you tell the difference?

Some of you may be thinking that this trick will be quickly discovered by spambot authors. However I think that spambots are generally only after the quick pickings and unless this trick becomes very popular it is not going to appear on their radar.

About a year ago we ran a test for a couple of hours to see what incoming emails we could reject because they had incorrect HELO/EHLO commands. Our criteria for rejection were:

1. If they specified a hostname (FQDN or not) but it did not resolve.
2. If they specified a hostname which did resolve but the address it resolved to was different from the IP address of the connecting host.
3. If they specified a hostname that did resolve but was different from the hostname obtained by doing a reverse lookup on the IP address of the connecting host (yes I know this was a bit harsh).
4. If they specified an IP address instead of a hostname and this was different from the IP address of the connecting host.
5. If they specified nothing or nothing intelligible.

To our surprise in just the small test period we had hundreds of rejected emails. We did an analysis of the headers and contacted about fifty of the sources to came up with the following characterisations, in no significant order:

• a hostname was specified which was our domain name. This was pretty frequent. This seems to be a clear indicator of spam. Doing a reverse lookup on the IP address invariably gives a hostname from an ISP DHCP pool.
• a hostname was specified that that was the hostname of our mail server. This was fairly rare. Again this seems to be a clear indicator of spam.
• an IP address was specified that was the IP address of our mail server. This was pretty frequent and again this seems to be a clear indicator of spam.
• a hostname was specified but this was a single label. Normally when the reverse lookup was done the hostname obtained bore no relation to the single label specified.
• a hostname was specified that ended with ‘.local’. From examination these all seem to have been Windows Domain Controllers (judging by the rest of the hostname).
• a hostname of ‘localhost’ was specified.
• an IP address of ‘127.0.0.1′ was specified.
• a hostname was specified but it was a domain name, with no hostname part. Again there was no correlation between this and the hostname returned by a reverse lookup.
• a hostname was specified but it could not be resolved. In some cases the hostname given by the reverse lookup was very similar to that specified. This nearly always indicated that the hostname that had been presented was the internal name of the host, which is why it could not resolve.
• an IP address from a private range (RFC 1918) was specified.
• a hostname was specified that resolved but was different from the hostname obtained from a reverse lookup on the IP address of the connecting host. Interestingly very little of this was spam, it was nearly always genuine but the specified hostname was from a related domain. Take the example where a company uses .co.uk for the public names but net.uk for the server names. The mail server specifies the co.uk name but it actually resolves on a reverse lookup to a net.uk name.

Unfortunately we didn’t have the time to do any statistical analysis of these results but hopefully some time we will get a chance.

Having moved over to our IronPort MTAs we have discovered that some people were no longer accepting delivery of some of our messages. The major symptom of this showed up in the logs as “[Errno 54] Connection reset by peer”

After a bit of searching we found one log entry where there was an error message generated by qmail which pointed to a URL that actually redirects to http://cr.yp.to/docs/smtplf.html. This very useful page explained that some MTAs send messages with lines terminated by a bare LF instead of the required CR + LF pair. One MTA identified as doing that is the IronPort.

A search on the IronPort KB (the one with ridiculous password protection) throws up an article which states:

“IronPort believes that a messaging gateway appliance should be as transparent to the messaging flow as possible and does not reject or repair messages with bare <LF> characters. This means that the behavior of the final destination messaging system with regard to improperly formatted messages (such as those with bare <LF> in them) will override. In other words, if bare <LF> messages are allowed by the destination messaging system, then AsyncOS will not block them. If bare <LF> messages are not allowed, then these will be bounced back to the sender by the IronPort appliance.”

So that narrowed the problem down to some processes at our end that were sending emails with bare LF line terminators. These turned out to be mails generated using the Oracle mail package, possibly where the body of the mail was copied from a Unix text file.

Interestingly these problems never appeared when the MTA was Postfix. It turns out that Postfix was doing some silent fixing of the bare LFs and replacing them with CR + LF pairs.

We recently completed the installation of a pair of IronPort C30 servers and these are now filtering out almost all spam, as we expected them to do after our evaluation. The IronPorts come as 2U appliances, with all the software pre-installed. They are actually Dell servers underneath as we found out when the impressive looking bezel fell off one. Most visitors to our computer room notice them straight away.

The IronPorts come with two different anti-spam systems:

The first of these is the excellent Brightmail anti-spam system, which is a signature and heuristic content filter. Brightmail is now owned by Symantec so there is always the possibility that some marketing person will ruin it, but so far it seems to be unaffected. The Brightmail service seems to be pretty efficient, we have had no false positives so far and not that much seems to get past it. I don’t have any stats yet on just how much we think it misses but anecdotaly it appears to be just a few messages per person per day.

As we run Lotus Notes we have installed the Brightmail plugin for Notes that allows us to mark messages as spam and it dutifully moves them to a spam folder. To be honest I’m not sure exactly what communication then takes place with the IronPorts if you do that, but I do know that it loads a DLL, making it unusable on our OSX boxes.

The second anti-spam system is the SenderBase Reputation Score (SBRS), which we are not yet using. This looks up the address of the MTA that connects to the IronPorts in the SenderBase database and assigns it a score of -10 (definitley spam) to +10. You can then decide how different ranges of scores are handled. SenderBase assigns scores based on a number of different sources, including SpamCop, which ironPort owns along with SenderBase. This probably explains why the IronPort does not support RBL or DNSBL services directly, since they all go into SBRS.

Once of the nice features of the IronPort is that you can choose to accept messages from a particular source but throttle the number of messages it can send.

You can configure the IronPort to share its logs with SenderBase to help increase the effectiveness of SenderBase. However we have at least one MTA that receives mail before the IronPorts, processes some that matches a particular format and forwards the rest to the IronPorts. Since this MTA receives a lot of spam it does mean that the IronPort sees it as a source of spam. So if you share your data with SenderBase and you have this particular setup then you can actually end up giving your own MTAs a bad reputation. For that reason we have had to disable sharing with SenderBase. Unfortunately you cannot turn off this sharing on a per MTA or per group basis.

The final integrated product is Sophos anti-virus, which comes with all the usual features though it is much easier to configure through the IronPort interface than normally.

The most unusual thing about the IronPort is that it runs their own operating system, based on FreeBSD, called AsyncOS. This claims to allow for extremely high volume processing but we have not yet tested it to destruction (though with our excellent Spirent Avalanche we could always try). One side effect of the use of AsyncOS is that it never writes the email to disk, so if you have a power failure after it has received a message but before it has forwarded it, then that message is lost.

The IronPort has quite a nice web interface through which you can configure the box, view reams of statistics and create adhoc and scheduled reports. The actual configuration concepts are fairly obtuse and unfriendly. It takes a few reads of the manual to understand them and configure it correctly. You can do all sorts of custom filtering, for example we do not allow anyone to connect to us specifying a hostname in our domain in their HELO command. However finding where to set this kind of thing is not always obvious. In this example it appears at a point that I think is much too late in the mail handling process, since of course the HELO command comes first. Despite the awkwardness we haven’t yet found anything we can’t get it to do.

We’ve used IronPort support and they were quick and helpful. IronPort do password protect their online manuals and knowledgebase, but with a username/password combination that is obviously shared by all users, so it just acts as an irritation.

The IronPorts are expensive and I can see why you might not want to fork out this much. Bear in mind then that you could always build something similar yourself. Brightmail is available to purchase directly from Symantec, and of course Sophos is widely available. SenderBase is actually free to use, even though it is owned by IronPort. So you could always install your own server with a decent mail server like Postfix and add on these services. The one thing you might miss is the IronPort reports but I guess Brightmail probably does a lot of that.