Главная страница


ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : NiK                                  2:5020/968.79  05 May 2000  12:52:08
 To : Alexey Kozakov
 Subject : NetBios
 -------------------------------------------------------------------------------- 
 
  AK> Кто этот rfp?
 
 From rfp@wiretrip.net Mon Nov  1 09:20:06 1999
 Date: Mon, 1 Nov 1999 08:18:50 -0600 (EST)
 From: ".rain.forest.puppy." <rfp@wiretrip.net>
 To: vacuum@technotronic.com, thegnome@nmrc.org
 Subject: RFP9906 - RFPoison
 -+- 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 -----------
                 C уважением, Nikita Kuznezov.
 
   np:  Winamp is not active ( only cooler work ;)
 
 ... [Team THE DOORS] [FidoNET USE \\GolDEd+/386 1.1.4 ] [Team Beginner]
 --- GoldED+/386 1.1.4.3
  * Origin: -----====>}[TEAM Kn0pKa]{<====----- My Address - (2:5020/968.79)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

 Тема:    Автор:    Дата:  
 NetBios   Alexey Kozakov   04 May 2000 22:53:45 
 NetBios   NiK   05 May 2000 12:52:08 
 NetBios   NiK   05 May 2000 12:53:14 
 NetBios   Oleg Ivanov   06 May 2000 15:30:02 
Архивное /ru.nethack/241733912c417.html, оценка 3 из 5, голосов 10
Яндекс.Метрика
Valid HTML 4.01 Transitional