Random thoughts on reporting abuse

laura
Industry
January 6, 2016

On IRC today, someone mentioned an Ars Technica article discussing how a research team tried to contact Xfinity about a security flaw in their home security system.

We attempted to contact anyone responsible for the security of Xfinity home security devices at the following addresses: security@xfinity.com; secure@xfinity.com; support@xfinity.com; info@xfinity.com; abuse@xfinity.com, but we did not get a response to our attempt to disclose the issues to the vendor.

I’m not surprised they didn’t get a response from those addresses, there’s no mail server there. What I do question is a “security” group that doesn’t check their email bounces. Of course, it could be the mail is sitting in a queue somewhere waiting for it to time out due to lack of DNS resolution.
Thinking about how to find the right email address led me down the path of considering manually reporting problems or spam to groups. What is the right way to do it? I’ll be honest, I’ve mostly stopped reporting abuse to senders I don’t know, and in many cases I only report abuse as a favor to colleagues.
There isn’t a standard for how to accept abuse reports. Yes, yes, yes I know about RFC2142. I’ll just point out that’s a nearly 20 year old RFC that’s still “standards track” and hasn’t been updated or improved since it was initially published.
Historically, the internet was very different when 2142 was published. In 1997 the web was still new. Not every company even had a website. Abuse problems were much simpler. Those companies that had a website tended to have one website, on one domain. The sent mail from the same domain, with links pointing to the same domain. A single abuse@ address maintained at the domain could accept reports about a lot of different things.
Today, email is much more complex. Many organizations have dozens of different domains for different purposes and different . Even a company as small as Word to the Wise has different domains for different things. Many of them are just websites, no email services provided. Larger organizations have different domains for different divisions. They have domains that never receive email and never send email, but are present in email sends. Should a company maintain a server on that domain, with all the associated costs and hassle, just to get the occasional complaint?
In some ways it doesn’t matter that these ESPs can’t get individual abuse reports because enforcement at most ESPs is an issue of numbers. Either they get enough FBL emails to justify action or they don’t. The individual complaints don’t matter and don’t move the needle.
Even in the case were companies care and want those individual complaints there are barriers that prevent reports from getting to the right place.

Legacy Domains

Companies have lots of legacy domains from acquisitions and mergers. Some of these domains are maintained and used, some of them aren’t. In any case, abuse handling isn’t always considered when merging companies and making sure reports get to the right place.

Complex Ownership and Responsibility

Sometimes the company that “owns” an IP doesn’t actually control the IP or the users of that IP. Some of this is a consequence of merger and acquisitions. Not all of it is, though. Sometimes it’s a business partnership that may not be completely visible to the outside. To anyone outside the IPs look like they’re managed and owned and provisioned by provider A but they’re actually the responsibility of provider B. Earthlink broadband is one example that comes to mind – that was a maze of twisty little providers.

Filters

It’s near impossible to run a mail server without any filters these days. Any decent filter will catch spam, including forwarded spam. Companies that run abuse@ on their primary domain can often filter out reports. In many filters it’s hard, if not impossible, to special case specific addresses. Larger companies can.

Hosting Intercepting “special” boxes

Many email hosting platforms, like Google Apps, prohibit role accounts like abuse@ or postmaster@. This means companies using Google Apps often cannot monitor abuse complaints at the standard addresses.
It’s not always easy to necessarily contact “the right people” to get a security repot handled. Particularly if you’re not a part of the community and your report is something unusual. But if the company wants reports there are usually ways to get to the right person. Sometimes this involves calling the switchboard and leaving messages. Sometimes it involved poking around on a website. Sometimes it means joining a mailing list (like NANOG, or mailop, or one of the security lists) and asking for help. Generally if you’re polite, show some clue and share as much info as possible, someone will reach out and help you find the right person to talk to.
In the Xfinity case, the researchers have no excuse for not contacting Comcast directly. They sent mail to a non-existent domain. They never noticed the mail bounced? Even so, as there was no response, they should have worked a little harder to get a response from Xfinity. For instance, while writing this post I found a toll free number directly into Comcast’s security desk. I visited the page that the researchers said “had no useful information”. I went to the bottom and saw “security”, which takes you to https://constantguard.xfinity.com. I clicked on the giant “HELP” link and found:

The Customer Security Assurance organization has been established to ensure a safe and secure online experience for Comcast customers. This team is a dedicated group of security professionals who respond to issues pertaining to phishing, spam, infected computers (commonly referred to as bots), online fraud and other security issues.
Business Hours: 6:00am – 2:00am EST, 7 days a week
Contact: 1-888-565-4329
Xfinity Security Help Page

(Full disclosure: I know some of the folks who handle that 1-888 number).
It’s not always easy. But it is a very rare case where I haven’t been able to get in touch with someone willing to talk to me about an issue with persistence and work. It’s usually not worth the time, but it’s generally not as hard as reported.

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.

Are you ready for DMARC?

The next step in email authentication is DMARC. I wrote a Brief DMARC primer a few years ago to help clear up some of the questions about DMARC and alignment. But I didn’t talk much about where DMARC was going. Part of the reason was I didn’t know where things were going and too much was unclear to even speculate.
We’re almost 2 years down the line from the security issues that prompted Yahoo to turn on p=reject in their DMARC record. This broke a lot of common uses of email. A lot of the damage created by this has been mitigated and efforts to fix it continue. There’s even an IETF draft looking at ways to transfer authentication through mailing lists and third parties.
For 2016, DMARC alignment is going to be a major factor in deliverability for bulk email, even in the absence of a published DMARC record.

A series of tubes

The Internet and pundits had a field day with Senator Stevens, when he explained the Internet was a series of tubes.
I always interpreted his statement as coming from someone who demanded an engineer tell him why his mail was delayed. The engineer used the “tube” metaphor to explain network congestion and packets and TCP, and when the Senator tried to forward on the information he got it a little wrong. I do credit the Senator with trying to understand how the Internet works, even if he got it somewhat wrong. This knowledge, or lack there of, drove his policy positions on the issue of Net Neutrality.
In the coming years, I believe we’re going to be seeing more regulations around the net, both for individuals and for corporations. These regulations can make things better, or they can make things worse. I believe it’s extremely important that our elected officials have a working understanding of the Internet in order to make sensible policy. This understanding doesn’t have to be in their own head, they can hire smart people to answer their questions and explain the implications of policy.
Apparently I’m not the only one who thinks it is important for our elected officials to have a working knowledge of technology. Paul Schreiber put up a blog post comparing the website technology used by the current Presidential candidates. Do I really expect the candidate to be involved in decisions like what domain registrar or SSL certificate provider to use? No. But I do expect them to hire people who can create and build technology that is within current best practices.