RE: Writing to Windows Security Log

From: Brass, Phil (ISS Atlanta) (PBrassat_private)
Date: Fri Dec 07 2001 - 04:41:02 PST

  • Next message: Alfred Huger: "Sluggish moderation until January."

    I don't know of a specific tool, but I can tell you that there are a variety
    of functions designed to allow a "private" service (one which is managing
    security on it's own objects (imagine a database with actual DACL's on its
    tables)) to audit access (as long as SE_AUDIT_NAME is enabled).
    
    Functions like AccessCheckAndAuditAlarm, PrivilegedServiceAuditAlarm, etc.
    are used for an application to generate what are probably standard access
    error messages in the security event log.
    
    Unfortunately, there is a limited set of these functions - for example I
    can't generate password changed messages, or logon failure messages, etc.
    To do that would require a little bit of reverse engineering of
    msaudite.dll, which I believe is the message DLL for the logon system.
    Probably opening this in a resource decompiler like reshack would give
    enough information (i.e. message IDs) that you could generate any standard
    security audit message you want (again, assuming you had SE_AUDIT_NAME).
    
    Phil 
    
    -----Original Message-----
    From: Tina Bird [mailto:tbird@precision-guesswork.com]
    Sent: Wednesday, December 05, 2001 4:16 PM
    To: Mr Rufus Faloofus
    Cc: pen-testat_private; jon.bullat_private;
    marvin.marinat_private; tbird@precision-guesswork.com
    Subject: Re: Writing to Windows Security Log
    
    
    Let me provide more details.
    
    We all understand that one of the big problems with
    UNIX syslog-the-network-protocol is that it's UDP -
    not authenticated, not reliable.  An evildoer who
    wants to make my logs less trustworthy can easily
    send bogus data to my central loghost, at a minimum
    introducing nonsense into my audit stream, and at 
    a maximum, knocking the loghost off line.
    
    As explained below, a Windows application or service
    that registers itself with the Event Log service can
    write messages to the Windows System and Application
    Logs.  So one way for me to introduce a roughly 
    equivalent source of bogus data into an Event Log stream
    is to register an illegitimate application with 
    associated DLL with the Event Log service.  I expect
    that's a relatively straightforward thing to do, given
    how easy it is to install back doors on Windows boxes --
    although one doesn't typically write back doors with lots
    of logging capabilities, it might make sense to create
    a program that muddied up the logs.
    
    However, the only things on a Windows box that can write
    to the >Security< Event Log are the LSA and the Event
    Log service itself, which have the SeAuditPrivilege.
    This suggests that the Security Event Log has a much
    higher level of assurance than anything in the off-the-shelf
    UNIX world.
    
    This conclusion startled me ;-) so I figured I'd ask this
    group if anyone knew of a tool that would get around
    this access restriction.  Does that clarify what I'm
    after?
    
    thanks -- tbird
    
    On Wed, 5 Dec 2001, Mr Rufus Faloofus wrote:
    
    > At 07:26 PM 12/4/01 -0600, Tina Bird wrote:
    > >Anyone out there have a tool that allows me to
    > >forge Windows Security Event Log data?
    > 
    > Depends what you mean by "forge," and what kind of access
    > you have to the machine.  To log an event, the Right Way is 
    > to register a DLL with your messages in it.  It's not hard 
    > (see LOGEVENT.EXE from the resource kit, or section 15.2 in
    > Marshall Brain's Win32 SYSTEM SERVICES: The Heart of Windows
    > 95 and Windows NT [Prentice Hall PTR: NJ]: 1996), and you 
    > can roll your own.
    > 
    > But these don't "forge" events, in the sense that the 
    > events they record are legitimate messages, and don't appear
    > to come from bogus sources.  So, for example, if you want
    > to insert an apparent IIS message into a log (not using
    > IIS), this would be hard.  Also, we're assuming, so far,
    > that you have NetBIOS access to the machine in question.
    > 
    > If you want to insert arbitrary false messages into the
    > files, that's complicated: the logging API doesn't permit
    > it, and you'd be relegated (I think) to either finding a
    > flaw in it-- like the recent discussions involving URLs 
    > with special characters embedded in them (but related to
    > the security log, instead of the application log), or to
    > programmatically editing the log files (which also is
    > tricky, I bet).
    > 
    > Does this help at all?
    > 
    > --Foofus.
    > 
    > 
    
    
    
    
    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
    Service. For more information on SecurityFocus' SIA service which
    automatically alerts you to the latest security vulnerabilities please see:
    https://alerts.securityfocus.com/
    
    ----------------------------------------------------------------------------
    This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
    Service. For more information on SecurityFocus' SIA service which
    automatically alerts you to the latest security vulnerabilities please see:
    https://alerts.securityfocus.com/
    



    This archive was generated by hypermail 2b30 : Mon Dec 10 2001 - 11:53:55 PST