Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security NTBugtraq
[Top] [All Lists]

Re: NT2K systems dying, LsaSrv EventID 5000

Subject: Re: NT2K systems dying, LsaSrv EventID 5000
Date: Wed, 15 Jun 2005 14:32:49 -0700
While your waiting for microsoft...

Without a network packet capture, I will take a guess that your system is 
beiing hit either by the recently surfaced worm/exploit for the ASN vulns 
published a while back. There was an exploit written by Solar Eclipse for ASN 
that has finally been publicly released and recently someone took this exploit 
and piggy backed it to turn it into a rather lame ASN Worm. The reason I think 
this is what your experiencing is by the symptons you described. http was being 
used by the exploit/worm, and the ASN would be triggered through the 
negotiation request, which is then handed off to lsa, hence the crash there 
instead of in iis itself. You can read about these symptoms on the incidents 
mailing list.

Again just taking a guess, well have to all wait and see what the experts at 
microsoft have to say.

-Marc Maiffret

P.s. You can go read more about the ASN flaws on our website www.eeye.com 
although you should note that the specific ASN flaw being exploited was 
silently fixed by microsoft in the patch they created for us which is why most 
ids/ips do not detect the attack genrically, because they didn't know about it. 
Core Impact and Canvas have had ASN exploits in there tools for a while now. 
Another case of people thinking something isn't a problem just because THEY 
don't see it.

-----Original Message-----
From: Windows NTBugtraq Mailing List <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM>
Sent: Mon Jun 06 05:23:28 2005
Subject: NT2K systems dying, LsaSrv EventID 5000

Greetings;

Summary: Someone is testing a new exploit, most likely one fixed by MS04-11
though Microsoft should confrm this sometime today. If you have an NT2K
machine with IIS running open on port 80 facing the internet and have not
patched your system, you will most likely see this exploit knock on your
front door.

Prior to 6/1/05, the MS04-11 holes were not exploited via port 80 & IIS.

Details:

Windows Server 2000 / SP4 / not fully security patched is affected.
Windows Server 2000 / SP4 / fully security patched - not yet known (I've
been waiting patiently for the offending packet to re-arrive, but whoever
was testing this exploit stopped for awhile)
Windows Server 2003 / IIS 6.0 is not affected.

The attack vector is via an IIS packet which calls for authentication, hands
it a whole lot of data, and crashes LsaSrv that instant. Requires a server
reboot to bring the 2K Server back online.

I've captured the offending packets and turned them over to Microsoft
awaiting analysis.

How to know if you've been hit:

The crash event in the event log follows:

Event Type:     Error
Event Source:   LsaSrv
Event Category: Devices 
Event ID:       5000
Date:           6/3/2005
Time:           7:38:06 AM
User:           N/A
Computer:       <your server name here>
Description:
The security package Negotiate generated an exception.  The package is now
disabled. The exception information is the data. 
Data:
0000: 05 00 00 c0 00 00 00 00   .......
0008: 00 00 00 00 18 f2 55 78   .....Ux
0010: 02 00 00 00 00 00 00 00   ........
0018: 0c 00 00 00 3f 00 01 00   ....?...
0020: 00 00 00 00 00 00 00 00   ........
0028: 00 00 00 00 00 00 00 00   ........
0030: 00 00 00 00 00 00 00 00   ........
0038: 7f 02 ff ff 00 00 ff ff   ...
0040: ff ff ff ff 00 00 00 00   ....
0048: 00 00 00 00 00 00 00 00   ........

At the exact same date / time LsaSrv died, a log entry in the IIS logs that
looks something like this:

(assuming MS IIS log format, yours might differ)

66.54.153.162, -, 6/3/2005, 7:38:06, W3SVC1, SERVER-E, 192.168.1.2, 110,
5699, 1 82, 500, 2148074244, GET, /, -,

The error code back from IIS of 2148074244 is not right. The inbound packet
size of 5699 is a key indicator this exploit has knocked on your front door.

Note: This is for the variant of the exploit that was being tested late last
week and crashes LsaSrv. I believe (but have no hard data to verify) this
was someone testing an exploit that didn't quite work, causing the crash.
He/She is probably fixing this so the exploit is more useful. So if you are
curious if you've seen this exploit knock on your door, search your logs for
the 5699 incomming packet size.

I believe we're seeing the field testing of a new exploit. The input vector
is via a public facing IIS port 80. The packet gets IIS to try and do an
SNMPv2-SMI::security.5.2 authentication (AKA: "SPNEGO - Simple Protected
Negotiation") When the oversized packet (it is filled with "AAAAAAA...AAAA"
to pad the buffer out) is handed around to various windows processes,
apparently that overflows a buffer and does some other damage. I'm not sure
what that other damage is -- there are some responses in various newsgroups
where some people are saying they've got other processes running on their
system now.

More to come as I find out.

-----
David Soussan

--
NTBugtraq Editor's Note:

Most viruses these days use spoofed email addresses. As such, using an 
Anti-Virus product which automatically notifies the perceived sender of a 
message it believes is infected may well cause more harm than good. Someone who 
did not actually send you a virus may receive the notification and scramble 
their support staff to find an infection which never existed in the first 
place. Suggest such notifications be disabled by whomever is responsible for 
your AV, or at least that the idea is considered.
--

<Prev in Thread] Current Thread [Next in Thread>