1

I've setup an application for my client, that sends lists of job vacancies to subscribers every Monday morning.

The emails use a custom link redirector service, to make the links email friendly, and to count clicks etc.

This redirector uses a hashed path parameter to uniquely identify the click.

Every week, after the emails are sent, I start receiving error alerts in the logs, for redirector links that can't be decoded.

At first I thought this must have been a bug in the coding, and that some end users were unable to click on the links. However I was able to verify that these links were bogus, and had not been created by our system.

What seems to be happening, is a bot of some kind must be trying to create random redirector links. What I can't understand is why?

The links have clearly been designed to try to mimic the format of the real links. At first glance they look legitimate. They could be identified initially because they included non-hexadecimal characters in the parameters, where the real parameters are always hex encoded. However now the bogus links are also hex encoded.

What would be the purpose of this link hacking? Would the attackers be hoping to figure out how the links are encoded, thinking they might be able to then create login links, or password reset links?

The other curious thing, is that that these attacks only seem to occur directly after the mail-out. If it was a regular intrusion attempt, I would expect it to just happen at various times throughout the week. Would this be intended to make it look less suspicious, and to make it appear more likely to be legitimate user activity?

In case it's helpful, the links that are sent in the emails look something like this...

/email/links/287545cb07c0/985edd0470e453.asp

Note: The .asp is completely arbitrary, it's not actually using classic ASP, I mostly just wanted to use an extension which wouldn't confuse email clients, but would also give hackers less clues about the back-end application environment.

user1751825
  • 905
  • 4
  • 10
  • What are the user agents which are accessing the invalid URLs? Are the attempts from IPs within the country you're sending the emails to? – Daisetsu Oct 29 '18 at 02:14
  • It would be useful to have concrete examples of how a valid link looks like and what invalid links you see and how exactly the link is included in the mail. There are security products which scan mails and follow links to check if this might be phishing or malware and these might extract the link from your mail in a different way than you intended. – Steffen Ullrich Oct 29 '18 at 05:42
  • It is possible you have a decoding problem in your e-mail, of you send the email as HTML (which I suppose you do), make sure you use the proper URL encoding. Also, mail servers and clients may fetch the URL before the user receives it (i.e. to detect malware, spam, enable caching, etc). –  Oct 29 '18 at 11:53
  • @Securist This was my first thought. That the hashing code may have had a bug, so I started logging the full HTML content of each email sent. I was then able to verify that the links I was seeing in the error logs, didn't exist in any of the delivered emails. – user1751825 Oct 30 '18 at 06:05
  • Your mention that initially the link attempts were not hex encoded, then later they were, suggests human intervention. If that's the case, perhaps someone in your mailing list is *really* bored, and trying to guess what they're thinking is probably impossible. – TTT Nov 07 '18 at 15:30
  • How long is the hash? If it's significantly longer than typical URL shortener IDs (32 nibbles for example) then seeing non hexadecimal characters in many queries (more than half of the first batch of fake queries?) seems odd. That might suggest either unintelligent bots or an incompetent human hacker. Try decoding the parameter using various algorithms. (base32, base64, hexadecimal to UTF-8, hexadecimal do UTF-16 BE/LE, etc. It may be double encoded like `base64enc(base64enc(text))`.) If it doesn't encode to anything then it's probably a false alarm. Unless they're brute forcing a short hash. – Future Security Nov 15 '18 at 02:41
  • I saw your edit. 26 characters is enough to guess that it's hexadecimal. The presence of the '/' may fool scripts into thinking it's a base64 string. Still try decoding the fake URLs. Also check if the IP is associated with Google or something. (Long shot. It could be something related to GMail or they might be using some sketchy crawling tactics. For example, their bots did sometimes submit forms on websites, hoping the it was your site's search form and that it would turn up new links.) – Future Security Nov 15 '18 at 03:00

1 Answers1

1

Since your links do not contain a target URI, there are only a few possibilities for an attack here:

  1. The attacker has (or assumes to have) found a way to route through your redirector (unlikely)
  2. An attempt to damage your web reputation; look up your domain for URI DNSBL listings
  3. An attempt to water down your service in the eyes of your users
  4. The attacker assumes your anti-spam system whitelists emails with such URIs
  5. An attempt at Bayesian poisoning (which doesn't even work) or another nonsensical task

Perhaps there's a bug in your (and/or the attacker's) code, but I'm guessing it's more of an annoyance than anything else: damaging your reputation in some way (to your users or globally) or trying to game some anti-spam system.

If your redirector had retained the target URI

I had originally assumed that your redirection service retained the target URI, something like
https://host/redir?hash=b17d56eb7444&uri=http%3A%2F%2Fexample.com given hash = substr(sha1("s3cret_pepper:" + uri), 0, 12) and that these forgeries failed the verification but the attacker was too stupid to have checked that.

In such a case, the redirection targets in these messages would probably be malicious sites.

This would be web reputation hijacking, in which they're using your redirector's reputation in place of the likely bad reputation of their own landing site, thus bypassing URI DNSBLs in spam detection.

Another possibility is that they don't like you and they're trying to damage your web reputation.

A third possibility is that they're trying to trick your users (and/or your internal whitelisting) into thinking these links are safe.

The first two scenarios are likely to harm your web reputation. Look yourself up at a site like http://multirbl.valli.org/lookup/ to see if you've been blacklisted already (and compare your reputation to that of the sites this attacker is trying to redirect to).

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
  • Based on the way the redirector works, it can't actually fake the target. The redirector can only redirect to URL's that have been pre-added to a NewsletterLink table. The links in the emails that people receive, just have a hashed id for the entries in this table. – user1751825 Nov 15 '18 at 02:13
  • About all they could possibly do, if they were able to break the hashing algorithm (possible, as it's only CRC32) they could redirect to an old expired job-vacancy on our site. – user1751825 Nov 15 '18 at 02:15
  • I should just add, that I chose CRC 32 because these links don't need to be particularly secure, and because this way the hashed URL's were much shorter than they would have been had I used SHA256 or something. – user1751825 Nov 15 '18 at 02:17