Afrikaans - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Basic Github Information

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Basiese Struktuur

Die basiese Github-omgewingsstruktuur van 'n groot maatskappy is om 'n onderneming te besit wat verskeie organisasies besit, en elkeen van hulle kan verskeie bewaarplekke en verskeie spanne bevat. Kleiner maatskappye mag dalk net een organisasie besit en geen ondernemings nie.

Vanuit 'n gebruikersoogpunt kan 'n gebruiker 'n lid wees van verskillende ondernemings en organisasies. Binne-in hulle kan die gebruiker verskillende onderneming-, organisasie- en bewaarplekrolle hê.

Verder kan 'n gebruiker deel wees van verskillende spanne met verskillende onderneming-, organisasie- of bewaarplekrolle.

En uiteindelik kan bewaarplekke spesiale beskermingsmeganismes hê.

Voorregte

Ondernemingrolle

  • Ondernemingseienaar: Mense met hierdie rol kan administrateurs bestuur, organisasies binne die onderneming bestuur, ondernemingsinstellings bestuur, beleid afdwing oor organisasies. Hulle kan egter nie toegang tot organisasie-instellings of inhoud hê tensy hulle 'n organisasie-eienaar is of direkte toegang tot 'n organisasie-eienaarsbewaarplek het nie.

  • Ondernemingslede: Lede van organisasies wat deur jou onderneming besit word, is ook outomaties lede van die onderneming.

Organisasierolle

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 minder as twee mense in jou organisasie nie.

  • Organisasie-lede: Die verstek, nie-administratiewe rol vir mense in 'n organisasie is die organisasie-lid. Standaard het organisasie-lede verskeie toestemmings.

  • Faktureringsbestuurders: Faktureringsbestuurders is gebruikers wat die faktureringsinstellings vir jou organisasie kan bestuur, soos betalingsinligting.

  • Sekuriteitsbestuurders: Dit is 'n rol wat organisasie-eienaars aan enige span in 'n organisasie kan toeken. Wanneer dit toegepas word, gee dit elke lid van die span toestemmings om sekuriteitswaarskuwings en -instellings regoor jou organisasie te bestuur, sowel as leestoestemmings vir alle bewaarplekke in die organisasie.

  • As jou organisasie 'n sekuriteitsspan 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-bestuursregte verleen.

  • Buiteste medewerkers: 'n Buiteste medewerker is 'n persoon wat toegang het tot een of meer organisasiebewaarplekke, maar nie uitdruklik 'n lid van die organisasie is nie.

Jy kan die toestemmings vergelyk van hierdie rolle in hierdie tabel: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Ledevoorregte

In https://github.com/organizations/<org_name>/settings/member_privileges kan jy sien watter toestemmings gebruikers net deur deel van die organisasie te wees, sal hê.

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

  • Admin, skrywer, leser of geen toestemming oor al die organisasiebewaarplekke wees.

  • As lede private, interne of openbare bewaarplekke kan skep.

  • As vurk van bewaarplekke moontlik is.

  • As dit moontlik is om buiteste medewerkers uit te nooi.

  • As openbare of private webwerwe gepubliseer kan word.

  • Die toestemmings wat admins oor die bewaarplekke het.

  • As lede nuwe spanne kan skep.

Bewaarplekrolle

Standaard word bewaarplekrolle geskep:

  • Lees: Aanbeveel vir nie-kode-bydraers wat jou projek wil sien of bespreek.

  • Triage: Aanbeveel vir bydraers wat aktief sake en trekversoeke moet bestuur sonder skryftoegang.

  • Skryf: Aanbeveel vir bydraers wat aktief bydraes lewer aan jou projek.

  • Onderhou: Aanbeveel vir projekbestuurders wat die bewaarplek moet bestuur sonder toegang tot sensitiewe of vernietigende aksies.

  • Admin: Aanbeveel vir mense wat volle toegang tot die projek nodig het, insluitend sensitiewe en vernietigende aksies soos die bestuur van sekuriteit of die uitvee van 'n bewaarplek.

Jy kan die toestemmings vergelyk van elke rol in hierdie tabel: 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 elke ouerspan moet besoek om die spanne wat kinders van ander spanne is, te sien.

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 lid is, en die bewaarplekke waarop die gebruiker toegang het, sien.

Github-verifikasie

Github bied verskillende maniere om by jou rekening aan te meld en aksies namens jou uit te voer.

Webtoegang

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

SSH-sleutels

Jy kan jou rekening konfigureer met een of verskeie openbare sleutels wat die betrokke privaatsleutel in staat stel om aksies namens jou uit te voer. https://github.com/settings/keys

GPG-sleutels

Jy kan nie die gebruiker voorstel met hierdie sleutels nie, maar as jy dit nie gebruik nie, is dit moontlik dat jy ontdek word vir die stuur van commits sonder 'n handtekening. Lees meer oor [waaksaamheidsmodus hier](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification

Oauth Aansoeke

