Black Box Test 2

 This explains how I pwned the second black box penetration test lab from ine.com


First of all, I did quick nmap scans looking for remote hosts which were alive. I checked using a half-open TCP scan (a SYN scan), a SCTP scan and a UDP scan of common UDP ports. I then combined the discovered hosts into a target file which I then fed into nmap to perform a more in-depth SYN scan.








The machine @ 172.16.64.166 was serving a web site on port 8080 using Apache 2.4.18 The version was discovered by grabbing the server header banner with nmap. I started Burpsuite and started to explore the web site. At the same time, I started directory busting using Gobuster. I decided to search for .php files as well as directories because Apache was being used as the web server. Gobuster didn't find anything interesting, but by clicking through the web site and looking into the source code of the responses in Burpsuite, I found information being leaked in comments about members of the team.






I tried the first name of elizabeth to SSH into the machine, as the nmap scan had revealed an SSH service listening on port 2222. The connections worked, and there was further information leakage in that the default password of CHANGEME was mentioned in a message. This suggested to me that the company had had problems with staff not changing default passwords. I therefore created a list of possible usernames and a similar list with the passwords CHANGEME changeme Changeme and ChangeMe. I used this list of usernames and passwords with hydra to brute force the SSH service. Hydra discovered the credentials sabrina:CHANGEME






I tried to connect to SSH using the found credentials and this worked. I found the flag but also a .bak file. I checked the .bak file and found host information which seemed useful for pwning another machine on the network. I therefore copied the host information into my own /etc/hosts file.




The machine @ 172.16.64.81 had a web server (Apache 2.4.18) on port 80. I once again started Gobuster and attempted to enumerate the site by using a web browser and Burpsuite. Gobuster found some directories and robots.txt which I decided to take a look at in my browser.





It took me a while to find the next step in solving this lab. It would have been a lot faster if I could have used the spider tool on Burpsuite, but this is not included in the free version anymore. Still, by visiting the directories discovered by Gobuster whilst at the same time running Burpsuite and then looking through the sitemap, I was able to eventually find a backup file called users.bak This obviously was of interest to me, so I had a look inside its content using Burpsuite.





I tried using the credentials to log into the web application being served. I found that john1:password123 worked, but got redirected to a dead end. Still, when I looked in the response header of the redirection using Burpsuite, I found further information leakage in the form of headers which had database credentials as values.




These seemed likely to be for the MYSQL daemon listening on port 13306 so I tried to connect using them. They worked and I was able to use some basic SQL commands to find the flag which was in a column of one of the tables of one of the databases.







The next machine which was @ 172.16.64.92 had a DNS server on port 53. It was also serving a website on port 80. I couldn't find much but there was an alert which said "Loaded". I decided to take a look into the Javascript scripts to see if I could find the script calling this alert("Loaded") function. I found it and when I inspected it I saw a GET request for a .php file in a directory which Gobuster was never going to find!




I changed the IP address but kept the rest of the path the same and found a new web page which didn't seem to do much.




The .php file was called tracking2.php, which made me wonder if other numbers existed such as tracking3.php or tracking1.php I tried these different possibilities and eventually found a more interesting web page @ tracking.php




This .php file appeared to let users search for information about different records. I tried it, but nothing was returned. It seemed as though the SEND button wasn't working, so I had a look at the source code and found that there was a parameter called id that I could input.




I tried to add the parameter directly to the URL bar and send it as a GET request. This worked and I was able to see the data relating to the record with the id of 1




Since I couldn't think of anywhere else to go, and here was a web application which allowed users to input data, I decided to try an SQL Injection. I tried it first of all directly into the URL bar and observed the resulting behaviour of the web application. I discovered that I received two different results when I injected ?id=1' and 1=1 -- - and ?id=1' and 1=2 -- - This suggested that the web application was vulnerable to an SQL Injection using the id parameter.





I have been learning more about Burpsuite and encoding recently, so I also tried the same injection attacks in the repeater tool and encoding the blank spaces myself with %20 (this is automatically done by web browsers). I was happy to see that I got the same results in the responses.





I then proceeded to manually attack the web application using SQL Injection commands. I eventually found usernames and passwords. The commands I use to hack web applications using SQL Injection attacks can be found in my post about SQL Injections here. The commands cannot be seen fully in the following screen shots as they are too long!










I enjoy performing SQLI attacks manually, but for speed and due to the fact that it is easier to use, SQLMap is a great tool. I therefore repeated the above work using SQLMap and retrieved the same usernames and passwords.













SQLMap cracked the two non-admin user passwords for me. I tried them to log into the MYSQL service which was operating on port 63306, but neither of them worked. I therefore went back to some directory busting and found a new .php file called panel.php





This appeared to be an administrative console, so I tried to log into it using the discovered credentials. Obviously, since the users were not admin, this did not work. I started thinking about trying to crack the admin hashes, but knew that could take a long time, so I first of all had a quick look into the source code. So far on this lab, lots of information had been leaked in the source code and its comments, so this seemed like a good idea before launching a password cracking attempt. When I had a look into the source code, I did indeed find more information leakage in a comment. The credentials for a different user were given, so I tried connecting to the MYSQL service using them. This was successful, and I was able to change the admin status of the user tracking1 I tried to access the admin console again, and was happy to see that since tracking1 now had admin rights, I was able to use the admin console!







The admin console had a parameter called code which didn't seem to do anything by default. Since .php files were being used on the server, I tried to input some PHP code using the parameter called code. I did this first of all in Burpsuite's repeater tool.




