Compromises and phishing and email

Earlier this month, Sendgrid reported that a customer account was compromised and used for phishing. At the time Sendgrid thought that it was only a single compromise. However, they did undertake a full investigation to make sure that their systems were secure.
Today they released more information about the compromise. It wasn’t simply a customer account, a Sendgrid employee’s credentials were hacked. These credentials allowed the criminals to access customer data, and mailing lists. Sendgrid has a blog post listing things customers should do and describing the changes they’re making to their systems.
Last month it was Mandrill. Today it’s Sendgrid. It could be anyone tomorrow.
Security is hard, there’s no question about it. Users have to have access. Data has to be transferred. Every user, every API, every open port is a way for a bad actor to attempt access.
While it wasn’t said directly in the Sendgrid post, it’s highly likely that the employee compromise was through email. Most compromises go back to a phish or virus email that lets the attacker access the recipient’s computer. Users must be ever vigilant.
We, the email industry, haven’t made it easy for users to be vigilant. Just this weekend my best friend contacted me asking if the email she received from her bank was a phishing email. She’s smart and she’s vigilant, and she still called the number in the email and started the process without verifying that it was really from the bank. She hung up in the transaction and then contacted me to verify the email.
She sent me headers, and there was a valid DMARC record. But, before I could tell her it wasn’t a phishing email, I had to go check the whois record for the domain in question to make sure it was the bank. It could have been a DMARC authenticated email, but not from the bank. The whois records did check out, and the mail got the all clear.
There’s no way normal people can do all this checking on every email. I can’t do it, I rely on my tagged addresses to verify the mail is legitimate. If the mail comes into an address I didn’t give the sender, then it’s not legitimate – no matter what DMARC or any other type of authentication tells me. But most people don’t have access to tagged or disposable addresses.
I don’t know what the answers are. We really can’t expect people to always be vigilant and not fall for phishing. We’re just not all present and vigilant every minute of every day.
For all of you who are going to tell me that every domain should just publish a p=reject statement I’ll point out DMARC doesn’t solve the phishing problem. As many of us predicted, phishers just move to cousin and look alike domains. DMARC may protect citi.com, but citimarketingemail.com or citi.phisher.com isn’t.
We’ve got to do better, though. We’ve got to protect our own data and our customer’s data better. Email is the gateway and that means that ESPs, with their good reputations and authentication, are prime targets for criminals.

Office365/EOP IPv6 changes starting today
Political Fraud & Spam

Related Posts

I know your customers' passwords

Go to your ESP customer login page and use “View Source” to look at the HTML (under “Page” on Internet Explorer, “Tools->Web Developer” on Firefox, and “View” on Safari).
Go on, I’ll wait.
Search for the word autocomplete. If it says something like autocomplete=”off” then your web developers have already thought about this security issue. If it doesn’t, then you might have a serious security problem.
What’s going on here? You’ve probably noticed that when you’re filling in a web form your browser will often offer to fill in data for you once you start typing. This feature is supported by most modern browsers and it’s very convenient for users – but it works by recording the contents of the form in the browser, including the username and password.
As a bad guy that’s very interesting data. I can take some off-the-shelf malware and configure it with the URLs of a bunch of ESP login pages. Then I just need to get that malware installed on your customers desktops somehow. A targeted web drive-by malware attack, maybe based on targeted hostile banner ads is one approach, but sending email to people likely to be ESP customers is probably more effective. Maybe I’ll use hostile email that infects the machine automatically, or – most likely – I’ll use a phishing attack, sending a plausible looking email with an attachment I’m hoping recipients will open.
Once the malware is installed it can rummage through the users browser files, looking for any data that matches the list of login pages I gave it. I just need to sit back and wait for the malware to phone home and give me a nicely packaged list of ESPs, usernames and passwords. Then I can steal that customer’s email lists and send my next phishing run through that ESP.
This isn’t a new issue – it’s been discussed since browsers started implementing autocompletion over a decade ago, and it’s been a best practice to include autocomplete=”off” for password fields or login forms for years.
How serious a risk is this for ESPs? Well, I looked at the customer login pages at several ESPs that have a history of being compromised and none of them are using autocomplete=”off”. I looked at several that haven’t been compromised that I know of, and they’re all using either autocomplete=”off” or a complex (and reasonably secure-looking) javascript approach to login. Correlation isn’t causation, but it’s fairly strong circumstantial evidence.
ESPs should fix this hole if they haven’t already. If any customers are upset about having to actually type in their password (really?) they can take a look at secure password management tools (e.g. 1Password, LastPass or KeePass).
Thanks to Tim at Silverpop for reminding me that this is a serious security hole that many ESPs haven’t plugged yet and pointing me at some of these resources.
More on passwords and application security tomorrow.

Read More

Is any data safe?

Today another major retailer announced their customer files were compromised. This company had clearly implemented some security that kept hackers from getting too much information. Passwords were hashed and credit card numbers were kept on a separate server, which does signal that the company designed with security in mind. Nevertheless, personal information was compromised.
Is there anyway to keep information safe if it’s accessible from the internet? Some of my uber-security conscious friends would say no. I am beginning to believe them.

Read More

Are you ready for the next attack?

ESPs are under attack and being tested. But I’m not sure much progress in handling and responding to the attacks has been made since the Return Path warning or the Epsilon compromise.
Last week a number of email marketers became aware that attacks against ESPs and senders were ongoing. The shock and surprise many people exhibited prompted my Spear Phishing post on Friday.
The first round of phishing went out on Wednesday, by Friday they were coming from a different ESP. Whether this was a compromised ESP customer or employee it doesn’t matter. ESPs should have reaction plans in place to deal with these threats.
It’s been months since the first attacks. This is more than enough time to have implemented some response to reports of attacks. Yet, many people I talked to last week had no idea what they should or could be doing to protect themselves and their customers.
Last time the attacks were publicly discussed I was frustrated with many of the “how to respond” posts because few of them seemed to address the real issue. People seemed to be pushing agendas that had nothing to do with actually fixing the security holes. There were lots of recommendations to sign all mail with DKIM, implement 2 factor authentication, deploy validation certificates on web properties, or adhere to sender’s best practices.
None of those recommendations actually addressed the gaping security hole: Humans.

Read More