Summary:

• I will walk you through the source code analysis approach behind finding the bugs within Hackthebox "Magic". Tho this particular challenge is supposed to be solved in a black-box approach I decided to download the source code and analyze it for the sake of having a better understanding of the root cause behind those bugs.

Login SQLi:

• There were two unauthenticated endpoints on this box, one to view images, which didn't seem to have any security issues, and a login endpoint. This later was vulnerable to an SQLi

  

• The SQLi was pretty straight, a simple admin'+or+1=1--+ would bypass the authentication and redirect us to a post-authentication file upload endpoint:

  

  • The vulnerable code behind the SQLi was under /var/www/Magic/login.php:

  • 

    We are interested in the highlighted lines which are the source and the sink. In line 4 the back-end checks if the username POST parameter was submitted in the request and if so it assigns the user input in the $username and the $password variables. In line 12 both of those variables ( That contain non sanitized user controlled input ) were hard-coded within the SQL query without being prepared first, which in other words means that we can control the SQL query and alter it.

File upload restrictions bypass:

• Although the box name suggests that we are going to use magic bytes at some point, I went and tried uploading a webshell directly just to see how the web app reacts to it.

  

  • It turned out that the back-end code had a white list of allowed extensions in place which were png, jpeg, jpg. To keep it short let's analyze the source code responsible for file uploads:

    

    • Extracting the extension: In line 15 the code used the built-in pathinfo() function with the PATHINFO_EXTENSION flag to extract the extension of our uploaded file.

    • Extension check: In line 16 the code compares our file's extension to a whitelist of extensions and if the condition evaluates to "true" the $uploadOK variable will be assigned to 0 which will prevent the rest of the code from executing and as a result we fail to upload our file. At this point, we know that our webshell extension needs to be either a jpg, png or a jpeg for a successful attack.

    • Magic Bytes check: Magic bytes exist at the beginning of every file and they represent the file type, for instance, FF D8 FF E0 are the magic bytes for JPEG files. So back to the code analysis, after the extension check is passed another check is performed using the exif_imagetype() function in line 23, this function would extract the magic bytes of our uploaded files and in line 24 there's an if condition which would compare our file's magic bytes with an array of allowed magic bytes, the array is initially defined at line 10 $allowed = array('2', '3'); the 2 and 3 values stand for IMAGETYPE_JPEG and IMAGETYPE_PNG which are aliases for both JPEG and PNG magic bytes that exif_imagetype() use ( read the manual https://www.php.net/manual/en/function.exif-imagetype.php ). If this last condition fails, again the $uploadOK variable gets assigned to 0 which would prevent the rest of the code from executing, in contrast, if this condition succeeds the rest of the code has no further security checks it would just fully upload the file to the upload directory.

    • Bypassing the magic bytes check: The magic bytes check isn't enough to secure a web app from unrestricted file uploads for a simple reason, magic bytes can be manipulated. For instance, we can change the magic bytes of a PHP web shell to a JPEG web shell using a HEX editor as follows.

      

      • In the previous screenshot, I used hexeditor CLI tool hexeditor -b webshell.php to change the magic bytes of my web shell to a JPEG magic bytes.

      • To sum up, for a remote code execution we need a PHP webshell with a JPEG extension webshell.php.jpeg and JPEG magic bytes.