OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NTSecAdvice Archives: Re: RFP9906 - Services.exe DoS in NT 4 (R

Re: RFP9906 - Services.exe DoS in NT 4 (RFPoison)


Chris (chrisCYBERBOOKIES.COM)
Mon, 1 Nov 1999 10:10:35 -0500


I tried to access your URL but get the following message:

y0 y0 flipz and fuqrag was here hehe .. wait .. this box don't have rds on
it .. we can't hack no .gov box and stuff without rds oh well go checkout
the cool shit (like whisker) on .r.f.p.'s website

Is this a joke?

> -----Original Message-----
> From: .rain.forest.puppy. [mailto:rfpWIRETRIP.NET]
> Sent: Monday, November 01, 1999 9:08 AM
> To: WIN2KSECADVICELISTSERV.NTSECURITY.NET
> Subject: RFP9906 - Services.exe DoS in NT 4 (RFPoison)
>
>
> --- Advisory RFP9906 ----------------------------- rfp.labs -----------
>
> Windows NT remote denial of service and compromise
> (RFPoison)
>
> ------------------------------ rain forest puppy / rfpwiretrip.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 > install history of that particular system. Email to rfpwiretrip.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. Seems
> fair enough.
>
> - 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 / rfpwiretrip.net ----------- ADM / wiretrip ---
>
> So what if I'm not elite. My mom says I'm special.
>
> --- Advisory RFP9906 ----------------------------- rfp.labs -----------
>



This archive was generated by hypermail 2.0b3 on Mon Nov 01 1999 - 09:43:00 CST