Session forensics: TRYHACKME WALKTHROUGH | by Alham Rizvi

Recap

Before diving in, let’s quickly recap the concepts we’ll explore in this room: Sessions and tokens.

Authentication & Authorisation

Authentication is the process of verifying your identity (are you J. Doe?). In contrast, authorisation determines what actions an identity can perform in a given resource (what can J. Doe do?).

Sessions

When you authenticate in a web app, there is a high probability that a session was created. Servers use sessions to remember user information, which gets sent through multiple requests. When you log in, the server stores your User ID, role, and other useful information to keep track of your session. This is typically stored centrally in a database. They are stateful, in the sense that the server keeps track of the user information whilst the user interacts with the site. To maintain the user authenticated, the server sends a Session ID to the browser (the client), which gets stored as a cookie. This cookie gets sent back to the server with each request. This way, the server can tell who is sending the request.

Advantages

• More Control: Since the server stores and manages the session, it is easier to control the user’s data and revoke permissions when needed.
• Tight Security by Design: Since no session data (apart from the Session ID) is stored on the client side, it’s harder for an attacker to modify the session, especially if implemented with HTTPS and the correct cookie flags (Secure, HttpOnly, SameSite).
• No Exposure of Data: Only the Session ID is exposed, so no sensitive information is stored on the client side.

Disadvantages

• Scalability: You need to use a centralised database to manage session data. This can become tricky if you want to scale multiple servers, as it becomes a single point of failure if not appropriately managed.
• Resource Consumption & High Costs: Sessions are stored on the server side, meaning each user takes up space. Suppose the application grows and has a large number of users. In that case, resource consumption can become expensive and potentially lead to performance issues if it is not managed and scaled to endure user growth.
• Session Hijack: If an attacker can steal the Session ID, they can impersonate the user, and they will temporarily have the keys to the kingdom.

Spotting Sessions In The Wild

Understanding the types of apps you are dealing with can help your investigation. Certain architecture strategies tend to use sessions more than others:

• Monoliths: In monolithic architectures, sessions tend to be the preferred method because the architecture implements a tightly coupled frontend-backend relationship. Centralised session management fits this pattern, as the backend server will manage user and session storage to verify session IDs against the user each time a request is made. For example, imagine a user logs in to Stack Overflow and makes requests to post a thread or answer a question, whilst the back end verifies the session ID stored in the database against the user to keep their session active.
• Expendable Sessions: Short-lived sessions are your friend in services where you make short bursts of requests, like filling out a form. The back-end can quickly end your session as you click submit. Or, if you are logging into your online banking to check your statement, your period of inactivity is likely to be short, both for security reasons and given that your actions are temporary and straightforward.
• Single-Pane Management: If your application is small to medium-sized and you don’t have a distributed/microservices architecture, sessions are the go-to. This way, you don’t have to hand tokens and verify them across services.

JWT and Tokens

You might have heard of JSON Web Tokens (JWT), which are commonly seen in modern web applications. JWT is an open standard used for authentication and authorisation. JWT is stateless because session information is stored on the client side and not on the backend. The structure is as follows:

1. Header: Dictates the algorithm used for signing, usually RSA.
2. Payload: Contains information about the user, like role, session ID, or when the token expires.
3. Signature: Used to check if the token has been tampered with.

Advantages

• No Back-End Dependency: JWT contain all the necessary session information, so the server does not need to store information compared to sessions.
• Security: JWT can be encrypted and signed with algorithms like RSA.
• Non-repudiability: Tokens can be signed, making validating the token’s authenticity easier.
• Cross-domain Access: Because the tokens are stored on the client side, it makes it possible to authenticate across different domains.
• Scalable: The application is no longer dependent on the server, so it can scale easily without stressing about session memory.

Disadvantages

• Can’t Revoke As Easily: When you issue a token, you set a value for expiration. That means if a token is compromised, you technically have to wait until it expires. Revocation mechanisms need to be set when designing systems using JWT.
• Client Security Dependability: JWT are usually stored in cookies or local storage. If the client or website is not built securely, the JWT can be stolen, for example, via XSS.
• Encryption: JWT’s payload is not encrypted by default, although you can implement it. HTTPS has to be present so the token is not intercepted.

Spotting JWTs in the wild

Similar to the previous section, we aim to understand where you usually see JWTs so you can nourish your investigation. Common architectural patterns are:

• Distributed Systems: If you have an application running on microservices, where different services are interconnected, JWTs are your best friend. Each service can validate a JWT instead of constantly talking to the back end to verify the session. You need scalability in distributed systems, and JWTs ensure you can scale autonomously by having all the session information needed on the payload. Imagine an online food delivery service. You have a service for authenticating the user, the basket, the checkout service, etc. Each of these services can verify your session by validating your JWT.
• Single-page applications (SPAs): You might have encountered SPAs multiple times. As the name suggests, SPAs are single pages that load content dynamically without refreshing the page or travelling to another subdomain. As stated in the linked article, “Imagine a Single Page Application (SPA) to be like a magical book. In a traditional book, you flip pages to move to different chapters. However, in the magical SPA book, every chapter appears instantly with a wave of your hand, without having to flip pages.” As you can imagine, SPAs are extremely client-heavy, so JWTs are the preferred choice. SPAs are mainly seen on sites that use newer frameworks like React or Angular.

TASK-2

1, What security mechanism do you have to implement when introducing JWT?

Answer — revocation

2, What is the attack called when an attacker steals your session ID?

Answer — session hijacking

TASK-3

1, Where would you find logs useful for investigating privilege escalation?

Answer — application logs

2, Where would you find logs useful for mapping user-agent and IP addresses?

Answer — web server logs

4, Which logs would you check if a JWT token has been forged?

Answer — Identity Provider logs

TASK4

1, What user-agent can be seen in the logs?

Answer — Mozilla/5.0

2, Based on the logs, what kind of tokens are we dealing with?

Answer — Jwt

3, What is the IdP server that issued the tokens?

Answer — auth.catportal.internal

4,Which user has requested the tokens?

Answer — FluffyCat

5, Which role change triggered the warning?

Answer — admin

6, What was the malicious token used?

Answer — eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VybmFtZSI6IkZsdWZmeUNhdCIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcyMTQzMTgwMCwiZXhwIjoxNzIxNDM1NDAwfQ

7, What algorithm did the malicious token use?

Answer — none

8, What was the previous legitimate token?

Answer — eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6IkZsdWZmeUNhdCIsInJvbGUiOiJ1c2VyIiwiZXhwIjoxNzIxNDM1NDAwfQ.WMKctz1p5KLwNP_C7XXcWbP8uEpbwSeEY_hU_dhG6Rk

9, What algorithm did the legitimate token use?

Answer — HS256

TASK-5

What can you add to ensure a JWT token is not tampered with?

Answer — token verification