Last Updated: 2014-07-09 09:33:39 UTC
by Daniel Wesemann (Version: 1)
Somewhat similar to the typo squatting story earlier, the recent proliferation of cloud service usage by enterprises has led to a new problem. For a project at a community college, we needed a couple servers, and didn't want (or have the funds) to build them on-site. In view of the limited duration of the experiment, we decided to "rent" the boxes as IaaS (infrastructure as a service) devices from two "cloud" providers. So far, all went well. But when we brought the instances live, we discovered to our surprise that three (out of 24) public IP addresses that we were assigned still had "afterglow", meaning they were receiving productive traffic that was intended for the former owner/holder of these IPs. Two of the IPs received DNS queries, one was receiving email. Researching through the passive DNS logs, I confirmed that yes, the three IP addresses had indeed been used accordingly. One of the DNSes had been active only for a week, obviously for nefarious purposes, because it had lots of random .ua and .pw domain names delegated to it. The other seems to have been the DNS+EMail of a midsize company that had been hosted with that IaaS provider for two years, and had been migrated elsewhere earlier that same week.
To make a long story short, for all services where the Internet has an extended memory and caching, make sure you hold on for a couple of weeks or months to the corresponding IP or domain name after you no longer need and use them, and let them "cool off". Otherwise, if the IP address is immediately reassigned, or the domain name immediately repurchased, someone else *will* end up with some of your web traffic, DNS requests, or even email.
Last Updated: 2014-07-09 01:18:03 UTC
by Daniel Wesemann (Version: 2)
Here's one way how to get at sensitive data that seems to be making a comeback. Already in the olden days, it was popular with the crooks to register domain names that only differed by a typo from the name of a legitimate high traffic site. Googl.com, for example. The crooks would then run web pages with lots of advertisements on these domains, and live happily ever after from the ad revenue that the misdirected typo traffic alone brought their way.
Google put a stop to this by registering, for themselves, pretty much all typos of their brand that you can imagine. Not all companies have done so, and with the increased use of smart phones with annoyingly fumbly keyboards (and often autocorrect, as well), typos are making a comeback. As do the typo harvesting sites. This time though, it looks as if they are not after ad clicks -- instead, we see an increase of typo domains that publish an MX record, and thus receive all the mail that was meant for the attacked company, but where the @domain portion of the address contained a typo.
I was recently participating in the analysis of data taken from such a server that the crooks had used to collect other people's mail. One thing that particularly stood out was that a lot of the harvested emails actually came from within the attacked real estate company, and contained rather sensitive internal mails. In other words, say, an employee @samplecompany.com had wanted to send something to a coworker, but typed email@example.com instead on her (not-so)smartphone. As a result, instead of getting delivered internally, the email took the Internet route, and ended up on the server that the crooks had set up.
For every email address with a typo that came from a customer or other external sender, we found a dozen or so of mails that were intended to be from and to an internal employee. What made matters worse is that some of the mobile phones that the company employees used were helpfully "remembering" previously typed email addresses, so once a typo had been made, the fix was in, and the problem persisted until/unless the user noticed that his colleague never answered.
If you don't own the most likely permutations and typos of your main email domain for yourself, you might want to check who does. And if they publish an MX record for these domains, you might want to check your outbound email log to see how much of your intended internal email has typos, and is leaking out.
Update: ISC reader Jerry points out that according to RFC 5321, if no MX record is returned, the A record will be tried instead. So don't count only on the presence of MX records in typo squatting domains to determine if your email is being siphoned off, if in doubt, check their port 25 as well.