Re: RFP9903: AeDubug vulnerabilty

[mdixon () TYNDALL COM AU (Mark Dixon)]

> > > > > 4) Put a binary on the system

> > > > If you can run programs, you can (attempt) to use ftp or rcp to
pull files
> > > > in.  I realize this is dependant on outgoing firewall rules,
access to the
> > > > commands, etc.  But it's not impossible--these methods have been
used by
> > > > many people contacting me on the RDS issue.

> > > UNC paths work here. If you can setup your own share with guest
access I
> > > believe you can run whatever you like from it.

> > UNC paths may not work in this instance.  Not all paths contained in
the
> > registry can be remote.  I'd have to test this to be sure, and also
note

I already tested this before I posted. I should have said UNC paths do
work here.

I have a machine which Dr.Watsons reliably when running SRVINFO.EXE
against a particular host (I haven't figured out why yet...) I changed
the key to point to an executable on a UNC path on a totally unrelated
machine with an enabled GUEST account and everyone permissions on the
share. Sure enough when I fired up SRVINFO it crashed and ran the
executable from the remote share. I was careful to make sure the share
was being accessed using guest privileges (verified in the security
log).

> > that it may be dependent on what user caused the debugger to fire.

    I'm not quite sure what you mean here... true I crashed the process
as administrator on the machine SRVINFO was running on, but I can't see
why this should make any difference if I was using an unpriveliged
account or an Administrator.

    If you're refering to whether it would work without a user logged in
(say a service crash at the logon screen) then you may well be right. I
haven't tested this. Does the debugger fire when no one is logged in ? I
imagine it does but I've never seen a Dr Watson at the login screen.

    At any rate an Administrator logged in at the console is definately
would be vulnerable to someone using this type of attack to elevate
privileges. It's just one more reason to not use administrator accounts
unless you really have to.

    Regards,

                Mark Dixon