Assessment
- I was able to achieve SSRF with the forged JWT. This allows me to access the internal services
- A session cookie,
cybermonday_session, was decrypted using the secret key,APP_KEY, found in the .env file while leveraging Nginx Alias Path Traversal with theoff_by_slash technique- a string with 2 data came out;
25c6a7ecd50b519b7758877cdc95726f29500d4c|JKWALJ4QOBcyb5sgRAtTddJlKNwgQ6rtsOokplkw
- a string with 2 data came out;
Checking back at the .env file, an instance of Redis appear to be present, operating with
- the hostname of
redis- likely an internal instance since it wasn’t visible during the Recon phase
- on the port
6379 - the prefix of
laravel_sessionThis appears to indicate that the session storage of the target web application might be handled through the Redis instance and25c6a7ecd50b519b7758877cdc95726f29500d4c|JKWALJ4QOBcyb5sgRAtTddJlKNwgQ6rtsOokplkwis directly relevant to it
further research online revealed that it is possible to communicate with a Redis instance via SSRF
additional online source also revealed that communicating to a Redis instance via SSRF through the HTTP protocol is possible with the CRLF injection
another online resource also pointed out the possibility of code execution by overwriting the Redis session storage via deserialization attack
Since
- communicating with the internal Redis instance via SSRF through the HTTP protocol is possible
- session storage of the web application is suspected to be handled through the internal Redis instance , I might be able to overwrite the session id to get code execution on the web application, which is Laravel
Assessment is complete. Moving on to the Exploitation phase