GitBook: [#3136] No subject

cloud-security/concourse/concourse-architecture.md

@@ -2,7 +2,7 @@
 
 ## Architecture
 
-![](<../../.gitbook/assets/image (651) (1).png>)
+![](<../../.gitbook/assets/image (651) (1) (1).png>)
 
 ### ATC: web UI & build scheduler
 

cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -236,7 +236,7 @@ kubectl port-forward pod/mypod 5000:5000
 
 ### **Hosts Writable /var/log/ Escape**
 
- As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)**,**If you can access or create a pod with the **hosts `/var/log/` directory mounted** on it, you can **escape from the container**.\
+As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html)\*\*,\*\*If you can access or create a pod with the **hosts `/var/log/` directory mounted** on it, you can **escape from the container**.\
 This is basically because the when the **Kube-API tries to get the logs** of a container (using `kubectl logs <pod>`), it **requests the `0.log`** file of the pod using the `/logs/` endpoint of the **Kubelet** service.\
 The Kubelet service exposes the `/logs/` endpoint which is just basically **exposing the `/var/log` filesystem of the container**.
 
@@ -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) (1).png>)
+![](<../../../.gitbook/assets/image (651) (1) (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.
 

external-recon-methodology/README.md

@@ -17,7 +17,7 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
 </details>
 
 {% hint style="danger" %}
-****
+****<img src="../.gitbook/assets/image (651).png" alt="" data-size="original">****
 
 **Bug bounty tip**: sign up for **Intigriti**, a premium **bug bounty platform created by hackers, for hac**kers! Join us at [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) today, and start earning bounties up to $100,000!
 

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) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (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):
 

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) (1).png>)
+![](<../.gitbook/assets/image (651) (1) (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.
 

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) (1).png>)
+![](<../../.gitbook/assets/image (651) (1) (1) (1).png>)
 
 If you are contacting a JTAG, you will find one or several **lines starting by FOUND!** indicating the pins of JTAG.

windows/windows-local-privilege-escalation/leaked-handle-exploitation.md

@@ -51,7 +51,7 @@ Note that in order to **see all the handles of all the processes, the SeDebugPri
 
 To see the handles of a process, right click in the process and select Handles:
 
-![](<../../.gitbook/assets/image (651).png>)
+![](<../../.gitbook/assets/image (651) (1).png>)
 
 You can then right click on the handle and **check the permissions**:
 
@@ -298,7 +298,7 @@ In a real scenario you probably **won't be able to control the binary** that is
 {% endhint %}
 
 In this example you can find the code of a possible exploit for _C:\users\username\desktop\client.exe_.\
-The most interesting part of this code is located in `GetVulnProcHandle`. This function will **start fetching all the handles**, then it will **check if any of them belongs to the same PID** and if the handle belongs to a **process**. If all these requirements are completed (an accessible open process handle is found) , it try to **inject and execute a shellcode abusing the handle of the process**. \
+The most interesting part of this code is located in `GetVulnProcHandle`. This function will **start fetching all the handles**, then it will **check if any of them belongs to the same PID** and if the handle belongs to a **process**. If all these requirements are completed (an accessible open process handle is found) , it try to **inject and execute a shellcode abusing the handle of the process**.\
 The injection of the shellcode is done inside the **`Inject`** function and it will just **write the shellcode inside the privileged process and create a thread inside the same process** to execute the shellcode).
 
 ```c
@@ -512,7 +512,7 @@ In a real scenario you probably **won't be able to control the binary** that is
 
 In this example, **instead of abusing the open handle to inject** and execute a shellcode, it's going to be **used the token of the privileged open handle process to create a new one**. This is done in lines from 138 to 148.
 
-Note how the **function `UpdateProcThreadAttribute`** is used with the **attribute  `PROC_THREAD_ATTRIBUTE_PARENT_PROCESS` and the handle to the open privileged process**. This means that the **created process thread executing **_**cmd.exe**_** will have the same token privilege as the open handle process**.
+Note how the **function `UpdateProcThreadAttribute`** is used with the **attribute `PROC_THREAD_ATTRIBUTE_PARENT_PROCESS` and the handle to the open privileged process**. This means that the **created process thread executing \_cmd.exe**\_\*\* will have the same token privilege as the open handle process\*\*.
 
 ```c
 #include <windows.h>