Elevate your kode-share experience with kode-viewer.
by vidner
Analysis
We are given full source-code of a website built using Nest.js. From the docker-compose.yml we can infer that the database used for this challenge is Redis.
From the kode.services.ts file, we could see that the create function uses the whole payload argument and expands them when sending it to the Redis database. This is dangerous since we can add new keys outside of the KodeDTO type. The payload is not checked against the KodeDTO type since types are only a suggestion in TypeScript, rather than a strict rule.
On the list function, we can see that we could only see our own kode if we are not an admin. But if we are an admin, we can see every kode on the database. So we would probably want to be an admin to get the flag.
To somehow overwrite the user, we need to look at how the session is implemented. The session token is just a random UUIDv4 and no sanitization is applied to it.
Therefore, we can use a kode ID as a session token, where that kode is injected with an isAdmin with a value of True . This exploit is possible because of Redis, where it does not have a concept of tables. This means that if different types of objects are using the same database, the key must be identifiable to that type and also checked rigorously to avoid collisions like what is happening in this case.
Then, the new kode can be interpreted as a session token and we can get all the kode in the database. On the remote service, the kode containing the flag will start with flag as the name and will be set to private.