Spamming is a word we all know and an activity we all loathe – it’s when crooks blast out unwanted emails for products we don’t want at a price we won’t pay from from suppliers we’ll never trust.
And the word spam has given us related terms such as SPIM for spam via instant messaging; SPIT for spam via internet telephony – robocalls and fake tech support scams, for example; and SPEWS, which is our tongue-in-cheek name for spam via electronic web submissions.
SPEWS have typically gone two main ways:
- Crooks use bulk HTTP posting tools to fill out online comment forms on forums and blogs. The idea is to sneak past spam filters or harried moderators to get free ads, promotional guff and bogus endorsements posted and publicly visible, at least until they’re reported and removed.
- Crooks use reporting or contact forms to send phishy messages into your organisation. The idea is to trick the form processing system into generating an internal email from content that came from outside, thereby sidestepping some or all of the spam filtering that external emails would usually undergo.
Russian cybersecurity researchers at Russian outfit Dr.Web recently reminded us all of a third way that crooks can use SPEWS to do their dirty work.
They noticed spamtrap emails that actually came from genuine corporate senders, but with poisoned web links in the greeting part.
Instead of saying,
Hi, Mr Ducklin, as you might expect from a genuine email from a trustworthy brand, they said something more along the lines of
Hi, MONEY FOR YOU! [weblink here], but with a legitimate-looking sender.
Indeed, digging into the emails showed not only that the sender was legitimate but also that the email did originate from a server you’d expect – there was no sender spoofing going on.
(Spoofing is where the crooks deliberately put a bogus name in the
From: field, so at first glance the email seems to come from somewhere you trust.)
How it works
What the crooks are doing is subscribing to official corporate mailing lists but putting in other people’s email addresses so that the victims receive a signup message, even though they didn’t sign up themselves.
Ironically, the crooks are abusing a built-in mailing list safety feature – one that’s been de rigueur in most of the world for some time, if not actually required by law – that sends a one-off confirmation email before actually activating a mailing list subscription.
This safety feature is often referred to as double opt-in – you won’t get any email until you put in your address (opt-in #1), and then you won’t get anything but a confirmation message until you reply to or click a link in that message (opt-in #2).
Double opt-in is meant to stop other people signing you up, either through accident or malevolence, but it does mean that anyone with access to the sign-up form can get a legitimate company to send you a one-shot email from one of its legitimate servers.
To a crook, that feels like a challenge, not merely an observation – a genuine email server that can be automatically or semi-automatically triggered to send a message to someone’s else’s email address.
In many cases, signup emails are dull and unexciting – they don’t need to be inviting or attractive, after all, because they’re meant to be simple confirmations of a choice you have already made.
But some organisations can’t resist giving the glitzy marketing treatment even to their mailing list confirmations, filling them with logos, clickable links, tempting offers and all the other COOL THINGS YOU WILL ENJOY as long as you actually do complete your signup.
There’s something circular and unappealing about this approach – given that the company isn’t supposed to email you marketing material until you sign up and opt in, emailing you marketing material as part of the opt-in process seems to be putting the cart before the horse, or at least the “in” before the “opt”.
Even though marketing to you as part of getting approval to market to you is annoying, receiving one glamorous and groovy but potentially unwanted email that you weren’t expecting probably isn’t a big deal.
After all, ignoring the email automatically means that you’ll get no more of them.
What is a big deal is that Dr.Web noticed that several major brands and services were incautious about how much information from the signup form itself they trustingly copied into the signup email and ‘reflected’ back to the supplied email address.
For example, instead of signing me up as
Duck and getting an email pushed out to me with a greeting
…the crooks might be able to sign up as
Duck! GET RICH QUICK [link] and trigger an email to me that said,
Hi, Duck! GET RICH QUICK [clickable link].
The spammy part of the confirmation email would end up wrapped into a visually appealing, on-brand, professionally produced HTML page, giving it cultural credibility it didn’t deserve.
Worse, the email itself would pass all anti-spam sender checks such as SPF, DKIM and DMARC, because it really, genuinely, actually came from the right server, giving it a quantifiable technical credibility it didn’t deserve.
What to do?
When re-using untrusted data submitted from outside, be careful not to ‘reflect’ or pass on any of that data in the body of any web page your return, or email you generate.
Otherwise you open up your website or email server to reflection attacks, where you send out dodgy content that I get to choose.
If I give my name as
Paul (or some crook gives my name for me), then sending me an email with the text
Hello, Paul is mostly harmless, albeit presumptuous given that you actually have no idea who I am.
But if a crook gives give my name as
Why not try this fantastic website [insert web hyperlink here], then sending me an email with that text in it is dangerous, because it could lead to a phishing site, to malware, to inappropriate content, and so on.
So, follow our advice:
- Validate your input. If it came from outside, you can’t trust it, so check it. And even if it came from inside, check it anyway to filter out inappropriate, irrelevant or unwanted data as soon as you can.
- Keep confirmation emails simple. They aren’t a marketing opportunity – by definition they are almost exactly the opposite! – so don’t overdo it. The less you send and the simpler you keep it, the lower the chance that anyone can abuse your system to spew out messages that look like something they aren’t.
- Don’t re-use anything from the input form except the raw signup email address. There’s no point in addressing me as
Dear Paul Ducklinin an email that’s supposed to assume it might not be me at all. You don’t know me, so be honest and just use the word
- Pass autogenerated emails like this through your regular spam filter if you can. Don’t exonerate web form submissions from spam filtering just because they were generated on from a supposedly secure server managed by IT.
As so often in cybersecurity, less is more!
6 comments on “Serious Security: How web forms can steal your bandwidth and harm your brand”
Hello Paul, I count the content of the post pretty distant from the title. What you are in fact explaining is that any subscription form can be used maliciously by setting somebody else’s email.
The problem on your idea is that I don’t see the advantage for somebody to push tons of unknown people’s emails in the confirmation list. The only goal I can see in this is to make some nasty joke to the company owning the site, but there is a reason this can’t work and is that normally subscription forms have the IP of the client in them, and I’m pretty sure that services like MailChimp would block this written and funny malicious attempt as soon as the number reaches 10.
What’s the goal in it?
Also, don’t understand what stealing bandwidth means for you.
Stealing bandwidth is when you install some phony VPN that resells your fast internet to others as proxy.
Firstly, not *every* subscription form can be misused this way. Only ones that aren’t careful about how much data from the form is copied into the email that gets generated and sent out. If I can use a subscription form to send you a clickable link *of my choice* in an email sent out by *your* server, then I am less likely to get filtered as spam, and the recipient is more likely to trust the content of the message.
(Our own subscription form only asks for email address, and sends a standard boilerplate email to that address with no hacker-controlled content.)
Secondly, yes, some services may lock out spammers after N attempts, or make you solve a CAPTCHA, or whatever, but not all.
Thirdly, I still call “using someone else’s mail sender for free” to be stealing bandwith – if I use your mailing list server to deliver my messages without your permission, I am stealing at least some of your mail throughput. If I “borrow” your car and drive round the corner and leave it parked outside Burger King, I’m still a car thief, even if I don’t drive it 1000km to Aberdeen and back.
Why does “Follow our advice” not include “Use reCAPTCHA.”
You advocate for form validation. reCAPTCHA is just another chunk of form data to validate.
reCAPTCHA certainly cuts down on automated form abuse, does it not? And v3 is unobtrusive to the user so UX is no longer an excuse to not use it.
I suppose I understand that you may not want to endorse a specific company or product, but who else is in the game?
I thought of that, but CAPTCHAs are neither popular nor necessary in cases like this, so I decided not to include “add a CAPTCHA” in my primary advice.
CAPTCHAs aren’t a data validation technique, they’re a rate limiting mechanism that essentially makes the user do some extra work to reduce the maximum quantity of abuse. But here they treat the symptom, not the cause. So I wanted to focus on the things that you can do to improve things *after accepting the form data anyway*, whether you decide to use a CAPTCHA or not. Those include: ‘reflect’ as little user-supplied data as you can, ideally none; aggressively filter out input that makes risky output, such as HTML special characters; and keep your confirmation emails simple and therefore less abusable – because you don’t actually have permission to spam me with marketing guff until after I agree via the confirmation email!
Whether you rate limit via CAPTCHAs, IP detection or some other “this looks like a bad guy” detection algorithm, those techniques only reduce the *rate* at which your form can be abused if you don’t address the ways in which the form data itself, once submitted, can be abusive.
I’m with Barry. Why not include CAPTCHA/RECAPTCHA? What happened to the “defense in depth” philosophy you always preach? What would it hurt to ad one more layer?
As I said above, I considered it but decided to stick to things that will make form-generated emails safer *even if you do have a CAPTCHA*. In other words, things you can and should do first, as core changes to immunise against the problem, not merely to leave the problem intact but make it happen more slowly.
Rate limiting through techniques like CAPTCHA and IP filtering is a good idea but input validation, and uncomplicated confirmation emails with little or no reflected data… they’re a must and therefore what I focused on.