Last Updated: 2011-10-12 14:53:56 UTC
by Tom Liston (Version: 1)
"What's in a name? That which we call a rose
By any other name would smell as sweet." – Juliet, Romeo and Juliet (II, ii, 1-2)
"A good name is more desirable than great riches; to be esteemed is better than silver or gold." – Proverbs 22:1 (NIV)
A rose is a rose is a rose
What if I could hack your organization and abuse your company’s reputation – and what if I could do it without your firewall, IDS, IPS, or your host-based badware detection making a peep?
What if I could use your organization’s good name to sell ED drugs, questionable Facebook "apps," shady online "personal ads," or to distribute porn that would make a sailor blush?
What if I did all of that, and you didn’t know? What if the hack itself took place on a machine you didn’t directly control and only accessed rarely? And what if the hack was so subtle, so obscure, and so difficult to find that once I had it in place, it might be years before you ever stumbled across it – if you ever stumbled across it?
This nightmare scenario is, unfortunately, reality for at least 50 organizations – ones that I’ve been able to uncover – and I'm certain that there are many, many more. Each of these organizations has been a victim of a malicious alteration of their domain information – an alteration that added new machine names to their existing information, and allowed bottom-feeding scam artists to abuse their good reputation to boost the search-engine profile of their drug, app, "personal ad," or porn sites.
Take a look at the following table:
|These sites...||Resolve To||While the main site...||Resolves To|
Over 150 "new" entries have been created in the zone information for these organizations. Each of these new "sites" inherits whatever good reputation the parent domain may have accumulated, and is, therefore, valuable as a means of search engine optimization (SEO).
The following table shows that these hacks occurred at multiple DNS providers with a few being somewhat more "popular" than others:
Finding these sites was a matter of luck and perseverance. Initially, I happened across a single, odd-sounding site name while looking for organizations that had been compromised by the bad guys for SEO purposes. Using tools that attempt to list all of the domain records pointing to a particular IP address led me to more. Google searches for sites linking to these domains led me further. Unquestionably, there are more of these types of sites out there – some not currently in use. However, because there is no good way to truly search DNS information, attempting to find these from the "outside" is difficult and frustrating.
"Round up the usual suspects..."
How did this happen? Unsurprisingly, no one I talked to about this was standing at the front of the line, ready to take the blame for these issues: Domain owners swear they used good passwords and are sure that the DNS providers were hacked, DNS providers are certain that the Domain owners used lousy passwords on their accounts... 'round and 'round we go.
My gut tells me that the truth lies somewhere in between: bad passwords combined with poor account lockout controls on something like a cPanel-type web interface probably led to successful brute force attacks on most of these... I could, however, be completely wrong. Unfortunately, I just don't have the time to chase every one of these to ground.
Don’t Let This Happen To You
- Check your DNS zone file information periodically, just to make sure nothing has been added without your knowledge.
- Choose passwords wisely, especially on interfaces where brute-force attacks are likely (i.e. pretty much anything accessible from the internet). Never use dictionary words. And remember: while "qwertyuiop" may not be in your dictionary, it IS in mine...
- Periodically take a look at your website how Google sees it (Google search: "site:yoursite.com" – NOT www.yoursite.com, and look through the pages for anything out of the ordinary. Toss a few choice keywords in as well ("Viagra," "Cialis," "drugs," "personals," etc...). This kind of search can help you discover many different types of issues with your site.
Last Updated: 2011-10-10 18:31:01 UTC
by Jim Clausing (Version: 1)
The next of our critical controls for Cyber Security Awareness Month is log management/monitoring/analysis. This has been a interest/passion of mine for a long time. As Eric Cole (among others) is fond of saying in SEC 401, prevention is ideal, but detection is a must. If you aren't logging as much as possible, how will you ever know when something bad happens?
As mentioned in a couple previous diaries this month, one of the keys for this control is that all of the log generating devices (routers, switches, firewalls, servers, workstations, ...) be synchronized, so NTP is your friend.
The third key is to collect the logs somewhere other than the device that generates them, our "central log server." This server should be one of your most locked down, best protected servers in the enterprise. This way, even if the bad guys breach one of the servers and are able to modify the logs on the server to hide their tracks, there will still be the unmodified copy of the logs on the log server.
All of this does you no good if you aren't actually looking at the logs and this is where you need both some software to automate things and an experienced analyst. The software is going to be necessary because sheer volume can quickly overwhelm an analyst. This doesn't necessarily mean you need to spend a lot of money though. While the commercial SEIM packages are good, you can accomplish a lot with a free software like awk and grep. In 1997, Marcus Ranum introduced the notion of "artificial ignorance," the idea of using software to remove the "known good" entries to let the analyst concentrate on the new/unusual stuff. For a number of years, I used his nbs (never before seen) software on my home system (though I recently tried to recompile it and ran into an issue that I haven't taken the time to track down yet). Just last week I saw announcement of some new software, called LogTemplater, that implements a similar idea. I've just started looking at it, but it looks like it has some promise.
Once you've cut the logs down to a manageable volume, the analyst is also still crucial. Analysis is an area where I personally think you are doing your enterprise a disservice by making this the job of the newbie. An analyst who knows the environment and has developed a feel for what is normal can much more quickly hone in on where the real problems are. On the other hand, if the newbie can work with an experienced analyst, this is a good way to quickly learn the environment.
There is no point in me repeating everything that is already at the SANS critical controls page linked below, so please check out the page linked below.
So, what do you use for your log analysis? Let us know either in the comments section below or via our contact page.
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu