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.

Peeple, Security and why hiding reviews doesn't matter

There’s been a lot of discussion about the Peeple app, which lets random individuals provide reviews of other people. The founders of the company seem to believe that no one is ever mean on the Internet and that all reviews are accurate. They’ve tried to assure us that no negative reviews will be published for unregistered users. They’re almost charming in their naivety, and it might be funny if this wasn’t so serious.
The app is an invitation to online abuse and harassment. And based on the public comments I’ve seen from the founders they have no idea what kind of pain their app is going to cause. They just don’t seem to have any idea of the amount of abuse that happens on the Internet. We work with and provide tools to abuse and security desks. The amount of stuff that happens as just background online is pretty bad. Even worse are the attacks that end up driving people, usually women, into hiding.
The Peeple solution to negative reviews is two fold.

Brian Krebs answers questions

Brian Krebs did an AMA on Reddit today answering a bunch of questions people had for him. I suggest taking a browse through his answers.
A few quotes stood out for me.
Q: Why do you think organizations seem to prefer “learning these lessons the hard way”? It doesn’t seem to be an information gap, as most IT executives say security is important and most individual contributors share risks upward with specific steps that can be taken to remediate risks. Given the huge costs for some breaches, why do you think more organizations don’t take the easy, preventative approach?

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.