NT2K systems dying, LsaSrv EventID 5000

From: David Soussan (das_at_DASCOMPUTERCONSULTANTS.COM)
Date: 06/06/05

  • Next message: Cooper, Russ: "FW: MinorRev: Microsoft Security Bulletin MS05-025 - Cumulative Security Update for Internet Explorer (883939)"
    Date:         Mon, 6 Jun 2005 08:23:28 -0400
    To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
    
    

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

  • Next message: Cooper, Russ: "FW: MinorRev: Microsoft Security Bulletin MS05-025 - Cumulative Security Update for Internet Explorer (883939)"

    Relevant Pages

    • Re: Question on IIS servers and reverse lookup
      ... Have you tried disabling netbios over TCP/IP? ... There's a huge list of steps to take to secure an IIS ... server depending on the version. ... logs) in addition to the low-level packet capture. ...
      (Focus-Microsoft)
    • RE: Help! LsaSrv dies w/Event ID: 5000
      ... I don't know if it is for a new security ... for the nasty expoit to again be tested on the server) ... The attack vector is via an IIS packet which calls for authentication, ... I've correlated 4 occurrences of LsaSrv crashing with 4 incomming IIS ...
      (microsoft.public.win2000.general)
    • Re: Question on IIS servers and reverse lookup ... found answer
      ... netbios over TCP/IP on the interface your web server uses to talk to the ... There's a huge list of steps to take to secure an IIS ... logs) in addition to the low-level packet capture. ... packet is being sent to that UDP:137 port. ...
      (Focus-Microsoft)
    • Re: Question on IIS servers and reverse lookup
      ... Do you have Security Audit turned on and see Failure Events of the Logon/Logoff type timestamped at the same time when IIS tries to send the NetBIOS Name Resolution packet? ... Maybe these are authentication attempts against your IIS Server coming from the Internet and the IIS Server is sending a packet to destination asking for Domain Name? ... Source port: 137 ...
      (Focus-Microsoft)
    • [NT] Heap Overrun in HTR Chunked Encoding Could Enable Web Server Compromise
      ... This patch eliminates a newly discovered vulnerability affecting Internet ... in IIS 4.0 and 5.0, and could likewise be used to overrun heap memory on ... allowing code to be run on the server. ... * Microsoft has long recommended disabling HTR functionality unless there ...
      (Securiteam)