# Mini project - Attack :bat: **Target:** Group L / stud14 **Author:** Group E / stud07 [TOC] --- # Information gathering In the beginning, the flask app of our rival team was not up at http://stud14.itu.dk:5000/, so we decided to scan as much as we could with nmap, attempting to detect vulnerabilities on their server using the following command: --- ``` >> sudo nmap -sS -sV --script=default,vuln -p- -T5 stud14.itu.dk ``` ### Nmap information - **Port 21**: vsftpd 3.0.3 - **Port 22**: OpenSSH 8.2p1. None of the 3 listed vulnerabilities were exploitable - **Port 33060**: MySQLX unrecognized by vuln script --- ### SSH and MySQL Service Bruteforcing We first tried to just login using the default supplied credentials. Afterwards we ran the metasploit bruteforcing script with the provided common passwords with no success with the users stud14 and root. --- We also tried to exploit the mysql service that was exposed on port 33060. To do this we created a script that tries to gain access to the mysql service. It uses the most common password/usernames combinations as can be seen [here](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/mysql-betterdefaultpasslist.txt) along with the common passwords supplied in the defence part of this project. --- The script can be seen below: ```python from logging import error from sys import stdin import mysqlx for line in stdin: u, p = line.rstrip().split(":") try: # Connect to server on localhost my_session = mysqlx.get_session({ 'host': '130.226.140.114', 'port': 33060, 'user': u, 'password': p }) isOpen = my_session.is_open() print(isOpen) except Exception as e: print(e) print("Not hit for: " + u + ":" + p) ``` --- # Initial access When the rival group started the flask service, we were able to login with the standard SQL injection: ``` ' or 1=1 -- ``` We then created notes to retrieve information from their SQLite. To get the table names, we used the default `sqlite_master` table. ``` '||(SELECT GROUP_CONCAT(tbl_name, ';') FROM sqlite_master WHERE 1=1 LIMIT 1)||' ``` --- A note was created with the following info: ``` ahashedpassword;ahashedpassword;860b854f6a7d5ab5f4fdb0d57bffadc1 ``` We google'd this hash and the following string `student2020` was listed as a result. It allows access to the user `andreas@stud14.itu.dk`. --- # Privilege Escalation ## SUID/SGID missconfiguration We tried to find missconfigured SUID's with ``` find / -perm -4000 find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -la {} \; ``` revealed no interesting binary we could exploit. --- ## Cron missconfiguration None of the cron directories were writable by `andreas`. --- ## Sudo missconfiguration The user `andreas` was not a sudoer, however, `stud14` is, but we weren't able to get into this user either. --- ## Privilege escalation scripts We went as suggested on the assignment through every privilege escalation techniques from `PayloadAllTheThings`. Also running the suggested tools, but no interesting missconfiguration was found either --- https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Linux%20-%20Privilege%20Escalation.md We have tried to run different exploit finder scripts:  * [linpeas.sh](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) by running `./linpeas.sh | less -r` * [lse.h](https://github.com/diego-treitos/linux-smart-enumeration) * [LES: Linux privilege escalation auditing tools (name on picture: yoana)](https://github.com/mzet-/linux-exploit-suggester) --- ## The unsafe.py file There's an `unsafe.py` file that has write access for user andreas and is owned by root. On the same directory, there was a `safe.py` which wasn't writeable by `andreas` but it imported `unsafe.py`. However we couldn't figure out a way to get `root` to run this script. --- We wrote a script, that if we managed to get `root` to run it, it with supply us with a copy of bash with missconfigured SUID bits, giving us an admin terminal. ``` import os import shutil shutil.copyfile("/usr/bin/bash", "/home/andreas/root-bash") os.system("chmod u+s /home/andreas/root-bash") os.system("chmod g+s /home/andreas/root-bash") os.system("chmod +x /home/andreas/root-bash") ``` We hoped a background cron or something may run this, but we had no luck with that. After asking to our rival group we found out this was the intended way, and after they reconfigured it, we got a root-shell as expected --- # Security goal violations **Confidentiality** Information stored in the note-taking app was not confidential. An attacker could get access to the whole database through an SQL injection. Moreover, the passwords were unhashed. --- **Integrity** An attacker could use the database access to create notes that looks as if created by another user, or modify or delete existing notes: All through SQL-injection. An attacker can with the root account CRUD any file in the file systems. --- **Availability** We as a group did not try any DDOS or DOS attack towards our rival in order to attack their availability. As a result we do not know if their flask app would be able to sustain a DOS attack, since they're not using a server program like Apache or nginx, we doubt it. --- # Maintaining access Once we had root access, we added ourselves to the `authorized_keys` of the root user. We're able to login as root from ssh with our keys. --- To ensure that even when the keys are removed we still have access to the server, we could do several things, like adding a `systemd` unit and a cron job that adds to the `authorized_keys` of every user our keys. Such changes could be disguissed as legitimate crons and units.