GitBook: [#3071] No subject

loretanr · Mar 21, 2022 · 777c070 · 777c070
1 parent 5346a4c
commit 777c070
Show file tree

Hide file tree

Showing 26 changed files with 48 additions and 12 deletions.
diff --git a/.gitbook/assets/image (628) (1) (1) (1).png b/.gitbook/assets/image (628) (1) (1) (1).png
diff --git a/.gitbook/assets/image (628) (1) (1).png b/.gitbook/assets/image (628) (1) (1).png
diff --git a/.gitbook/assets/image (628) (1).png b/.gitbook/assets/image (628) (1).png
diff --git a/.gitbook/assets/image (628).png b/.gitbook/assets/image (628).png
diff --git a/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (651) (1) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (651) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1).png
diff --git a/.gitbook/assets/image (651) (1) (1).png b/.gitbook/assets/image (651) (1) (1).png
diff --git a/.gitbook/assets/image (651) (1).png b/.gitbook/assets/image (651) (1).png
diff --git a/.gitbook/assets/image (651).png b/.gitbook/assets/image (651).png
diff --git a/.gitbook/assets/image (654) (1) (1) (1) (1).png b/.gitbook/assets/image (654) (1) (1) (1) (1).png
diff --git a/.gitbook/assets/image (654) (1) (1) (1).png b/.gitbook/assets/image (654) (1) (1) (1).png
diff --git a/.gitbook/assets/image (654) (1) (1).png b/.gitbook/assets/image (654) (1) (1).png
diff --git a/.gitbook/assets/image (654) (1).png b/.gitbook/assets/image (654) (1).png
diff --git a/.gitbook/assets/image (654).png b/.gitbook/assets/image (654).png
diff --git a/cloud-security/concourse/concourse-architecture.md b/cloud-security/concourse/concourse-architecture.md
@@ -2,7 +2,7 @@
 
 ## Architecture
 
-![](<../../.gitbook/assets/image (651).png>)
+![](<../../.gitbook/assets/image (651) (1).png>)
 
 ### ATC: web UI & build scheduler
 

diff --git a/cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation.md b/cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation.md
@@ -17,7 +17,7 @@ Note that other cloud resources could be searched for and that some times these
 
 As other clouds, GCP also offers Buckets to its users. These buckets might be  (to list the content, read, write...).
 
-![](<../../.gitbook/assets/image (628) (1) (1).png>)
+![](<../../.gitbook/assets/image (628) (1) (1) (1).png>)
 
 The following tools can be used to generate variations of the name given and search for miss-configured buckets with that names:
 

diff --git a/...curity/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md b/...curity/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md
@@ -537,7 +537,7 @@ More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security
 
 An admission controller is a piece of code that **intercepts requests to the Kubernetes API server** before the persistence of the object, but **after the request is authenticated** **and authorized**.
 
-![](<../../../.gitbook/assets/image (651) (1) (1) (1).png>)
+![](<../../../.gitbook/assets/image (651) (1) (1) (1) (1).png>)
 
 If an attacker somehow manages to **inject a Mutationg Adminssion Controller**, he will be able to **modify already authenticated requests**. Being able to potentially privesc, and more usually persist in the cluster.
 

diff --git a/...g-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md b/...g-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md
@@ -75,7 +75,7 @@ In case you can **make an app resolve a JNDI LDAP UR**L, you can control the LDA
 
 #### Deserialization exploit
 
-![](<../../.gitbook/assets/image (654) (1) (1).png>)
+![](<../../.gitbook/assets/image (654) (1) (1) (1).png>)
 
 The **exploit is serialized** and will be deserialized.\
 In case `trustURLCodebase` is `true`, an attacker can provide his own classes in the codebase if not, he will need to abuse gadgets in the classpath.

diff --git a/pentesting-web/deserialization/python-yaml-deserialization.md b/pentesting-web/deserialization/python-yaml-deserialization.md
@@ -24,7 +24,7 @@ print(yaml.dump(range(1,10)))
 
 Check how the **tuple** isn’t a raw type of data and therefore it was **serialized**. And the same happened with the **range** (taken from the builtins).
 
-![](<../../.gitbook/assets/image (628).png>)
+![](<../../.gitbook/assets/image (628) (1).png>)
 
 **safe\_load()** or **safe\_load\_all()** uses SafeLoader and **don’t support class object deserialization**. Class object deserialization example:
 

diff --git a/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md b/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md
@@ -92,7 +92,7 @@ There could be another problem, if the **response** to the legit request **conta
 
 However, the **HEAD** request **doesn't contain a body** but it usually **contains** the **Content-Length** as if the request was a GET request. Therefore, sending a **HEAD** request **instead of a POST** request you can **read the HEAD Content-Length** bytes of the smuggled request response.
 
-![](<../../.gitbook/assets/image (628) (1).png>)
+![](<../../.gitbook/assets/image (628) (1) (1).png>)
 
 ### Leaking Internal Headers via Tunneling
 

diff --git a/pentesting-web/http-response-smuggling-desync.md b/pentesting-web/http-response-smuggling-desync.md
@@ -70,7 +70,7 @@ Therefore, if an attacker **injects** a **HEAD** request, like in this images:
 
 Then, **once the blue one is responded to the attacker**, the next victims request is going to be introduced in the queue:
 
-![](<../.gitbook/assets/image (651) (1) (1) (1) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (1) (1) (1) (1).png>)
 
 Then, the **victim** will **receive** the **response** from the **HEAD** request, which is **going to contain a Content-Length but no content at all**. Therefore, the proxy **won't send this response** to the victim, but will **wait** for some **content**, which actually is going to be **response to the yellow request** (also injected by the attacker):
 
