Maelezo ya Msingi ya Github

Reading time: 16 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Muundo wa Msingi

Muundo wa msingi wa mazingira ya Github kwa kampuni kubwa ni kwamba kampuni inamiliki enterprise ambayo inamiliki several organizations na kila moja yao inaweza kuwa na several repositories na several teams. Kampuni ndogo zinaweza kumiliki just one organization and no enterprises.

Kutoka kwa mtazamo wa mtumiaji, user anaweza kuwa member wa different enterprises and organizations. Ndani yao mtumiaji anaweza kuwa na different enterprise, organization and repository roles.

Zaidi ya hayo, mtumiaji anaweza kuwa part of different teams na kuwa na majukumu tofauti ya enterprise, organization au repository.

Na hatimaye, repositories may have special protection mechanisms.

Privileges

Enterprise Roles

  • Enterprise owner: Watu wenye jukumu hili wanaweza manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations. Hata hivyo, hawawezi access organization settings or content isipokuwa wakateuliwa kuwa organization owner au wakapewa ufikiaji wa moja kwa moja wa repository inayomilikiwa na organization.
  • Enterprise members: Members wa organizations zinazomilikiwa na enterprise yako pia huwa automatically members of the enterprise.

Organization Roles

Ndani ya organization watumiaji wanaweza kuwa na majukumu tofauti:

  • Organization owners: Organization owners wana complete administrative access to your organization. Jukumu hili linapaswa kufungiwa kwa idadi ndogo, lakini si chini ya watu wawili, ndani ya organization yako.
  • Organization members: Hili ndilo default, jukumu lisilo la utawala kwa people in an organization. Kwa default, organization members have a number of permissions.
  • Billing managers: Billing managers ni watumiaji wanaoweza manage the billing settings for your organization, kama vile taarifa za malipo.
  • Security Managers: Hii ni jukumu ambalo organization owners wanaweza kulipa timu yoyote ndani ya organization. Linapotekelezwa, linawapa kila mwanachama wa timu ruhusa za manage security alerts and settings across your organization, as well as read permissions for all repositories ndani ya organization.
  • Ikiwa organization yako ina timu ya usalama, unaweza kutumia jukumu la security manager kuwapa wanachama wa timu ufikiaji mdogo wanaohitaji kwa organization.
  • Github App managers: Ili kuruhusu watumiaji wengine manage GitHub Apps owned by an organization, owner anaweza kuwapa ruhusa za GitHub App manager.
  • Outside collaborators: Outside collaborator ni mtu ambaye ana access to one or more organization repositories but is not explicitly a member wa organization.

Unaweza compare the permissions za majukumu haya katika jedwali hili: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Members Privileges

Katika https://github.com/organizations/<org_name>/settings/member_privileges unaweza kuona permissions users will have just for being part of the organisation.

Mipangilio iliyo hapa itabainisha ruhusa zifuatazo za wanachama wa organisation:

  • Kuwa admin, writer, reader au bila ruhusa juu ya repositories zote za organization.
  • Ikiwa wanachama wanaweza kuunda private, internal au public repositories.
  • Ikiwa forking ya repositories inawezekana.
  • Ikiwa inawezekana kumualika outside collaborators.
  • Ikiwa public au private sites zinaweza kuchapishwa.
  • Ruhusa ambazo admins wana juu ya repositories.
  • Ikiwa wanachama wanaweza kuunda timu mpya.

Repository Roles

Kwa default majukumu ya repository huundwa:

  • Read: Inashauriwa kwa non-code contributors ambao wanataka kuona au kujadili mradi wako.
  • Triage: Inashauriwa kwa contributors who need to proactively manage issues and pull requests bila ufikiaji wa kuandika.
  • Write: Inashauriwa kwa contributors ambao actively push to your project.
  • Maintain: Inashauriwa kwa project managers who need to manage the repository bila ufikiaji wa vitendo nyeti au vinavyoharibu.
  • Admin: Inashauriwa kwa watu wanaohitaji full access to the project, ikijumuisha vitendo nyeti na vinavyoharibu kama kusimamia usalama au kufuta repository.

Unaweza compare the permissions za kila jukumu katika jedwali hili https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Unaweza pia create your own roles katika https://github.com/organizations/<org_name>/settings/roles

Teams

Unaweza list the teams created in an organization katika https://github.com/orgs/<org_name>/teams/. Note that to see the teams which are children of other teams you need to access each parent team.

