Hello fella hackers! Appreciate it for clicking on this post. This post will be about a topic that caught my curiosity while doing insecure deserialization on Portswigger academy on phar deserialization which are polyglot files!. This post will describe what they are, how it manipulates and confuses applications and whereabouts can hackers use this as a leverage in a scenario.

So, tell me abit more about polyglots?!

When it comes to describing what is Polyglots in cyber security, they are files which are very valid form of various different file types, like for instance a combination of GIF and JS or a GIF and RAR file. Which is pretty cool and also dangerous in the hands of the right person.

These polyglot files can be used to bypass protections where applications allows users to upload a file or an image in a specific format to prevent uploading malicious files like JS, or PHP files.

This is where the cool part starts! an example of a Polyglot file which can be used maliciously is a Phar-JPEG file which is often crafted for object injection attacks in PHP. As these attacks usually concludes to RCEs but it needs to be kept in mind that malicious attackers should be able to upload a readable Phar file somewhere on the website. Since many websites usually have preventive measures to uploading these file formats, hence where a Phar-JPEG file comes to aid, as it allows a malicious upload which looks like a normal JPEG file which meets and bypasses the uploading criteria while still holding the functionalities of a Phar file.

Thats pretty cool and all, but how do they work to be effective?

As we mentioned above, these polyglot files have the capability to fool applications that are processing them. But how? How does a Phar-JPEG tend to appear as an image while being processed and to meet the requirement of uploading security checker that’s on most websites, yet being able to be used as a Phar file? To completely understand this and how it works, like the old ways, we need to first understand how applications detect files types while being uploaded.

Understanding how applications determine file types

Modern application have various methods of verifying and checking file type of files being uploaded via its file extensions, or looking for magic bytes, and validation of file signatures.

Detection based on file extensions

This is the most common method of detection that is placed where it looks at file extensions but as common as it is, it is also not really reliable as a preventive measure as files nowadays tend to have no extension too.

Magic byte detection

For some types, we use magic bytes, these are usually at the start of the file which distinguishes that its of a certain format. For example:

1. JPEG files usually begin with FF D8 and always ends with FF D9
2. PDFs start with a %PDF which in hex variant is 25 50 44 46

Signature detection validation

More complex validation checkers will make security checks based on file signatures like for instance, it verifies to see if a legitimate JPEG file does actually contain all required header fields.

To sum it up?

To summarize what we’ve spoken, polyglots are tend to be polyglots when they have the functionality and capability to pass verification checks for more than one file type. Where an application to upload image is looking for only image files, it will meet its requirement and contain all signature to validate as one and for application that is looking for a different indicator, it becomes something else and also meets its requirement.

Since, we are talking about Phar-JPEG file, this will have to pass all the validity check for a JPEG file format and can still be used as a PHP archive when a malicious user is crafting a PHP objection injection attack.

Applying this to a concept of constructing a Phar-JPEG

Only reason why a Phar-JPEG file is a possible outcome is mainly due to Phar format specifications. As there is really no restrictions to the stub section of a Phar apart from it requiring to end with __HALT_COMPILER();.

This means that the stub section of the Phar can be exploited to via injecting dummy data that can be disguised as a JPEG file. So, if we are to inject a legitimate JPEG image into the stub section of the Phar before __HALT_COMPILER(); the file will look something like this:

To an image validation, this file will be considered a legitimate JPEG image as it contains all the mandatory signatures thats specific to a JPEG file, a start of image marker, headers, and lastly an end of image marker.

Here comes the really interesting part, when you use this concept with a Phar stream wrapper like phar://, the file will look completely different, different in the sense where it will look like a file that consist of a valid stub section, with a valid manifest with contents in the content section. So when you operate on this file, PHP still performs an unserialization operation on the metadata of Phar files, which is very crafty for malicious attackers to achieve RCE :D

Outro

I personally have never seen this exploit methods engagement using Phar deserialization apart from in labs as these methods do need a white box engagement.

This was a really interesting piece of content I found while studying for eWPTX using portswigger and I hope out of curiousity people found this useful!

Till then, I will see you in my next post :D

Resources:

1. https://portswigger.net/web-security/deserialization/exploiting#phar-deserialization

2. https://hackaday.com/tag/polyglot/