From nmap scanning we can see that our target has 3 open ports i.e
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
On my way moving there is this documentation 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.
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.
i found it easy to enumerate and exploit it RMI with beanshooter
. There is this repo explain well on how to configure beanshooter 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
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.
The shell was not stable, it has some delays so we can try to forward a shell into out machine i.e
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.
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.
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.
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
.
Now if we try to run again sudo -l
, Lets now try to switch to user admin
.