Username: natas33
Password: Ihchno1voinhchisaieem1ainge
URL:http://natas33.natas.labs.overthewire.org/
(I change the point colour into blue)

Looking at the source code, we know that the server executes the uploaded file when its MD5 checksum matches adeafbadbabec0dedabada55ba55d00d. It’s easy to think of an MD5 collision, however it’s useless here because it’s limited to 4096 bytes.
Looking at the front-end code, you’ll see that we can modify two parameters, the filename and the contents of the file. In the following code, we can see that the filename is set with session_id as the default value. And the source code has no restriction on the type of the uploaded file.

Continuing to audit the source code, we found that the __destruct() magic method was called when the class was destroyed, and guessed that there might be a PHP deserialisation vulnerability in the code.
We use the deserialisation vulnerability, usually with the help of the unserialize() function, but as people’s awareness of security increases, this vulnerability is becoming more and more difficult to exploit, but at the Blackhat 2018 conference in August 2018, Sam Thomas, a security researcher from Secarma, talked about a new way of attacking PHP applications, which is to use the __destruct() magic method to destroy a class without using the __destruct() magic method. Using this method it is possible to trigger the PHP deserialisation vulnerability without using the unserialize() function. The vulnerability is triggered by using the Phar:// pseudo-protocol to deserialise information stored in meta-data when reading a phar file (article at https://github.com/s-n-t/presentations/blob/master/us-18-Thomas-It%27s-A-PHP-). Unserialisation-Vulnerability-Jim-But-Not-As-We-Know-It-wp.pdf).
Phar file structure
The Phar file contains three to four main sections:
1. A stub
The basic structure of the stub: 2. a manifest describing the contents
Some information about the compressed file in the Phar file, where the Meta-data part of the information will be stored in deserialised form, which is the key point of the exploit.
3. the file contents
The file contents of the compressed file, in the absence of special requirements, the compressed file contents can be written casually, because we use this vulnerability is mainly to trigger its deserialisation
4. a signature for verifying Phar integrity
a signature for verifying Phar integrity
Attempting to obtain a password using the phar deserialisation vulnerability
I. Serialisation
According to the file structure let’s build our own phar file (php has a built-in Phar class) with the following code:

Finally, change the filename to phar://test.phar/test.txt to force the md5_file() function to parse the phar document and get the flag.

