I wasn't sure if I wanted to send this considering the thrashing I took the last time I sent an email to this group, but here goes! -------- Original Message -------- Subject: [DISCUSS] OT Fwd: Analyzing the Mescaline Worm Date: Tue, 5 Aug 2003 12:56:50 -0500 From: MAOS <teck@charter.net> Reply-To: discuss@sluug.org To: discuss@sluug.org ---------- Forwarded Message ---------- Subject: Windevnet Security: Analyzing the Mescaline Worm Date: Tue, 05 Aug 2003 10:00:00 -0700 From: Windows Developer Network <security@windevnet.email-publisher.com> To: teck@charter.net Windevnet Security Newsletter August 5, 2003 Analyzing the Mescaline Worm Editor's Note: This is first issue of Windevnet Security, a new newsletter by Jason Coombs from Windows Developer Network. We're sending it to subscribers of the Windevnet Update Newsletter because we believe you'll value the information Jason will provide. If you wish to be removed from the Windevnet Security Newsletter mailing list, please click the "Unsubscribe" link at the bottom of this newsletter. A worm is about to destroy the Internet. Again. For the second time this year. The worm has been given a name in advance this time, like tropical storms that are sure to develop each season before a few become hurricanes. The name of this worm shall be Mescaline (http://securityfocus.com/columnists/174) It will target the now well-known vulnerabilities in Distributed Component Object Model (DCOM) that can be invoked remotely by way of Remote Procedure Call (RPC), as described in Microsoft Security Bulletin MS03-026 (http://www.microsoft.com/technet/security/bulletin/MS03-026.asp) and demonstrated by a variety of sample code and scanning utilities; see Resources. Beating Mescaline before it strikes is now a matter of patching Windows boxes and protecting vulnerable TCP/IP ports. The vulnerable DCOM code can be reached in many ways, both locally and remotely, such as through ports 135 (RPC), 139 (NetBIOS), and 445 (SMB) that are exposed by default on Windows boxes. Other TCP/IP ports also expose an interface to DCOM in configurations where services like RPC over HTTP (port 593) are available or in the case of nearly any custom code that uses DCOM for interprocess communication. Just as we would prepare our homes and businesses to weather a coming storm, first by building a secure foundation, sturdy frame, and reliable roof, and next by covering breakable glass and other unpreventable vulnerabilities with plywood until the storm passes, we all must stop whatever else we're doing and hurry to patch, protect, and repair our Windows boxes. While doing so, we should figure out how to prevent our work from causing this type of problem again so future storms remain small and the Internet weather bureau won't have to make a regular practice of naming things in advance. Note that the line of code that enables Mescaline isn't in DCOM, rather, it's in the network communications portion of RPC. The defective line of code causes RPC to bind TCP port 135 on the address of the default interface (0.0.0.0), which is also known as "all unassigned" or "INADDR_ANY." This binding is done instead of explicit bindings to each address supported by the box. This conserves memory, improves performance, and ensures that hardware configuration changes such as adding or removing network adapters that result in readdressing, or in the case of DHCP a preplanned dynamic addressing, don't result in network services that lose track of the current address to which they must bind in order to receive data over the network. A TCP/IP stack is also memory and performance sensitive, and conventional wisdom says that you err on the side of the small footprint when building a general-purpose network service like RPC that might need to communicate on many, if not all, network interfaces present on a box. As is often the case, this conventional wisdom is just plain wrong when you consider its security impact. A Windows box should not expose features that may allow remote execution of code, either intentionally or because of bugs, unless the Windows box is actively controlled, monitored, protected, and patched by its rightful owner. Mescaline would be virtually impossible today, despite the DCOM buffer overflow bug, if Microsoft had chosen not to force Windows to expose ports 135, 139, and 445 as listening TCP/IP endpoints. Microsoft made it extremely difficult, and in some cases impossible, to disable system components like RPC that bind these ports. Our software should only expose features we actually use when it binds to network endpoints. In order to use typical enterprise software packages under Windows, you must leave the default Windows services active, including components that expose remote services, even though you may never use these features remotely. They are often called locally as a mechanism for interprocess communication (IPC). The fact that RPC can be used instead of the Local Procedure Call (LPC) interface for IPC results in programmers building software that uses RPC when it should use LPC. They get away with it because it works. No registry settings or other configuration options can force RPC to stop binding to the default interface. This is apparently by design. Unsupported registry hacks are possible that remove all network interfaces while preserving some aspects of network functionality, or that simply bind the majority of services to the loopback adapter where they can only be addressed locally (IIS Security and Programming Countermeasures, Ch. 4: Platform Security, http://www.forensics.org/jasonc/iisforensics.zip). A supported registry setting was introduced in a Windows 2000 service pack, however, that will compel Windows to stop binding port 445 entirely. The registry entry is a DWORD of 0 (disable) or 1 (enable) located at the following key/value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\ SMBDeviceEnabled Disabling DCOM using dcomcnfg.exe helps to protect against remote exploits of the MS03-026 DCOM RPC vulnerability, but considering the extent to which Windows aggressively compels the presence of this type of system service, there are most likely other ways for it to be called, at least locally. MS03-026 is precisely the type of bug that is prone to return if service packs or hotfixes are reapplied in the future. As programmers, we must take a moment to appreciate the technical and business process failures that led to this vulnerability. A postmortem review of other people's compiled code isn't nearly as helpful to our collective knowledge of information security as is a detailed review of the vulnerable source code. Vendors of compiled code whose software is found to contain security flaws should publish a thorough forensic analysis of the source code that produced the vulnerability. Full disclosure both educates other programmers and reassures customers that the full extent of the vulnerability has been assessed accurately. Without full disclosure, and without access to the source code, we have no reason to trust the patched code any more than we trusted the original. And we can't disable its features. Resources http://www.securiteam.com/exploits/5CP0N0KAKK.html http://www.iss.net/support/product_utilities/ms03-026rpc.php http://www.eeye.com/html/Research/Tools/RPCDCOM.html http://www.lsd-pl.net/files/get?WINDOWS/win32_dcom --------------------------------------------------------------------- Jason Coombs works as forensic analyst and expert witness in court cases involving digital evidence. Information security and network programming are his areas of special expertise. He can be reached at jasonc@science.org. * * * * * * * * * * * * * * *Advertisements * * * * * * * * * * * * * * * A new "Anti-Spam White Paper" by Aladdin offers a comprehensive review of the problem and 16 advanced techniques for preventing spam. The paper focuses on in-depth, new information with minimal commercial product discussion. For your copy of the white paper, visit the Aladdin Web site. http://click.wd-mag.email-publisher.com/maabjQXaaZCBqb5V5Iib/ Limited Time Offer: Get Windows Developer CD-ROM 6 For Only $19.95! For a limited time offer the Windows Developer Network CD-ROM 6 is only $19.95 plus shipping and handling! CD-ROM 6 gives you all editorial content and source code from December 1991 through December 2002 issues. For more than 11 years Windows Developer Network has been the independent technical magazine for Windows programmers covering articles ranging from quick technical tips to ready to use solutions for complex programming problems. Place your order today! http://click.wd-mag.email-publisher.com/maabjQXaaZCBIb5V5Iib/ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The PDF edition of Windows Developer is now available online at http://click.wd-mag.email-publisher.com/maabjQXaaZCBAb5V5Iib/ ==================================================================== Update your profile here: http://security.u.tclk.net/survey/?b1dqFG.b5V5Ii.dGVja0Bj Unsubscribe here: http://security.u.tclk.net/survey/?b1dqFG.b5V5Ii.dGVja0Bj.u ------------------------------------------------------- ------- St. Louis Unix Users Group - http://www.sluug.org/ To unsubscribe from the SLUUG discussion mailing list, send a message to discuss-request@sluug.org with the word 'unsubscribe' as the body -- Duaine Hechler Piano, Player Piano, Organ, Pump Organ Tuning, Servicing & Rebuilding Associate Member of the Piano Technicians Guild Reed Organ Society Member St. Louis, MO 63034 (314) 838-5587 dahechler@charter.net
This PTG archive page provided courtesy of Moy Piano Service, LLC