7

I have a private website that every week sends e-mails with two different http links to a group of around 30 people. When a link is clicked, the answer is registered in a database. Starting last week, one of the recipient's links is automatically followed by either a network sniffer or some malware on the recipient's computer.

Each e-mail is sent individually since the links contain each recipient's e-mail adress:

Yes, I will attend:
http://mywebsite.com/?email=user@domain.com&answer=yes

No, I can't attend:
http://mywebsite.com/?email=user@domain.com&answer=no

Around 20 minutes after the e-mail has been sent, I get the following request to my website:

UserHostName: 209.133.77.166
UserHostAddress: 209.133.77.166
UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; MS-RTC LM 8)
Browser: IE 7.0
Platform: WinXP
HttpMethod: GET
Path: /default.aspx
Url: http://mywebsite.com/default.aspx?answer=ab&email=hfre@qbznva.pbz
UrlReferrer:

There are some strange things to observe here:

  • The e-mail adress and answer are both ROT13-encoded (but not the parameter names).
  • The order of the parameters are reversed.
  • Only the second link, with answer=no, is followed.

Also:

  • The IP-adress, UserAgent, Browser and Platform fields do not match those of the recipient's computer (but they might be spoofed, of course).
  • The IP-address used last week was 209.133.77.167. Both addresses seems to be dynamically allocated at the above.net domain, performing a tracert yields the hostname 209.133.77.166.T01713-01.above.net.
  • Checking the e-mail headers, the e-mail was sent from my web hotel binero.net via messagelabs.com to the recipients mailserver.
  • It is only this single recipient that have these problems.

Does anyone recognize the pattern of following e-mail links and encoding the parameters with ROT13?

Anlo
  • 281
  • 1
  • 7

1 Answers1

10

Hah, 5 minutes after posting the question I found the answer myself. Ever had that happen to you? :-)

https://security.stackexchange.com/questions/48684/help-investigating-potential-website-attack-url-rewriting-and-rot-13-obfuscatio

Essentially:

It took a few calls with AboveNet (now part of Zayo), but we were finally able to determine that one of their customers is an anti-malware firm based in the UK, providing services to two of our common customers. They were scanning all incoming emails and probing any hyperlinks to identify potential hazards and/or vulnerabilities in the destinations.

Community
  • 1
Anlo
  • 281
  • 1
  • 7
  • Ditto for us. Once I realised just the values in the params were ROT13 a quick google led me here. IP probing our 'unsubscribe' links was also an AboveNet server – jaygooby Oct 08 '14 at 10:46
  • 1
    Been tearing my hair out wondering what was causing this for a month. Finally coming to the same conclusion after adding logging for IP and user-agent, then came upon this - confirmation. Thanks. – Chris Feb 03 '15 at 11:04
  • BTW, did you come up with a way a to avoid the problem? I've added a constant param that is now the only thing being ROT13d that I can check and discard if it doesn't match original. Concerned it could be a bit brittle though. They could easily change their algorithm. – Chris Feb 03 '15 at 11:09
  • 1
    No, at the moment I'm only checking for ROT13:d parameters and discard the request if found. – Anlo Feb 03 '15 at 15:01
  • 1
    We lost so MUCH time trying to figure out were those calls where coming from... Thanks for this answer. We're considering responding to those calls with a HTTP response "418 I'm a teapot" since it looks like this is the more appropriate answer i could find in the spec. – nfroidure Jun 21 '16 at 08:34
  • This also has happened to me, but from Microsoft IP addresses. (40.x.x.x) – Simon Fredsted Jan 05 '21 at 09:55
  • Same, Microsoft IPs (40.x.x.x) – Tim Nyborg May 13 '21 at 16:44