RFP9906.txt

`  
From [email protected] Mon Nov 1 09:20:06 1999  
Date: Mon, 1 Nov 1999 08:18:50 -0600 (EST)  
From: ".rain.forest.puppy." <[email protected]>  
To: [email protected], [email protected]  
Subject: RFP9906 - RFPoison  
  
  
  
--- Advisory RFP9906 ----------------------------- rfp.labs -----------  
  
Windows NT remote denial of service and compromise  
(RFPoison)  
  
------------------------------ rain forest puppy / [email protected] ---  
  
Table of contents:  
- 1. Problem  
- 2. Solution  
- 3. Where to Get This Weapon of Mass Destruction  
- 4. Miscellanous Updates (Important stuff!)  
  
-----------------------------------------------------------------------  
  
My website has been launched! Up to the minute advisories, tools, (and  
code fixes...heh) are available from http://www.wiretrip.net/rfp/  
  
-----------------------------------------------------------------------  
  
----[ 1. Problem  
  
Interesting on how things go around/come around. Recently Luke   
Kenneth Casson Leighton posted a message on NTBugtraq in response to SP6  
not fixing the LSA denial of service. He states that this problem is  
essentially "due to marshalling/unmarshalling MSRPC code being unable to  
cope with a NULL policy handle." He also states that they reported this  
problem to Microsoft around February 1999.  
  
Well, no, I did not 'rediscover' the LSA denial of service (ala  
the AEDebug advisory earlier this month). I did, however, discover a  
different denial of service based out of services.exe. When sent a  
specific packet, it's possible to get srvsvc.dll to choke, and cause  
services.exe to reference a bad memory location. For those geeks in the  
crowd, essentially srvsvc_netrshareenum in srvsvc.dll uses  
rpcrt4_ndrcomplexstructunmarshall to tweak a string, but returns a NULL.  
srvsvc_netrshareenum doesn't check for return value, adds four to the  
pointer, and passes it up a function stack until finally that memory is  
read (address 00000004). Blam...Dr. Watson.   
  
So we have another problem due to marshalling/unmarshalling MSRPC  
code. This was found independantly of Luke's info and the LSA  
vulnerability.  
  
The impact is pretty severe. Services.exe handles named pipes for  
the system. Once this crashes, everything named-pipe-based goes with it.  
This means logons, logouts, remote system access (registry, server  
functions, etc), local server management, IIS, file sharing, etc...all go  
down the tube. However, the box will, for the most part, appear to  
function normally on the local side, until you do something involving a  
named pipe service. The only fix is to reboot...however, the shutdown  
procedure waits for every (non-existant) service to respond to shutdown,  
and timeout. On a typical box this could cause the full shutdown  
procedure to push over a half-hour; therefore, hard reset is most likely  
needed. Also, once in a great while the bug will 'survive' during a  
reset. It may take two reboots to get the system back in order. Strange,  
yes. How, I'm not sure. But it's happened over a half dozen times across  
four separate boxes I've tested on.  
  
Now, I'm sure some of you are thinking "well, denial of services  
suck. How can I own .gov and .mil websites with this?" (hi flipz and  
fuqrag)  
  
Well, let's go back to David LeBlanc's response to RFP9903  
(AEDebug advisory). He states, for AEDebug to really be a problem, you  
have to "make something crash that has higher access rights than you do."   
He also states "you've got to make a service go down that won't kill the  
machine."   
  
Bingo, this fits the bill. If we have access to change the  
AEDebug registry key, we can set what programs to run on crash, set  
autorun to True, and then crash services.exe. Our programs run as  
Local_System, the box is still alive (TCP/IP-wise) and usable via netcat  
and whatnot. A much more useful situation for a denial of service, don't  
you think?  
  
Also, Eric Schultze has detailed out many situations where someone  
could have access to your AEDebug key. I suggest you read his tidbit.  
It's posted as document 11 in the knowledge base on my website, available  
at http://www.wiretrip.net/rfp/  
  
So far, I have been able to use this exploit on NT 4.0 server and  
workstation, with various levels of SP 1, 3, 5, and 6 service packs  
installed. I even tried applying SP 5 with the following hotfixes (in the  
following order): lsareq, ipsrfix, csrssfx, ioctlfx, and igmpfix. I've  
also tried using the Security Configuration Editor on various different  
'secure' system profiles, testing to see if perhaps a registry key  
affected it. After all modifications, the systems were still susceptible.  
HOWEVER, I do have reports of two boxes *NOT* being susceptible. The  
reason for this, however, is unfound. Information will be released when  
it is found. If you come across a situation where a box is impervious to  
the exploit, PLEASE EMAIL ME. I would really appreciate the entire  
install history of that particular system. Email to [email protected].  
  
  
----[ 2. Solution  
  
Well, as previously stated, Luke and ISS informed Microsoft of the  
LSA vulnerability in February 1999. To be fair, I also reported this  
exact bug, along with the working exploit, to Microsoft on Oct 25th. Have  
not hear a word. So, in the meantime, I can recommend two things:  
  
- Block port 139 on your firewall. This, however, does not stop internal  
attack.  
  
- Turn off the Server service. While inconvenient, this should be deemed  
as a temporary solution until Microsoft releases a patch. Just for  
reference, shutting off the Server service will also shut down the  
Computer Browser service. Glitch, a fellow Wiretrip member, describes the  
functions of these services as follows:  
  
SERVER: Used as the key to all server-side NetBIOS applications, this  
service is somewhat needed. Without this service, some of the  
administrative tools, such as Server Manager, could not be used. If remote  
administration is not needed, I highly recommend disabling this service.  
Contrary to popular belief, this service is NOT needed on a webserver.  
  
COMPUTER BROWSER: The Computer Browser service is a function within  
Microsoft networking for gathering and distributing resource information.  
When active on a server, the server will register its name through a  
NetBIOS broadcast or directly to a WINS server.   
  
So you should note that turning these services off will disable the server  
from participating in NetBIOS-related functions, including file sharing  
and remote management. But realistically, how many servers need this?  
Alternate means of content publishing (for webservers) exist (FTP and  
-ugh- FrontPage). Of course this leaves the myriad of other services  
though. I'd be interested to see how MS SQL fairs.  
  
It's hoped that between the services.exe and the lsass.exe denial of  
services, both based on bad RPC code, Microsoft will find this problem  
worthy of fixing.  
  
Now we wait...  
  
  
----[ 3. Where to Get This Weapon of Mass Destruction  
  
I use this title jokingly. But trust me, I have gone back and  
forth about the release of this exploit. However, as a proponent of full  
disclosure, I definately will release a working exploit. But I do so with  
conditions:  
  
- I will only release a Windows executable.  
  
- The windows executable is coded to reboot (NT) or crash (9x) upon  
successful execution. If you blow something up, you blow up too.  
  
- A few checks that keep the program from running if you run in a user  
context that does not allow the above 'safety features' to work.  
  
But it is a working executable. I'm hoping this will at least curb the  
script kiddie activity. Of course, I'm sure this program will be reversed  
and a new version made within 6 hours of posting--but that's not my  
problem. This should be more than enough to verify/test the exploit, and  
I've provided the details of how it works and the solutions necessary for  
stopping it. The skilled will be able to go off this, and the, well, the  
abusers will hit the glass ceiling as intended. Thanks to Vacuum for  
helping me come up with a responsible solution.  
  
Also, I want to make it very clear, before I tell you where to get the  
executable....  
  
DO NOT ASK ME FOR SOURCE.  
DO NOT ASK ME FOR SOURCE.  
DO NOT ASK ME FOR SOURCE.  
DO NOT ASK ME FOR SOURCE.  
DO NOT ASK ME FOR SOURCE.  
DO NOT ASK ME FOR SOURCE.  
DO NOT ASK ME FOR SOURCE.  
  
oh, and  
  
DO NOT ASK ME FOR SOURCE.  
  
  
I don't care who you are. All email asking for source will be instantly  
deleted. I don't care if you send me the secret to life--if it has "p.s.  
can I get the source?" I will pipe that thing to /dev/null, along with  
whatever goodies you may have sent me. Don't even joke; you won't get a  
reply.  
  
Now that that's established, you can download RFPoison.exe from my  
website (of course) at http://www.wiretrip.net/rfp/  
  
  
  
----[ 4. Miscellaneous Updates (Important stuff!)  
  
  
- whisker 1.2.0 has been released! Includes the ability to bounce scans  
off of AltaVista (thanks to Philip Stoev) Plus some new feature additions,  
and new scan scripts, including a comprehensive script for scanning  
FrontPage (thanks to Sozni).  
  
- flipz and fuqrag have been busy hacking .gov and .mil sites. Turns out  
they're using a vanilla copy of msadc2.pl. Check out msadc2.pl (their  
exploit) at my website.  
  
- Zeus Technologies had an outstanding response to RFP9905. In under 12  
hours they had a patched version available, and were all-around terrific in  
their private and public response. As an indication of how they do  
business, I would recommend Zeus Technologies as a vendor to anyone. Kudos  
for them.  
  
- technotronic and rfp.labs have teamed up! We're going to combine a couple  
of resources--starting with the mailing list. Technotronic already puts out  
some good info on his list...now I'll be giving the same list up to date  
information on rfp.labs advisories, information, and other various cool  
info. If you're not on it already, you may consider joining. Signup at  
www.technotronic.com  
  
- with the (sad?) end of octoberfest, I'm also pleased to see w00w00 take  
over with 'w00giving'--all through the month of November w00w00 will be  
releasing some more stuff! You can start looking for the first (of many)  
advisories today (Nov 1st).  
  
Special greetings to Simple Nomad (and others) on this special day where  
the wheel finishes its cycle and starts its revolution anew.  
  
  
  
--- rain forest puppy / [email protected] ----------- ADM / wiretrip ---  
  
So what if I'm not elite. My mom says I'm special.  
  
--- Advisory RFP9906 ----------------------------- rfp.labs -----------  
  
`