diff --git a/.gitbook/assets/image (1) (2) (1).png b/.gitbook/assets/image (1) (2) (1).png deleted file mode 100644 index 97bc5bee6..000000000 Binary files a/.gitbook/assets/image (1) (2) (1).png and /dev/null differ diff --git a/.gitbook/assets/image (1) (2).png b/.gitbook/assets/image (1) (2).png index 03b2fa6b3..97bc5bee6 100644 Binary files a/.gitbook/assets/image (1) (2).png and b/.gitbook/assets/image (1) (2).png differ diff --git a/.gitbook/assets/image (1).png b/.gitbook/assets/image (1).png index 7ad845a6e..03b2fa6b3 100644 Binary files a/.gitbook/assets/image (1).png and b/.gitbook/assets/image (1).png differ diff --git a/.gitbook/assets/image (158) (1).png b/.gitbook/assets/image (158) (1).png new file mode 100644 index 000000000..f809ea855 Binary files /dev/null and b/.gitbook/assets/image (158) (1).png differ diff --git a/.gitbook/assets/image (158).png b/.gitbook/assets/image (158).png index f809ea855..7ad845a6e 100644 Binary files a/.gitbook/assets/image (158).png and b/.gitbook/assets/image (158).png differ diff --git a/backdoors/salseo.md b/backdoors/salseo.md index 6f7162216..2431c6bb1 100644 --- a/backdoors/salseo.md +++ b/backdoors/salseo.md @@ -30,7 +30,7 @@ You can **select the architecture** inside Visual Studio in the **left "Build" T Then, build both projects (Build -> Build Solution) (Inside the logs will appear the path of the executable): -![](<../.gitbook/assets/image (1) (2) (1).png>) +![](<../.gitbook/assets/image (1) (2).png>) ## Prepare the Backdoor diff --git a/cloud-security/jenkins.md b/cloud-security/jenkins.md index 035d42da2..384478c80 100644 --- a/cloud-security/jenkins.md +++ b/cloud-security/jenkins.md @@ -102,7 +102,7 @@ This method is very noisy because you have to create a hole new project (obvious Go to the projects and check **if you can configure any** of them (look for the "Configure button"): -![](<../.gitbook/assets/image (158).png>) +![](<../.gitbook/assets/image (158) (1).png>) Or **try to access to the path \_/configure**\_ in each project (example: /_me/my-views/view/all/job/Project0/configure_). diff --git a/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md b/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md index 24680d32c..7bf45605c 100644 --- a/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md +++ b/pentesting-web/http-request-smuggling/browser-http-request-smuggling.md @@ -49,7 +49,7 @@ Secondly, the request must be **triggerable in a web-browser cross-domain**. Bro The way to test this missconfig is to **send 2 requests and smuggle one** in the **middle**. If the **smuggled** connection **affected** the response of the **second** **request**, it means that it's **vulnerable**: -![](<../../.gitbook/assets/image (1) (2).png>) +![](<../../.gitbook/assets/image (1).png>) {% hint style="warning" %} Note that you **cannot** test this vuln by just sending a **Content-Length bigger** than the one sent and **looking for a timeout** because some servers **respond** even if they **didn't receive the whole body**. @@ -83,7 +83,7 @@ I've set the fetch mode **'no-cors'** to ensure Chrome **displays the connection When you execute this, you should see **two requests** in the Network tab with the **same connection ID**, and the **second** one should trigger a **404**: -![](<../../.gitbook/assets/image (1).png>) +![](<../../.gitbook/assets/image (158).png>) If this works as expected, congratulations - you've found yourself a client-side desync! @@ -191,6 +191,65 @@ fetch('https://www.verisign.com/%2f', { * Then, the user sends a POST whose body contains the **end chunk of the the previous HEAD** request and a **new request that is smuggled** with **content** (the JS payload) that will be **reflected** in the response. * Therefore the browser will treat the **response to the HEAD** request as the **response to the POST request** which will also **contains** in the **body** response that **reflects** the **input** of the user in the second smuggled request. +### Host header redirect + RC + +* **JS Exploit** + +```html + +Start attack +``` + +In this case, again, there is a **host header** **redirect** that could be used to **hijack** a **JS** import. However, this time the **redirect isn't cacheable**, so client-side **cache** **poisoning** isn't an option. + +Therefore, the attack performed will make the **victim access the vulnerable page** in a tab and then, just **before** the page tries to **load a JS** file, **poison** the socket **smuggling connections** (3 in this case).\ +Because the **timing** has to be extremely **precise**, the attack is performed against a **new tab on each iteration** until it works. + +{% hint style="warning" %} +Keep in mind that in this case `/meeting_testjs.cgi` was attacked because it **loads** a **Javascript** that is responding with a **404**, so it's not cached. In other scenarios where you try to attack a **JS that is cached** you need to wait for it to **disappear from the cache** before launching a new attack. +{% endhint %} + +Summary steps: + +* Open a new window. +* Issue a harmless request to the target to establish a fresh connection, making timings more consistent. +* Navigate the window to the target page at /meeting\_testjs.cgi. +* 120ms later, create three poisoned connections using the redirect gadget. +* 5ms later, while rendering /meeting\_testjs.cgi the victim will hopefully attempt to import /appletRedirect.js and get redirected to x.psres.net, which serves up malicious JS. +* If not, retry the attack. + +## Pause-based desync + +\ + + ## **References** * All the information of this post was taken from [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)