Github Security
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
(Van hier) 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.
Github repositories kan as publiek, privaat en intern gekonfigureer word.
Privaat beteken dat slegs mense van die organisasie toegang sal hê.
Intern beteken dat slegs mense van die onderneming (een onderneming kan verskeie organisasies hê) toegang sal hê.
Publiek beteken dat alle internet toegang sal hê.
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 lekkasies op elke repo.
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 potensiële sensitiewe inligting in jou teiken soek.
Gereedskap (elke gereedskap bevat sy lys van dorks):
Let asseblief daarop dat die github dorks ook bedoel is om te soek na lekkasies 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).
Gereedskap (elke gereedskap bevat sy lys van regexes):
Wanneer jy soek na lekkasies in 'n repo en iets soos git log -p uitvoer, moenie vergeet daar mag wees ander takke met ander verbintenisse wat geheime bevat nie!
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.
Selfs al is dit verwyder of intern, mag dit moontlik wees om sensitiewe data van forks van github repositories te verkry. Kyk dit hier:
Accessible Deleted Data in GithubDaar is 'n paar standaard privileges 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.
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 spanne 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.
Verskeie sekuriteit gerelateerde instellings kan geconfigureer word vir aksies vanaf die bladsy https://github.com/organizations/<org_name>/settings/actions.
Let daarop dat al hierdie konfigurasies ook op elke repository onafhanklik gestel kan word
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.
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 afgeradeer 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 is afgeradeer 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.
Laat weet my as jy die API eindpunt ken om toegang tot hierdie inligting te kry!
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).
Vir hierdie scenario gaan ons veronderstel dat jy toegang tot 'n github rekening verkry het.
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.
Let daarop dat 2FA dalk gebruik word sodat jy slegs toegang tot hierdie inligting sal hê as jy ook daardie toets kan slaag.
Let daarop dat as jy slaag om die user_session koekie (huidiglik geconfigureer met SameSite: Lax) te steel, jy kan volledig die gebruiker naboots sonder om kredensiale of 2FA te benodig.
Kyk na die afdeling hieronder oor tak beskerming omseilings in geval dit nuttig is.
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 veranderings in repositories waar die gebruiker sekere privileges het, 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 opneem om inligting oor die repos en gebruiker waartoe jy toegang het, te verkry:
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.
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.
Soos verduidelik hier is dit soms nodig om die verbintenisse te teken of jy mag ontdek word.
Kontroleer plaaslik of die huidige gebruiker enige sleutel het met:
Vir 'n inleiding oor Gebruikerstokens kyk na die basiese inligting.
'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. Afhangende van die voorregte wat daaraan gekoppel is, mag jy in staat wees om verskillende aksies uit te voer.
'n Gebruikerstoken lyk soos volg: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123
Vir 'n inleiding oor Github Oauth Toepassings kyk na die basiese inligting.
'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 phishing veldtog aanvaar.
Hierdie is die skoppe wat 'n Oauth toepassing kan aanvra. 'n Mens moet altyd die gevraagde skoppe nagaan voordat jy dit aanvaar.
Boonop, soos verduidelik in die basiese inligting, kan organisasies toegang tot derdeparty-toepassings gee/weier tot inligting/repos/aksies wat met die organisasie verband hou.
Vir 'n inleiding oor Github Toepassings kyk na die basiese inligting.
'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 phishing veldtog aanvaar.
Boonop, soos verduidelik in die basiese inligting, kan organisasies toegang tot derdeparty-toepassings gee/weier tot inligting/repos/aksies wat met die organisasie verband hou.
Daar is verskeie tegnieke om 'n Github Aksie te kompromitteer en te misbruik, kyk dit hier:
Abusing Github ActionsVereis '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 die beskerming van Kode Eienaars nie van toepassing nie.
Laat gespesifiseerde akteurs toe om pull request vereistes te omseil: As jy een van hierdie akteurs is, kan jy pull request beskermings omseil.
Sluit administrateurs in: As dit nie ingestel is nie en jy is 'n admin van die repo, kan jy hierdie tak beskermings omseil.
PR Hijacking: Jy kan dalk 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.
Verwydering van Tak Beskermings: As jy 'n admin van die repo is, kan jy die beskermings deaktiveer, jou PR saamvoeg en die beskermings weer instel.
Omseiling van druk beskermings: As 'n repo slegs sekere gebruikers toelaat om druk (kode saam te voeg) in takke te stuur (die tak beskerming mag al die takke beskerm deur die wildcard * te spesifiseer).
As jy skrywe toegang oor die repo het, maar jy mag nie kode druk nie weens die tak beskerming, kan jy steeds 'n nuwe tak skep en binne dit 'n github aksie skep wat geaktiveer word wanneer kode gestuur word. Aangesien die tak beskerming nie die tak sal beskerm totdat dit geskep is nie, sal hierdie eerste kode druk na die tak die github aksie uitvoer.
Vir 'n inleiding oor Github Omgewing kyk na die basiese inligting.
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 dalk 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 dalk die randgeval mag vind waar al die takke beskerm is (deur wildcard *) dit is gespesifiseer wie kode na die takke kan druk (jy kan dit in die tak beskerming 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 tak beskerming laat die druk na 'n nuwe tak toe, so die github aksie sal geaktiveer word.
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.
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 agterdeur
Vind kwulnerbare Github Action vir opdraginjekie deur geheime waarde wysiging
In Github is dit moontlik om 'n PR na 'n repo van 'n fork te skep. Selfs al is 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, gebruik.
Soos hierdie:
For more info check https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
