> > > > >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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:07:08 PDT