Harlan, et al
Indeed, it requires some access to the machine to start with, but I don't
think you'd need too much in the way of initial rights.
I compare it with the other well known way of compromising the logon prompt,
the "rename CMD.EXE for LOGON.SCR and wait around for 10 minutes for a LOCAL
SYSTEM context command line to appear". It struck me that since WFP arrived,
it might be easier to cause a service/driver to fail in any one of a variety
of ways and hit the event sink instead.
This isn't one of those "media darling" type attacks where some spotty oik
can own you in 4 seconds from his remote location, this is more your
escalation of rights by an in-house script kiddie or downloaded trojan - aka
"boring, but important".
If this was done by an automated trojan, then it could hide the MSGINA and
display it's own logon prompt then popup a "wrong password" message, exit
and display the real MSGINA while storing your username, password and domain
for later use or transmission. You think you typed your password in wrong
and are none the wiser.
Another good reason for looking at the event sink as a weak point is that
the sink has been around since the early days of NT, and as a non-primary
bit of code is less likely to have gone through the 2002 Trustworthy
Computing Initiative that delayed Windows 2003 by 6 months - and more likely
to be insecure.
Cheers
James
James D. Stallard, MIoD
Infrastructure Technical Architect
Web: www.leafgrove.com
LinkedIn: www.linkedin.com/in/jamesdstallard
Mobile: +44 (0) 7979 49 8880
Skype: JamesDStallard
-----Original Message-----
From: Harlan Carvey
Sent: 23 May 2007 16:49
To: James D. Stallard
Subject: Re: Compromising the Windows Service or Driver failure event sink
James,
Interesting thought...
If a windows service or driver set to start at boot (ie "Automatic")
fails to start for whatever reason, a message is displayed at the
console. The message also appears on top of the logon prompt, and is
therefore running in the system context. The "service or driver failed
to start" message is a generic event sink for a variety of failures
(including, oddly enough "file not found").
It occurs to me that this event sink could probably be compromised,
such that it would drop your exploit code out to executable RAM, and
in the system context.
For this to work and compromise the event sink that appears prior to the
login prompt, wouldn't the code need to be on the system and/or in memory
already?
This may be a good priv escalation technique, but woulnd't you also need
some elevated privileges already to get the event sink to appear in the
first place?
Maybe I'm missing one or two pieces in the path to a successful exploit
here...can you fill me in?
Thanks,
H
------------------------------------------
Harlan Carvey, CISSP
author: "Windows Forensic Analysis"
http://windowsir.blogspot.com
------------------------------------------
