Remote Sudo Escalation

IRJ

@Dashrender I updated the OP to make a little more sense

Dashrender

why is Remote server1 trying to run software on Local Server1 through a share? The file exists on Local Server natively.

In Windows parlance

 Local Server1
       SMB Share
 Remote Server1
      map \\local server1\share to T: and somehow attempt to execute a file on T: on the hosting server.

This isn't possible via SMB, as you said in the OP, you'd have to use something like powershell or RDP to connect to Local server1, map the share to a drive on itself (or directly access a UNC) and then execute.

I would assume you could SSH into Local Server1 from Remote server1, and execute a UNC style command from it's own share, no?

Remote server 2 here is a red herring? completely meaningless? I'm not sure what role it plays here?

IRJ

@Dashrender said in Remote Sudo Escalation:

Remote server 2 here is a red herring? completely meaningless? I'm not sure what role it plays here?

I need that server to be able to access and run the files off the SMB share. The share has wide open access.

Now it may be that I am getting wrong information from the vendor, but the main reason I am upgrading to this new version is for centralization. The old version let me connect via SSH and manage accounts for each system.

I want to be able to setup local cron jobs to handle mounting and unmounting share and running a process from share only when needed.

Dashrender

Why is the share important? The files are on the machine - who cares if they are shared or not - because you're not trying to access those files from another machine, you're simply trying to execute a file that exists on Local Server1.

what's the equiventant of

 psexec local-server1 "c:\path\program.sh -argument" -username local-admin -password P@$$w0rd

in Linux?

IRJ

@Dashrender said in Remote Sudo Escalation:

Why is the share important? The files are on the machine - who cares if they are shared or not - because you're not trying to access those files from another machine, you're simply trying to execute a file that exists on Local Server1.

what's the equiventant of
 psexec local-server1 "c:\path\program.sh -argument" -username local-admin -password P@$$w0rd
in Linux?

All i know to try is ssh hostname "comand_here" but it runs the output on the SMB server itself as expected.

Dashrender

@IRJ said in Remote Sudo Escalation:

@Dashrender said in Remote Sudo Escalation:
Why is the share important? The files are on the machine - who cares if they are shared or not - because you're not trying to access those files from another machine, you're simply trying to execute a file that exists on Local Server1.

what's the equiventant of
 psexec local-server1 "c:\path\program.sh -argument" -username local-admin -password P@$$w0rd
in Linux?
All i know to try is ssh hostname "comand_here" but it runs the output on the SMB server itself as expected.

What do you mean the output runs on the SMB server itself? If you have a shell open on Local Server1, you see the output in that shell? not on Remote Server1?

I think the same happens with psexec, there's no feedback to the remote host (remote server1 in this case) for the command - because it all ran on the Local Server1.

If cron is running this - why would you need output on Remote Server1?

black3dynamite

ssh -t remote_user@remote_host 'sudo reboot'

stacksofplates

What possible tool is using remote SSH commands with sudo like this?

Dashrender

@stacksofplates said in Remote Sudo Escalation:

What possible tool is using remote SSH commands with sudo like this?

he wants to execute a command using cron on a remote server, yet have the output display on the server running the cron job.

stacksofplates

@Dashrender said in Remote Sudo Escalation:

@stacksofplates said in Remote Sudo Escalation:

What possible tool is using remote SSH commands with sudo like this?

he wants to execute a command using cron on a remote server, yet have the output display on the server running the cron job.

Ah my bad. I missed the Cron part. I didn't read all of that.

stacksofplates

Can't it use local files? If so, you could just mount through NFS to access locally and not need the SMB share.

IRJ

@stacksofplates said in Remote Sudo Escalation:

Can't it use local files? If so, you could just mount through NFS to access locally and not need the SMB share.

The share has java which, we I want to avoid running locally.

travisdh1

@IRJ said in Remote Sudo Escalation:

@stacksofplates said in Remote Sudo Escalation:

Can't it use local files? If so, you could just mount through NFS to access locally and not need the SMB share.

The share has java which, we I want to avoid running locally.

So don't install a java runtime on the remote computer... now no java can possibly run on it, no matter what files are in the share.

Dashrender

@IRJ said in Remote Sudo Escalation:

@stacksofplates said in Remote Sudo Escalation:

Can't it use local files? If so, you could just mount through NFS to access locally and not need the SMB share.

The share has java which, we I want to avoid running locally.

Why does everything have to be in that one share?

IRJ

Update on this...

I just got off the webex screen share with vendor. They are baffled and are going to create an exact sandbox environment to replicate.

It is still a very early version of this software

dafyre

So...

Client Server 2 needs to mount //smbserver1/some_path /mnt/some_path
Then Client Server 2 needs to run sudo /mnt/some_path/some_script.sh ?

scottalanmiller

@IRJ said in Remote Sudo Escalation:

The vendor is telling me I should be able to run .sh file directly from samba share on client server2. So ssh should not need to be part of equation. Otherwise having the share would be pointless.

Sounds like the vendor needs some basic IT support themselves.