|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
[Plug] interesting thing I came across today
|
--- 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. 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 / rfp@wiretrip.net ----------- ADM / wiretrip ---
So what if I'm not elite. My mom says I'm special.
--- Advisory RFP9906 ----------------------------- rfp.labs -----------
_______________________________________________
Plug maillist - Plug@lists.nothinbut.net
http://lists.nothinbut.net/mail/listinfo/plug
|
|