Linux PrivEsc - TryHackMe

This write-up is based on the Linux PrivEsc room from Try Hack Me:- https://tryhackme.com/room/linuxprivesc

[Task 1] Deploy the Vulnerable Debian VM

#1  Deploy the VM

#2  SSH in to the VM using the credentials given and run the id command

[Task 2] Service Exploit

This task is to exploit the following vulnerability in MySql:-

https://www.cvedetails.com/cve/CVE-2005-0711

The exploit is available here:-

https://www.exploit-db.com/exploits/1518

The create of the room has already made the exploit file - raptor_udf2.c on the VM at location:-

/home/user/tools/mysql-udf

Then run the following commands as asked:

Get the root shell:

Learning from this task:-

• Avoid running applications as "root"
• Patch things and stay up to date.

[Task 3] Weak File Permissions - Readable /etc/shadow

#1 What is the root user's password hash?

As we can see that hashes of root and user are exposed, which can be cracked offline!

#2 What hashing algorithm was used to produce the root user's password hash?

We can use john the ripper to crack the password which also tells us the hashing algorithm used.

We can use another tool named "hashid" to determine the hash types.

#3 What is the root user's password?

Use the cracked password of the root to login using SSH.

Learning from this task:-

• /etc/shadow permission should not be readable by "others" (NOT world-readable)
  
• Check out here for learning more about /etc/shadow file and hashes used:- https://en.wikipedia.org/wiki/Passwd#Shadow_file
  

[Task 4] Weak File Permissions - Writable /etc/shadow

The /etc/shadow file on the VM is not only world readable, it is also world writable. This can be abused by changing the hash of root to a new hash for which we know the plain text password.

"mkpasswd" utility is used to create a new sha 512 password. Replace the new hash for root using vi.

SSH to the VM with root user and new password "123456"

Learning from this task:-

• /etc/shadow permission should be not be writable by "others" (NOT world-writable)

[Task 5] Weak File Permissions - Writable /etc/passwd

#1 Run the "id" command as the newroot user. What is the result?

This task is to abuse the write permission for "others" on /etc/passwd file.

Edit the root user password:

Or Create a new user - "newroot" with id=0:-

Learning from this task:-

• /etc/passwd permission should be not be writable by "others" (NOT world-writable)

[Task 6] Sudo - Shell Escape Sequence

# How many programs is "user" allowed to run via sudo?

Count them :)

Here are various ways the sudo permission of these programs can be abused:

• sudo iftop ====> then ====> !/bin/bash
  
• sudo find /home -exec /bin/bash \;
• sudo nano ====> then ====> ^R^X ====> reset; sh 1>&0 2>&0
  
• sudo vim -c '!sh'
• sudo man man ====> then ====> !/bin/bash
• sudo awk 'BEGIN {system("/bin/sh")}'
• sudo less /etc/hosts ====> then ====> !/bin/bash
• sudo ftp ====> then ====> !/bin/bash
• echo "os.execute('/bin/sh')" > shell.nse && sudo nmap --script=shell.nse
• TERM= sudo more /etc/profile ====> the ====> !/bin/sh

#2 One program on the list doesn't have a shell escape sequence on GTFOBins. Which is it?

   Easy to figure out - A famous web server.

#3 Consider how you might use this program with sudo to gain root privileges without a shell escape sequence.

Abuse option which this application provide:

Learning from this task:-

• SUDO permissions can be abused and thus should be provided very carefully and with proper authentication.

[Task 7] Sudo - Environment Variables

Read these articles first to gain more understanding of this topic:-

https://jvns.ca/blog/2014/11/27/ld-preload-is-super-fun-and-easy/

https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/

Follow the steps given:

What just happened?

• In Preload.c
  

  setresuid() sets the real user ID, the effective user ID, and the saved set-user-ID of the calling process.

    These are set as 0 i.e. the ROOT user ID.

• In Preload.so is loaded first as it is set with LD_PRELOAD
• iftop has got sudo permissions set and thus we get a root shell
  

Now using the LD_LIBRARY_PATH trick:-

Now lets try renaming /tmp/libcrypt.so.1 to /tmp/libpcre.so.3 used by apache2 and re-run apache2 using sudo again and lets see if gives us the root shell.

It doesn't work, so we edited the /home/user/tools/sudo/library_path.c as shown above, so that we satisfy the compiler and it then works!

 

[Task 8] Cron Jobs - File Permissions

Follow the steps given:-

Start the Netcat listener from your kali machine:-

When the overwrite.sh runs again, we will get the root shell.

Learning from this task:-

• The jobs running from system wide crontab must have proper permissions specially if they are running as "root" and should not be world writable.
  

[Task 9] Cron Jobs - PATH Environment Variable

Follow the steps given to get the root shell:-

Learning from this task:-