Users

Watumiaji wa organization wanaweza listed katika https://github.com/orgs/<org_name>/people.

Katika taarifa za kila mtumiaji unaweza kuona teams the user is member of, na repos the user has access to.

Github Authentication

Github inatoa njia mbalimbali za ku-authenticate kwa akaunti yako na kutekeleza vitendo kwa niaba yako.

Web Access

Kupitia github.com unaweza kuingia kwa kutumia username and password (na mara nyingi 2FA).

SSH Keys

Unaweza kusanidi akaunti yako na moja au zaidi ya public keys zinazomruhusu private key kuperform actions on your behalf. https://github.com/settings/keys

GPG Keys

Huwezi impersonate the user with these keys lakini ikiwa hautatumia inaweza kutokea utakaguliwa kwa kutuma commits bila signature. Jifunze zaidi kuhusu vigilant mode here.

Personal Access Tokens

Unaweza kuunda personal access token ku give an application access to your account. Unapounda personal access token user anatakiwa specify ruhusa ambazo token itakuwa nazo. https://github.com/settings/tokens

Oauth Applications

Oauth applications zinaweza kukuomba ruhusa to access part of your github information or to impersonate you kutekeleza vitendo fulani. Mfano wa kawaida ni kitufe cha login with github utakachoona kwenye baadhi ya platform.

Baadhi ya mapendekezo ya usalama:

  • OAuth App inapaswa daima act as the authenticated GitHub user across all of GitHub (mfano, katika kutoa notifikeshini kwa mtumiaji) na kuwa na ufikiaji tu wa scopes zilizobainishwa.
  • OAuth App inaweza kutumika kama identity provider kwa kuwezesha "Login with GitHub" kwa mtumiaji aliye authenticated.
  • Don't tengeneza OAuth App ikiwa unataka application yako itekeleze vitendo juu ya single repository. Kwa repo OAuth scope, OAuth Apps zinaweza act on all of the authenticated user's repositories.
  • Don't tengeneza OAuth App ili itumike kama application ya team or company. OAuth Apps zina-authenticate kama single user, hivyo kama mtu mmoja ataunda OAuth App kwa ajili ya kampuni na baadaye aondoke, hakuna mtu mwingine atakayeshika ufikiaji wake.
  • More in here.

Github Applications

Github applications zinaweza kukuomba ruhusa za access your github information or impersonate you kutekeleza vitendo maalum juu ya rasilimali maalum. Katika Github Apps unatakiwa kubainisha repositories ambazo app itakuwa nazo.

Baadhi ya mapendekezo ya usalama:

  • GitHub App inapaswa take actions independent of a user (isipokuwa app inatumia user-to-server token). Ili kuweka user-to-server access tokens kuwa salama zaidi, unaweza kutumia access tokens zitakazokoma baada ya saa 8, na refresh token inayoweza kubadilishwa kwa access token mpya. Kwa maelezo zaidi, angalia "Refreshing user-to-server access tokens."
  • Hakikisha GitHub App inajiunga na specific repositories.
  • GitHub App inapaswa connect to a personal account or an organisation.
  • Usitarajie GitHub App ijue au ifanye kila kitu ambacho mtumiaji anaweza kufanya.
  • Don't use a GitHub App if you just need a "Login with GitHub" service. Lakini GitHub App inaweza kutumia user identification flow kuwalogisha watumiaji and kufanya mambo mengine.
  • Usitengeneze GitHub App ikiwa only unataka kuonekana kama GitHub user na kufanya kila kitu mtumiaji huyo anaweza kufanya.
  • Ikiwa unatumia app yako na GitHub Actions na unataka kubadilisha workflow files, lazima u-authenticate kwa niaba ya mtumiaji na OAuth token inayojumuisha workflow scope. Mtumiaji lazima awe na admin au write permission kwa repository inayobeba workflow file. Kwa maelezo zaidi, angalia "Understanding scopes for OAuth apps."
  • More in here.

Github Actions

Hii isn't a way to authenticate in github, lakini Github Action yenye malicious inaweza kupata unauthorised access to github na depending juu ya privileges zilizotolewa kwa Action, mashambulizi mbalimbali yanaweza kufanywa. Tazama chini kwa maelezo zaidi.

Git Actions

Git actions zinaruhusu kuendesha kiotomatiki execution of code when an event happen. Kawaida code inayotekelezwa ina uhusiano na code ya repository (labda kujenga docker container au kukagua kwamba PR haina secrets).