Oauth-aansoeke kan jou vra om toestemmings om toegang te verkry tot 'n deel van jou github-inligting of om jou te verteenwoordig om sekere aksies uit te voer. 'n Algemene voorbeeld van hierdie funksionaliteit is die aanmelding met github-knoppie wat jy dalk op sommige platforms sal vind.

Sekuriteitsaanbevelings:

  • 'n OAuth-aansoek moet altyd optree as die geautehtiseerde GitHub-gebruiker regoor GitHub (byvoorbeeld, wanneer gebruikerskennisgewings verskaf word) en slegs toegang tot die gespesifiseerde omvang hê.

  • 'n OAuth-aansoek kan gebruik word as 'n identiteitsverskaffer deur 'n "Aanmelding met GitHub" vir die geautehtiseerde gebruiker in te skakel.

  • Bou nie 'n OAuth-aansoek as jy wil hê jou toepassing moet optree op 'n enkele argief nie. Met die repo OAuth-omvang kan OAuth-aansoeke optree op alle van die geautehtiseerde gebruiker se argiewe.

  • Bou nie 'n OAuth-aansoek om as 'n toepassing vir jou span of maatskappy op te tree nie. OAuth-aansoeke autentiseer as 'n enkele gebruiker, dus as een persoon 'n OAuth-aansoek vir 'n maatskappy skep om te gebruik, en dan die maatskappy verlaat, sal niemand anders toegang daartoe hê nie.

  • Meer in hier.

Github Aansoeke

Github-aansoeke kan toestemmings vra om toegang tot jou github-inligting te verkry of jou te verteenwoordig om spesifieke aksies oor spesifieke hulpbronne uit te voer. In Github-aansoeke moet jy die argiewe spesifiseer waarop die aansoek toegang sal hê.

