Aetna, phishing and security

We’ve just gotten home from M3AAWG and I’m catching up with a lot of the administrative stuff that’s gotten ignored while we were soaking up the tons of information from some of the smartest Internet security folks around. One of the tasks I’m working on is checking on our recent bills from our health insurance provider. Their website seems to be down, so I called them up and asked them if it was down or if something was broken on my end.
They did confirm there was a problem with the site “earlier today” but then started asking me for my account information. They’ve promised to email me a new password because of reasons.
One of the things about M3AAWG is that concentrated discussions about spam and online criminals and security can make everything feel so fragile and security so inadequate to protect us against criminals. I start thinking that everything is compromised. It doesn’t help that websites fail just at the time when I start trying to figure out if my personal information leaked out.
In the course of trying to figure out if there is something wrong at Aetna and if my personal information is safe, I find an article about how poor security is for health companies. “Health companies flunked an email security survey—except Aetna.” Apparently, out of all the health companies out there, Aetna are the only ones fully implementing DMARC on all their mail streams.
The problem is that for the mail I received from Aetna, the visible From: address is AetnaeBilling@aetnagroupbilling.com. This is one of the major vulnerabilities of DMARC. How can I, as a recipient, tell that this is officially mail from Aetna? Any phisher could register “aetnabilling.com” or “aetnagoupbilling.com” or “aetnaebilling.com” and publish DMARC records and use those records to phish customers. Even worse, aetnagroupbilling.com isn’t a SSL registered website.
This is exactly the type of setup a phisher would use to gain access to people’s health insurance accounts. And Aetna offers the ability to draft payments directly from a business checking account, so breaking into the billing account also offers some level of access to the business money.
Do I think this is a phish? No.
Do I think the average person would be able to tell that? No.
There’s got to be a better way to secure folks online.

Salesforce SPF and now DKIM support
A must read on engagement

Related Posts

Disposable addresses

Both Steve and I have blogged about how we use tagged addresses to monitor and manage our incoming mail. This is not something unique to our system, but rather a feature that’s existed in many mail systems for a long time. Many unix systems support tagged addresses out of the box, but there are also commercial MTAs and even some webmail services that support tags.
Gmail offers “+ addressing” where users can use unique tags after their username. This gives every gmail use an unlimited number of addresses to use. Any address gets leaked or compromised, and you can set filters to ignore future mail to that particular tagged address.
Yahoo offers up to 500 unique addresses per account. Initially this was a service provided by OtherInbox, now owned by Return Path, but it’s not clear if that’s still the case.
Spamgourmet has been offering disposable addresses since 2000. Their system has a built in limit on the number of emails a particular email will receive, which can help control the incoming volume.
Spamex is another provider of disposable addresses that’s been around for years and is providing services that allow recipients to control their incoming mail.
New on the scene is MeAndMyID.com who popped up in the comments here today. They are offering disposable addresses, free for a lifetime, if you sign up soon.
There are also the “short term” or “open inbox” disposable addresses like Malinator or 10 Minute Mail
I find disposable addresses invaluable for sorting through the mail coming into my account. A bank email to an address I didn’t give the bank? It’s a phish. A pizza hut email to an untagged address? Not real. Target emails to an address only given to Amazon? Amazon is selling or giving addresses away in violation of their privacy policy. Unexpected email from a vendor, but to a tagged address? Time to unsubscribe as I’ve lived this long without their mail.

Read More

Nominations for the J.D. Falk Award

J.D. Falk was one of the first names I encountered when learning how to read headers and report spam back in the mid-90s. He was one of the folks leading the fight against spam and actively trying to improve the Internet. When I was hired by MAPS I got to work with J.D. and a number of other big-names. One of the things that really surprised me was that this “internet elder” I had imagined was younger than me and with much bluer hair.
After MAPS imploded, J.D. and I carved out separate careers. He went to work at a number of major mailbox providers and I started delivery consulting. Our paths crossed occasionally, usually at conferences, but we also were on a number of mailing lists together. I kept an eye on J.D and his impact on email delivery. In fact, J.D. was responsible for a lot of the modern anti-spam techniques implemented at ISPs.
Eventually, he moved to Return Path where he worked on their Receiver Support group; even as he continually argued against the false sender / receiver dichotomy that so many people endorse.
M3AAWG, with financial support from Return Path, created the J.D. Falk award to recognize people who work to create a better online world. Nominations for the 3rd annual J.D. Falk award are now open. The M3AAWG website has more details.

Read More

May 2014: The month in email

It’s been a busy and exciting month for us here.
Laura finished a multi-year project with M3AAWG, the Messaging, Malware and Mobile Anti-Abuse Working Group (look for the results to be published later this year) and continued working with clients on interesting delivery challenges and program opportunities. Steve focused on development on the next version release of Abacus, our flagship abuse desk tool, which will also be available later this year.
And as always, we had things to say about email.
The World of Spam and Email Best Practices
We started the month with a bit of a meta-discussion on senders’ fears of being labeled spammers, and reiterated what we always say: sending mail that some people don’t want doesn’t make you evil, but it is an opportunity to revisit your email programs and see if there are opportunities to better align your goals with the needs of people on your email lists. We outlined how we’ve seen people come around to this position after hitting spamtraps. That said, sometimes it is just evil. And it’s still much the same evil it’s been for over a decade.
We also wrote a post about reputation, which is something we get asked about quite frequently. We have more resources on the topic over at the WiseWords section of our site.
Gmail, Gmail, Gmail
Our friends over at Litmus estimate Gmail market share at 12%, which seems pretty consistent with the percentage of blog posts we devote to the topic, yes? We had a discussion of Campaign Monitor’s great Gmail interview, and offered some thoughts on why we continue to encourage clients to focus on engagement and relevance in developing their email programs. We also wrote a post about how Gmail uses filters, which is important for senders to understand as they create campaigns.
SMTP and TLS
Steve wrote extensively this month about the technical aspects of delivery and message security. This “cheat sheet” on SMTP rejections is extremely useful for troubleshooting – bookmark it for the next time you’re scratching your head trying to figure out what went wrong.
He also wrote a detailed explanation of how TLS encryption works with SMTP to protect email in transit, and followed that with additional information on message security throughout the life of the message. This is a great set of posts to explore if you’re thinking about security and want to understand potential vulnerabilities.
DKIM
Steve also wrote a series of posts about working with DKIM (DomainKeys Identified Mail), the specification for signing messages to identify and claim responsibility for messages. He started with a detailed explanation of DKIM Replay Attacks, which happens when valid email is forwarded or otherwise compromised by spammers, phishers or attackers. Though the DKIM signature persists (by design) through a forward, the DKIM specification restricts an attacker’s ability to modify the message itself. Steve’s post describes how senders can optimize their systems to further restrict these attacks. Another way that attackers attempt to get around DKIM restrictions is by injecting additional headers into the message, which can hijack a legitimately signed message. If you’re concerned about these sort of attacks (and we believe you should be), it’s worth learning more about DKIM Key Rotation to help manage this. (Also of note: we have some free DKIM management tools available in the WiseTools section of our site.)
As always, we’re eager to hear from you if there are topics you’d like us to cover in June.

Read More