Healthchecker
Healthchecker was a ASP.NET challenge that provided us the .dll file of the backend app.
Last updated
Healthchecker was a ASP.NET challenge that provided us the .dll file of the backend app.
Last updated
The app allows us to register and gives us a uuid to login. Once logged in we can add websites to the healthcheck feature. Everytime we access the app with our session, it will send a GET request to all the websites on the list to determine if they are up or down. During registration we ca upload a profile image, which will be very important later on.
Reading the source code we can see the user session data is serialized using BinaryFormatter and saved to a file stored in ~/App_Data/Users/
, the file name is the users uuid.
Our profile image is also stored to a different file in ~/Content/images/
and the file name si the users uuid + the file extension (jpg or png).
If my uuid is 796ca550-fa08-4fbd-9acb-327e7204429e, and I upload a .png file, then my profile pic is at ~/Content/images/796ca550-fa08-4fbd-9acb-327e7204429e.png
and my serialized session data is at ~/App_Data/Users/796ca550-fa08-4fbd-9acb-327e7204429e
.
Whenever we load the page, the program deserializes the user data file of our user. It concatenates the uuid from the session cookie to determine it's path.
If you smell path traversal, you're definitely right. We can't drop a payload on the user data that is meant to be deserialized but there is one file we have full control over, which is the image file, so, theoretically, if we change our cookie to ../../Content/images/796ca550-fa08-4fbd-9acb-327e7204429e.png
we should be able to make the application deserialize our image (controlable data).
We can generate a reverse shell payload with ysoserial.net and upload it as our image upon registration, then we could abuse the path traversal vulnerability to cause a deserialization against our payload and achieve RCE. Where is the ysoserial command I used to generate the payoload:
Stacking commands wasn't working for some reason so I ran 3 payloads, one to create a \temp dir in case it doesn't exist already, one to download netcat, and the last one to run it.
Now we would need do decode the b64 data and save it to a .png or .jpg file and then register a new user with the payload as profile pic.
At last, if we use our new uuid in our previous path traversal payload and reload the page.
Finally, we shoud get a shell and read the flag.