Problem with security package Negotiate generated an except

I came across this article and it seems to solve the problem, most versions of IIS5 (win2kAdvanced Server) run the default web server on port 80, the solution seems to be to run IIS webs on an alternate port or if running multiple servers, to disable or change the default server to a different port. I noticed on startup my firewall was telling me tftp wanted net access, stopping it, ftp wanted net access, and each of my ftp servers log files had an identical ip entry at the same times a minute apart,obviously someone was trying all ports for ftp access, also noticed my event viewer was posting failed logons with various accounts, mssql, Iuser, asp etc...on disabling these accounts my server then proceeded to crash every hour. Obviously somewasa trying a hack, probably on sql server data to see what it contained. Another item to perhaps watch is spam in guestbooks, on blocking ip addys that were spamming my guest books, the other problem then occurred - my guess being maybe spammers try to access servers running guestbooks then try to use same to spam other places, failing, then try alternate hacks on the system.
On disabling default web (closing port 80) or changing the port - it now runs fine. All other webs I have run on alternate ports and 80 is never used as a working web on my machines. The article below makes sense because if you disable all accounts except Iuser, and close everything except port 80 - then data coming into port 80 only has to be the cause. Another good option is to change the admin accont name and use a alphanumeric password of at least 7 characters. Microsoft does not appear to have any patches and calling their tech support (I've tried) is totally useless. Simply close port 80 by running the web on a different port. Internet services manager/properties/tcp port. (Change 80 to some other number)

Anyhow here is the article and source:

http://www.networksecurityarchive. [...] 00020.html

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.
--