Win32_Process, create process

[Simon Manners]

Hi,

hope someone can help me.

I am creating a new process on a remote workstation by
calling the following VB code:

Set objProcess = Services.Get("Win32_Process")
Set objStartup = Services.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = SHOW_NORMAL

Result = objProcess.Create("""" & txtRemoteCommand
& """", Null, objConfig, ProcessID)

If I run notepad.exe it works no problem on the
workstation I'm logged onto.

If I run it on a remote workstation (using a services =
locator.connectserver) the process runs but is hidden.
The SDK doco does say for XP and .NET it will run hidden
however I am under the impression that:

Set objStartup = Services.Get("Win32_ProcessStartup")
Set objConfig = objStartup.SpawnInstance_
objConfig.ShowWindow = SHOW_NORMAL

Will make it visible, but this does not appear to be the
case. How do I make this process visible on the remote
workstation?

Thanks

[Ivan Brugiolo [MS]]

The SHOW_NORMAL flag will make the main window of the application
(if the application has one by any chance) visible in the
WindowsStation\Desktop where the process ahs been created.

Since the process is created in the Services windowstation,
even if you make the window visible in that windowstation\desktop,
you will never see the window in the *interactive* windowstation.

Just immagine the security implications of opening a program remotely
on somebody else interactive windowstation.
If you spawn explorer.exe for User1 in the interactive windowstation of
User2,
you can induce User2 to think it's its own copy of explorer.exe,
and you can track it's activities, install message hooks,
get its password by faking the UI of the prompt-for-credentials.

--
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Simon Manners" <bci...@hotmail.com> wrote in message
news:126ca01c21a9c$26e33500$35ef2ecf@TKMSFTNGXA11...

[alex_k._angelopoulos_(mvp)]

Ivan,

Kibitzing on this thread...

This seems to be a repeated question here as well in scripting groups, primarily
for administrative purposes.

I can see why this is not a standard part of the present WMI core. Not only
would it take a lot of counter-intuitive addition/hacking to the core services
(as well as an extended security model) but it would also be a guaranteed
Achilles Heel for Windows security initially.... and many of us who have asked
for this functionality would be griping about the problems.

That said, what about some method for allowing a session or user to "take
ownership" of a currently running process and switch its windowstation? I
understand that may introduce another set of issues, but allowing proactive
"pull" of a process somehow might be a safer workaround.

"Ivan Brugiolo [MS]" <ivan...@online.microsoft.com> wrote in message
news:#8HsaRuGCHA.1600@tkmsftngp12...

[Simon Manners]

I understand all of this but to create this process you
need to have admin rights anyway. So knowing this is an
employee of a company given admin rights such a high
risk? The point is that under Windows 2000 and NT
creating a process remotely actually did show it. It only
changed with XP and .NET, does this mean that Windows
2000 and NT have huge security holes? I dont think so.

>.
>

[Ivan Brugiolo [MS]]

By default only members of the administrator are granted
remote access with metod execution permission to WinMmgt.
This does not mean that a certain configuration might allow
other users to excute metods on classes remotely.
In any case, administrators do not have normally access
to certain resources.
That is why, for example, the "take ownership" action can be audited,
to protect users from the administrators.
Normally an administrators cannot act on behalf of a user
(while a service normally can, but Localsystem != Administrators)

The same change that are in WindowsXP are beeing
considered to be released together with W2K SP3.
(and please re-read the disclaimer at the end, especially the 'confer no
rights' part)

--
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Simon Manners" <bci...@hotmail.com> wrote in message

news:fa6801c21b12$bdca2ca0$37ef2ecf@TKMSFTNGXA13...

[Ivan Brugiolo [MS]]

Let's say it can be implemented a way to create a process in a given
< TS Session - WindowStation - Desktop > triple.

Now these objects are secured in a default way to prevent
User1 from opening windows in User2 desktop,
reading its clipboard, it's atom table, installing a hook, ecc, ecc.

What would you regard a reasonable administrative action ?

would something like the following pseudo-code be reasonable ?

pWin32_WinstaDesktop =
pWbemSerices->Get("Win32_WinStaDesktop.Session=1,NameSta='winsta0',NameDeskt
op='default'");
pWin32_WinstaDesktop.LowerSecurityForUser("InjectedUser","ALL_PERMISSION");
pWin32_ProcessEx = pWbemSerices->Get("Win32_ProcessEx");
pWin32_ProcessEx->Create("notepad.exe",pWin32_WinstaDesktop);
pWin32_WinstaDesktop->RestoreOriginalPermission();

You would create a window of time where the WinSta\Desktop are
"unprotected".
How would you synchronize the death of "notepad.exe" with the restoration of
the original permission ?
Who is liable of closing notepad.exe ?
How would you make User1 participant/responsible for allowing User2 to
interact with its desktop ?
Would you make this a system-level feature or a WinMgmt supported hack that
changes
on the fly security of kernel objects since it's running as LocaSystem by
chance ?

I have way too many concerns in an feature that is prone to be used in the
wong way,
and that does not fit in a reasonable security model.

If admins have to open a program for a user, why not use Remote Assistance ?

--
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

<Alex K. Angelopoulos (MVP)> wrote in message
news:u9VyuowGCHA.2684@tkmsftngp10...

[alex_k._angelopoulos_(mvp)]

I can see the flaw with that approach.

Looking at the "big picture", most of the requests for this kind of capability
come from a situation where a particular application does not allow full
automation. The best resolution to that (from what I can see) seems to be
redesign of applications to allow full automation and/or remote interactivity
following remote launch with the administrator's credentials, instead of
compromising the security model...

"Ivan Brugiolo [MS]" <ivan...@online.microsoft.com> wrote in message

news:erCy#zyGCHA.1604@tkmsftngp09...

[Simon Manners]

If the approach to creating processes is consistent
across the operating systems then thats fine. What makes
it VERY hard in application development is if the
function does one thing on one operating system but not
on another.

Being a Domain Admin I dont see the issue in allowing a
remote process to be created and visible regardless of
who is logged on or not. You are the Administrator and
with that goes a responsibility.

Tough call.

>> >> get its password by Í{ wÀ E 4Rj_"Èr_s° ìo faking

[Simon Manners]

Geez what an issue,

Guys as an Admin I can remotely change registry entries
from any profile, unisnatll software, Install Software,
make changes to the file system, you name it, it can be
done. Thats the purpose or remote Administration and
having the domain privileges to do it.

So...Why is it such an issue to create a process remotely
and if I see fit have it displayed. Given all the things
I can do remotely how does this pose a security threat. I
want to display notepad with a message in it to a user.
Big deal. If I really wanted to I could probably find
another way to do it but I am standardising on WMI
because it is so cool.

>> > "pull" of a process sÍ{ wÀ O Dʲad÷Àaĺ ìV omehow

[Ivan Brugiolo [MS]]

As and Admin tou can even format the Hard Drive of the machine,
that is granted.
But you cannot open a file owned by a user unless you first take ownership
of the object, and this action is non-reversible
Or, in other words, administrators cannot (normally) act of behaf of users.

Moreover, WinMgmt is usable remotely by any authenticated user.
You just need to flip-on the ENABLE_REMOTE bit if the ACL
in the namespace security descriptor.

That's way I was referring to USer1 and User2 in the discussion below,
because it's a matter of faking from USer2 the UI that normally runs under
User1

--
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Simon Manners" <bci...@hotmail.com> wrote in message

news:1171001c21b36$af356050$9be62ecf@tkmsftngxa03...

[Ivan Brugiolo [MS]]

Hopefully the inconsistencies among OS-es will be solved with the next SP
for W2K.

BTW, if you open an interactive application on some users desktop as a
domain admin,
who guarantees you that the user will NOT abuse of that application ?

You open Notepad.exe to leave a message to the user,
and the user uses the open/save-as dialogs to delete/replace all the logon
scripts
on the DC, since he has a process running as a domain admin.

If by any chance this process is, let's say, Word.exe, I can run VBScript
code
as a Domain Admin, maybe using it to grant myself an admin account.

--
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Simon Manners" <bci...@hotmail.com> wrote in message

news:faea01c21b35$712741d0$37ef2ecf@TKMSFTNGXA13...

Tough call.

>> >> get its password by ﾍ{掫ﾀ E 4Rj_"ﾈr_ sｰ �o faking