DNS Cache Poisoning Again

(from ISC handler Kyle Haugsness)


We have received information that another DNS cache poisoning attack has
been launched. This time, it appears that the motivation is a little
different. The site being re-directed to is a website that sells
generic versions of popular prescription drugs. There are numerous
references on the Internet to this site as being spammers and the like.
We do not see any spyware/adware/malware being served from the server.


Before going any further, let's talk about the DNS server on Windows NT
4 and 2000 (not 2003). By default, the DNS server does NOT protect you
against DNS cache poisoning. If you run a resolving nameserver on
Windows NT 4 or Windows 2000, you are HIGHLY ADVISED to set the follow
the instructions here to protect yourself from these attacks:


http://support.microsoft.com/default.aspx?scid=kb;en-us;241352


Here is how the attack works. First, there needs to be a trigger that
forces the victim site's DNS server to query the evil DNS server. There
are several ways to accomplish this. A couple of easy methods are
e-mail to a non-existant user (which will generate an NDR to the source
domain), spam e-mail with an external image, banner ads served from
another site, or perhaps triggering it from a bot network or installed
base of spyware.


Once the trigger executes, the victim's site DNS server queries the evil
DNS server. The attacker includes extra information in the DNS reply
packet. In this particular attack and the one from earlier in March,
the reply packets contain root entries for the entire .COM domain. If
your DNS server is not configured properly, then it will accept the new
entries for .COM and delete the proper entries for the Verisign
servers. Once this has occurred, any future queries that your DNS
server makes for .COM addresses will go to the malicious DNS server.
The server can give you any address it wants. In this attack, any
hostname that you request is returned with a single IP address.


The gory details are as follows... The site users are being re-directed
to displays a page advertising megapowerpills.com. Interesting, the
real IP address for www.megapowerpills.com is different and seems to
only host an "under construction" image. The malicious DNS servers have
the IP addresses of 222.47.183.18 and 222.47.122.203. There are
numerous domain names and nameservers that point to these IP addresses.
Here are some of the domain names pointing to the malicious DNS servers:


baronpill.com

bizwebb.us

cbarricadepill.com

cflabbergastgood.com

cnd-dns.us

disc0unt.us

ezcliq.us

m-dns.us

medauditory.com

medverdantgood.com

medverdigrisgood.com

medverdictgood.com

outfacegood.com

outregood.com

prostrategood.com

ururu.us

InfoCon Alert Status Calibration

We have received a couple of emails about our InfoCon Alert Status recently. As our alert has been at green so much of the time, there has been questions about how useful the InfoCon Alert really is. As we are talking internally about re-calibrating when we bring the alert status up the alert scales, we would be interested in hearing what our readers think would be the best use of the InfoCon Alert Status. For information on how we consider raising the alert, please take a look at <A href="http://isc.sans.org/infocon.php"> the InfoCon faq page. What would you like to see as our litmus test of changing the InfoCon? Please contact us through and let us know how things should work best for you.

NIST HIPAA Guide Released

One of the handlers noted today that a new guide had been released by NIST entitled "Special Publication 800-66: An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule". (Thanks George for pointing this out.) In light of some of the discussions earlier this week concerning log retention, I am planning on reading this guide and seeing what this guide says about the current best practices for log retention, and workstation security. For those that really love to read such things, this guide is available at <A HREF="http://csrc.nist.gov/publications/nistpubs/index.html#sp800-66"> http://csrc.nist.gov/publications/nistpubs/index.html#sp800-66 .
Scott Fendley

Handler on Duty