All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
An email security vendor is leaving 2M domains open to phishing hacks
Is Mailchannels really vulnerable as reported in the article below?
A security researcher has uncovered a way to spoof at least 2 million email domain names for phishing attacks that requires little or no expertise to use, according to research shared first with Axios.
Why it matters: Phishing, which often relies on spoofed email addresses, remains one of the top entry points for malicious hackers looking to install malware or conduct social engineering campaigns.
Generative AI is also threatening to make phishing emails more believable. Driving the news: Marcello Salvati, an independent security researcher, is presenting his findings at the DEF CON hacking conference in Las Vegas on Friday.
The big picture: Salvati's research focuses on email security vendor MailChannels, which offers tools for organizations looking to send automated emails to their customers, such as newsletters.
Typically, companies providing such services require customers to prove they own a domain before they can send an email using it. MailChannels doesn't do that — in part, because the company caters primarily to web-hosting companies that need to send emails on behalf of their clients, like a password reset email or email signup confirmation. Instead, MailChannels relies on spam detection tools that measure users' past behavior and IP address reputations. It also scans portions of the message before sending it out.
Details: Salvati's research found that those anti-spam tools are relatively easy to bypass.Salvati built a tool that allows someone to send an email from whatever MailChannels' customer domain name they want without verifying if they own the domain. In one example, Salvati was able to spoof the domain name for the Black Hat hacking conference, which also took place in Vegas this week. As long as the message seems harmless, malicious actors' emails most likely won't get flagged by the company's chosen security features. Someone wanting to do this themselves would just need $80 to sign up for a basic MailChannels account and gain access to the system. Yes, but: MailChannels has security tools in place and doesn't consider this issue a security vulnerability.
MailChannels CEO Ken Simpson told Axios in a LinkedIn message after this story's publication that Salvati's research points out a broad flaw in the DMARC standard — an email authentication protocol — "that is well known." "MailChannels sends email for 30 million different domains that are hosted behind over 600 web hosting provider networks," Simpson said. "We cannot force every domain owner to verify the ownership of their domain because domain owners do not even authenticate domain ownership with their own hosting provider." Simpson and Salvati also spoke a few times about the research in the months leading up to the DEF CON presentation. Simpson also pointed Axios to a new feature called "Domain Lockdown" — which the firm rolled out in June in response to Salvati's research — that details a new, anti-spoofing security tool for customers. The intrigue: MailChannels has a partnership with CloudFlare under which it validates emails coming from CloudFlare's Workers customers.
The partnership would mean that it's highly probable that anyone with a free CloudFlare account could spoof any of MailChannels' customers, Salvati said. MailChannels now requires CloudFlare customers to turn on the "Domain Lockdown" feature before sending emails. Threat level: MailChannels has roughly 40% of the global market share among companies sending emails on behalf of domain owners, the company said in a press release last year.
Some of the spoofable domains seemingly include those belonging to city governments, lottery websites and mobile phone companies. MailChannels has also adopted a relatively new email authentication protocol known as ARC that allows emails to more easily bypass spam filters. Of note: Salvati, a former researcher at cybersecurity firm Rapid7, worked with his ex-colleagues to verify his findings.
What they're saying: "In all of our testing, none of our emails were blocked, and I've personally tried once or twice to send myself a phishing email with a link to an executable and that wasn't blocked either," Salvati told Axios.
"There are existing hard security controls that other vendors have that don't allow you to spoof the emails in the first place," he added. Be smart: Salvati's presentation concludes with a cheeky, but necessary disclosure for those attending his talk: "Don't do crimes, plz."
"Only test on domains you own/control and have permission," he adds.
https://www.axios.com/2023/08/11/mailchannels-security-phishing-hacks-study
Comments
Watching security researches pretend shock and awe over things like this kind of makes me laugh. I blew the whistle on this one drunk years ago, where's my credit 🤣
Email is insecure by design, and the mechanisms to secure it are reactionary and poor (sorry to the guys, I mean no insult, you did the best you could to put lipstick on a pig). Either it needs rethinking from the ground up or people simply need to be better educated about phishing. It's not all that much unlike BGP in that way, but far less important on average.
Forcing everyone to prove domain ownership cuts out a service like Mailchannels for shared hosting providers, just totally takes the use case off the table. It's not an option, and anyone who suggests it isn't willing to have tough conversations they just want the easy out. "Securing" the setup only to drive the customers to someone new that isn't "securing" it (by severely inconveniencing them over an issue 999 out of 1000 don't care about) provides a net zero output on the solution front. This isn't going to be a quick fix.
MC's domain lockdown feature is brilliant. It's not enough and it never will be, the only solution right now is to break nearly all of their customer's use cases. But for what it is, it deserves recognition. My advice for @mc_ksimpson is be slow to respond to this if possible, there's not a lot of ways to please the people involved here in the short term without closing the doors.
Block how, they expect the spoofed mail to be outright rejected? From my experience most email server doesn't honor dmarc record for reject policy. Failed spf/dkim mail would still be accepted, just marked and dumped into spam. Its a honor policy, not a hardcoded protocol. Really upto mail server to honor it or not.
Actually you can always choose to use reject mode (-) on SPF and (reject) on DMARC for flat out rejection instead of getting put in spam with softfail.
But this case is due to sharing of same email server relay between multiple domains, and hence the issue.
It doesn't matter how strict the policy is, ultimately its a honor system. Random mail server sometime just doesn't respect it. They would still accept spoofed email, dumped into spam folder even for the strictest p=reject; sp=reject; aspf=s; adkim=s for dmarc and -all for spf. Nowadays i just use =quarantine and ~all knowing it'll end up be treated as such by those random mail server out there.
I've known about that for ages, it's kind of obvious you're able to spoof other customers domains, it's not like MC forces you to verify a domain before you can send using it so any mailchannel account is able to relay mail for any domain and pass SPF.
The only way for them to stop it would be enforcing verification but for the use case of the service it would be a nightmare.
This is a wasted talk slot really. Mailchannels does it, SpamExperts does it, basically any "designed for hosting" relay service will not validate any domains.
The problem won't be fixed because it'd require customers of the host/provider to make changes to their domain to validate it, and they're not going to want to do that, hence they'll just move to the next provider which offers it without the excess steps.
There’s another part to why it matters as much as well. No one would even be able to have their “gotcha” moment and 15 minutes of fame by smearing a vendor if there wasn’t so much of people having to mass collapse into the same mail relays. But if email wasn’t a problem they specifically set out to solve themselves in-house, then they have to do just that.
Email is still largely an IPv4 concern so forgive me for glossing right over v6, but the number of IPs acceptable for sending mail to major providers is only shrinking. Someone might argue with me over how fast that pool is shrinking but not that it is. They don’t make any more IP addresses. Clawing them back from a bad reputation is not always possible. Sometimes, but not always.
The best hope anyone has to keep an IP range clean and functional for delivering mail to Gmail, Hotmail, AT&T, and Verizon (simultaneously all of those) all from the same range is to be “too big to fail.” That means we’re at our most powerful when we pool together. And that’s where the problem appears too: when we all pool together.
Individual relay providers can do things, but it’s just treating symptoms all the way down the line, for the sole purpose of trying to live in the world run by “big email” (I thought that was a funny way to say it). I still think making my own pool was the best thing I ever did (and hopefully Louis feels the same since his hand in it was far more than I just implied). For all of the (mostly theoretical in practice) problems it creates, it's still the best way to solve the problems people are actually (not theoretically) facing today.
LowEndTalk warms my heart. Thank you for the words of support, @jar and others.
The email RFC makes it plain that efforts to constrain the sender's address in the name of preventing spoofing "are largely misguided":
The DEFCON researcher made a very big deal out of something that RFC5321 specifically advises is a lost cause. Unfortunately, because restricting domain spoofing via ownership checks seems like an "obvious idea," his presentation got a good reception from people who can't be faulted for being naive about how email actually works at scale.
To give just one example of something that would break if we forced domain verification on our customers: mailing lists. Many many legitimate mailing lists send emails "from" the actual list subscriber's domain. Sure, you can configure Mailman to set the MAIL FROM to something else, but when you do that, it means your mail client can't represent the identity of the sender properly (because it doesn't really have their address).
Nonetheless, we are excited about Domain Lockdown and will be adding this to our cPanel plugin to make rolling it out easier for customers who wish to use it. I think that giving people the ability to restrict how their domain is used within our service is a fine idea. You don't even have to be a customer of ours; you can add a Domain Lockdown record that contains no fields and it will prevent us from ever delivering any email from your domain:
_mailchannels.example.com TXT "v=mc1"I haven't spent too much time looking at it, but one small thing will make the world of difference there:
The TXT record for domain lockdown should specify that particular hosting server as the one that can send email for the domain. It shouldn't be the whole of the hosting provider's MailChannels account, just that server. That may mean that hosting providers need to be told point blank that they need to generate new credentials for each hosting server. Because if the hosting provider has 1000 servers and a user approves the provider to send for their domain, 999 servers are capable of spoofing their domain and passing domain lockdown. (Tbh it's actually 1000 because 0 shared hosting providers prevent spoofing on the server but that's their problem not yours)
I also think it's a bit of a lost cause in the grand scheme of things, especially when a minor domain typo is going to zoom right past the eyes of 99.99% of end users, breaking the whole entire thing anyway, so why even bother with anything other than educating users? But since domain lockdown is a thing and it's billed as the answer, that'll short circuit the next complaint at a relatively low cost.
Regardless, congrats on the press. No press is bad press, I fully believe that.
1: For the email Envelope From and header From,it can be different
2: For most of the relay service provider,they do not check the header from at all,in that case,you can spoof any domain as you like.
3: For the past two years,sendgrid was widely used to send scam and phishing and virus emails,during that time,I make a rule to marked all emails from sendgrid as spam unless whitelist account
4: Sendgrid now fix such issue,all header from used must be active by dns check with mx,cname record.So now,it is hard to send scam,phishing from sendgrid now.
5: Other provider like mailgun,still no check the header from,you can set to any domain as you like.
What's really fun about this, and it really just destroys the whole email industry in a sweeping move:
The From header is not checked by most services. Most meaning the most number of services, not necessarily the most number of emails (because Gmail actually does police this and remains the bulk of email).
The From header is not logged by any major MTA, it's largely seen as cosmetic and written by the email client rather than the server.
Every major email client treats the From header as an authority as to who the email came from.
Anytime you do the work day to day, you recognize the inherent flaws in the things you're working with. That's why the best "gotcha" is to take someone from an industry and buy them dinner. You'll learn all of the things that make your jaw drop, and often they'll make incredibly good headlines. I don't know whether to be happy or upset when email makes it into that arena, because email in general does need a good kick in the pants, but I also hate being in the middle when the shit starts to get exposed. Because I was never going to be the one to fix the problem areas that people didn't notice, but I'll be one of the ones they pick on for them (and was the other day, for using default DKIM signing behavior). For that I feel a bit of sympathy for MailChannels, because you build something great but you fail to solve all of the problems inherent in the protocol and you never know when someone is going to try to get their 15 minutes of fame at your expense.
It's not even that it's unfair to call it out either, that's what makes it frustrating. It's fair. It's just frustrating to be a vendor and be the one called out for a problem that's not really of your making alone.
For the postfix,the safe config is to put reject_sender_login_mismatch before permit_sasl_authenticated,otherwise,when someone at your company,the email password is got by the hacker,they can spoofed as any other domain or account as they like.
1: The config order:
permit_sasl_authenticated,
reject_sender_login_mismatch
You can login as [email protected] and show it as [email protected] at header from
2: The config order:
reject_sender_login_mismatch
permit_sasl_authenticated,
You can login as [email protected] and can only show as [email protected],you can not show it to be:[email protected] at the header from.
The best way to protect your own domain:
1: For the SPF, set it to be: -all not ~all, for example: v=spf1 mx -all
2: Set up dkim if your mailserver support it.
3: Set up DMARC and set it to be: v=DMARC1; p=reject; sp=reject
SPF is useful for RFC5321(Envelope From) and DMARC useful for RFC5322(header from)