Windows & PSTools - Security Flaw?

[0phoi5]

Hi all,

So, this script shouldn't work without a password for a user, but it does.

Using PSTools and being on the same network as the target PC. Set the %Time% to be in a couple of minutes . . .

XCOPY C:\Foo.bat \\%Hostname%\c$ /E /S /C /Y

psexec \\%Hostname% -s -c -f cmd.exe /c "Schtasks /create /RU %UserID% /SC ONCE /TN %NameOfTask% /TR c:\Foo.bat /ST %Time%

This actually successfully runs Foo.bat on a user's PC, as the %UserID% set in the script, but doesn't actually prompt for their password. It just runs.

I've even managed to use this to send a command to copy files, from a folder that only they have access to, to a location I can then pull them from.

If I clean up after me (delete schtask and bat file), it looks to the system like they ran the command and not anyone else.

Security flaw?

Edited January 27, 2016 by haze1434

[digininja]

To be able to copy the file to c$ you need admin creds on the destination which suggests there is an account that matches yours on the destination. If that is the case then this is expected behaviour.

[0phoi5]

To be able to copy the file to c$ you need admin creds on the destination which suggests there is an account that matches yours on the destination. If that is the case then this is expected behaviour.

Not really.

I could copy the file to any location I and the user have access to. Doesn't have to be C:\, that was just an example.

The security flaw is the second line of code, which runs the file as the user. Not me, the user. Without their password.

If you look at all CMD or Powershell commands that Windows have created, they did not intend this to be available. Their scripts ALWAYS ask for the password for the user specified after /RU.

[digininja]

What creds are you using with the psexec to set the scheduled task up?

[0phoi5]

What creds are you using with the psexec to set the scheduled task up?

I am using my Admin account, because PSEXEC doesn't send commands without Admin privledges, but you're misunderstanding the point.

Regardless of being an Admin, the Foo.bat runs entirely as the user. Not me, the user.

As an Admin, I should only be able to send commands to a PC using my account or as SYSTEM. Not as a user. This script runs Foo.bat ENTIRELY as the user. Without their password.

[digininja]

It looks like what is happening is you are setting up a scheduled task for the administrator which you are telling (with /RU) to run as a different user. As the admin has the powers to become other users that is allowed.

Easiest way to prove this is to set up the scheduled task for tomorrow and then browse the tasks for the admin and for the user it is running as, I bet it is in the admin's list.

[0phoi5]

Case-in-point;

Each user has their own personal drive, their Z:\ drive, which regardless of me being an Admin, I don't have access to. It's their personal space.

Say they have a file called 'Personal.txt' on their Z:\ drive.

I can send this . . .

XCOPY C:\Foo.bat \\%Hostname%\c$ /E /S /C /Y

psexec \\%Hostname% -s -c -f cmd.exe /c "Schtasks /create /RU %UserID% /SC ONCE /TN Pull_File_From_Z /TR c:\Foo.bat /ST %Time%

. . . and set Foo.bat as . . .

XCOPY Z:\Personal.txt C:\ (or wherever) /E /S /C /Y

This gives me access to open their C:\ drive and grab Personal.txt.

I shouldn't be able to do that.

Edited January 27, 2016 by haze1434

[digininja]

But if the admin does runas (Windows equivalent to sudo) then they become that user and so are them for the duration of the operations which means they will have full access to their z drive.

[0phoi5]

But if the admin does runas (Windows equivalent to sudo) then they become that user and so are them for the duration of the operations which means they will have full access to their z drive.

RUNAS asks for the user's password.

http://ss64.com/nt/runas.html

*edit*

Also...

"When a script is run with elevated permissions several aspects of the user environment will change: The current directory, the current TEMP folder and any mapped drives will be disconnected."

Edited January 27, 2016 by haze1434

[digininja]

When combined with the scheduled task, are you sure? There is the /RP to pass the parameter but I thought that was only when you were elevating privileges not downgrading from an admin to a normal user.

[0phoi5]

When combined with the scheduled task, are you sure? There is the /RP to pass the parameter but I thought that was only when you were elevating privileges not downgrading from an admin to a normal user.

I'm sure, yes. It prompts for the user's password.

And if I run as SYSTEM or Admin (me), then . . .

XCOPY Z:\Personal.txt C:\ (or wherever) /E /S /C /Y

. . . fails, as the local user's Z:\ drive is not accessible.

[digininja]

For the second bit I'd expect that as you are running in your environment but the scheduled task would be setting up a new environment to run in which may result in the login scripts or drive mappings being done, that is just a guess though.

For the first bit, you have proved that it doesn't ask for the password when running it as a different user, the question is, should it? Logically to me it would make sense that an admin can set up a task to run as a user without needing to know their password otherwise there wouldn't be any point in being an admin.

I've asked some friends, will let you know what they say.

[0phoi5]

I've asked some friends, will let you know what they say.

That'd be great, cheers

Maybe it is supposed to be how it is, but it seems a bit dodgy that I can use it to grab files I shouldn't be able to get to.

[digininja]

The consensus seems to be that it doesn't need the password to do the run as but it should need it to access any network resources. That makes sense, you need the password to authenticate to the resource provider.

The suggestion as to why it is working in your case is that it is using cached credentials so doesn't need you to provide them. Would you be able to clear out the cache and try again. Or try a user who hasn't logged in to that machine and see if it works for them.

The other question was does the network share require a password to access it or just a username? It it is set up to just require the user id then that would remove the need for the password.

[0phoi5]

Thank you.

I'll check those details and post again as soon as I am able.