* DNS Cache Poisoning Report; Increase in Port Activity

Published: 2005-04-03
Last Updated: 2005-04-04 03:36:51 UTC
by Marcus Sachs (Version: 1)
0 comment(s)
<H3>DNS Cache Poisoning Detailed Analysis Report.</H3> We are flashing the ISC alert tool ( http://www.labreatechnologies.com/ISCAlert.zip ) to draw our readers to a new report written by handler Kyle Haugsness and several other handlers. This excellent report discusses what they found so far with respect to the DNS cache poisoning we reported over the past several days. The summary of the report is below, and the remainder of the report is at http://isc.sans.org/presentations/dnspoisoning.php



Summary

Around 22:30 GMT on March 3, 2005 the SANS Internet Storm Center began receiving reports from multiple sites about DNS cache poisoning attacks that were redirecting users to websites hosting malware. As the "Handler on Duty" for March 4, I began investigating the incident over the course of the following hours and days. This report is intended to provide useful details about this incident to the community.



The initial reports showed solid evidence of DNS cache poisoning, but there also seemed to be a spyware/adware/malware component at work. After complete analysis, the attack involved several different technologies: dynamic DNS, DNS cache poisoning, a bug in Symantec firewall/gateway products, default settings on Windows NT4/2000, spyware/adware, and a compromise of at least 5 UNIX webservers. We received information the attack may have started as early as Feb. 22, 2005 but probably only affected a small number of people.



On March 24, we received reports of a different DNS cache poisoning attack. This attack did not appear to affect as many people. This will be referred to as the "second attack" in the remainder of this report.



After monitoring the situation for several weeks now, it has become apparent that the attacker(s) are changing their methods and toolset to point at different compromised servers in an effort to keep the attacks alive. This attack morphed into a similar attack with different IP addresses that users were re-directed toward. This will be referred to as the third attack and is still ongoing as of April 1, 2005.



Before proceeding, a note of thanks is in order for all the people that have submitted reports to us, helped us investigate further, and provided us logs or data. The Internet Storm Center is a volunteer effort and the better information that we receive from the community, the better analysis we can perform and contribute back to the community.



Contents:



1. How can others help?

2. How do I recover from a DNS cache poisoning attack?

3. What software is vulnerable?

4. I am a dial-up/DSL/cable modem user -- am I vulnerable?

5. Where can I test my site to see if I am vulnerable?

6. What exactly is DNS cache poisoning?

7. What was the motivation for this type of attack?

8. Weren't DNS cache poisoning attacks squashed around 8 years ago?

9. What was the trigger for the attack?

10. How exactly did this DNS cache poisoning attack work?

11. What domain names were being hijacked?

12. What were the victim sites?

13. What malware was placed on my machine if I visited the evil servers?

14. Got packets?

15. Got snort?



Read the rest of the report at http://isc.sans.org/presentations/dnspoisoning.php



<H3>Increase in Port Activity.</H3> Arno wrote us today to draw our attention to two ports that have shown a big increase in activity in the past few days. Check out ports 8082 (BlackIce Capture) and 20031 (BakBone NetVault). Notice that the 8082 traffic is largely UDP, comes from several thousand sources, but is aimed at less than 200 targets. There is a known issue with NetVault, which accounts for all of the 20031 scanning, but what is going on with BlackIce?


http://isc.sans.org/port_details.php?port=8082

http://isc.sans.org/port_details.php?port=20031


<H3>San Diego SANS Conference</H3>
It has come to our attention that the DNS servers for the hotel where the San Diego SANS conference is being held are possibly poisoned. The best recommendation we can offer until we can fix/correct this, is to use a public DNS server that is not vulnerable, such as:


4.2.2.1

4.2.2.2

4.2.2.3





Marcus H. Sachs

Handler on Duty

Director, SANS Internet Storm Center


Keywords:
0 comment(s)

Comments


Diary Archives