How I compromised 5 Websites during a class?

Last year, I started my Master’s in Information Security with a desire to add new skills to my bucket in the information security domain and interact and learn from others’ experiences.

It was a routine evening, and I was taking an online class on Ethical Hacking. The stakes of this class were high because we were about to explore information gathering techniques. Therefore, I wanted to make the most of it. Sir Mustafa Shiraz was conducting the course, who is an epitome in teaching Information Security subjects.

We studied the information gathering phase, where we look in-depth at foot-printing, scanning, and enumeration techniques. During the class, we were assigned to present results in the information-gathering phase. Student’s were showing similar kinds of results. Meanwhile, I was thinking of gathering some exceptional results through which my knowledge can get expanded. I skimmed 10’s of websites, and decided to dig into Github Dorking. It was new concept for me. I started to explore it. I had an initial idea that developers seldom take precautions while publishing their code publicly. This thought kept me moving forward and I narrowed my search.

Eye’s on the target.

I used numerous GitHub dorks (are like Google dorks, where we can find specific information) and was astonished to find the amount of exposed sensitive information like credentials, api’s, tokens,config files etc.

I found one developer who had inadvertently shared his entire configuration file, among other codes. The interest was mounting. Initially, I had no intention to look deeper, but once I was logged into the server, the amount of data it had, kept me looking at all the aspects.

.config file

In the first step, I enumerate the target machine via nmap.

Nmap is used to find unknown network services, and vulnerabilities.

After I logged in to the server, I verified the server details.

IPINFO provides the details of the IP.

I was super curious to know why the developer had not implemented any firewall. To my surprise, the server had a firewall enabled, and the SSH was allowed from anywhere.

UFW, or uncomplicated firewall is used to filter the traffic.

From looking at the firewall rules, I discovered that it was not only an SFTP server but also a web server. I confirmed it by checking the status of the Nginx.

Systemctl is used to inspect and control the systemd system.

I then checked network status and discovered it had a MYSQL database as well.

Netstat command displays the current network connections over the network.

I then went on to see the Nginx directory. To my surprise, the server was hosting five different websites.

Present working directory.

All of them were live. The level of excitement grew more. I then checked all the websites and then decided to document one of them. i.e ******nutritions.com.

SSL certificate details of ******nutritions.com.

Since I was logged in with the root user, I can read any file. There was no encrypted file at all.

I looked in the environment’s file and found the Database credentials in it. The credentials were in plain text.

.env file is used to define variables which you want to pass into your application’s environment.

After getting the Database credentials, I logged into the database, and then it was a regular job for me. All the databases were visible to me. I had full read/write access to the contents of 5 databases.

Show databases; is a mysql query which displays all the databases on the server.

I stopped myself for further digging in the database as it would have gone out of scope. Anyways, there were some other interesting things as well like Public/Private keys.

With the public and private keys exposed, encrypted communication can be decrypted.

After discovering all these things, I stopped and thought, what could I have done if I was the hacker?

1- I could have leaked the data.

2- I could have deleted the data.

3- I could have demanded ransom after leaving a backdoor.

4- Modify files in the server

5- rm -rf *

Summarizing, what I found:

1. A simple information gathering leads to a web application with unrestricted access from anywhere.
2. Credentials to MySQL database, which led to read/write access databases.
3. Lots of readable sensitive files.

Finally, I wrote to the developer and asked him to fix the issue.

In a similar case like this, I discovered an RDS which was open to the public. I didn’t penetrate the database but reported the issue to the developer. There are 1000’s of cases like this.

1000’s of available results.

Checking the connectivity.

Telnet is used to check the connectivity among the hosts.

Accessed the RDS.

Access to RDS via leaked sensitive information.

Reported the issue to the developer.

Opened an issue.

Conclusion:

Since the threat is higher, we need to educate the developers of the risk of a negligence can cost. Information Security nowadays have become a collective responsibility of all.