gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/github-security/abusing-github-actions

Browse Source
This commit is contained in:
Translator
2025-06-25 00:23:39 +00:00
parent 8be9eb4b92
commit 3b3345cca3
2 changed files with 113 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/images/CH_logo_ads.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
+113 -72
View File
@@ -2,29 +2,39 @@
{{#include ../../../banners/hacktricks-training.md}}
## Araçlar
Aşağıdaki araçlar, Github Action iş akışlarını bulmak ve hatta savunmasız olanları tespit etmek için faydalıdır:
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Ayrıca [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) adresindeki kontrol listesini kontrol edin
## Temel Bilgiler
Bu sayfada şunları bulacaksınız:
- Bir saldırganın Github Action'a erişim sağlaması durumunda **tüm etkilerin özeti**
- **Bir action'a erişim sağlama** yolları:
- Action oluşturmak için **izinlere** sahip olmak
- Bir saldırganın Github Action'a erişim sağlaması durumunda tüm etkilerin **özeti**
- Bir **action'a erişim sağlama** 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** ile ilgili **post-exploitation teknikleri** hakkında bir bölüm (belirtilen etkileri yaratmak için)
- Son olarak, bir action'ı içeriden kötüye kullanmak için **post-exploitation teknikleri** hakkında bir bölüm (belirtilen etkileri yaratmak için)
## Etkilerin Özeti
[**Github Actions hakkında temel bilgileri kontrol edin**](../basic-github-information.md#github-actions) için bir giriş.
Eğer bir **repository** içinde **arbitrary code** çalıştırabiliyorsanız, şunları yapabilirsiniz:
Eğer bir **depo** içinde **Github Actions'ta 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ı**.
- Pipeline'a monte edilmiş **gizli bilgileri çalmak** ve dış platformlara, örneğin AWS ve GCP'ye yetkisiz erişim sağlamak için **pipeline'ın ayrıcalıklarını kötüye kullanmak**.
- **Dağıtımları** ve diğer **artifaktları** tehlikeye atmak.
- 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**, hesaplama gücünü kötüye kullanmak ve diğer sistemlere pivotlamak.
- `GITHUB_TOKEN` ile ilişkili izinlere bağlı olarak **repository kodunu üzerine yazmak**.
- **Özel işçilerde kod çalıştırmak**, hesaplama gücünü kötüye kullanmak ve diğer sistemlere geçiş yapmak.
- `GITHUB_TOKEN` ile ilişkili izinlere bağlı olarak **depo kodunu üzerine yazmak**.
## GITHUB_TOKEN
@@ -32,14 +42,14 @@ Bu "**gizli**" ( `${{ secrets.GITHUB_TOKEN }}` ve `${{ github.token }}`'den gele
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
Bu token, bir **Github Uygulaması'nın** kullanacağı aynı token'dır, bu nedenle aynı uç noktalara erişebilir: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
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](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
> [!WARNING]
> Github, bir repo'nun `GITHUB_TOKEN` kullanarak diğer iç repolara erişmesine olanak tanıyan [**flow**](https://github.com/github/roadmap/issues/74) yayınlamalıdır.
> Github, `GITHUB_TOKEN` kullanarak bir repo'nun diğer iç reposuna erişmesine izin veren [**bir akış**](https://github.com/github/roadmap/issues/74) yayınlamalıdır.
Bu token'ın olası **izinlerini** şurada görebilirsiniz: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](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.\
Token'ın **iş 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:
@@ -111,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
<details>
<summary>Gizli anahtarlarla ters shell al</summary>
<summary>Secrets ile ters shell al</summary>
```yaml
name: revshell
on:
@@ -143,17 +153,17 @@ Github Token'ına verilen izinleri diğer kullanıcıların depolarında **logla
> [!NOTE]
> 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, [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) kısmını kontrol edebilirsiniz.
> Bu senaryoda iseniz, [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) bölümüne göz atabilirsiniz.
### Depo Oluşturarak Çalıştırma
### Depo Oluşturma ile Çalıştırma
Bir organizasyonun üyeleri **yeni depolar oluşturabiliyorsa** ve github eylemlerini çalıştırabiliyorsanız, **yeni bir depo oluşturup organizasyon seviyesinde ayarlanan gizli bilgileri çalabilirsiniz**.
Eğer bir organizasyonun üyeleri **yeni depolar oluşturabiliyorsa** ve github eylemlerini çalıştırabiliyorsanız, **yeni bir depo oluşturup organizasyon seviyesinde ayarlanmış gizli bilgileri çalabilirsiniz**.
### Yeni Bir Dal Üzerinden Çalıştırma
### Yeni 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 dal üzerinden çalıştırabilirsiniz**. Bu şekilde **depo ve organizasyon seviyesindeki gizli bilgileri dışarı sızdırabilirsiniz** (ama bunların nasıl adlandırıldığını bilmeniz gerekir).
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ıya çıkarabilirsiniz** (ama bunların nasıl adlandırıldığını bilmeniz gerekir).
Değiştirilen eylemi **manuel olarak** çalıştırabilirsiniz, bir **PR oluşturulduğunda** veya **bazı kodlar yüklendiğinde** (ne kadar dikkat çekmek istediğinize bağlı olarak):
Değiştirilen eylemi **manuel olarak** çalıştırabilirsiniz, bir **PR oluşturulduğunda** veya **bazı kodlar itildiğinde** (ne kadar dikkat çekmek istediğinize bağlı olarak):
```yaml
on:
workflow_dispatch: # Launch manually
@@ -174,7 +184,7 @@ branches:
### `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 sizin **ilk kez** **işbirliği** yapmanızsa, bazı **bakıcıların** iş akışının **çalıştırılmasını** **onaylaması** gerekecektir:
Workflow tetikleyicisi **`pull_request`**, bazı istisnalarla birlikte her seferinde bir pull request alındığında workflow'u çalıştırır: varsayılan olarak, eğer bu sizin **ilk kez** **işbirliği** yapmanızsa, bazı **bakıcıların** workflow'un **çalıştırılmasını** **onaylaması** gerekecektir:
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
@@ -185,31 +195,31 @@ branches:
Ayrıca, varsayılan olarak **yazma izinlerini** ve **gizli verilere erişimi** hedef depoya engeller, [**belgelere**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) göre:
> `GITHUB_TOKEN` hariç, **gizli veriler bir iş akışı bir **forked** depodan tetiklendiğinde** çalıştırıcıya **geçmez**. **`GITHUB_TOKEN`'ın pull request'lerde **forked** depolardan yalnızca okuma izinleri vardır**.
> `GITHUB_TOKEN` hariç, **gizli veriler bir workflow tetiklendiğinde** **forked** bir depodan **çalıştırıcıya geçmez**. **`GITHUB_TOKEN`'ın sadece okuma izinleri** vardır, **forked 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.
> [!CAUTION]
> **Evet, eğer saldırgan PR'de tetiklenecek github action'ı değiştirirse, onun Github Action'ı kullanılacak ve orijinal depodaki değil!**
> **Evet, eğer saldırgan PR'de tetiklenecek github action'ı değiştirirse, kullanılan Github Action onunki olacak 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**.
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 dosyalar yükleyebilir**.
### **`pull_request_target`**
**`pull_request_target`** iş akışı tetikleyicisi, hedef depoya **yazma iznine** ve **gizli verilere erişime** sahiptir (ve izin istemez).
Workflow tetikleyicisi **`pull_request_target`**, hedef depoya **yazma iznine** ve **gizli verilere erişime** sahiptir (ve izin istemez).
**`pull_request_target`** iş akışı tetikleyicisinin **PR tarafından verilen** bağlamda değil, **temel bağlamda** çalıştığını unutmayın (güvenilmeyen kodu **çalıştırmamak için**). `pull_request_target` hakkında daha fazla bilgi için [**belgelere**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) bakın.\
Workflow tetikleyicisinin **`pull_request_target`** **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**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) bakın.\
Ayrıca, bu özel tehlikeli kullanım hakkında daha fazla bilgi için bu [**github blog yazısını**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) kontrol edin.
**`pull_request_target`** kullanmanın **güvenli** olduğunu düşündürebilir çünkü **çalıştırılan iş akışı** **temelde** tanımlanmıştır ve **PR'de** değil, ancak bunun **güvenli olmadığı birkaç durum vardır**.
**Çalıştırılan workflow** temel tanımda olduğu ve **PR'de** olmadığı için **`pull_request_target`** kullanmanın **güvenli** olduğu gibi görünebilir, ancak bunun **güvenli olmadığı birkaç durum vardır**.
Ve bu, **gizli verilere erişim** sağlayacaktır.
### `workflow_run`
[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) tetikleyicisi, bir iş akışı `tamamlandığında`, `istek yapıldığında` veya `devam ediyor` olduğunda başka bir iş akışını çalıştırmaya olanak tanır.
[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) tetikleyicisi, bir workflow'un `tamamlandığında`, `istek yapıldığında` veya `devam ederken` başka bir workflow'dan ç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:
Bu örnekte, bir workflow, ayrı "Testleri Çalıştır" workflow'u tamamlandıktan sonra çalışacak şekilde yapılandırılmıştır:
```yaml
on:
workflow_run:
@@ -217,29 +227,29 @@ 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**.
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 anahtarlara 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 blogda**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**bulunabilir.** İlk örnek, **`workflow_run`** tetiklenen iş akışının saldırganın kodunu indirmesidir: `${{ github.event.pull_request.head.sha }}`\
Bu tür bir iş akışı, **dış bir kullanıcı tarafından** **`pull_request`** veya **`pull_request_target`** ile **tetiklenebilen** bir **iş akışına** **bağlıysa** saldırıya uğrayabilir. Birkaç savunmasız örnek [**bu blogda**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**bulunabilir.** İ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`'tan çalıştırıldığında kullanılan/indirilen kodun orijinalden mi yoksa fork edilmiş PR'den mi olduğunu kontrol et
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 Execution'ı Kötüye Kullanma
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:
Dış bir saldırganın bir github iş akışını çalıştırma yollarını 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 **yetkilendirmesi** gerekiyor ve bazı [kısıtlamalarla](#pull_request) çalışacak.
**`pull_request_target` veya `workflow_run`** kullanan bir iş akışında, **`pull_request_target` veya `pull_request`** aracılığıyla 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**.
**`pull_request_target` veya `workflow_run`** kullanan bir iş akışında, **`pull_request_target` veya `pull_request`** ile 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**.
> [!CAUTION]
> Ancak, eğer **action**'da **açık bir PR checkout** varsa, bu **PR'den kod alacak** (veya temelden değil), saldırganın kontrolündeki kodu kullanacaktır. Örneğin (PR kodunun indirildiği 12. satıra bakın):
> Ancak, eğer **action**'da **açık bir PR checkout** varsa ve bu **PR'dan 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):
<pre class="language-yaml"><code class="lang-yaml"># GÜVENLİ DEĞİL. Sadece bir örnek olarak verilmiştir.
on:
@@ -269,14 +279,14 @@ message: |
Thank you!
</code></pre>
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**.
Potansiyel olarak **güvenilmeyen kod, `npm install` veya `npm build` sırasında çalıştırılmaktadır** çünkü build scriptleri ve referans verilen **paketler PR yazarının kontrolündedir**.
> [!WARNING]
> Savunmasız eylemleri aramak için bir github dork'u: `event.pull_request pull_request_target extension:yml` ancak, eylem güvensiz 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ün kim olduğuna dair koşullu ifadeler kullanmak).
> Savunmasız action'ları aramak için bir github dork'u: `event.pull_request pull_request_target extension:yml` ancak, action güvenli bir şekilde yapılandırılmasa 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 gibi).
### Bağlam Script Enjeksiyonları <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
Belirli [**github bağlamları**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) vardır ki 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 **rastgele kod çalıştırmaya** yol açabilir:
Belirli [**github bağlamları**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) olduğunu unutmayın, bu bağlamları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 **rastgele kod çalıştırmaya** yol açabilir:
{{#ref}}
gh-actions-context-script-injections.md
@@ -286,21 +296,61 @@ gh-actions-context-script-injections.md
Belgelerden: Bir iş akışı işinde herhangi bir sonraki adımda kullanılabilir bir **çevre değişkeni** oluşturmak veya güncellemek için bu değişkeni tanımlayarak ve **`GITHUB_ENV`** çevre dosyasına yazarak yapabilirsiniz.
Eğer bir saldırgan bu **env** değişkeninin içine **herhangi bir değer** enjekte edebilirse, **LD_PRELOAD** veya **NODE_OPTIONS** gibi sonraki adımlarda kod çalıştırabilecek env değişkenlerini enjekte edebilir.
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**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) ve [**bu**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), bir iş akışının **`GITHUB_ENV`** env değişkeninin içeriğini depolamak için yüklenen bir artifact'a güvenmesi durumunu hayal edin. Bir saldırgan bunu tehlikeye atmak için şöyle bir şey yükleyebilir:
Örneğin ([**bu**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) ve [**bu**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), **`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:
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
### Savunmasız Üçüncü Taraf Github Eylemleri
### Dependabot ve diğer güvenilir botlar
[**Bu blog yazısında**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) belirtildiği gibi, birçok kuruluşun `dependabot[bot]`'tan gelen herhangi bir PR'yi birleştiren bir Github Action'ı vardır.
```yaml
on: pull_request_target
jobs:
auto-merge:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m
```
Bu, `github.actor` alanının, iş akışını tetikleyen en son olayı başlatan kullanıcıyı içerdiği için bir sorun. Ve `dependabot[bot]` kullanıcısının bir PR'yi değiştirmesi için birkaç yol var. Örneğin:
- Kurban deposunu fork'lamak
- Kopyanıza kötü niyetli yükü eklemek
- Fork'unuzda eski bir bağımlılık ekleyerek Dependabot'u etkinleştirmek. Dependabot, kötü niyetli kodla bağımlılığı düzelten bir dal oluşturacaktır.
- O daldan kurban deposuna bir Pull Request açmak (PR, kullanıcı tarafından oluşturulacak, bu yüzden henüz bir şey olmayacak)
- Sonra, saldırgan, fork'unda Dependabot'un açtığı ilk PR'ye geri döner ve `@dependabot recreate` komutunu çalıştırır
- Ardından, Dependabot o dalda bazı işlemler gerçekleştirir, bu da kurban deposundaki PR'yi değiştirir, bu da `dependabot[bot]`'u iş akışını tetikleyen en son olayın aktörü yapar (ve dolayısıyla, iş akışı çalışır).
Devam edelim, eğer Github Action bir komut enjeksiyonu içerseydi, ne olurdu:
```yaml
on: pull_request_target
jobs:
just-printing-stuff:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}
```
İyi, orijinal blog yazısı bu davranışı kötüye kullanmak için iki seçenek öneriyor, bunlardan ikincisi:
- Kurban deposunu fork'layın ve bazı eski bağımlılıklarla Dependabot'u etkinleştirin.
- Kötü niyetli shell enjeksiyon koduyla yeni bir dal oluşturun.
- Depo için varsayılan dalı bu dal olarak değiştirin.
- Bu daldan kurban deposuna bir PR oluşturun.
- PR'da Dependabot'un fork'unda açtığı `@dependabot merge` komutunu çalıştırın.
- Dependabot, fork'lanmış deponuzun varsayılan dalına değişikliklerini birleştirecek ve kurban deposundaki PR'ı güncelleyerek `dependabot[bot]`'u iş akışını tetikleyen son olayın aktörü yapacak ve kötü niyetli bir dal adı kullanacak.
### Hassas Üçüncü Taraf Github Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
[**bu blog yazısında**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) belirtildiği gibi, bu Github Eylemi farklı iş akışlarından ve hatta depolardan artifact'lara erişim sağlar.
[**bu blog yazısında**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) belirtildiği gibi, bu Github Action farklı iş akışlarından ve hatta depolardan artefaktlara 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.
Sorun şu ki, **`path`** parametresi ayarlanmazsa, artefakt mevcut dizine çıkarılır ve daha sonra iş akışında kullanılabilecek veya hatta çalıştırılabilecek dosyaları geçersiz kılabilir. Bu nedenle, eğer Artefakt hassassa, bir saldırgan bunu, Artefakt'a güvenen diğer iş akışlarını tehlikeye atmak için kötüye kullanabilir.
Savunmasız bir iş akışı örneği:
Hassas iş akışı örneği:
```yaml
on:
workflow_run:
@@ -344,10 +394,10 @@ path: ./script.py
### 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 **silinenle aynı isimde bir depo oluşturmasına** izin verecektir.
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'den az yıldız aldıysa**, Github, aynı isimle yeni kayıtlı kullanıcının **silinenle aynı isimde bir depo oluşturmasına** izin verecektir.
> [!CAUTION]
> 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.
> Yani, eğer bir işlem var olmayan bir hesaptan bir depo 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/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
@@ -356,11 +406,11 @@ Eğer diğer depolar **bu kullanıcı depolarından bağımlılıklar** kullanı
## Repo Pivotlama
> [!NOTE]
> 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).
> 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ümü kontrol edin).
### Önbellek Zehirleme
### Cache Zehirleme
Bir önbellek, **aynı dalda workflow çalışmaları arasında** korunur. Bu, bir saldırganın **bir paketi tehlikeye atması** durumunda, bu paketin önbellekte saklanıp **daha ayrıcalıklı** bir workflow tarafından **indirilip** çalıştırılması halinde, o workflow'u da **tehlikeye atabileceği** anlamına gelir.
Bir cache, **aynı dalda workflow çalışmaları arasında** korunur. Bu, bir saldırganın **bir paketi tehlikeye atması** durumunda, bu paketin cache'de saklanacağı ve **daha yetkili** bir workflow tarafından **indirilip** çalıştırılacağı anlamına gelir; bu durumda o workflow'u da **tehlikeye atabilecektir**.
{{#ref}}
gh-actions-cache-poisoning.md
@@ -368,7 +418,7 @@ gh-actions-cache-poisoning.md
### Artifact Zehirleme
Workflow'lar, **diğer workflow'lardan ve hatta depolardan artifact'ler** kullanabilir. Eğer bir saldırgan, başka bir workflow tarafından daha sonra kullanılan bir **artifact'ı yükleyen** Github Action'ı **tehlikeye atmayı** başarırsa, o **diğer workflow'ları da tehlikeye atabilir**:
Workflow'lar **diğer workflow'lardan ve hatta depolardan** **artifact'lar** kullanabilir; eğer bir saldırgan, başka bir workflow tarafından daha sonra kullanılan bir **artifact'ı yükleyen** Github Action'ı **tehlikeye atmayı** başarırsa, o zaman **diğer workflow'ları da tehlikeye atabilir**:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -376,11 +426,11 @@ gh-actions-artifact-poisoning.md
---
## Bir Aşama Sonrası Sömürü
## Bir Aksiyon Sonrası Sömürü
### OIDC Üzerinden AWS ve GCP'ye Erişim
Aşağıdaki sayfalara bakın:
Aşağıdaki sayfaları kontrol edin:
{{#ref}}
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -394,7 +444,7 @@ Aşağıdaki sayfalara bakın:
Eğer bir script'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.
- Eğer gizli bilgi veya token bir **çevre değişkeni** olarak ayarlandıysa, **`printenv`** kullanarak çevre üzerinden doğrudan erişilebilir.
<details>
@@ -425,7 +475,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
<details>
<summary>Gizli anahtarlarla ters shell al</summary>
<summary>Secrets ile ters shell al</summary>
```yaml
name: revshell
on:
@@ -448,7 +498,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
- Eğer gizli bilgi **bir ifadede doğrudan kullanılıyorsa**, oluşturulan shell scripti **diskte** saklanır ve erişilebilir.
- Eğer gizli bilgi **bir ifadede doğrudan** kullanılıyorsa, oluşturulan shell scripti **diskte** saklanır ve erişilebilir.
- ```bash
cat /home/runner/work/_temp/*
```
@@ -466,11 +516,11 @@ key: ${{ secrets.PUBLISH_KEY }}
### Kendinden Barındırılan Çalıştırıcıları Kötüye Kullanma
**Github Actions'ın non-github altyapısında hangi eylemlerin çalıştırıldığını** bulmanın yolu, Github Action yapılandırma yaml'ında **`runs-on: self-hosted`** aramaktır.
**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**, diğer **ağ sistemlerine** (ağda savunmasız uç noktalar mı? meta veri servisi?) erişim sağlayabilir veya, izolasyon sağlansa 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ı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, **\_Runner.Listener**\_\*\* sürecinden gizli bilgileri elde etmek de mümkündür\*\*; bu süreç, bellek dökümü yapılarak herhangi bir adımda iş akışlarının tüm gizli bilgilerini içerecektir:
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:
```bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
@@ -484,7 +534,7 @@ Aşağıdaki genişletilebilir örnekte bir örnek bulabilirsiniz:
<details>
<summary>Github Eylemi Docker Görüntüsü Oluştur ve Yükle</summary>
<summary>Github Action Docker Görüntüsü Oluştur & Yükle</summary>
```yaml
[...]
@@ -517,7 +567,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
Ö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 token'ı kullanarak Docker Görüntüsünü indirebilir:
Repo üzerinde okuma izinlerine sahip bir kullanıcı, kişisel erişim token'ı 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>
@@ -530,24 +580,15 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
### 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ş **diğer hassas veriler** gizli kalmayacaktır. Örneğin, bir gizli değerle imzalanmış bir JWT, [özellikle yapılandırılmadıkça](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) gizli kalmayacaktır.
**Github** gizli değerleri **tespit etmeye** ve **göstermemeye** çalışsa da, eylemin yürütülmesi sırasında üretilmiş **diğer hassas veriler** gizli kalmayacaktır. Örneğin, bir gizli değerle imzalanmış bir JWT gizli kalmayacaktır, eğer [özellikle yapılandırılmamışsa](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
## İzlerinizi Kapatma
## İzlerinizi Gizleme
([**buradan**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) bir 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'lar 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** internetten gizleyecektir (temelde tüm istismar PR'larınızı kaldırır).
([**buradan**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) bir 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, **internet üzerindeki bir PR'ı silemeyiz**, ancak bir twist var. Github tarafından **askıya alınan** hesaplar için, tüm **PR'lar 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'larınızı 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.
> [!WARNING]
> 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/CycodeLabs/raven)
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
> 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.
{{#include ../../../banners/hacktricks-training.md}}