Sekuriteitsaanbevelings:

  • 'n GitHub-aansoek moet aksies neem onafhanklik van 'n gebruiker (tensy die aansoek 'n gebruiker-na-bediener token gebruik). Om gebruiker-na-bediener toegangstokens veiliger te hou, kan jy toegangstokens gebruik wat na 8 uur verval, en 'n hernuwings-token wat vir 'n nuwe toegangstoken ingewissel kan word. Vir meer inligting, sien "Refreshing user-to-server access tokens."

  • Maak seker dat die GitHub-aansoek integreer met spesifieke argiewe.

  • Die GitHub-aansoek moet verbind word met 'n persoonlike rekening of 'n organisasie.

  • Moenie verwag dat die GitHub-aansoek alles weet en doen wat 'n gebruiker kan doen nie.

  • Moenie 'n GitHub-aansoek gebruik as jy net 'n "Aanmelding met GitHub"-diens nodig het nie. Maar 'n GitHub-aansoek kan 'n gebruiker-identifikasievloei gebruik om gebruikers aan te meld en ander dinge te doen.

  • Bou nie 'n GitHub-aansoek as jy net wil optree as 'n GitHub-gebruiker en alles doen wat daardie gebruiker kan doen nie.

  • As jy jou aansoek met GitHub-aksies gebruik en werkstroomlêers wil wysig, moet jy namens die gebruiker outentiseer met 'n OAuth-token wat die workflow-omvang insluit. Die gebruiker moet admin- of skryfregte hê vir die argief wat die werkstroomlêer bevat. Vir meer inligting, sien "Understanding scopes for OAuth apps."

  • Meer in hier.

Github Aksies

Dit is nie 'n manier om in github te outentiseer nie, maar 'n skadelike Github-aksie kan onbevoegde toegang tot github verkry en, afhangende van die bevoegdhede wat aan die Aksie gegee is, verskeie verskillende aanvalle uitvoer. Sien hieronder vir meer inligting.

Git Aksies

Git-aksies maak dit moontlik om die uitvoering van kode outomaties te outomatiseer wanneer 'n gebeurtenis plaasvind. Gewoonlik is die uitgevoerde kode op een of ander manier verwant aan die kode van die argief (miskien 'n docker-houer bou of nagaan dat 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-aksies vir die organisasie te sien.

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

Dit is ook moontlik om te konfigureer wie goedkeuring nodig het om 'n Github-aksie uit te voer en die bevoegdhede van die GITHUB_TOKEN van 'n Github-aksie wanneer dit uitgevoer word.

Git-geheime

Github-aksies benodig gewoonlik 'n sekere soort geheime om met github of derdeparty-toepassings te kommunikeer. Om te verhoed dat hulle in die argief as duidelike teks geplaas word, laat github toe om hulle as Geheime te plaas.

Hierdie geheime kan gekonfigureer word vir die argief of vir die hele organisasie. Dan moet jy dit so verklaar dat die Aksie toegang tot die geheim kan verkry:

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"

Geheime kan slegs vanaf die Github-handelinge wat hulle verklaar, toegang verkry word.

Sodra dit in die repo of die organisasie gekonfigureer is, sal gebruikers van Github nie weer toegang daartoe hê nie, hulle sal dit net kan verander.

Daarom is die enigste manier om Github-geheime te steel om toegang tot die masjien te hê wat die Github-handeling uitvoer (in daardie scenario sal jy slegs toegang hê tot die geheime wat vir die Handeling verklaar is).

Git-omgewings

Github maak dit moontlik om omgewings te skep waarin jy geheime kan stoor. Daarna kan jy die Github-handeling toegang gee tot die geheime binne die omgewing met iets soos:

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

Jy kan 'n omgewing toeganklik maak vir alle takke (verstek), slegs beskermde takke, of spesifiseer watter takke toegang daartoe het. Dit kan ook 'n aantal vereiste resensies instel voordat 'n aksie uitgevoer word met behulp van 'n omgewing, of 'n tyd wag voordat implementering toegelaat word.

Git Aksie Loper

'n Github Aksie kan binne die Github-omgewing uitgevoer word, of dit kan in 'n derde party-infrastruktuur wat deur die gebruiker gekonfigureer is, uitgevoer word.

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

Jy kan die self-gehoste lopers 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 gegenereer word vir die Loper wanneer dit gekonfigureer word om te weet waar die loper behoort.

As die aangepaste Github Loper gekonfigureer is in 'n masjien binne AWS of GCP byvoorbeeld, kan die Aksie toegang hê tot die metadata-eindpunt en die token van die diensrekening steel waarmee die masjien loop.

Git Aksie Ondermyn

As alle aksies (of 'n skadelike aksie) toegelaat word, kan 'n gebruiker 'n Github-aksie gebruik wat skadelik is en die houer waarin dit uitgevoer word, ondermyn.

'n Skadelike Github-aksie-uitvoering kan deur die aanvaller misbruik word om:

  • Alle geheime waarop die Aksie toegang het, te steel

  • Sydelings beweeg as die Aksie binne 'n derde party-infrastruktuur uitgevoer word waar die SA-token wat gebruik word om die masjien te laat loop, toeganklik is (waarskynlik via die metadata-diens)

  • Die token wat deur die werkstroom gebruik word, misbruik om die kode van die repo waar die Aksie uitgevoer word, te steel of selfs te wysig.

Takbeskerming

Takbeskerming is ontwerp om nie volledige beheer van 'n argief aan die gebruikers te gee nie. Die doel is om verskeie beskermingsmetodes te plaas voordat kode in 'n tak geskryf kan word.

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

Dit is nie moontlik om 'n takbeskerming op organisasievlak in te stel nie. Dit moet dus op elke argief verklaar word.

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

  • Jy kan 'n PR vereis voordat dit saamgevoeg word (sodat jy nie direk kode oor die tak kan saamvoeg nie). As dit gekies word, kan verskillende ander beskermings van toepassing wees:

  • Vereis 'n aantal goedkeurings. Dit is baie algemeen om te vereis dat 1 of 2 meer mense jou PR goedkeur, sodat 'n enkele gebruiker nie in staat is om kode direk saam te voeg nie.

  • Verwerp goedkeurings wanneer nuwe commits gedruk word. As dit nie gedoen word nie, kan 'n gebruiker legitieme kode goedkeur en dan skadelike kode byvoeg en dit saamvoeg.

  • Vereis resensies van kode-eienaars. Ten minste 1 kode-eienaar van die argief moet die PR goedkeur (sodat "willekeurige" gebruikers dit nie kan goedkeur nie)

  • Beperk wie pull request-resensies kan verwerp. Jy kan mense of spanne spesifiseer wat pull request-resensies kan verwerp.

  • Laat gespesifiseerde akteurs toe om pull request-vereistes te omseil. Hierdie gebruikers sal in staat wees om vorige beperkings te omseil.

  • Vereis statuskontroles voordat dit saamgevoeg word. Sommige kontroles moet slaag voordat die toewysing saamgevoeg kan word (soos 'n Github-aksie wat nagaan of daar geen klaarteks-geheim is nie).

  • Vereis oplossing van gesprekke voordat dit saamgevoeg word. Alle kommentaar op die kode moet opgelos word voordat die PR saamgevoeg kan word.

  • Vereis ondertekende toewysings. Die toewysings moet onderteken word.

  • Vereis lineêre geskiedenis. Voorkom dat saamvoegtoewysings na ooreenstemmende takke gestuur word.

  • Sluit administrateurs in. As dit nie ingestel is nie, kan administrateurs die beperkings omseil.

  • Beperk wie na ooreenstemmende takke kan stuur. Beperk wie 'n PR kan stuur.

Soos jy kan sien, selfs as jy in staat was om sekere geloofsbriewe van 'n gebruiker te verkry, kan argiewe beskerm wees om te voorkom dat jy byvoorbeeld kode na die hooftak stuur om die CI/CD-pyplyn te ondermyn.

Verwysings

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

PreviousGh Actions - Context Script InjectionsNextGitea Security

Last updated