The phpinfo() function worked, so I tried the system() function. This time, I used it in the URL bar directly and observed the responses in the web browser. I was able to execute these system commands and therefore find the next flag.







Since this machine was running a DNS server, it made sense to take a look at the /etc/hosts file to see if I could find any new virtual hosts. I used the cat /etc/hosts command (along with encoding of blank spaces) in Burp's repeater tool as when I tried it in the URL bar the resulting output was difficult to read in the browser.




I added this new virtual host to my local machine's /etc/host file




Next, I visited the web page, but received a 404 error. I therefore did some more directory busting using Gobuster and found a directory called apps which I navigated to. This page looked like a file upload application, but an annoying alert kept on popping up!






My next plan was to find the HTML code for the file upload, copy it into a file on my local machine, and then open it in a browser so I could still attempt to upload a file to the path specified but without loading the script which was causing the alert box to pop up. I soon found the HTML code in the source code. I amended it slightly to make the path correct. The /upload/upload.php part of the path had been provided in the source code. I just added the rest to make it a full path.




Once I had saved this as an HTML file on my local machine, I opened it in a browser and tried to upload a file. The file upload did not work!






I was running out of ideas, so I went back to using Gobuster for further directory busting. This time, I specified the path leading to /app as I hadn't had a look in that directory. This appears to be a good way to proceed with the ine.com labs. When a new directory has been found and explored, it seems always to be worthwhile to then run Gobuster with the new directory which has been discovered. Of course, dirbuster could be used in its recursive mode right from the beginning, but I find that it takes too long and is inefficient as it digs recursively into every discovered directory rather than the ones which are of interest to me. I therefore like to use a mixture of automated and manual techniques.




Looking carefully at the results, we can see that the upload.php file is actually in the /app directory and not the /upload directory - no wonder the previous HTML file was not working - it was pointing to a non-existent file! I therefore amended the path in the HTML file and tried it again. This time it appeared to work!




It wasn't 100% clear where the file had been uploaded to, but it made sense to just try the /upload directory. I did this and executed the PHP function which was inside the file which I had uploaded as a test file.








All of a sudden, the end was in sight! I crafted a PHP reverse meterpreter shell using msfvenom, uploaded it using my HTML file, started a listener in msfconsole and triggered the reverse shell by navigating to it in the /upload directory. I was then able to get the flag from the final machine in the lab! :-)







I enjoyed working through the machines in this lab as they gave me lots of practice hacking web applications. I was able to apply my knowledge of directory busting, sqli attacks and malicious file uploads. I was also able to gain a better understanding of Burpsuite, HTML code and msfconsole. Perhaps most importantly, I was able to better understand the importance of using a specific methodology when penetration testing a network. I became much more aware of the cyclical nature of pen testing in that I had to investigate and enumerate further each step of the way and information found on one machine was necessary for me to pwn other machines. I feel a lot more confident with the methodology needed to tackle further labs, along with an increased understanding and confidence in web application testing.




Popular posts from this blog

Hacking Year of the Owl (thm)

Image
NOTE: I am currently migrating my writeups and cybersecurity notes to  my github This writeup can be found in a new and shiny form at puzz00 year of the owl writeup  --- The Year of the Owl is a machine by MuirlandOracle on tryhackme   We start by using nmap to scan the TCP ports. The results show us that this appears to be a windows machine because we see netbios on port 139, SMB on 445 and winrm on its default port of 5985. We take a closer look but don't find much of interest. Since SMB is running, we can try a null session attack, but this does not work. We cannot connect using rpcclient without valid creds, either. Web app enumeration does not reveal anything of interest, so I have not included it in this post. We need to find another way to enumerate usernames and potential passwords. We can try common UDP ports using nmap. The results come back in the open|filtered state which is not very useful. We do not know if the ports are open or if the UDP datagrams are bei...
Read more

Hacking Reset (thm)

Image
  NOTE: I am currently migrating my writeups and notes regarding hacking aka pentesting to  my github - my reset writeup can be found here     Reset is a fun active directory based box on thm   We start with an nmap scan which shows us that the target machine is probably a domain controller as it has port 88 open. Domain controllers typically have this port open since they are involved in kerberos based authentication. We also find some useful data regarding the domain and machine we are attacking. In addition, we find port 5985 is open - this is of interest as it is a port which is used by winrm which in turn is a service which could potentially give us a remote session on the target machine if we find valid credentials.    Since smb is being used, we start our enumeration of the haystack machine by taking a look at it - can we get a null session and thereby enumerate useful data? We find that we can. The IPC$ share has read access to non-authentica...
Read more

Simple CTF (tryhackme)

Image
  I started with a quick SYN scan of all ports on the target machine. The -T4 flag speeds up the scan from the default -T3 and the -p- flag specifies all ports to be scanned. As can be seen from the results, ports 21, 80 and 2222 had services listening on them. It was now time to take a closer look at those three ports, so I used the -A flag with nmap to find out more. The anonymous login allowed using FTP on port 21 seemed interesting, so I connected to it in passive mode using the username anonymous and no password ftp -p 10.10.179.144 The connection was successful, but I could not get any listing of the directories or files using ls so I turned my attention to port 80 by navigating to the home page in my browser. I was greeted with a default Apache "It Works!" page. I then checked the robots.txt file and fired up a directory buster. I used gobuster as it is fast, but dirb, dirbuster or a home-grown one would also do. The /simple directory stood out as interesting, so I na...
Read more