diff --git a/.gitbook/assets/image (651) (1) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1) (1) (1) (1).png new file mode 100644 index 000000000..47a9e657a Binary files /dev/null and b/.gitbook/assets/image (651) (1) (1) (1) (1) (1) (1).png differ diff --git a/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png index 47a9e657a..4d79f5764 100644 Binary files a/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png and b/.gitbook/assets/image (651) (1) (1) (1) (1) (1).png differ diff --git a/.gitbook/assets/image (651) (1) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1) (1).png index 4d79f5764..fcb7c18a6 100644 Binary files a/.gitbook/assets/image (651) (1) (1) (1) (1).png and b/.gitbook/assets/image (651) (1) (1) (1) (1).png differ diff --git a/.gitbook/assets/image (651) (1) (1) (1).png b/.gitbook/assets/image (651) (1) (1) (1).png index fcb7c18a6..5c11c2d01 100644 Binary files a/.gitbook/assets/image (651) (1) (1) (1).png and b/.gitbook/assets/image (651) (1) (1) (1).png differ diff --git a/.gitbook/assets/image (651) (1) (1).png b/.gitbook/assets/image (651) (1) (1).png index 5c11c2d01..3f14c6127 100644 Binary files a/.gitbook/assets/image (651) (1) (1).png and b/.gitbook/assets/image (651) (1) (1).png differ diff --git a/.gitbook/assets/image (651) (1).png b/.gitbook/assets/image (651) (1).png index 3f14c6127..20c8def05 100644 Binary files a/.gitbook/assets/image (651) (1).png and b/.gitbook/assets/image (651) (1).png differ diff --git a/.gitbook/assets/image (651).png b/.gitbook/assets/image (651).png index 20c8def05..8b7813787 100644 Binary files a/.gitbook/assets/image (651).png and b/.gitbook/assets/image (651).png differ diff --git a/cloud-security/concourse/concourse-architecture.md b/cloud-security/concourse/concourse-architecture.md index 9ca2cb87a..f46e183ce 100644 --- a/cloud-security/concourse/concourse-architecture.md +++ b/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 diff --git a/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md b/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md index fa11e4d05..de557ebb6 100644 --- a/cloud-security/pentesting-kubernetes/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/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 `), 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. diff --git a/external-recon-methodology/README.md b/external-recon-methodology/README.md index 3a4e5b127..f167a24de 100644 --- a/external-recon-methodology/README.md +++ b/external-recon-methodology/README.md @@ -17,7 +17,7 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com) {% hint style="danger" %} -**** +******** **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! diff --git a/pentesting-web/http-response-smuggling-desync.md b/pentesting-web/http-response-smuggling-desync.md index a8e7edbc7..fbdb5ccc6 100644 --- 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) (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): diff --git a/pentesting/5353-udp-multicast-dns-mdns.md b/pentesting/5353-udp-multicast-dns-mdns.md index 7838779bd..db992b72b 100644 --- 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 "\.\". 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 **\** 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/todo/hardware-hacking/jtag.md b/todo/hardware-hacking/jtag.md index ff3f8cf5a..c42bf5bcc 100644 --- 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) (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. diff --git a/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md b/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md index a8bdb0224..2382c3bf4 100644 --- a/windows/windows-local-privilege-escalation/leaked-handle-exploitation.md +++ b/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