Login Name: "offsec" - Indicates the username used for login.
Encrypted Password: "x" - This field typically contains the hashed version of the user's password. In this case, the value x means that the entire password hash is contained in the /etc/shadow file (more on that shortly).
UID: "1000" - Aside from the root user that has always a UID of 0, Linux starts counting regular user IDs from 1000. This value is also called real user ID.
GID: "1000" - Represents the user's specific Group ID.
Comment: "offsec,,," - This field generally contains a description about the user, often simply repeating username information.
Home Folder: "/home/offsec" - Describes the user's home directory prompted upon login.
Login Shell: "/bin/bash" - Indicates the initial directory from which the user is prompted to login.
Checking our user's sudo permissions
offsec@linux01:~$ sudo -l
Matching Defaults entries for offsec on linux01:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, env_keep+=LD_PRELOAD
User offsec may run the following commands on linux01:
(ALL : ALL) ALL
All privileged operations using sudo and sui are logged by default to /var/log/auth.log
Unlike Ubuntu/Debian, Linux distributions such as CentOS and Fedora store authentication logs in /var/log/secure.
Blocked attempt to read /etc/shadow
bob@linux01:/home/offsec$ sudo cat /etc/shadow
[sudo] password for bob:
Sorry, user bob is not allowed to execute '/usr/bin/cat /etc/shadow' as root on linux01.
Reviewing the log entry for the blocked attempt
offsec@linux01:~$ sudo cat /var/log/auth.log | grep shadow
Aug 16 15:39:08 linux01 sudo: bob : command not allowed ; TTY=pts/0 ; PWD=/home/offsec ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
aureport can be used to efficiently inspect very detailed logs generated by the audit daemon.
Enabling aureport detailed keylogging
session required pam_tty_audit.so enable=*
Running aureport to fetch user's keylogs
offsec@linux01:~$ sudo aureport --tty
[sudo] password for offsec:
TTY Report
===============================================
# date time event auid term sess comm data
===============================================
...
4. 08/17/21 05:30:02 2183 1002 pts0 153 bash <up>,<up>,<^U>,"ssh bob@localhost -i /home/alice/stolen_id_rsa",<ret>,"exit",<ret>
User config files tend to reside in the home directory and shouldn't be editable by other users. Two specific configuration files are responsible for executing aliases and bash functions (.bashrc) and setting environmental variables (.profile).
Weak .bashrc permissions discovered
alice@linux01:~$ ls -asl /home/bob/.bashrc
4 -rw-r--rw- 1 bob bob 3771 Aug 27 03:24 /home/bob/.bashrc
"Backdooring" (PoC) bob's .bashrc
alice@linux01:~$ echo 'echo "hello from bob .bashrc"' >> /home/bob/.bashrc
Triggering the "backdoor" with a new login
kali@kali:~$ ssh bob@192.168.51.12
...
hello from bob .bashrc
bob@linux01:~$
Now from a defender's perspective, we can enable auditing rule to detect these. We can use auditctl to watch configuration files for any write and attribute change operations.
Configuring audit rules for privilege escalation detection
offsec@linux01:~ sudo auditctl -w /home/bob/.bashrc -p wa -k privesc
offsec@linux01:~ sudo auditctl -w /home/bob/.profile -p wa -k privesc
Verifying the audit rule
offsec@linux01:~$ sudo auditctl -l
-w /home/bob/.bashrc -p wa -k privesc
-w /home/bob/.profile -p wa -k privesc
Audit rules configured through auditctl will not be persistent across reboots. To make them permanent, rules have to be added to the /etc/audit/rules.d/audit.rules file.
To enhance analysis, the aureport tool supports the -i option that interprets user IDs and translates them into usernames.
The auid value is assigned every time a user logs in and is unchanged for the duration of that session.
Attacking the System
Abusing System Programs
Effective UID/GID was introduced which represents the actual value being checked when performing sensitive operations. Set-UID (SUID) allows programs to execute as a separate effective user.
In this case, with the Set-UID flag on the user owner permission set, it's stating that this binary should be run as the user owner. In this case, root.
The two rules above log any activity of processes, either on x86 or x64 architectures, with effective UIDs equal to zero (root) that are also invoking the execve system call, which is ultimately responsible for executing programs throughout a shell.
Extend the audit_key_search.py script to extract and print out the euid field. Once done, print an extra warning if the euid is zero and the auid is a standard user.
Weak Permissions
Linux File Permission Table for /etc/passwd
FORMAT
OWNER
GROUP
OTHER
symbolic
rw-
r--
r--
binary
110
100
100
octal
6
4
4
If you find scripts, cronjobs, etc. with write permissions to everyone then that's a no-no.
Audit rule to monitor all files in a folder
offsec@linux01:~$ sudo auditctl -w /home/offsec/SOC-200/Linux_Privilege_Escalation/cron_scripts/ -p wa -k cron_scripts
Analyzing the cronjob script modification from audit logs
The audit rules provided in this module should be taken as a baseline. Further rules should be customized and tailored depending on the environment being defended.
Monitoring /etc/shadow with audit watch rule
offsec@linux01:~$ sudo auditctl -w /etc/shadow -p war -k etc_shadow
Run the audit_key_search.py file to search for password file dumping events. After inspecting the audit logs we might notice an auid value of 4294967295. This string corresponds to a specific numeric value in POSIX. What value does it represent?
