Pentesting CI/CD Metodologija

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

VCS

VCS означава Version Control System, овај систем омогућава програмерима да управљају својим source code-ом. Најчешћи је git и обично ћете фирме наћи да га користе на једној од следећих платформи:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (они нуде своје VCS платформе)

CI/CD Pipelines

CI/CD pipelines омогућавају програмерима да аутоматизују извршавање code-а у разне сврхе, укључујући build, testing и deploy апликација. Ови аутоматизовани токови рада се активирају специфичним акцијама, као што су пушеви у репо (push), pull requests или заказани задаци. Они помажу да се процес од development-а до production-а поједностави.

Међутим, ти системи морају да се извршавају негде и обично то радију са повлашћеним credentials-има да би деплојовали code или приступили осетљивим информацијама.

VCS Pentesting Methodology

Note

Чак и ако неке VCS платформе дозвољавају креирање pipelines, за овај одељак ћемо анализирати само потенцијалне нападе на контролу source code-а.

Платформе које чувају source code вашег пројекта садрже осетљиве информације и људи морају бити веома опрезни са дозволама које дају унутар те платформе. Ово су неки уобичајени проблеми на VCS платформама које нападач може злоупотребити:

  • Leaks: Ако ваш code садржи leaks у commit-овима и нападач може приступити repo-у (јер је public или зато што има приступ), може открити leaks.
  • Access: Ако нападач може да приступи налогу на VCS платформи могао би добити већу видљивост и дозволе.
  • Register: Неке платформе ће једноставно дозволити спољним корисницима да креирају налог.
  • SSO: Неке платформе неће дозволити регистровање корисника, али ће дозволити било коме да уђе са валидним SSO (на пример нападач може користити свој github налог да уђе).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies… постоји више врста token-а које корисник може украсти да би на неки начин приступио repo-у.
  • Webhooks: VCS платформе омогућавају генерисање webhooks. Ако нису заштићени са невиђеним secrets нападач их може злоупотребити.
  • Ако нема секрета на месту, нападач може злоупотребити webhook треће стране платформе
  • Ако је secret у URL-у, исто се дешава и нападач има тај secret
  • Code compromise: Ако злонамерни актер има неки ниво write приступа над репо-овима, могао би покушати да инјектује злонамерни код. Да би био успешан можда ће морати да заобиђе branch protections. Ове акције се могу извршити са различитим циљевима:
    • Компромитовати main branch да компромитује production.
    • Компромитовати main (или друге brancheve) да компромитује developer-ске машине (јер они обично извршавају тестове, terraform или друге ствари из repo-а на својим машинама).
  • Compromise the pipeline (погледај следећи одељак)

Pipelines Pentesting Methodology

Најчешћи начин да се дефинише pipeline је коришћењем CI configuration file-а који се налази у repository-ју који pipeline гради. Тај фајл описује редослед извршених job-ова, услове који утичу на ток и подешавања build окружења.
Ови фајлови обично имају конзистентно име и формат, на пример — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), и GitHub Actions YAML фајлови смештени под .github/workflows. Када се активира, pipeline job повлачи code из изабраног извора (нпр. commit / branch), и извршава наредбе наведене у CI configuration фајлу против тог code-а.

Дакле, крајњи циљ нападача је на неки начин компромитовати те configuration фајлове или наредбе које они извршавају.

Tip

Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., “..”) to ingest host files during build and exfiltrate secrets. See:

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution (PPE) пут експлоатише дозволе у SCM repository-ју да манипулише CI pipeline-ом и изврши штетне наредбе. Корисници са неопходним дозволама могу модификовати CI configuration фајлове или друге фајлове које pipeline job користи да укључе злонамерне наредбе. Ово „поји“ CI pipeline, што доводи до извршавања тих злонамерних наредби.

Да би злонамерни актер био успешан у PPE нападу, мора:

  • Имати write access на VCS платформи, јер се pipeline-ови обично активирају када се уради push или pull request. (Погледај VCS pentesting methodology за резиме начина добијања приступа).
  • Имајте на уму да понекад један external PR може се сматрати “write access”.
  • Чак и ако има write permission-e, мора бити сигуран да може модификовати CI config file или друге фајлове на које config зависи.
  • За ово може бити потребно да заобиђе branch protections.

Постоје 3 PPE варијанте:

  • D-PPE: Direct PPE напад се дешава када актер модификује CI config фајл који ће бити извршен.
  • I-DDE: Indirect PPE напад се дешава када актер модификује неки фајл на који CI config фајл који ће бити извршен зависи (нпр. make file или terraform конфигурацију).
  • Public PPE or 3PE: У неким случајевима pipeline-ови могу бити активирани од корисника који немају write access у repo-у (и који можда чак нису ни део организације) јер могу послати PR.
  • 3PE Command Injection: Обично, CI/CD pipeline-ови ће постављати environment variables са информацијама о PR-у. Ако та вредност може бити контролисана од стране нападача (нпр. title of the PR) и користи се на опасном месту (нпр. извршавање sh commands), нападач може инјектовати команде у њега.

Exploitation Benefits

Познавање 3 варијанте пута да се poisoning pipeline омогућава преглед шта нападач може да добије након успешне експлоатације:

  • Secrets: Као што је поменуто раније, pipeline-ови захтевају повластице за своје job-ове (повлачење code-а, build, deploy…) и те повластице су обично чуване у secrets-има. Ови secrets су обично приступачни преко env variables или фајлова у систему. Стога ће нападач увек покушати да извуче што више secrets-а.
  • У зависности од pipeline платформе нападач можда мора да наведе secrets у config-у. То значи да ако нападач не може да промени CI configuration pipeline-а (I-PPE на пример), он може само исксфилтровати secrets које тај pipeline има.
  • Computation: Code се извршава негде; у зависности где се извршава, нападач може да се помери даље.
  • On-Premises: Ако се pipeline-ови извршавају on-premises, нападач може завршити у интерној мрежи са приступом више ресурса.
  • Cloud: Нападач може приступити другим машинама у cloud-у али такође може извести IAM roles/service accounts токене из њега да би добио даљи приступ у облаку.
  • Platforms machine: Понекад job-ови ће се извршавати на машинама платформе за pipeline-ове, које обично налазе у cloud-у са нема додатног приступа.
  • Select it: Понекад pipeline платформа има конфигурисане неколико машина и ако можете модификовати CI configuration file можете навести где желите да покренете злонамерни code. У таквој ситуацији, нападач ће вероватно покренути reverse shell на свакој могућој машини да покуша да даље експлоатише.
  • Compromise production: Ако сте у pipeline-у и коначна верзија се гради и деплојује из ње, можете компромитовати code који ће се наћи у production-у.

More relevant info

Tools & CIS Benchmark

  • Chain-bench је open-source алат за аудиторске провере вашег software supply chain стека у смислу сигурности, базиран на новом CIS Software Supply Chain benchmark. Аудит се фокусира на цео SDLC процес, где може открити ризике од code-а до deploy-а.

Top 10 CI/CD Security Risk

Погледајте овај занимљив чланак о top 10 CI/CD ризицима према Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

  • На свакој платформи коју можете покренути локално наћи ћете упутство како да је покренете локално да је конфигуришете по вољи за тестирање
  • Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

  • Checkov: Checkov је static code analysis алат за infrastructure-as-code.

References

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks