?

Log in

No account? Create an account
entries friends calendar profile Previous Previous Next Next
I don't like spam! - shadows of echoes of memories of songs — LiveJournal
j4
j4
I don't like spam!
... but by and large I just shrug and delete it, even though recently the sheer volume of the stuff has been truly incredible.

But today, on a whim, I went to look at the website for one of those Natwest scams. The mail claimed to be from support@natwest.com, and the text of the message was as follows:

Dear Valued Customer,

- Our new security system will help you to avoid frequently fraud transactions and to keep your investments in safety.

- Due to technical update we recommend you to reactivate your account.

Click on the link below to login and begin using your updated NatWest account.

To log into your account, please visit the NatWest Online Banking https://www.nwolb.com/

If you have questions about your online statement, please send us a Bank Mail or call us at 0846 600 2323 (outside the UK dial +44 247 686 2063).

We appreciate your business. It's truly our pleasure to serve you.

NatWest Customer Care

This email is for notification only. To contact us, please log into your account and send a Bank Mail.


Now, to me it's perfectly obvious that this isn't kosher. For one thing, the peculiar translationese ("will help you to avoid frequently fraud transactions and to keep your investments in safety"?) isn't at all what I'd expect from an official Natwest email. For another thing, I've never heard of a "Bank Mail"; it sounds like a scammy invention. (I'm sure people will now tell me that it's a perfectly legit term and has a very specific meaning!) But the real clincher is that I haven't had an account with Natwest for over 7 years now.

Nonetheless, I went to have a look at the site out of curiosity, and it's really quite impressive -- the site pointed to in the email looks just like the Natwest online banking login page. And indeed, https://www.nwolb.com/ is the Natwest OB page. So, as the TV show asks, "How do they do that?"

Well, that's when sion_a pointed me at the source:

To log into your account, please visit the NatWest Online Banking
https://www.nwolb.com/

Weird linebreak, yeah, but so what? Well, after that "nwolb.com" comes an eternity of whitespace, followed by this:
:UserSession=2f4d0zzz899amaiioiiabv5589955&userrstste=SecurityUpdate&StateLevel=CameFrom@64.174.108.131/

Ah-HA. Suddenly it becomes a lot clearer (not that I know exactly what they're doing, but at least it tells me how one page can be a stinking great bear-trap and another apparently-identical page can be the genuine article).

This is a really, really dirty trick. I can't help but be impressed at the deviousness, but at the same time it's horrifying to think of how many people are likely to be taken in by this kind of thing. Oh, I know, it's probably old news by now (and indeed the IP address in the clever-hacky-stuff above is unpingable, suggesting that this one's already been nailed) but it's still a scary thought -- not least because even if this particular scam has been stopped, there's nothing to stop other people doing the same thing again, only more cleverly. And even without the added cleverness, there will always be new people to fall for the same old tricks...

Current Mood: spammed out