@@ -80,7 +80,7 @@ Then, the **victim** will **receive** the **response** from the **HEAD** request
 
 Following the previous example, knowing that you can **control the body** of the request whose response is going to receive the victim and that a **HEAD** **response** usually contains in its headers the **Content-Type and the Content-Length**, you can **send a request like the following** one to **cause XSS** in the victim without the page being vulnerable to XSS:
 
-![](<../.gitbook/assets/image (654) (1) (1) (1).png>)
+![](<../.gitbook/assets/image (654) (1) (1) (1) (1).png>)
 
 ### Cache Poisoning
 

diff --git a/pentesting/5353-udp-multicast-dns-mdns.md b/pentesting/5353-udp-multicast-dns-mdns.md
@@ -29,7 +29,7 @@ To request a PTR record, clients use the name form "\<Service>.\<Domain>". The *
 
 The part of the PTR record to the **left** of the colon is its **name**, and the part on the **right** is the **SRV** **record** to which the PTR record points. The **SRV** record lists the target **host** and **port** where the **service** instance can be reached. For example, the next image shows a "test.\_ipps.\_tcp.local" SRV record in Wireshark in host ubuntu.local and port 8000:
 
-![](<../.gitbook/assets/image (651) (1) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (1) (1).png>)
 
 Therefore, the **name of the SRV** record is **like** the **PTR** record **preceded** by the **\<Instance>** name (test in this case). The **TXT** has the **same** **name** as the **SRV** record and contains the information needed when the IP address and port number (contained in the SRV record) for a service aren’t sufficient to identify it.
 

diff --git a/pentesting/pentesting-kubernetes/exposing-services-in-kubernetes.md b/pentesting/pentesting-kubernetes/exposing-services-in-kubernetes.md
@@ -87,7 +87,7 @@ If you **don't specify** the **nodePort** in the yaml (it's the port that will b
 
 Exposes the Service externally **using a cloud provider's load balancer**. On GKE, this will spin up a [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) that will give you a single IP address that will forward all traffic to your service.
 
-![](<../../.gitbook/assets/image (654) (1).png>)
+![](<../../.gitbook/assets/image (654) (1) (1).png>)
 
 You have to pay for a LoadBalancer per exposed service, which can get expensive.
 

diff --git a/todo/hardware-hacking/jtag.md b/todo/hardware-hacking/jtag.md
@@ -17,6 +17,6 @@ In Arduino, after connecting the cables (pin 2 to 11 to JTAG pins and Arduino GN
 Configure **"No line ending" and 115200baud**.\
 Send the command s to start scanning:
 
-![](<../../.gitbook/assets/image (651) (1).png>)
+![](<../../.gitbook/assets/image (651) (1) (1).png>)
 
 If you are contacting a JTAG, you will find one or several **lines starting by FOUND!** indicating the pins of JTAG.
diff --git a/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md b/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md
@@ -35,10 +35,46 @@ In [**this excellent article**](http://dronesec.pw/blog/2019/08/22/exploiting-le
 * THREAD\_DIRECT\_IMPERSONATION
 * THREAD\_SET\_CONTEXT
 
-### File & Key
+### File, Key & Section Handles
 
 If an **unprivileged process inherits** a **handle** with **write** equivalent **permissions** over a **privileged file or registry**, it will be able to **overwrite** the file/registry (and with a lot of **luck**, **escalate privileged**).
 
+**Section Handles** are similar to file handles, the common name of this kinds of [objects is **"File Mapping"**](https://docs.microsoft.com/en-us/windows/win32/memory/file-mapping). They are used to work with **big files without keeping the entire** file in memory. That makes the exploitation kind of "similar" to the exploitation of a File Handle.
+
+## How to see handles of processes
+
+### Process Hacker
+
+****[**Process Hacker**](https://github.com/processhacker/processhacker) is a tool you can download for free. It has several amazing options to inspect processes and one of them is the **capability to see the handles of each process**.
+
+Note that in order to **see all the handles of all the processes, the SeDebugPrivilege is needed** (so you need to run Process Hacker as administrator).
+
+To see the handles of a process, right click in the process and select Handles:
+
+![](<../../.gitbook/assets/image (651).png>)
+
+You can then right click on the handle and **check the permissions**:
+
+![](<../../.gitbook/assets/image (628).png>)
+
+### Sysinternals Handles
+
+The [**Handles** ](https://docs.microsoft.com/en-us/sysinternals/downloads/handle)binary from Sysinternals will also list the handles per process in the console:
+
+![](<../../.gitbook/assets/image (654).png>)
+
+### Methodology
+
+Now that you know how to find handles of processes what you need to check is if any **unprivileged process is having access to privileged handles**. In that case, the user of the process could be able to obtain the handle and abuse it to escalate privileges.
+
+{% hint style="warning" %}
+It was mentioned before that you need the SeDebugPrivilege to access all the handles. But a **user can still access the handles of his processes**, so it might be useful if you want to privesc just from that user to **execute the tools with the user regular permissions**.
+
+```bash
+handle64.exe /a | findstr /r /i "process thread file key pid:"
+```
+{% endhint %}
+
 ## Vulnerable Example
 
 For example, the following code belongs to a **Windows service** that would be vulnerable. The vulnerable code of this service binary is located inside the **`Exploit`** function. This function is starts **creating a new handle process with full access**. Then, it's **creating a low privileged process** (by copying the low privileged token of _explorer.exe_) executing _C:\users\username\desktop\client.exe_. The **vulnerability resides in the fact it's creating the low privileged process with `bInheritHandles` as `TRUE`**.