Recently a friend subscribed me and some others to a mailing list in Pardot. He was stunned when a few people immediately unsubscribed. Was it something he said? The unsubscribers denied all knowledge. Upon some digging, it was discovered that a corporate email security threat scanner was fetching HTTP links, and, the emails in question had a link http://host/unsub?user=name. You can see where this is going, the users were unsubscribed by the scanner.
The friend in question rushed in a solution to the Pardot symptom, based on this thread. Mission accomplished, right? Well, read on!
First, lets discuss why this should be safe. An HTTP GET (should be) is idempotent. No, not the thing you take the blue pill for. The operation that can be repeated without side effects. So, http://host/unsub?user=name should not cause an action, and, should be callable multiple times. The correct thing for Pardot to do would be to use a POST operation here. But, they, like many others, didn’t get the memo. Also, its a bit harder for them to do, and, well, why spend time when you can be lazy, right?
By this stage you are saying “so what, I don’t run Pardot, I don’t like mailing lists”. You have fallen victim misreading the symptom as ‘i.e.’ when it really is ‘e.g.’. Let’s talk about how much more dangerous this corporate email scanner is.
First, let’s make an assumption. Let’s assume your company runs an email server on site. You buy a anti-phishing, anti-malware product and bolt it on. Let’s say I know this or can reasonably assume it. That email scanner became a threat.
Now, let’s assume I know you have some other piece of equipment or software on site that also didn’t get the memo about GET vs PUT vs POST. For me, in my house, I have a Kankun smart switch, I’ve written about here. In a nutshell http://switch?state=on causes it to turn on. So you could now send me an email and turn my lights on. Hmmm. I wonder what other industrial automation is within the firewall that might have this property and be more expensive? SCADA? Front-door lock for after-hours delivery? is the email scanner threat worse than those things inhernently?
So now we have expanded the problem of the email security threat scanner, but let’s make it worse. Let’s assume there exists a tool like Facebook Business. In order to register a brand page, I need an email address @yourdomain. But I don’t work there. Good thing you installed that security scanner, I will go to Facebook, say “Add user@yourdomain”. Facebook will send an email to that address containing a link http://facebook/proof=true, which will get auto-clicked by the scanner. Boom, I can now impersonate your brand.
At my last company we had a corporate membership to ETSI. As long as email was @domain you could use it. So you could create a login, get it confirmed by the email auto-scanner, and, free standards.
We can now see the blast radius is large. By installing an automated email scanner inside the corporate firewall, and by not using Zero Trust networking, we have allowed anyone in the world to call URL inside our building, on any service, and, to create accounts or impersonate our own staff. Maybe we can use this to reset passwords, steal money, cause general mayhem.
What could this email security scanner do differently? I guess it could remove CGI parameters (the ?X=Y stuff). But then it might get a different page back. It could try and enumerate all the poorly written GET vs POST systems in the world. It could invent some marketing verbiage around machine learning paradigms and hope you don’t read further.
I recommend reading my companion article “The browser was the accomplice“, which has a video, for an understanding of how the same techniques as this email scanner threat can be used through a browser to trick you into setting fire to your manufacturing.
Quis custodiet ipsos custodes.