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 Vuln-Dev
[Top] [All Lists]

Re: [Full-disclosure] Fun with event logs (semi-offtopic)

Subject: Re: [Full-disclosure] Fun with event logs (semi-offtopic)
Date: Thu, 21 Dec 2006 16:28:40 +0100
There  is  interesting  thing  with  event  logging on Windows. The only
security  aspect  of  it  is  event log record tampering and performance
degradation,  but  it may become sensitive is some 3rd party software is
used for automated event log analysis.

I doubt this. The event logs don't contain the actual formatted string, because 
the template string is localized and only retrieved when the entry is displayed 
- what is logged is just a message id and the string inserts (see documentation 
for EVENTLOGRECORD). FormatMessage (which is used to build the full message to 
display to the user) isn't the culprit, either, because it doesn't operate 
recursively (that would have bizarre consequences, since FormatMessage also 
performs automatic line wrapping and indenting) - to prove it quickly and 
cheaply, make a copy of ntoskrnl.exe as "%1.exe" and try to run it: the error 
message you get back is prepared with FormatMessage (see kernel32, message 
table, entry 129), and it doesn't exhibit recursion

I think this is just a fairly minor bug/feature of the standard event log 
viewer, and wouldn't affect log analyzers, unless they implement this 
counterintuitive behavior (that was probably coded to support some pathological 
case where a single pass of formatting wasn't enough). But I expect log 
analyzers would rather work with the message source + id than the formatted 
display message, anyway

Most  services  do  not escape any user-supplied input then constructing
log  event.

They are not supposed to, in fact that would damage the log. A human being 
might be fooled (for example you could embed newlines and fake fields in 
multi-line messages), but an automatic analysis tool will always see exactly 
the parameters passed


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

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