GitBook: [#3058] No subject

cloud-security/concourse.md

@@ -143,6 +143,31 @@ Moreover, Concourse supports different credential managers:
 Note that if you have some kind of **write access to Concourse** you can create jobs to **exfiltrate those secrets** as Concourse needs to be able to access them.
 {% endhint %}
 
+## Architecture
+
+![](<../.gitbook/assets/image (651).png>)
+
+### ATC: web UI & build scheduler
+
+The ATC is the heart of Concourse. It runs the **web UI and API** and is responsible for all pipeline **scheduling**. It **connects to PostgreSQL**, which it uses to store pipeline data (including build logs).
+
+The [checker](https://concourse-ci.org/checker.html)'s responsibility is to continously checks for new versions of resources. The [scheduler](https://concourse-ci.org/scheduler.html) is responsible for scheduling builds for a job and the [build tracker](https://concourse-ci.org/build-tracker.html) is responsible for running any scheduled builds. The [garbage collector](https://concourse-ci.org/garbage-collector.html) is the cleanup mechanism for removing any unused or outdated objects, such as containers and volumes.
+
+### TSA: worker registration & forwarding
+
+The TSA is a **custom-built SSH server** that is used solely for securely **registering** [**workers**](https://concourse-ci.org/internals.html#architecture-worker) with the [ATC](https://concourse-ci.org/internals.html#component-atc).
+
+The TSA by **default listens on port `2222`**, and is usually colocated with the [ATC](https://concourse-ci.org/internals.html#component-atc) and sitting behind a load balancer.
+
+The **TSA implements CLI over the SSH connection,** supporting [**these commands**](https://concourse-ci.org/internals.html#component-tsa).
+
+### Workers
+
+In order to execute tasks concourse must have some workers. These workers **register themselves** via the [TSA](https://concourse-ci.org/internals.html#component-tsa) and run the services [**Garden**](https://github.com/cloudfoundry-incubator/garden) and [**Baggageclaim**](https://github.com/concourse/baggageclaim).
+
+* **Garden**: This is the **Container Manage AP**I, usually run in **port 7777** via **HTTP**.
+* **Baggageclaim**: This is the **Volume Management API**, usually run in **port 7788** via **HTTP**.
+
 ## Concourse Enumeration
 
 In order to enumerate a concourse environment you first need to **gather valid credentials** or to find an **authenticated token** probably in a `.flyrc` config file.
@@ -206,3 +231,7 @@ If you have enough privileges (**member role or more**) you will be able to **li
 ```bash
 fly -t tutorial intercept --job pipeline-name/job-name
 ```
+
+## References
+
+* [https://concourse-ci.org/internals.html#architecture-worker](https://concourse-ci.org/internals.html#architecture-worker)

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

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

@@ -51,7 +51,7 @@ As you can see in the previous command line it said that it found 0 errors. This
 
 To connect with the bus pirate you can follow the docs:
 
-![](<../../.gitbook/assets/image (307).png>)
+![](<../../.gitbook/assets/image (307) (2).png>)
 
 In this case I'm going to connect to an EPROM: ATMEL901 24C256 PU27:
 

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