I don't like spam!

[j4]

... 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...

Comments

[bjh21.livejournal.com]

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 (http://www.iana.org/assignments/uri-schemes), 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.livejournal.com]

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.