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