• The PATH variable in /etc/crontab should not be edited in almost all the cases and should not point to the directories controlled by other user, as this can be abused for the jobs which are running as root.
  

[Task 10] Cron Jobs - Wildcards

Lets view the content of the other cron job script:-

tar command is running as a wildcard and that too in users directory.

Using a script from https://github.com/t0thkr1s/gtfo to check about tar command.

Tar can let you run other commands with its checkpoint feature, which can be abused.

Run the following commands in the /home/user directory:-

Also start a listener on our target kali machine, to get a root shell:-

Remove the files once the job is done:-

[Task 11] SUID / SGID Executables - Known Exploit

Lets find out all the binaries with suid and sgid bit set:-

Scan through the binaries and try to find out exploits from various source as suggested (plus few more):-

• https://www.exploit-db.com/
• https://vulners.com/
• https://gtfobins.github.io/
  

Run the exploit given to get root shell:-

/home/user/tools/suid/exim/cve-2016-1531.sh




[Task 12] SUID / SGID Executables - Shared Object Injection

In task 11 we saw there are many binaries with suid bit set. Let try to check them out one by one and try to spy on them with strace.

Learn more about strace from here in a funny and interesting way:-

• https://jvns.ca/strace-zine-v3.pdf
  

Lets pick up /usr/local/bin/suid-so

So it is clear that "/usr/local/bin/suid-so" is try to find out libcalc.so and that too from user's home directory. This can be abused in so many ways and can get a root shell as suid bit is set on "/usr/local/bin/suid-so"

Shown below is a slight variation of the technique given THM room to get the root shell:-

[Task 13] SUID / SGID Executables - Environment Variable

We have already seen "/usr/local/bin/suid-env" with suid/sgid bit set.

Follow along as it is pretty straight forward to get the root shell:-

Learning from this task:-

• Always use absolute paths
• Suid and Sgid permissions are dangerous and should be used with precautions.
  

[Task 14] SUID / SGID Executables - Abusing Shell Features (#1)

/usr/local/bin/suid-env2 is better then /usr/local/bin/suid-env2 as absolute path is used. But we have an issue with Bash version which is used here for exploitation, which basically allows to define shell functions with names that resemble file paths.

Learning from this task:-

• Keep the system up to date ==> Patch it!
  
• Suid and Sgid permissions are dangerous and should be used with precautions.
  

[Task 15] SUID / SGID Executables - Abusing Shell Features (#2)

This task exploits the following vulnerability :-

https://www.cvedetails.com/cve/CVE-2016-7543/

Bash before 4.4 allows local users to execute arbitrary commands with root privileges via crafted SHELLOPTS and PS4 environment variables.

Learning from this task:-

• Bash version can also an attack vector.
  
• Keep the system up to date ==> Patch it!
  
• Suid and Sgid permissions are dangerous and should be used with precautions.

[Task 16] Passwords & Keys - History Files

Learning from this task:-

• Look in history files
  
• System Admins should clear history files periodically.

[Task 17] Passwords & Keys - Config Files

Follow the steps given:

Learning from this task:-

• Scan the system for plain text passwords
• Hashes should be used instead of plain test password and those should also be not world readable or writable.
  

[Task 18] Passwords & Keys - SSH Keys

Wrong permissions set on the private keys can be very easily exploited.

Copy over the "root_key" to the kali machine and ssh to the target using that key:-

Learning from this task:-

• Private key should have 600 permission and not world readable/writable
  

[Task 19] NFS

Read here to know about root squashing:-

https://en.wikipedia.org/wiki/Unix_security#Root_squash

no_root_squash - Allows root users on client computers to have root access on the server. Mount requests for root are not be mounted to the anonymous user. This option is needed for disk less clients.

root_squash - Requests from root clients are mapped to the nobody user and group ID so they will only have file privileges associated with other.

On the attacker kali machine:-

On the Target VM :-

[Task 20] Kernel Exploits

Kernel Exploits are the last resort in Privilege Escalation.

Many tools are available to identify vulnerabilities in the current kernel version:-

• https://github.com/mzet-/linux-exploit-suggester
• https://github.com/jondonas/linux-exploit-suggester-2
  

On the VM:

Compile and run the exploit on VM:-

[Task 21] Privilege Escalation Scripts

Automated Tools available for PrivEsc:-

• https://github.com/diego-treitos/linux-smart-enumeration
• https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS
• https://github.com/rebootuser/LinEnum
  

Also check my other post related to PrivEsc :-

https://basicpentesting.blogspot.com/2020/06/70-ways-to-get-root-linux-privilege.html

Let's run linPEAS and see what all we can find which is exploited manually till now:-

So we can see the scripts picked up most of the cases that we tried in all these tasks.

These tools and scripts are really handy, but we should also know about the manual methods which help us in understanding the issues in depth and under certain cases these manual methods are our last resort.

That all, See you later :)