Configuration

Katika https://github.com/organizations/<org_name>/settings/actions inawezekana kuangalia configuration of the github actions kwa organization.

Inawezekana kuzuia kabisa matumizi ya github actions, allow all github actions, au kuruhusu actions maalum tu.

Pia inawezekana kusanidi who needs approval to run a Github Action na permissions of the GITHUB_TOKEN ya Github Action wakati inaendeshwa.

Git Secrets

Github Action kawaida inahitaji aina fulani ya secrets ili kuingiliana na github au applications za third party. Ili avoid putting them in clear-text katika repo, github inaruhusu kuyaweka kama Secrets.

Secrets hizi zinaweza kusanidiwa kwa repo au kwa organization nzima. Kisha, ili Action iweze kupata secret unahitaji kuiDeclare kama:

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

Mfano wa kutumia Bash

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

warning

Secrets zinaweza kupatikana tu kutoka kwa Github Actions ambazo zimewekwa.

Mara tu zinapowekwa kwenye repo au kwa mashirika, watumiaji wa github hawataweza kuzipata tena, wataweza tu kuzibadilisha.

Kwa hivyo, njia pekee ya kuiba github secrets ni kuwa na uwezo wa kupata mashine inayotekeleza Github Action (katika hali hiyo utaweza kupata tu secrets zilizoelezwa kwa ajili ya Action).

Git Environments

Github inaruhusu kuunda environments ambapo unaweza kuhifadhi secrets. Kisha, unaweza kumpa github action ruhusa ya kufikia secrets ndani ya environment kwa kitu kama:

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

Unaweza kusanidi environment ili iweze kufikiwa na tawi zote (default), tawi zilizolindwa pekee au kubainisha ni matawi gani yanaweza kuifikia.
Zaidi ya hayo, ulinzi wa environment unajumuisha:

  • Required reviewers: huzuia jobs zinazolenga environment mpaka zithibitishwe. Washa Prevent self-review ili kutekeleza kanuni ya four‑eyes kwenye idhini yenyewe.
  • Deployment branches and tags: zuia matawi/tags ambayo yanaweza ku-deploy kwenye environment. Inashauriwa kuchagua matawi/tags maalum na kuhakikisha matawi hayo yanalindwa. Kumbuka: chaguo "Protected branches only" kinahusu classic branch protections na huenda kisifanye kazi kama inavyotarajiwa ikiwa unatumia rulesets.
  • Wait timer: chelewesha deployments kwa muda unaoweza kusanidiwa.

Pia inaweza kuweka idadi ya uhakiki unaohitajika kabla ya kufanya kazi kwa environment au kusubiri muda fulani kabla ya kuruhusu deployments kuendelea.

Git Action Runner

Github Action inaweza ku endeshwa ndani ya github environment au inaweza kuendeshwa katika miundombinu ya mtu wa tatu iliyosanidiwa na mtumiaji.

Shirika kadhaa zitawawezesha kuendesha Github Actions katika miundombinu ya mtu wa tatu kwa sababu kawaida hupatikana kuwa gharama nafuu.

Unaweza orodhesha self-hosted runners za shirika katika https://github.com/organizations/<org_name>/settings/actions/runners

Njia ya kupata ni Github Actions gani zinatekelezwa katika miundombinu isiyo ya github ni kutafuta runs-on: self-hosted katika faili ya kusanidi Github Action yaml.

Haiwezekani kuendesha Github Action ya shirika ndani ya sanduku ya self hosted ya shirika tofauti kwa sababu token tofauti huzalishwa kwa Runner wakati wa kuisanidi ili ijue runner inatoka wapi.

Kama Github Runner maalum imesanidiwa katika mashine ndani ya AWS au GCP kwa mfano, Action inaweza kuwa na ufikiaji wa metadata endpoint na kuiba token ya service account ambayo mashine inaendesha nayo.

Git Action Compromise

Ikiwa actions zote (au action yenye nia mbaya) zinakaribishwa mtumiaji anaweza kutumia Github action yenye nia mbaya ambayo ita kuharibu container inayotekelezwa ndani yake.

caution

Run ya malicious Github Action inaweza kutumiwa vibaya na mshambulizi kwa:

  • Kuiba secrets zote ambazo Action ina ufikiaji wa
  • Kuhamia kwa njia ya lateral ikiwa Action inaendeshwa ndani ya miundombinu ya mtu wa tatu ambapo token ya SA inayotumiwa kuendesha mashine inaweza kupatikana (labda kupitia metadata service)
  • Kutumia token inayotumiwa na workflow ku iba code ya repo ambapo Action inaendeshwa au hata kuibadilisha.

