Random thoughts on reporting abuse

stop_atOn 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.

Related Posts

December 2015: The month in email

December2015_blogHappy 2016! We enjoyed a bit of a break over the holidays and hope you did too. Here’s our December wrap up – look for a year-end post later this week, as well as our predictions for the year ahead. I got a bit of a head start on those predictions in my post at the beginning of December on email security and other important issues that I think will dominate the email landscape in 2016.
DMARC will continue to be a big story in 2016, and we’re starting to see more emphasis on DMARC alignment as a significant component of delivery decisions. I wrote a bit more on delivery decisions and delivery improvement here.
December in the world of email is all about the holidays, and this year was no exception. We saw the usual mix of retailers creating thoughtful experiences (a nice unsubscribe workflow) and demonstrating not-so-great practices (purchased list fails). We took a deeper look at the impacts and hidden costs of list purchasing – as much as companies want to expand their reach, purchased lists rarely offer real ROI. And on the unsubscribe front, if you missed our discussion and update on unroll.me unsubs, you may want to take a look.
Steve wrote a detailed post looking at what happens when you click on a link, and how you can investigate the path of a clickthrough in a message, which is useful when you’re trying to prevent phishing, fraud, and other spam. In other malicious email news, the CRTC served its first ever warrant as part of an international botnet takedown.
In other industry news, some new information for both ESPs and recipients interested in feedback loops and a somewhat humorous look at the hot-button issues that divide our ranks in the world of email marketing. Please share any we may have missed, or any other topics you’d like us to address.

Read More

We're all targets

Last week, another email provider announced their systems had a security incident. Mandrill’s internal security team detected unusual activity and took the servers offline to investigate. While there’s no sign any data was compromised or servers infiltrated, Mandrill sent an email to their customers explaining the incident was due to a firewall rule change.
Email service providers are a high value target for hackers, even if all they have is email addresses. Selling the email addresses is extremely profitable for hackers who can either sell the list outright or sell access to the list. In addition to gaining access to the email addresses, hackers often use the ESP to send these messages essentially stealing the ESP’s reputation to deliver the spam.
It was just over four years ago when a number of major ESPs were targets of a large attack and multiple ESPs were compromised. Earlier this month, three people were arrested for their roles in the attack. While the attacks four years ago were primarily spear phishing attacks, the security incident at Mandrill shows that hackers and botnets are actively probing the ESP’s network looking for access or known vulnerabilities. Spear phishing is an attempt to gain unauthorized access to a system by specifically targeting an individual, group, or organization. The scam attempts to have the user to click a link to infect their computer and network or capture their user id and password via a fake website. The scam email may appear to be sent from the company’s security or human resources department, but the email is either forged or another user’s account has been compromised.
Just because recent arrests have been made does not mean the threat is over. Systems often change, are upgraded, and are integrated with many additional services and systems can become vulnerable.  Security will never be a set and forget policy. In the last 12 months there has been two significant vulnerabilities discovered, first Heartbleed and second was POODLE. Security professionals from all industries had to react quickly to secure their systems and hackers immediately began probing for systems that were unpatched. GFI reports there were over 7,000 vulnerabilities discovered in 2014 with 24% of them being rated as high severity. Security must not only cover servers, but the transmission of the data internally and with third-party vendors, and the workstations of employees.
IT and security professionals must be ever vigilant in protecting their network and their customers data. SANS Institute provides a number of security control best practices including a document on Data Protection. The control recommendations range from quick wins to advanced considerations such as monitoring all traffic leaving the organization and being able to detect any unauthorized or unusual transfer of data, blocking access to file transfer protocols and file sharing websites, performing annual reviews of all keys, certifications, and security procedures.
One of the best ways to help the entire industry to be secure is to be transparent and open when incidents happen. Mandrill has published a blog post with the results of their investigation.

Read More

Back from M3AAWG

Last week was the another M3AAWG meeting in San Francisco. The conference was packed full of really interesting sessions and things to learn. Jayne’s keynote on Tuesday was great, and brought up a lot of memories of just what it was like to be fighting spam and online abuse in the mid to late 90s. It’s somewhat amazing to me that many of the people I first met, or even just heard about are still actively working to fight abuse and make the Internet safer.
Wednesday was another great keynote from Facebook, discussing security. Facebook is committed to sharing threat information and has started the ThreatExchange website as a hub for sharing data among large companies.
One thing that was amusing was during one talk someone mentioned YubiKey for managing logins. They said many people were sharing long strings of random keys that sometimes happen because someone has accidentally triggered the one time passcode. YubiKey is awesome, if sometimes ccccccdkhjnbitklrrtnhjrdfgdlhektfnfeutgtdcib inscrutable.
As has become a bit of a M3AAWG tradition lately, Wednesday was also kilt day. There may be pictures. For those of you planning to go to Dublin, Wednesday will be kilt day as well.
The conference was great, but ended on a bit of a down note. We received word that Wednesday night a long time friend, Ellen R., passed away due to complications from a stroke. The conference held a moment of silence for her at the end. Ellen was a friend as well as a colleague. She was around on IRC when we started this crazy experiment called Word to the Wise and was always helpful and insightful. She volunteered with, and then worked for, Spamcop and then volunteered with Spamhaus. Ellen will be very missed.
I started off the conference remembering all the friends I made back in the late 90s and ended it remembering and missing those who are no longer around. Email has been one amazing journey, and doesn’t look like it’s going away anytime soon.

Read More