# Session Hijacking
## What does Session Hijacking consist of?
Session Hijacking or session seizure consists of intercepting the communication between two hosts with the intent of obtaining the role of an authenticated user on a given target. Normally this practice is usually carried out in a `passive` or `active` and with attacks such as`MITM(Man-in-the-middle)`, `STP(Session token prediction)`, `TP(token tampering)` and `SP(Session Replay)`, `XSS(Cross-site-scripting)`, `SF(Session-Fixation)` among others.
**`Passive attacks`** involve monitoring the network traffic between hosts, sniffing interesting traffic but without affecting the communication at all. In contrast **`active-type attacks`** involve the attacker sending network packets, which is known as `packet-injection`.
In turn, these types of attacks can be classified into the following categories:
* **Stealing:** Attacks where in effect the `"session is stolen"` For example using `Trojans`, `Network-Sniffing`, etc.
* **Guessing:** Attacks where an attempt is made to `"guess"` the session ID. For example the pattern used in the generation of `Session IDs` is identified and emulated until a valid one is generated.
* **Brute-Forcing:** Attacks where the brute force approach is used with scripts. For example attacks that try various combinations of `user:password` until finding the correct one.
Broadly speaking, session-hijacking consists of the following stages:
| Stage | Description |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Sniffing** | The attacker attempts to intercept the traffic between two hosts, to sniff the network traffic between hosts. |
| **Monitoring** | Monitoring network traffic in search of session information. |
| **Session Desync** | At this point the attacker is ready to break or desynchronize the connection between the hosts. |
| **Session ID** | The attacker takes control of the session, via various techniques such as `Session Guessing`. To achieve generating a **`session-ID`** valid. |
| **Command Injection** | Once the attacker controls the session they begin to inject malicious commands or may take full control of the authenticated session and operate in place of the legitimate user. |
Session hijacking differs from **`Spoofing`** in a fundamental trait: when spoofing the attacker tries to impersonate the victim and does not have an active session of that user. Generally they try to obtain a session through social engineering and data theft. In ~~**`session-hijacking`**~~ on the other hand, an attempt is made to **`take control`** of an existing authenticated session between the victim and a given host.
It should also be borne in mind that **session-hijacking occurs at two levels**: **`Network-Level Session Hijacking`** and **`Application-Level Session Hijacking`**. We will see below their differences and different types of attacks.
### Application-Level Session Hijacking
In Application-level session hijacking, the attacker attempts session hijacking as well as various techniques to create new sessions(**`session-ID`**). In this type of approach we need to adapt our attacks according to the technology that powers, for example, the web application we are trying to attack. For this purpose various types of attacks and techniques are used, some of which we will see below.
| Attack | Description |
| ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Session Sniffing** | Consists of sniffing the communication to obtain a Session Token or ID and manage to authenticate to the target web application. Normally some Network Sniffer is used(**`Wireshark or Ettercap`**) or by using a web proxy such as (**`Burp Proxy`** , **`ZAP`** or **`Fiddler`**). |
| **Session ID Prediction** | In this attack what is sought is to identify the pattern used in the generation of session tokens or **`session-IDs`**. If such a **`pattern`**is found, the attacker can then begin to generate **`session-IDs`** that are considered legitimate by the application. |
| **MITB(Man-in-the-browser)** | Similar to the **`Man-in-the-middle`** attack, **`trojans`**are generally used, and **`malicious extensions`** to intercept the communication between the browser and the security mechanisms implemented in the application. In this way the malicious code can directly manipulate the DOM (Document Object Model) and extract or modify information without the user realizing it. |
| | Since the server has no way of detecting which values were modified by the attacker and which by the user, it simply performs the requested transaction. Imagine this scenario in a home banking application, the malicious extension can modify the amount and destination account of a transfer without the user noticing and the attacker will receive those funds in an account under their control. The malicious code can even reset the original values for example when the server issues the transfer receipt. In this way the user does not detect any suspicious activity. |
| **XSS(Cross site scripting)** | It is an attack in which scripts are injected into normally benign sites so that these scripts are executed without issues since the website has no way of knowing that that code is not part of the same web it is serving. |
| | Usually these injected scripts are pieces of JavaScript code that can include HTML. In this way cookies, session tokens and any other information stored by the browser can be obtained or the user can be directly redirected to a server controlled by the attacker. There are several types of XSS: |
| | - Stored XSS: When the user's input is stored on the server, e.g., the DB or in a comment on a forum. When visited by another user this unsanitized code is executed directly because it is stored directly on the page.
- DOM Based XSS: In this case the malicious code is not interpreted directly and instead the actual page code includes it by modifying the DOM to present, for example, search results.
- Reflected XSS: In this case the payload is read by the server and rendered directly. Either in an error message or in search results. We will see a simple example of this XSS variant at the end of this document.
|
| **CSRF(Cross site request forgery)** | In this type of attack an attempt is made to force the authenticated victim to perform certain actions in a web application with malicious requests. The possible impact of this attack depends on what actions are available to the victim in the app. If it is a privileged user, the entirety of the web application can be compromised. |
| | **`CSRF`** is executed on **`state changes`** of the application, for example when profile data is updated such as email, password, addresses, fund transfers, etc. |
| **Session Fixation** | In this type of attack the victim is forced to use a **`session-ID`** controlled by the attacker. Commonly the victim is tricked to, for example, click on a login link that already contains an **`session-ID`** active. |
| | When this happens the server enables the user's session and since the attacker possesses the same session-ID, they can continue operating in the webApp as if they were the legitimate user. |
| **Session Replay** | In this type of attack request captures are used and re-sent in order to take control of the existing session-ID and perform malicious operations on behalf of the victim. |
| | In insecure applications, the session information **`session-ID`** is often exposed in the form of cookies or **`URL parameters`** and in apps where the **`session-IDs`** are not configured with an expiration date. Therefore the same request, once captured from the victim, can be resent to gain control of the session. |
### Network-Level Session Hijacking
Network-level session hijacking has the advantage that attacks do not have to be adapted according to the technology used, for example in a given web application, since this attack is performed directly on the network information flow which is independent of the technology in which the application is developed. In this modality, **`the objective is to intercept and manipulate the network traffic`** between hosts and various techniques are used, below we will see some of them.
| Attack | Description |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **IP Spoofing** | Using **`IP spoofing`**, the attacker can modify network packets and send them to the server indicating that the source IP is the victim's when in fact those packets are emitted by the attacker. |
| | These packets will be taken as valid traffic originated in the **`TCP session`** created by the victim. |
| **TCP Hijacking** | In **`TCP Hijacking`** the idea is to create a state in which the victim and the host cannot communicate and to be able to send altered network packets that simulate coming from both sides and thereby gain control of the session. |
| | For this it is necessary that the attacker be on the same network as the victim. Then to prevent the victim and the server from communicating one can make use of attacks such as **`DoS(Denial-of-Service)`**. |
| **UDP Hijacking** | Since in UDP network packets do not need to be sequential, nor does it use ACK packets, this protocol is much weaker than TCP and therefore UDP-Hijacking is much simpler than TCP-Hijacking.
|
| | In `UDP Hijacking` the objective is to create and send a `response packet` before the server has time to respond. UDP is susceptible to attacks such as `MITM` where the attacker can even prevent the server's response from reaching the victim at all. |
| **MITM (Man-in-the-middle)** | This attack consists of **`sniffing`** the network packets between the victim and the server. In this case the traffic between hosts is passing through the sniffer and the attacker can modify them. One technique used is **`ARP Poisoning`**, which consists of sending altered packets to cause the host to update its **`ARP Table`** and that the **`IP`** of the victim is **`mapped`** to the hardware address (**`MAC Address`**) of the attacker. In this way the server's traffic to the victim will be redirected to the attacker. |
| | Another way is with altered **`ICMP`** packets trying to make the victim believe that routing the network traffic through the attacker is better than doing it through the host. In this case **better** can be understood as **faster or less prone to errors**. |
### Tools for Session Hijacking
Some of the tools used for App and Network level Session Hijacking are listed below:
| Tool | Description |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **OWASP ZAP** (Zed Attack Proxy) | OWASP ZAP is an open source web application security scanner. It is used to perform security audits and analyze different vulnerabilities in webapps. |
| **Burp Suite** | It is an integrated tool for performing security audits on web applications. It includes various tools for forwarding requests, modifying requests, fuzzing, web crawling and even analyzing session tokens, among others. |
| **JHijack** | Based on Java, it is a cross-platform tool for the analysis and detection of web vulnerabilities. Some attacks that can be simulated include DOM Body Hijacking, URL Attack and session Hijacking. It requires programming and HTTP protocol knowledge for its use; it is aimed at programmers. |
| **DroidSheep** | Tool for Mobile (Android) sniffing and network analysis. It allows the capture of cookies and profiles to carry out session hijacking. |
| **DroidSniff** | Another Android app that allows performing security analysis on wireless networks and capturing user accounts from Facebook, Twitter among others. |
| **Wireshark & Ethercap** | Used among other things to perform Network Sniffing and capture sensitive network traffic such as session tokens. |
## Simple Example of XSS
Let's now see a simple example of how a **`Cross Site Scripting (XSS)`**attack works. For this example we will use a practice website called **`XSSGame`**, on which we can practice various techniques of **`XSS`**. In particular in this case we will see an attack of the **`Reflected XSS`**.
Previously we mentioned the possibility of stealing session cookies through **`XSS`**attacks. Let's see the following example:
* [**XSSGAME Foogle Challenge**](http://www.xssgame.com/f/m4KKGHi2rVUN/?) **website**.
The first thing we will do is create a cookie, since this practice site automatically filters the only valid cookie it uses (called ACSID).
{% hint style="danger" %}
**NOTE:** The creation of this cookie is purely to exemplify this XSS technique with this practice website. In real websites this is not part of the XSS attack process.
{% endhint %}
To create a test cookie it is enough to open the site URL and then pressing **`F12`** we open the **`Devs tools`** of the browser:
Once in the dev tools, we go to the tab **`Application -> Storage -> Cookies -> http://xssgame.com`** and we will see the following:
To create our cookie just double click on the empty row (marked in red in the image), in the Name column enter the cookie name and in value the value. Below are the values I put.
* **Name:** `CEH_XSS`
* **Value:** `Cookie Theft with XSS`
Once the cookie is created, we should see something similar to this:
Now let's see how, by exploiting the vulnerability of this simple web, we can directly steal that cookie without much effort. It should be clarified that this is possible because the site does not process the user's input in the search box and directly includes it in the page exactly as it comes. Since this app is intentionally vulnerable, apart from an XSS attack via the input available in the UI, we will see that we can also make use of an XSS attack via the URL.
### XSS via unsanitized Inputs and URLs
Let's see how simple this XSS attack via the practice site's search box is. We just need to prepare a small script that will be in charge of stealing the cookie we created and present its value in a Javascript alert box:
The script is super simple and since the site processes the content directly without making any checks on what is being entered, it is enough to use a **`
```
* **\**: Simple HTML tag that allows us to include JavaScript code.
* **alert:** It is a method that shows an alert window with the indicated content.
* **document.cookie**: **`cookie`** is a **`property`** version of **`document`**, which allows us to read and assign cookies associated with the document (web page) we are accessing. [Read more](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie).
Let's see what happens when we enter this code in the site's search input:
And when clicking the search button, our XSS attack is processed successfully.
Obviously this is a super basic example of an XSS attack, but it serves to demonstrate the importance of sanitizing values entered by the user.
Likewise, we can directly attack the site's URL. The only thing to keep in mind in this case is that we must URL encode special characters such as **`/`** , **`()`** and the **`spaces`** and then append the result to the URL:
If we perform a simple search on this site, we can see how the query that will later return or not results is built:
As we see after a search the URL looks as follows:
```
/?query=USER_INPUT
```
With this in mind we can convert our attack script so that it can be executed directly via URL. To do URL encoding we can use an online tool such as **URL Decoder/Encoder**([Link](https://meyerweb.com/eric/tools/dencoder/)).
We enter our simple Script exactly as we used it before, and click the **`Encode`**:
button.
```
Once we have our code encoded, we can directly use it in the URL respecting how the system normally forms the URL, for this example it would look as follows:
```
?query=%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E
If we add that to the URL of our vulnerable web and execute it we should get the same alert with the cookie content:
As we can see the XSS by URL attack is successful and if we look closely at the final URL, we see that after being processed some characters that we had encoded before are now shown directly. This same example can be adjusted so that instead of showing the cookie in an alert, it is sent to our machine or to a site we control and thus make use of that cookie to impersonate a valid user session.
The site presents other challenges about XSS attacks that I recommend exploring and practicing to understand this type of attacks and their variants.
{% hint style="info" %}
These labs are subject to modifications and corrections; the most up-to-date version is available online at [the following link](https://tzero86.gitbook.io/tzero86/).
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://tzero86.gitbook.io/tzero86/session-hijacking/session-hijacking.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.