Read 19 | Write
Comments
bopeepsheep From: bopeepsheep Date: December 8th, 2003 11:04 am (UTC) (Link)
Scarily, I've had a genuine letter (printed) from NatWest written in equally appalling English. If this email purported to be from a real person I wouldn't doubt it (but I would still be very suspicious since I always am of any of these 'please log in' things. I'll log in when *I* want to, thanks).
j4 From: j4 Date: December 8th, 2003 11:50 am (UTC) (Link)
That is quite scary... though I suppose not all that surprising as they're probably outsourcing all the admin overseas as well. </cynic>
olithered From: olithered Date: December 8th, 2003 11:33 am (UTC) (Link)
I got the same email today. The whitespace is not something I've seem in other messages and presumably intended to fool you into thinking the link is kosher if you point at it to see where it is going - the bit after the whitespace may not be visible depending on your screensize.
j4 From: j4 Date: December 8th, 2003 11:48 am (UTC) (Link)
Exactly -- I couldn't see the bit after the whitespace initially, I had to scroll across character-by-character in w3m to get to it. Though that was viewing the source, which I suspect Joe Average wouldn't do. No idea how it'd behave in an HTML mail client -- tempted to forward it to myself at work just to have a look in Outlook.
cjwatson From: cjwatson Date: December 8th, 2003 01:52 pm (UTC) (Link)
Also, be careful of the additional trick, where the bit after the @ sign is just a single long number, which works out as an IP address represented as a 32-bit integer. Browsers will generally decode this, largely pointless though it is for non-obfuscated uses.

If I were El Presidente Dictator For Life, the first thing I'd do (after sleeping for a week, sleeping with lots of cute people for a few weeks, and arranging for various unpleasant people to have nasty gardening accidents, of course) would be to fix the URI spec so that / wasn't a valid character in a username and you couldn't pull off this sort of evil masquerade. Unfortunately it's a bit late now.
bjh21 From: bjh21 Date: December 8th, 2003 02:08 pm (UTC) (Link)
From RFC 2396:
      userinfo      = *( unreserved | escaped |
                         ";" | ":" | "&" | "=" | "+" | "$" | "," )
'/' is already banned as a character in userinfo, and for good reason. Similarly, spaces aren't allowed in URIs, IPv4 addresses in URIs are required to be dotted-quads (and no sneaky using hex or octal), and HTTP URIs aren't allowed to contain userinfo at all. All that's needed is for the stupid browsers to actually enforce the rules that already exist.

Please excuse me. I seem to be ranting.

mobbsy From: mobbsy Date: December 8th, 2003 04:22 pm (UTC) (Link)
So Col can get back to his more pressing dictatorial activities?
fanf From: fanf Date: December 9th, 2003 02:46 am (UTC) (Link)
spaces aren't allowed in URIs

They are allowed but should be stripped out, per the appendix in RFC 1738.
imc From: imc Date: December 9th, 2003 06:53 am (UTC) (Link)
HTTP URIs aren't allowed to contain userinfo at all.

A strict reading of the relevant RFCs does seem to indicate this, yes. On the other hand, when they are used legitimately (rather than in nasty hacks like this) I don't see any reason why that should be the case. There is such a thing as a web page which requires a user name and password, so the fact that they are allowed in FTP URLs but not HTTP URLs seems slightly arbitrary. Moreover, RFC 2396 claims to replace 1738 and allows userinfo for any IP-based protocol in general, saying that scheme-specific details will be published in further documents - however, I can't find any such document detailing the restrictions of HTTP URLs. (Mind you, 2068 also contains a description of HTTP URLs which omits the userinfo part.)

IPv4 addresses in URIs are required to be dotted-quads

I'm fairly sure that IPv4 addresses in general are required to be dotted-quads (in decimal); the fact that most IPv4 implementations accept a 32-bit number seems to be a bug (although saying `0' instead of `localhost' does save a bit of typing sometimes) and is not necessarily the browser's fault (though this did expose a further bug in IE whereby the non-dotted number was considered to be an intranet address and thus placed in the trusted zone).
bjh21 From: bjh21 Date: December 9th, 2003 10:10 am (UTC) (Link)
A URI-scheme specification can't usefully say "userinfo MUST NOT be used for nasty hacks". It can either permit userinfo or not. Given the amount of confusion that userinfo causes, it seems entirely sensible that HTTP bans it.

There are two reasons why FTP needs userinfo where HTTP doesn't:

  • Anonymous FTP is only a convention, not a standard, so some FTP servers might use different user names for anonymous access and need a way to override it.
  • FTP doesn't distinguish "file not found" from "authentication required", so the client doesn't know when to prompt for a username/password to access a protected resource, and hence needs a hint in the URI.
As its introduction points out, RFC 2396 defines a superset of all valid URIs, so the fact that it permits something doesn't say require any scheme to permit it. According to the IANA list, RFC 2616 is the definition of HTTP URIs, and is quite clear that HTTP URIs never contain userinfo, just as they never contain params.

I'm fairly sure that IPv4 addresses in general are required to be dotted-quads (in decimal)

Can you quote C&V for that? I tried once, and eventually gave up. Certainly, some standards (POSIX, for instance) mandate support for other formats, which is evil.

imc From: imc Date: December 9th, 2003 03:24 pm (UTC) (Link)
A URI-scheme specification can't usefully say "userinfo MUST NOT be used for nasty hacks".

That's beside the point really (there's already lots of things that can be used for nasty hacks; anyway, if clients ban it then spammers will no doubt just switch to FTP URLs where it's still allowed).

Given the amount of confusion that userinfo causes, it seems entirely sensible that HTTP bans it.

But the clients do accept it (and always have, as far as I know). I suspect they always will, despite what RFCs say. (I don't think the confusion could necessarily have been foreseen when the HTTP/1.0 document was written; client authors may just have seen the omission as an oversight and implemented it anyway.)

RFC 2616 is the definition of HTTP URIs

This is of course the document I should have quoted when I referred to 2068.

Can you quote C&V for that?

I suspect not, as it turns out that the source I was thinking of actually quoted RFC 1945. :-/

However, he points out that this document refers to section 2.1 of RFC 1123 (as does RFC 2396), which strongly implies that dotted decimal form should be used (though technically it probably doesn't absolutely rule out other formats). This in turn refers back to RFC 952, which also (in assumption 2) specifies the dotted decimal form.
perdita_fysh From: perdita_fysh Date: December 9th, 2003 12:28 am (UTC) (Link)
As a result of this fraud, Natwest have turned off half the internet banking facilities (like being able to add new third parties to transfer to) which meant I was unable to pay my new employee last night. When I phoned the helpline they said I could do it with Actionline, so I phoned them and they asked me nothing I couldn't have found out through said spam, but then did say I couldn't do it there either (which was safer, but bloody annoying).

They assured me their technical people were working to 'resolve the matter as quickly as possible' and I couldn't help but wonder 'HOW?' because aside from brainwashing all users into not being gullible, there's not really a 'solution' is there? People will continue to send these emails forever.
imc From: imc Date: December 9th, 2003 07:23 am (UTC) (Link)
Ah-HA. Suddenly it becomes a lot clearer (not that I know exactly what they're doing, but at least it tells me how one page can be a stinking great bear-trap and another apparently-identical page can be the genuine article).

The source looks like this (from one of the seven copies which fell into my spamtrap yesterday):

To log into your account, please visit the NatWest Online Banking
<a href="http://www.nwolb.com                                                   
                                                                              :U
serSession=2f4d0zzz899amaiioiiabv5589955&userrstste=SecurityUpdate&StateLevel=Ca
meFrom@64.174.108.131/
">https://www.nwolb.com/<a>
(Now actually everything from `<a' up to and including `131/' was on the same line in my copy, but I've broken it here to avoid making this page three miles wide.)

An important thing to note here is that there is no slash between `http://' and the at-sign [because after a slash, an at-sign is just an at-sign]. As discussed in some of the other comments, a generic URI is allowed to contain `userinfo' (usually a username and password which may for instance be needed in order to log into an FTP site). What this boils down to is that your client will strip off everything between the `http://' and the at-sign and use it as login info, thus leaving `http://64.174.108.131/' - which is, of course, Mr. EvilHacker's web site.

In an above comment, it's discussed that stripping off the userinfo in this way for an HTTP URL is probably against the RFCs, but I doubt this behaviour will change in the real world. However, the developers of some clients [I think Lynx is one] are considering warning you before you visit a URL if it contains such userinfo, which is a nice compromise.

In Lynx, the whitespace in the HTML source had the desired effect (the nonsense at the end of the URL is not visible when you cursor over the link as it has been pushed off the side of the screen). However, Mozilla cunningly elides the middle of the URL, showing you the beginning and the end when you hover over it, so you can see that it looks a bit fishy.

SpamAssassin heavily penalises URLs that have userinfo in them, and with good reason - it's a very well used spammer trick. However, it didn't seem to notice this one. I think the whitespace fooled it.

ewx From: ewx Date: December 10th, 2003 01:59 am (UTC) (Link)
The spaces aren't allowed either; and the userinfo (i.e. user+password) part makes no sense in HTTP anyway, as well as not being allowed there. In today's environment I think this is a security hole in browsers that accept it.
imc From: imc Date: December 10th, 2003 03:12 am (UTC) (Link)
The spaces aren't allowed either

Quite right, so the clients shouldn't have interpreted it. (Both Mozilla and Lynx connected to 64.174.108.131 but Lynx failed because of a bug. Interesting to note that this address is now a place-holder for `The Rowe Group'.)

and the userinfo (i.e. user+password) part makes no sense in HTTP anyway

Not so: consider the difference between this and this. (Mozilla understands it; in fact, in Mozilla, clicking on the second link magically makes the first one work too.)

In today's environment I think this is a security hole in browsers that accept it.

It has its uses (as above, and I think I have occasionally seen such things in the wild) and I very much doubt it will go away, though I would support moves to make clients prompt the user before obeying the URL.

I note with amusement, though, the paranoia with which the Mozilla project deals with some aspects of security and not others: for example, although it blindly obeys the above non-RFC URL, it will simply ignore you if you click on a `file:///foo/bar' link on an http-served web page. (If you should happen to open the JavaScript console then you'll see the message which says that it didn't actually ignore you but you were blocked by the security manager.)
ewx From: ewx Date: December 10th, 2003 03:52 am (UTC) (Link)

Not so

If you want a link that anyone can follow then you don't set up a password and transmit it as part of the URL, you just don't password-protect the target URL in the first place.
imc From: imc Date: December 10th, 2003 04:52 am (UTC) (Link)
There are some security-by-obscurity applications of this. Your site is probably password protected because you don't want just anyone wandering in to look at it, but it's not `top security' enough for you to be bothered by the odd one or two unauthorised people who happen to find out the password. The link is either in an email you send to all authorised users or on an affiliate web page that happens to be protected by a different username and password.
ewx From: ewx Date: December 10th, 2003 05:28 am (UTC) (Link)
I don't see the difference between that and putting the hard-to-guess bit in the main part of the URL; either way the link contains all the information you need to view the page and either way you have to be equally careful (or careless) about distributing the URL. (OK, there is a difference: your suggestion probably doesn't work with all clients, but mine does.)
imc From: imc Date: December 10th, 2003 06:55 am (UTC) (Link)
I could make the scenario more complicated to explain why you might want to do that, but I shan't bother.

You originally claimed that the userinfo doesn't make sense in HTTP, and I think I have demonstrated that it sometimes does. You may very well be correct in saying that there are better ways to do it, but that's not the same as `doesn't make sense'.
Read 19 | Write