This is not a usual tutorial, but more of a “description of events” of the past few days. It began when Microsoft issued this bulletin.
Microsoft originally released this bulletin and patch on July 16, 2003 to correct a security vulnerability in a Windows Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) interface. The patch was and still is effective in eliminating the security vulnerability.
However, the “mitigating factors” and “workarounds” discussions in the original security bulletin did not clearly identify all of the ports by which the vulnerability could potentially be exploited. We have updated this bulletin to more clearly enumerate the ports over which RPC services can be invoked, and to ensure that customers who have chosen to implement a workaround before installing the patch have the information that they need to protect their systems. Customers who have already installed the patch are protected from attempts to exploit this vulnerability, and need take no further action.
Remote Procedure Call (RPC) is a protocol used by the Windows operating system. RPC provides an inter-process communication mechanism that allows a program running on one computer to seamlessly execute code on a remote system. The protocol itself is derived from the Open Software Foundation (OSF) RPC protocol, but with the addition of some Microsoft specific extensions.
There is a vulnerability in the part of RPC that deals with message exchange over TCP/IP. The failure results because of incorrect handling of malformed messages. This particular vulnerability affects a interface with RPC, which listens on RPC enabled ports. This interface handles DCOM object activation requests that are sent by client machines to the server. An attacker who successfully exploited this vulnerability would be able to run code with Local System privileges on an affected system. The attacker would be able to take any action on the system, including installing programs, viewing changing or deleting data, or creating new accounts with full privileges.
To exploit this vulnerability, an attacker would need to send a specially formed request to the remote computer on specific RPC ports.
Mitigating factors:
To exploit this vulnerability, the attacker would require the ability to send a specially crafted request to port 135, 139, or 445 or any other specifically configured RPC port on the remote machine. For intranet environments, these ports would normally be accessible, but for Internet connected machines, these would normally be blocked by a firewall. In the case where these ports are not blocked, or in an intranet configuration, the attacker would not require any additional privileges.
- Best practices recommend blocking all TCP/IP ports that are not actually being used, and most firewalls including the Windows Internet Connection Firewall (ICF) block those ports by default. For this reason, most machines attached to the Internet should have RPC over TCP or UDP blocked. RPC over UDP or TCP is not intended to be used in hostile environments such as the Internet. More robust protocols such as RPC over HTTP are provided for hostile environments. To learn more about securing RPC for client and server please refer to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/writing_a_secure_rpc_client_or_server.asp.
To learn more about ports used by RPC, please refer to: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappc.asp.
Severity Rating
Windows NT 4.0 Critical Windows NT 4.0 Terminal Server Edition Critical Windows 2000 Critical Windows XP Critical Windows Server 2003 Critical
The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.
Vulnerability Identifier CAN-2003-0352
Tested Versions
Microsoft tested Windows Me, Windows NT 4.0, Windows NT 4.0 Terminal Services Edition, Windows 2000, Windows XP, and Windows Server 2003 to assess whether they are affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by this vulnerability.
Microsoft thanks The Last Stage of Delirium Research Group for reporting this issue to us and working with us to protect customers.
Description of Events
For a detailed analysis of this exploit, see: http://www.xfocus.org/documents/200307/2.html.
I’ve never seen an exploit develop so quickly in my life. The hacker underground was rocked for 4 whole days. It was a gruesome sight – machines we’re being “Dropped” (hacked) at an insane rate. It was obvious that a large majority of computers were still not patched.
I watched sadly, as the Internet was being violated, innocent victims becoming the unsuspecting targets of over hormone-ized teenage kids. One by one they fell, while the hackers slaved relentlessly to gain control over more and more machines. At some stage, I even saw an IRC channel that had the topic “RPC – DCOM – Leave some for the worm!”. There was nothing I could do, except to warn everyone I knew.
The first exploit released by Xfocus was rather anticlimactic, as it was found to be a DOS attack, and not the promised SYSTEM shell. However, redemption was soon to come as Metasploit published a fixed fully working exploit, a few days later.
This was quickly compiled for windows and a working version was made public:
From this stage onwards, all hell broke loose. In a matter of hours, more universal offsets were published, and more advanced exploits were sent to the wild, which in turn would affect a larger variety (targets) of machines. Like mushrooms after the rain, newer versions of the exploit were being released; 9 targets, 18 targets, 29 targets, 48 targetsand thenthe nightmare became real. A universal RET address was found for both Windows XP and Windows 2000 (0x0100139d and 0x010016c6 respectively). This is what the hacker community was waiting for. An easy to use, 99% working fully blown universal exploit for Windows 2000 (upto SP4) and Windows XP (upto SP1).
With the RPC vulnerability scanners that were published by Eeye and ISS, the internet suddenly turned into an African savannah, with supercharged predators, and sick, weak prey.
An apocalyptic mood fell upon me, when I realized the implications of this. “Oy Vey,” I thought to myself, and went to sleep with a sigh.
Quite soon it was clear that the exploit was not flawless. It seemed to reboot the machines after one minute. A deeper inspection of this revealed that the RPC service crash would indeed result in a reboot, as can be seen on a Windows XP computer.
This meant that the hacker had little time to do his deed before the machine rebooted, and he’d lose control over it.
The community did not give up, and in a matter of hours the source code was modified to open a port (4444) on the target machine, without rebooting it. Not surprisingly this exploit was called rpc_univ_nocrash.exe.
Conclusions
For the sake of humanity, PATCH YOUR MACHINES!
If you have a few machines or a network; consider using SUS (it’s free!).
Mati Aharoni, MCSES, MCT, CCNA, CCSA, CISSP
Visit the Security through Hacking Web site at http://www.secureit.co.il for additional information.
