Hi everyone, I am finally back to the tutorial.
I am continuing the series of penetration testing tutorial Bilubox walthrough. This is not just a penetration testing walkthough but I will explain you the detail of the tools thus you can practice yourself by following my steps.
In this post I am hunting any credential which perhaps can be gathered by exploiting vulnerabilities found.
in this step I will go through the local file inclusion which get my attention, I got a feeling that this website has this vulnerability because there is a page found which show alert which missing variable file. As you know that common mistake for local file inclusion is non sanitized file variable to load local file.
Now lets activate our burpsuite and proxify our firefox. You can follow the step to proxify the traffic by following the step here
As we know that there are two types of passing data from client to the web server which are via POST or GET.
POST is sending the data enclosed in the body of request message to the web server. But GET is sending the data within its URL.
From the alert shown in the above picture that we do not know yet where the file parameter should be put in either using POST or GET. Lets start dig into.
Let examine the easiest way is to test sending data using GET. We can put the url just like http://192.168.5.140/test.php?file=index.php
but we still find an error, it means the file parameter shall be sent via POST.
To make life easier, The request that I have sent been proxied to burp so that I can easily modify the parameter and other things. To modify the request, You can send your proxied request to repeater which allow you to send the http request directly from burp. This below picture is the look of repeater section in burp. As you can see that I have the http request that I sent via browser catch by burp
We know that the parameter file is not working using GET method from our first test. So we need to switch to POST method, Burp provide an easy way to switch from GET to POST or vice versa by click on the Change Request Method
so the request will be like below. The file parameter is enclosed in the body of request rather than put in the url.
You can see when we changed the request from GET to POST the parameter was sent enclosed in the body of http request. The advantage of using repeater, You can send the http request directly from burp so you can avoid the hassle of proxying from web browser.
The easiest way to confirm the LFI is to include /etc/passwd for linux system. You can see the below picture for LFI bug confirmation. You may find another payload here to allow you get LFI confirmation. here below some example another path you can test
Here are the steps
- You can press the Go button in the repeater where you trigger send http request based on your modification
- Check the server response. If it is success LFI then the /etc/passwd file will be loaded and returned to the client. You can see the response is my server passwd file.
You can explore any file, we can load PHP file and start hunting for any important information such as credential and detailed web configuration.
Let see the index.php file
the above image is the php code of index.php. we can some important code that defines the behaviour of login page
- include c.php
- include head.php
- The SQL Query for checking username and password in the database
lets check each file and go through
Next is c.php. Yeahhhaayyy .. we find the credential for the web application to connect to the backend database which is user = billu and password = b0x_billu and database is ica_lab
lets start another file which is head.php, I found nothing is interesting in this file. Let start another file panel.php, I divide the panel.php into two interesting topic one is page include selection (most probable of another LFI vulnerabilities) and image upload processing.
Below is the image upload processing which it check the image integrity for success upload. I will explain the detail of this code and see for any possible bug of this code.
Another important file need to be check is the phpmyadmin file as we found the directory during the web traversal using gobuster. You can see the result below from gobuster
Gobuster v2.0.1 OJ Reeves (@TheColonial)
[+] Mode : dir
[+] Url/Domain : http://192.168.5.140/
[+] Threads : 4
[+] Wordlist : /usr/share/dirb/wordlists/big.txt
[+] Status codes : 200,204,301,302,307,403
[+] Timeout : 4s
2018/12/22 02:02:46 Starting gobuster
/.htaccess (Status: 403)
/.htpasswd (Status: 403)
/add (Status: 200)
/c (Status: 200)
/cgi-bin/ (Status: 403)
/head (Status: 200)
/images (Status: 301)
/in (Status: 200)
/index (Status: 200)
/panel (Status: 302)
/phpmy (Status: 301)
/server-status (Status: 403)
/show (Status: 200)
/test (Status: 200)
/uploaded_images (Status: 301)
2018/12/22 02:02:51 Finished
We know that our target machine is ubuntu with php 5.3.10 running apache, Oh wait where do I know it ? let see the http response of the server
by this information we can try the default installation of phpmyadmin page in ubuntu, lets googling or we can directly load index.php for phpmyadmin in /var/www/phpmy/index.php. Yeahhh we did it. We can load phpmyadmin index.php.
We know that most of the configuration for database connection for phpmyadmin is stored in the config.inc.php so shall try to load this file and find some important information
Yeah we can load the config.inc.php. Here is the most important information stored for Phpmyadmin where we can find the password for phpmyadmin connect to the back end database.
Okay .. I think we have find alot of information that should be enough for us to setup the proper attack to gain the access. I will post another blog for attack alternative which really interesting