sabato 6 ottobre 2018

RootMe - CTF App Security - Bash - System 2

I'm considering seriously the CTF topic, it is so funny but I need to learn more and more.

A good choice to start learning is


Root Me allows us to practice with a lot of challenges, classified in arguments: App - Script, App - System, Cracking, Cryptanalysis, Forensic, Network, Programming, Realist, Steganography, Web - Client, Web - Server.

Let's start with the first category: App - Script.

The third challenge that we face is: Bash - System 2:

Vulnerability type:
  • Privilege Escalation by SETUID permission

##################################################

This challenge is very similar to the Bash - System 1. At the beginning, open terminal and type:
  • ssh -p 2222 app-script-ch12@challenge02.root-me.org
to connect to the target system. If it asks for a password, insert app-script-ch12.

If we type ls -la command, we will see three files: ch12ch12.c and .passwd. I note also that ch12 and .passwd have the same owner (user) app-script-ch12-cracked.

It's easy to note that .passwd contains the solution of the challenge.

If we try to read the .passwd file by cat, less, more, etc. we cannot do that due to the permissions, indeed only the owner of this file has the privileges to READ that file. How can we do?

We can use a "weakness" caused by the SETUID (SET User ID) set by 1. This kind of exploit allows us to perform privilege escalation to execute a program with the owner's program privilege, even though we are not the owner.

The SETUID is a permission that can be set on files. Generally it can be set by the command: chmod u+s filename or chmod 4755 filename. This command substitutes the x parameter on the User (owner) permission with s.

In our case, we cannot chmod the interested file because we don't have permissions on them, but we can find which files have already the SETUID set. To check this, we type:
  • find / -perm -u=s -type f 2>/dev/null
In this way, we will search for all files that have SETUID set by 1. I note that ch12 has SETUID set by 1 so I can execute this program (so this process) as the owner of the program (that is the same owner of .passwd).

How does ch12 work? To check this, I can open the ch12.c file by less ch12.c. I note that ch12 executes ls -lA command on .passwd file. I need to read that file. How can I do?

One solution is to substitute the ls command of this system with another command or making a program and rename this last command/program as ls. For example I can substitute ls command with nano or I can make a new C program: in this way, when the ch12 will perform its code, the ls command will execute the C program. To do this, type:
  • mkdir /tmp/challenge1 --> The /tmp directory is one of directories that gives for all users all permissions (read/write/execute) since I don't have privileges anywhere. I use it to copy or create the C program that I desire to substitute to ls.
  • cd /tmp/challenge1
Make the C program like:
#include <stdlib.h>
#include <stdio.h>

int main(){
system("cat /challenge/app-script/ch12/.passwd");
//system("/bin/sh -i"); comment above and uncomment if you want a shell with app-script-ch12-cracked privileges return 0; }
  • gcc -m32 -o program program.c
  • mv program ls --> Rename program as ls
  • export PATH=/tmp/challenge1:$PATH
  • cd ~ --> Come back to the starting directory /challenge/app-script/ch12/
  • ./ch12
In this way, when ch12 will be performed, when the following piece of ch12 code will be executed 

system("ls -lA /challenge/app-script/ch12/.passwd");

ls will correspond to program, so the solution will be printed on the terminal and we insert it as password in the challenge webpage to end.

Note that we can substitute ls with any Linux command or we can make a script or a program (i.e. C program) and rename its name as ls and insert in the PATH environment variable its location. This makes us understand how this exploit is dangerous as it allows any users to escalate privileges and execute commands of other users (like also root).

Useful links:
http://www.hackingarticles.in/linux-privilege-escalation-using-suid-binaries/

Nessun commento:

Posta un commento