Let’s break it down a little bit more with an example path.

 This is the working directory of our fictional app: /var/www/cgi-bin/things/. When it is passed a parameter like ?page=file1.php, it looks in its working directory to load file1.PHP. When we execute these attacks, we don’t actually know the working directory of the application; it could be buried deep in a directory tree or it might be in a user’s home directory. So we want to be sure that our path includes enough previous directories to get us back to the root directory, which can be a guessing game.In this relative path, I have a total of 14 previous directories. That’s fine. Any previous directories beyond the root directory of the filesystem are ignored. This path goes back to the root directory, and then from there, to /etc/passwd Inject Code In this case, I’m going to take the easy route and insert the code for my shell into the log files, then access it with the web app. First, I verify that I can access the log files. In some cases, these may not be readable. If we have done our initial recon, we will have some idea of what type of system we are up against, including what type of web server the host is running. Armed with this knowledge, we can ascertain the path of the log files. In this example, we have an Apache server, and the default location for Apache logs is /var/log/apache2/, or /var/log/apache. As we can see below, I’ve successfully included the Apache access log into the page.

sharing is caring

Leave a Reply

shares