0

I am solving a lab related to serialization vulnerabilities. It deals with retrieving files based on the signature. The theory of the lab states as quoted, "Adding ./ will still give you the same file but the application will generate a different signature that may be loosely equal to 0."

ex:

curl -X POST -H "Content-Type: application/json" -d '{ "token": "<TOKEN>", "uuid": "../../.././././././././etc/passwd", "sig": 0}' https://lab.exploit/files

Would you please tell me how does this work at the back-end?

ThinkTank
  • 1
  • To answer this question, we would have to know what the server-side script at `https://lab.exploit/files` does with the data that is posted to this script, which is: `{ "token": "", "uuid": "../../.././././././././etc/passwd", "sig": 0}`. – mti2935 Jan 29 '22 at 15:11
  • I believe the script at the sever-side is script checks the auth token "TOKEN" which is a serialized user-object that gets deserialized later on and the application returns the content of the file based on the "UUID" (which is actually a filename) and the signature associated with the ''UUID". – ThinkTank Jan 29 '22 at 15:30
  • Based on the use of the term 'loosely equal to zero' in the part that you quoted - my hunch is that this involves exploiting a vulnerability in the server-side script where it does a comparison using `==` instead of `===`. `==` in some languages is for loose equality, e.g. in javascript, `'1'==1` results in `true`. Perhaps somehow the `/` characters in the filename cause the script to perform division. But, it would be hard to know without seeing the backend script, or at least having a way to pen-test it. – mti2935 Jan 29 '22 at 17:57
  • After spending few hours on the chall. My hunch is that the random UUID generation is not because we're providing "./" the script at the backend takes the custom UUID provided by the user and generates a signature to it. Luckily for us due to the loose comparison, we're able to retrieve the file with our signature value being 0. The random UUID can be generated by providing arbitrary string such as "..../" and not just "./" . – ThinkTank Jan 29 '22 at 18:47
  • Another edit: Today I checked, the "./" is basically linux directory traversal. only the filepath approach is changed wherein ../../../etc/passwd = ../../.././etc/passwd. Meaning the PWD for both the filepath would eventually be /etc/passwd only approaching the filepath in different way is changing the "id". – ThinkTank Jan 31 '22 at 17:26

0 Answers0