--- Advisory RFP9906 ----------------------------- rfp.labs ----------- Windows NT remote denial of service and compromise (RFPoison) ------------------------------ rain forest puppy / rfp@wiretrip.net --- 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 rfp@wiretrip.net. ----[ 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 / rfp@wiretrip.net ----------- ADM / wiretrip --- So what if I'm not elite. My mom says I'm special. --- Advisory RFP9906 ----------------------------- rfp.labs -----------