gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-25 04:15:49 -08:00
Code Issues Packages Projects Releases Wiki Activity
Files
154465e69f246770f32ce8a0abe6b1e5acba7541
hacktricks-cloud/src/pentesting-ci-cd/github-security/basic-github-information.md

20 KiB
Raw Blame History

Basiese Github Inligting

{{#include ../../banners/hacktricks-training.md}}

Basiese Struktuur

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.

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ê.

Boonop kan 'n gebruiker deel wees van verskillende spanne met verskillende onderneming, organisasie of repository rolle.

En uiteindelik kan repositories spesiale beskermingsmeganismes hê.

Privileges

Onderneming Rolle

  • 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.
  • Ondernemingslede: Lede van organisasies wat deur jou onderneming besit word, is ook outomaties lede van die onderneming.

Organisasie Rolle

In 'n organisasie kan gebruikers verskillende rolle hê:

  • 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.
  • Buitelandse samewerkers: 'n Buitelandse samewerker is 'n persoon wat toegang het tot een of meer organisasie repositories maar nie eksplisiet 'n lid van die organisasie is.

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

Lede Privileges

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.

Die instellings hier geconfigureer sal die volgende toestemmings van lede van die organisasie aandui:

  • 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 buitelandse 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 Rolle

Standaard word repository rolle geskep:

  • 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.

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

Jy kan ook jou eie rolle skep in https://github.com/organizations/<org_name>/settings/roles

Spanne

Jy kan die spanne wat in 'n organisasie geskep is lys in https://github.com/orgs/<org_name>/teams. Let daarop dat jy om die spanne wat kinders van ander spanne is te sien, elke ouer span moet toegang.

Gebruikers

Die gebruikers van 'n organisasie kan gelys word in https://github.com/orgs/<org_name>/people.

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 Verifikasie

Github bied verskillende maniere om jou rekening te verifieer en aksies namens jou uit te voer.

Webtoegang

Deur github.com te benader kan jy aanmeld met jou gebruikersnaam en wagwoord (en 'n 2FA moontlik).

SSH Sleutels

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

GPG Sleutels

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.

Persoonlike Toegangstokens

Jy kan 'n persoonlike toegangstoken genereer om 'n toepassing toegang tot jou rekening te gee. Wanneer 'n persoonlike toegangstoken geskep word, moet die gebruiker die toestemmings spesifiseer wat die token sal hê. https://github.com/settings/tokens

Oauth Toepassings

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.

Sommige sekuriteitsaanbevelings:

  • '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 die maatskappy verlaat, sal niemand anders toegang hê nie.
  • Meer in hier.

Github Toepassings

Github toepassings kan om toestemmings te vra om toegang tot jou github inligting 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ê.

Sommige sekuriteitsaanbevelings:

  • 'n GitHub App moet aksies onafhanklik van 'n gebruiker neem (tenzij die app 'n gebruiker-naar-bediener 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."
  • Maak seker 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 gebruik om gebruikers in te log en ander dinge te doen.
  • Moet nie 'n GitHub App bou as jy net wil optree as 'n GitHub gebruiker en alles 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 skryf toestemming hê tot die repository wat die workflow lêer bevat. Vir meer inligting, sien "Begrip van skoppe vir OAuth apps."
  • Meer in hier.

Github Actions

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 Action gegee word, kan verskeie verskillende aanvalle uitgevoer word. Sien hieronder vir meer inligting.

Git Aksies

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).

Konfigurasie

In https://github.com/organizations/<org_name>/settings/actions is dit moontlik om die konfigurasie van die github actions vir die organisasie te kontroleer.

Dit is moontlik om die gebruik van github actions heeltemal te verbied, alle github actions toe te laat, of net sekere aksies toe te laat.

Dit is ook moontlik om te konfigureer wie goedkeuring benodig om 'n Github Action te laat loop en die toestemmings van die GITHUB_TOKEN van 'n Github Action wanneer dit uitgevoer word.

Git Geheimen

Github Action benodig gewoonlik 'n soort geheim 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 Action toegang tot die geheim te gee, moet jy dit soos volg verklaar:

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 }}

Voorbeeld met Bash 

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Warning

Geheime kan slegs vanaf die Github Actions wat dit verklaar, toegang verkry.

Sodra dit in die repo of die organisasies geconfigureer is, sal gebruikers van github nie weer toegang tot hulle hê nie, hulle sal net in staat wees om hulle te verander.

Daarom is die enige manier om github geheime te steel, om toegang te hê tot die masjien wat die Github Action uitvoer (in daardie scenario sal jy slegs toegang hê tot die geheime wat vir die Action verklaar is).

Git Omgewings

Github laat toe om omgewings te skep waar jy geheime kan stoor. Dan kan jy die github action toegang gee tot die geheime binne die omgewing met iets soos:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

U kan 'n omgewing konfigureer om toegang te hê tot alle takke (standaard), slegs beskermde takke of spesifiseer watter takke toegang kan hê.
Dit kan ook 'n aantal vereiste hersienings stel voordat 'n aksie met 'n omgewing uitgevoer word of wag 'n tyd voordat ontplooiings voortgaan.

Git Action Runner

'n Github Aksie kan binne die github omgewing uitgevoer word of kan uitgevoer word in 'n derdeparty-infrastruktuur wat deur die gebruiker gekonfigureer is.

Verskeie organisasies sal toelaat dat Github Aksies in 'n derdeparty-infrastruktuur uitgevoer word, aangesien dit gewoonlik goedkoper is.

U kan die self-gehoste runners van 'n organisasie lys in https://github.com/organizations/<org_name>/settings/actions/runners

Die manier om te vind watter Github Aksies in nie-github infrastruktuur uitgevoer word is om te soek na runs-on: self-hosted in die Github Aksie konfigurasie yaml.

Dit is nie moontlik om 'n Github Aksie van 'n organisasie binne 'n self-gehoste boks van 'n ander organisasie uit te voer nie, omdat 'n unieke token vir die Runner gegenereer word wanneer dit gekonfigureer word om te weet waar die runner behoort.

As die persoonlike Github Runner in 'n masjien binne AWS of GCP gekonfigureer is, kan die Aksie toegang hê tot die metadata-eindpunt en die token van die diensrekening wat die masjien gebruik, steel.

Git Action Compromise

As alle aksies (of 'n kwaadwillige aksie) toegelaat word, kan 'n gebruiker 'n Github aksie gebruik wat kwaadwillig is en die houer waar dit uitgevoer word, kompromitteer.

Caution

'n Kwaadwillige Github Aksie kan misbruik word deur die aanvaller om:

  • Al die geheime wat die Aksie toegang het, te steel
  • Lateraal te beweeg as die Aksie binne 'n derdeparty-infrastruktuur uitgevoer word waar die SA-token wat gebruik word om die masjien te laat loop, toegang kan verkry (waarskynlik via die metadata-diens)
  • Die token wat deur die werkvloei gebruik word, te misbruik om die kode van die repo waar die Aksie uitgevoer word, te steel of selfs dit te wysig.

Takbeskermings

Takbeskermings is ontwerp om nie volledige beheer oor 'n repo aan die gebruikers te gee nie. Die doel is om verskeie beskermingsmetodes te plaas voordat daar geskryf kan word in 'n sekere tak.

Die takbeskermings van 'n repo kan gevind word in https://github.com/<orgname>/<reponame>/settings/branches

Note

Dit is nie moontlik om 'n takbeskerming op organisasievlak in te stel nie. So, al hierdie moet op elke repo verklaar word.

Verskillende beskermings kan op 'n tak toegepas word (soos op meester):

  • U kan 'n PR vereis voordat dit saamgevoeg word (so u kan nie direk kode oor die tak saamvoeg nie). As dit gekies word, kan verskillende ander beskermings in plek wees:
  • Vereis 'n aantal goedkeuringe. Dit is baie algemeen om 1 of 2 meer mense te vereis om u PR goed te keur sodat 'n enkele gebruiker nie in staat is om kode direk saam te voeg nie.
  • Verwerp goedkeuringe wanneer nuwe verbintenisse gestuur word. As nie, kan 'n gebruiker wettige kode goedkeur en dan kan die gebruiker kwaadwillige kode byvoeg en dit saamvoeg.
  • Vereis hersienings van Kode-eienaars. Ten minste 1 kode-eienaar van die repo moet die PR goedkeur (sodat "ewekansige" gebruikers dit nie kan goedkeur nie)
  • Beperk wie kan pull request hersienings verwerp. U kan mense of spanne spesifiseer wat toegelaat word om pull request hersienings te verwerp.
  • Laat gespesifiseerde akteurs toe om pull request vereistes te omseil. Hierdie gebruikers sal in staat wees om vorige beperkings te omseil.
  • Vereis status kontroles om te slaag voordat dit saamgevoeg word. Sommige kontroles moet slaag voordat die verbintenis saamgevoeg kan word (soos 'n github aksie wat kyk of daar nie enige duidelike teks geheim is nie).
  • Vereis gesprekresolusie voordat dit saamgevoeg word. Alle kommentaar op die kode moet opgelos word voordat die PR saamgevoeg kan word.
  • Vereis geskrewe verbintenisse. Die verbintenisse moet geskrewe wees.
  • Vereis lineêre geskiedenis. Voorkom dat saamvoegverbintenisse na ooreenstemmende takke gestuur word.
  • Sluit administrateurs in. As dit nie ingestel is nie, kan administrateurs die beperkings omseil.
  • Beperk wie kan na ooreenstemmende takke druk. Beperk wie 'n PR kan stuur.

Note

Soos u kan sien, selfs al het u daarin geslaag om 'n paar akrediteerbare inligting van 'n gebruiker te verkry, kan repos beskerm word wat u verhoed om kode na meester te druk om byvoorbeeld die CI/CD-pyplyn te kompromitteer.

Verwysings

{{#include ../../banners/hacktricks-training.md}}

Reference in New Issue View Git Blame Copy Permalink