Toxic

In this challenge we can see the files of the application but only 4 files are the ones that matter:

  • index.php: That have the code that will run when a request is made to the website.

  • PageModel.php: This Model is used in index.php to represent a page

  • entrypoint.sh: script that runs in the entrypoint of the docker file

  • nginx.conf: Configuration file for the nginx server

Index.php

Looking at the file we notice some kind of behavior. When we request the website if we do not have a cookie with the name "PHPSESSID" a new one is created and added to the session. The vulnerability begins here, the way the cookie is created.

If we look closely, in the creation of a new cookie it simply encodes a serialize o bject with base64, this object being the PageModel. Using cyberchef we can decode and look at the contents:

O:9:"PageModel":1:{s:4:"file";s:15:"/www/index.html";}

As we can see, we were right, its a PageModel.

If we already have a cookie with the name PHPSESSID the object that is inside this cookie is decoded and used. This is a really big problem because it lets the user decide what is the content of the object by changing and replace the cookie.

Knowing this information lets see if the object has some nasty function we can exploit.

PageModel.php

It seems that the only function that we have is __destruct(). Doing some research i found this link.

Here they explain the following:

If the class of the serialized object implements any method named __wakeup() and __destruct(), these methods will be executed automatically when unserialize() is called on an object.

This means that every time we do a request __destruct() runs. This function uses the file that is part of the object and use the function include(). This function can be very dangerous if the input is not sanitized. It shows the content of the file passed BUT and like they say in the documentation, it will execute php code.

When a file is included, parsing drops out of PHP mode and into HTML mode at the beginning of the target file, and resumes again at the end. For this reason, any code inside the target file which should be executed as PHP code must be enclosed within valid PHP start and end tags.

Entrypoint.sh

NOTE: This challenge would be more easy if we know where the flag and what is the full name of the file containing it but in this case the name is generated randomly in the entrypoint.sh file.

Log Poisoning

Since we can manipulate the file that is passed to the include and for that matter if we can see the contents we can use a technique called "LOG POISONING". This technique is used when the user can create logs in a logfile such as the one mentioned in the nginx.conf file, /var/log/nginx/access.log, and use this with functions like include to run php code if it is inside the file.

To create the payload we will use the parameter "user-agent" sent to the logfile to create a php script to run code to list all the files in a directory.

For that we can use multiple things, I used burpsuite for that purpose. I capture the request and then sent it to repeater. After that we change the User-Agent and assign the payload we want:

<?php system('ls /'); ?>

Looking at the log file again we see that we were able to execute the payload we wanted.

And we can see the name of the flag. Then we have multiple choices, we can use repeater to send the command:

<?php system('cat /flagsomething'); ?>

Or we can forge another cookie:

O:9:"PageModel":1:{s:4:"file";s:11:"/flag_bxpZJ";}

After that we get the flag!!! :)

References

Last updated