| Captus Networks
Stop DDoS Attacks, Worms & Port Scans
See
how with our live, hands-on
demo & FREE Vulnerability
Assessment Toolkit.
Integrated Intrusion Prevention and Traffic Shaping to Monitor & Secure Mission
Critical IP Networks
> Instantly
Stop DDoS Attacks, Worms & Port Scans
> Automatically
Control P2P, IM and Spam Traffic
FREE White
Paper: click here
"Securing
and Optimizing Traffic for Enterprise Networks"
|
|
08.14.03
 By Mati
Aharoni
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: http://www.microsoft.com/technet/treeview/? url=/technet/security/bulletin/MS03-026.asp
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.
Join our new forums at WebProWorld! Ask
your toughest questions or help your peers solve their issues. |
|
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 targets…and then…the 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!).
About the Author:
Mati Aharoni, MCSES, MCT, CCNA, CCSA, CISSP
Visit the Security through Hacking Web site at http://www.mutsonline.com
for additional information.
Read this newsletter at: http://www.securitypronews.com/2003/0814.html |
|
|
|