Branch Protections

Branch protections zimeundwa ili wasitope udhibiti kamili wa repository kwa watumiaji. Lengo ni kuweka mbinu kadhaa za ulinzi kabla ya kuweza kuandika code ndani ya tawi fulani.

Branch protections za repository zinaweza kupatikana katika https://github.com/<orgname>/<reponame>/settings/branches

note

Haiwezekani kuweka branch protection kwa ngazi ya shirika. Kwa hivyo zote lazima ziwe zimetangazwa kwa kila repo.

Ulinzi tofauti unaweza kutumika kwa tawi (kama master):

  • Unaweza kuhitaji PR kabla ya ku-merge (hivyo huwezi kuunganisha code moja kwa moja kwenye tawi). Ikiwa hii imechaguliwa, ulinzi mwingine unaweza kuwepo:
  • Require a number of approvals. Ni kawaida kutaka watu 1 au 2 zaidi kuidhinisha PR yako ili mtumiaji mmoja asiweze ku-merge code moja kwa moja.
  • Dismiss approvals when new commits are pushed. Ikiwa sio hivyo, mtumiaji anaweza kuidhinisha code halali kisha kuongeza code yenye madhara na ku-merge.
  • Require approval of the most recent reviewable push. Hii inahakikisha kwamba commits mpya baada ya idhini (ikiwa ni pamoja na pushes za washiriki wengine) zinasababisha upya uhakiki ili mshambuliaji asiweze kutuma mabadiliko baada ya idhini na ku-merge.
  • Require reviews from Code Owners. Angalau code owner mmoja wa repo anahitaji kuidhinisha PR (hivyo watumiaji "wasiofahamika" hawawezi kuidhinisha)
  • Restrict who can dismiss pull request reviews. Unaweza kubainisha watu au timu zinazoruhusiwa kukataa uhakiki wa pull request.
  • Allow specified actors to bypass pull request requirements. Watumiaji hawa watakuwa na uwezo wa kuruka vikwazo vilivyotajwa hapo juu.
  • Require status checks to pass before merging. Baadhi ya checks zinahitaji kupita kabla ya kuweza ku-merge commit (kama GitHub App inayoripoti matokeo ya SAST). Vidokezo: wahusishe required checks na GitHub App maalum; vinginevyo app yoyote inaweza kuiga check kupitia Checks API, na bots nyingi zinakubali maagizo ya kuruka (mfano, "@bot-name skip").
  • Require conversation resolution before merging. Maoni yote kwenye code yanahitaji kutatuliwa kabla PR inaweza ku-merge.
  • Require signed commits. Commits zinahitaji kusainiwa.
  • Require linear history. Zuia merge commits kutumwa kwenye matawi yanayolingana.
  • Include administrators. Ikiwa hii haijawekwa, admins wanaweza kuruka vizuizi.
  • Restrict who can push to matching branches. Zuia nani anaweza kutuma PR.

note

Kama unavyoona, hata ikiwa umeweza kupata nywila za mtumiaji fulani, repo zinaweza kulindwa zikizuia wewe kutuma code kwenye master kwa mfano ili kuharibu pipeline ya CI/CD.

Tag Protections

Tags (kama latest, stable) zinabadilika kwa default. Ili kutekeleza mtiririko wa four‑eyes kwenye masasisho ya tag, linda tags na tenganisha ulinzi kupitia environments na matawi:

  1. Kwenye kanuni ya ulinzi wa tag, washwa Require deployments to succeed na unaweza kuhitaji deployment iliyofanikiwa kwenye environment iliyolindwa (mfano, prod).
  2. Kwenye environment lengwa, zuia Deployment branches and tags kwa tawi la release (mfano, main) na hiari sanidi Required reviewers na Prevent self-review.
  3. Kwenye tawi la release, sanidi branch protections ili Require a pull request, weka approvals ≥ 1, na washwa zote Dismiss approvals when new commits are pushed na Require approval of the most recent reviewable push.

Mnyororo huu unazuia mshiriki mmoja ku-re-tag au kuchapisha kwa nguvu releases kwa kuhariri workflow YAML, kwa kuwa milango ya deployment inatekelezwa nje ya workflows.

References

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks