Clickthrough forensics

When you click on a link in your mail, where does it go? Are you sure?
HTTP Redirects
In most bulk mail sent the links in the mail aren’t the same as the page the recipients browser ends up at when they click on it. Instead, the link in the mail goes to a “click tracker” run by the ESP that records that that recipient clicked on this link in this email, then redirects the recipients web browser to the link the mail’s author wanted. That’s how you get the reports on how many unique users clicked through on a campaign.
In the pay-per-click business that’s often still not the final destination, and the users browser may get redirected through several brokers before ending up at the final destination. I walked through some of this a few years ago, including how to follow link redirection by hand.
HTTP Forensics
Evil spammers sometimes deploy countermeasures against that approach, though – having links that will only work once or twice, or redirects that must be followed within a certain time, or javascript within an intermediate page or any of a bunch of other evasions. For those you need something that behaves more like a web browser.
For serious forensics I might use something like wireshark to passively record all the traffic while I interact with a link from inside a sandboxed browser. That’s not terribly user-friendly to use or set up, though, and usually overkill. It’s simpler and usually good enough to use a proxy to record the web traffic from the browser. There are all sorts of web proxies, used for many different things. What they have in common is that you configure a web browser to talk to a proxy and it’ll send all requests to the proxy instead of to the actual website, allowing the proxy to make any changes it wants as it forwards the requests on and the results back.
For investigating what a browser is doing the most useful proxies are those aimed at either web developers debugging web apps or crackers penetration testers compromising web apps. Some examples are Fiddler (Windows), Cellist (OS X, commercial), mitmdump (OS X, linux, Windows with a little work), Charles (anything, commercial) or ZAP (anything).
I’m going to use mitmdump and Firefox. You don’t want to use your main browser for this, as the proxy will record everything you do in that browser while you have it configured – and I want to keep writing this post in Safari as I work.

Run mitmdump in a shell window, then configure Firefox to use it as a proxy (Preferences → Advanced → Network → Settings… → Manual proxy configuration) on 127.0.0.1 port 8080 for all protocols.

Visit a page and you’ll see mitmdump printing out all the URLs it’s accessing.

You’ll also see some errors, if it tries to load anything over TLS. Lets fix that before doing anything else. Visit mitm.it – not here, in the browser you’re using with the proxy – and click on the logo for your operating system. You’ll get a prompt to install a certificate – you’ll want to use it for “websites”. This certificate allows mitmdump to man-in-the-middle TLS connnections so it can record that traffic.

Finally, lets look at some spam

I’ve been getting some spam advertising T-Mobile being sent to a tagged email address that was used to register a domain that expired a decade ago and hasn’t been used since. Fairly scummy spam, but the branding and contact information looks like it’s being paid for by T-Mobile themselves.

The mail is being sent “from” info@t-mobile.emsecure.net, and all the links in the mail are in t-mobile.emsecure.net, so lets start there.

The base domain, emsecure.net, doesn’t appear in DNS at all, nor does www.emsecure.net. http://t-mobile.emsecure.net/ redirects to https://t-mobile.emsecure.net/ – which then returns a zero length file. Spammers who are trying to hide who they are.

So, we’re going to need to follow the actual links in the mail. The main clickthrough link looks like this:

https://t-mobile.emsecure.net/optiext/optiextension.dll? ID=3vu3xT_3CPZ_j6rc4uQh4sUS_7093dV7XpSiW9K 1u3OY8xvN%2BQbAkNTu%2BZfkh6hF0SSHlhh KjgLYcuXOlEg3dm1KLoTFM

I want to record the links visited, as well as displaying them, so I run “mitmdump -w tmobile.log” to record the output to a file. Then I visit that long, ugly link in Firefox.
And then I’m surprised. The link doesn’t redirect anywhere. Instead it goes to a T-Mobile branded landing page hosted on the t-mobile.emsecure.net domain. And all the links on this page go to URLs that are https://t-mobile.emsecure.net/optiext/optiexension.dll?id=string_of_gibberish too.
That’s good, though. This is exactly why using a real browser with a recording proxy is more convenient than trying to trace this by hand. I can see that there are just a few call-to-action links on this page. I pick the “Find out more” link and click on it. This time mitmdump shows me that the gibberish emsecure link redirects immediately to the advertiser:

https://business.t-mobile.com/contact-a-rep.html? cmpid=DMA_EM_UC9ETF09_SHDQJRY9M11888

So there aren’t multiple levels of resale of clicks going on in this case – T-Mobile are either paying the spammer to send the spam or buying leads directly from them. And I have all the 2.5 megabytes of traffic sent to and from my browser recorded in “tmobile.log” if I need to do further analysis, or present it as evidence, in the future – even if the site itself is removed.
Conclusion
The main conclusion is that a proxy can be a very useful tool for digging in to where a link goes, and who is responsible for it.
In this specific case it’s enough to show that T-Mobile (or perhaps an individual T-Mobile sales rep, but it seems really unlikely) are the responsible party for the spam, and they’re probably buying leads from the Belgian spammer who sent the spam. Digging a little deeper, the spammer is Selligent (who’ve just merged with StrongView, née StrongMail. You guys used to be cool.)
Whether it’s lead purchase, list purchase or epending – if you end up sending spam to an email address harvested from a domain registration at least a decade ago you’re buying terrible, terrible data. This is why you’ re hitting spamtraps, causing complaints and getting blacklisted.
 

November 2015: The month in email
But my purchased list is TARGETED!!!

Related Posts

Lets Encrypt Everything

Using SSL TLS to protect data in transit and authenticate servers you contacted originally required specialized software, complex configuration and expensive and complicated to require certificates.
The need for specialized software is long since gone. Pretty much every web server and mail server will support SSL out of the box.
Basic server configuration is now pretty simple – give the server a couple of files, one containing the TLS certificate and the other the associated private key. (Configuring a server securely, avoiding a variety of attacks on weak parts of the SSL/TLS protocol, can be a bit more work, but there are a lot of tools and documentation to help with that).
But acquiring a certificate from a reputable provider is still expensive enough (one Certificate Authority’s list price for entry level certificates is $77/year, though the same certificates are available for <$10/year from resellers, which tells you a lot about the SSL certificate market) that you might not want to buy one for every endpoint.
And the process of buying an SSL certificate is horrible.
First you have to find a Certificate Authority or, more likely, a cheap reseller. Then it requires generating a “Certificate Signing Request” – something that can be done in dozens of different ways, depending on the device it’s being generated for. The user-friendliest way I’ve found to do it is to use the openssl commandline tools – and that’s really, really not very friendly.
Then you need to log in to the CA, upload the CSR, follow a bunch of directions to confirm that you are who you say you are and you’re entitled to a certificate for the domain you’re asking for. That can be as simple uploading a file to a webserver that serves the domain you’re getting a certificate for. Or it can turn into an inquisition, where the CA requires your home address and personal phone number before they’ll even talk to you.
Then you need to use the same browser you submitted the CSR request from to get your certificate – as the CA doesn’t do all the cryptography itself, it relies on your web browser for some of it. There are some security-related reasons why they chose to do that, but it makes for a fragile – and near impossible to automate – process. And the attempts to upsell you to worthless “security” products are never-ending.
help
There’s probably more horribleness, but it’s 9 months since I last bought a certificate and I may have forced myself to forget some of the horror.
There’s no need for it to be that painful. It’s easy to mechanically prove to a Certificate Authority that you control a domain in the same way you prove ownership to other companies – put a file the CA gives you onto the webserver, or add a special CNAME to your DNS.
And once you’ve proved you own a domain a certificate for that domain could be generated completely automatically. For the most common web setups you could even prove domain ownership, generate a new certificate and install that certificate into the webserver entirely automatically.
I’m sure there’s some reason other than “because we’re milking the SSL cash cow for all it’s worth” that dealing with most Certificate Authorities is so painful and expensive. But there’s no need for them to be that way.
This year there’ve been several groups who have stepped forward to escape the pain of dealing with legacy Certificate Authorities, at least for basic domain verified TLS certificates (as opposed to the “green bar” extended verification certificates you might want for, e.g. an eCommerce site).
Lets Encrypt has been one of the higher profile new CAs who are driving this effort. With the help of ACME, an open protocol being developed for issuing certificates automatically, they’re providing zero-cost TLS certificates. They’re hoping that, to use their phrase, you’ll encrypt everything, using TLS to encrypt traffic everywhere it makes sense to do so.
So, how does it work?
coyote
It works wonderfully well.
Lets Encrypt is still in public beta testing for a few more weeks, but I just got beta access. Installing their client tool on a reasonably recent Linux box just took copy-pasting two commands and waiting a minute.
The tool supports a variety of different ways to request a certificate – from entirely automated for a vanilla Apache installation through to the most complicated, entirely manual.
To see how difficult it was I decided to install a certificate for blighty.com, a domain on one of our very old webservers – one that was too old to install the letsencrypt tool itself. Fully manual! For a website on a different server!
I ran the letsencrypt tool, telling it I wanted a certificate for blighty.com. It gave me a the contents and location of a file to put on the blighty.com webserver – creating that required copying and pasting two commands from one shell window to another. Then it created and gave me the new certificate and key. I copied those across to the webserver and reloaded it’s configuration. And I have TLS!
This is going to be very simple to completely automate, so you could easily build it in to existing automation to create TLS protected action and tracking links for branded domains. Supporting thousands of TLS protected hostnames wouldn’t be difficult.
And how about using the certificates for things other than webservers? Mail servers, say? You do need a webserver to be live while you’re generating or renewing a certificate – but that’s actually easier to do for a host that doesn’t usually serve web pages than one that does. Once the certificate is generated you can use it for any service, including mail servers.
ACME-movie
 

Read More

TLS and Encryption

Yesterday I talked about STARTTLS deployment, and how it was a good thing to support to help protect the privacy of your recipients.
STARTTLS is just one aspect of protecting email from eavesdropping; encrypting traffic as the mail is being sent or read and encrypting the message itself using PGP or S/MIME are others. This table shows what approaches protect messages at different stages of the messages life:
[table nl=”~”] Compromise point,SUBMIT~+IMAPS,TLS,PGP /~SMIME
Sender’s computer as mail is sent,,,
Sender’s computer later,,,[icon name=check-square] Sender’s network,[icon name=check-square],,[icon name=check-square] Sender’s ISP,,,[icon name=check-square] Global Internet (passive),,[icon name=check-square],[icon name=check-square] Global Internet (active),,[icon name=question-circle],[icon name=check-square] Global Internet (later),,[icon name=question-circle],[icon name=check-square] 3rd party mail services,,,[icon name=check-square] Recipient’s ISP,,,[icon name=check-square] Recipient’s network,[icon name=check-square],,[icon name=check-square] Recipient’s computer as mail is read,,,
Recipient’s computer later,,,[icon name=check-square] [/table] You can see that if you’re sending really sensitive data, you should be encrypting the entire message with PGP or S/MIME (or not sending the message via email at all). Doing so will protect the content of the mail against pretty most sorts of attack, but is pretty intrusive for the sender and recipient so can’t really be used without prior agreement with the recipient.
The other approaches will make some sorts of passive surveillance much more difficult, though.
Encrypting the connection a user uses to send mail ([rfc 6409]using the SUBMIT protocol[/rfc]) and to read mail ([rfc 2595]using TLS to protect IMAP or POP3[/rfc]) will protect against passive sniffing when the user is on possibly hostile network, such as public wifi or an employers network. That’s an easy place to try and sniff traffic, and if that traffic isn’t protected an attacker can not only read someone’s email, they can steal their credentials and cause all sorts of havoc. All general purpose mail clients and all ISPs support encryption here, so it’s almost universally used.
STARTTLS use with SMTP is all about protecting email traffic when it’s being sent between ISPs – both between the sender’s ISP and the recipient’s and also between any 3rd party mail services (outsourced spam filtering, mailing list providers, vanity domain fowarders, etc.).
I’ve listed three different sorts of attack on that inter-ISP traffic – passive, active and “later”.
A passive attack is where the attacker has the ability to listen to bytes as they go by, but isn’t able to modify or intercept them. While you might think of this as something a nation state would do, via secret agreements with backbone providers or high-tech fiber optic cable taps, there are ways a smaller attacker might be able to compromise an intermediate router and tap that traffic with little risk of detection. Deploying any sort of STARTTLS will protect against this, even if it’s misconfigured, using expired certificates or even just the default setup of a newly deployed mailserver. Facebook describe these weaker forms of STARTTLS as “opportunistic” in their survey – it’s not perfect, but it’s a lot better than nothing.
An active attack is one where the attacker has the ability to intercept and modify traffic between the two ISPs. This seems like it would be harder to do than a passive attack, but it’s often easier, though not as stealthy. Once that’s done, the attacker can pretend to be the recipient ISP and have full access to read, modify or discard messages. To protect against this sort of attack TLS needs to be used not just to encrypt the traffic in-flight, but also to allow the sender to validate that the mailserver they’re talking to really is who they think it is. This is what Facebook describe as “strict” – it requires that the mailserver have a valid certificate, issued by a legitimate certification authority for the domain that the mail is being sent to.
What about “later”? It’s easy to imagine a case where an attacker has been passively monitoring and recording encrypted traffic for a while, and then later they manage to acquire the encryption keys that were used (by, for example, issuing a subpoena to the recipient ISP, or using a compromise to rip them out of your servers memory). With many forms of encryption once you have those private keys it’s possible to decrypt all the traffic you’ve already captured. There are a few algorithms, though, that have what’s known as perfect forward secrecy – knowing the private keys that were used at the time the mail was transferred doesn’t allow you to decrypt them at a later time. If you’re concerned about the privacy of your messages, you should definitely read up on how to set that up.
All of these techniques are a great way to defend against ubiquitous or casual attempts to read your messages, but none of them are proof against a determined attacker. If all else fails, there’s always a wrench attack.
security

Read More

TWSD: Hiding the opt-out


This is an actual opt-out link that came in a recent email. Sadly, this is a real company, listed on the NYSE sent by a major ESP.
 

Read More