Swahili - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Basic Github Information

Support HackTricks

Basic Structure

Muundo wa mazingira ya github wa kampuni kubwa ni kumiliki enterprise ambayo inamiliki mashirika kadhaa na kila moja yao inaweza kuwa na hifadhi kadhaa na timu kadhaa. Kampuni ndogo zinaweza kumiliki shirika moja tu na hakuna enterprise.

Kutoka kwa mtazamo wa mtumiaji, mtumiaji anaweza kuwa mwanachama wa mashirika na enterprises tofauti. Ndani yao, mtumiaji anaweza kuwa na majukumu tofauti ya enterprise, shirika na hifadhi.

Zaidi ya hayo, mtumiaji anaweza kuwa sehemu ya timu tofauti zikiwa na majukumu tofauti ya enterprise, shirika au hifadhi.

Na hatimaye, hifadhi zinaweza kuwa na mifumo maalum ya ulinzi.

Privileges

Enterprise Roles

  • Mmiliki wa enterprise: Watu wenye jukumu hili wanaweza kusimamia wasimamizi, kusimamia mashirika ndani ya enterprise, kusimamia mipangilio ya enterprise, kutekeleza sera kati ya mashirika. Hata hivyo, hawawezi kufikia mipangilio ya shirika au maudhui isipokuwa wametengenezwa kuwa mmiliki wa shirika au kupewa ufikiaji wa moja kwa moja kwa hifadhi inayomilikiwa na shirika.

  • Wajumbe wa enterprise: Wajumbe wa mashirika yanayomilikiwa na enterprise yako pia ni wanachama wa enterprise kiotomatiki.

Organization Roles

Katika shirika, watumiaji wanaweza kuwa na majukumu tofauti:

  • Wamiliki wa shirika: Wamiliki wa shirika wana ufikiaji kamili wa kiutawala kwa shirika lako. Jukumu hili linapaswa kuwa na mipaka, lakini si chini ya watu wawili, katika shirika lako.

  • Wajumbe wa shirika: Jukumu la kawaida, lisilo la kiutawala kwa watu katika shirika ni mwanachama wa shirika. Kwa kawaida, wajumbe wa shirika wana idadi ya ruhusa.

  • Wasimamizi wa bili: Wasimamizi wa bili ni watumiaji wanaoweza kusimamia mipangilio ya bili kwa shirika lako, kama vile taarifa za malipo.

  • Wasimamizi wa Usalama: Ni jukumu ambalo wamiliki wa shirika wanaweza kuteua kwa timu yoyote katika shirika. Wakati linapotumika, linawapa kila mwanachama wa timu ruhusa za kusimamia arifa za usalama na mipangilio katika shirika lako, pamoja na ruhusa za kusoma kwa hifadhi zote katika shirika.

  • Ikiwa shirika lako lina timu ya usalama, unaweza kutumia jukumu la msimamizi wa usalama kuwapa wanachama wa timu ufikiaji mdogo wanahitaji kwa shirika.

  • Wasimamizi wa Github App: Ili kuruhusu watumiaji wengine kusimamia GitHub Apps zinazomilikiwa na shirika, mmiliki anaweza kuwapa ruhusa za msimamizi wa GitHub App.

  • Washirikishi wa nje: Mshirikishi wa nje ni mtu ambaye ana ufikiaji wa hifadhi moja au zaidi za shirika lakini si mwanachama wa shirika kwa wazi.

Unaweza kulinganisha ruhusa 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 ruhusa ambazo watumiaji watakuwa nazo kwa sababu tu ya kuwa sehemu ya shirika.

Mipangilio hapa iliyowekwa itaonyesha ruhusa zifuatazo za wanachama wa shirika:

  • Kuwa msimamizi, mwandishi, msomaji au hakuna ruhusa juu ya hifadhi zote za shirika.

  • Ikiwa wanachama wanaweza kuunda hifadhi za kibinafsi, za ndani au za umma.

  • Ikiwa kuiga hifadhi kunawezekana

  • Ikiwa inawezekana kuwalika washirikishi wa nje

  • Ikiwa tovuti za umma au za kibinafsi zinaweza kuchapishwa

  • Ruhusa ambazo wasimamizi wanazo juu ya hifadhi

  • Ikiwa wanachama wanaweza kuunda timu mpya

Repository Roles

Kwa kawaida majukumu ya hifadhi huundwa:

  • Soma: Inapendekezwa kwa wasaidizi wasio wa msimbo wanaotaka kuona au kujadili mradi wako

  • Triage: Inapendekezwa kwa wasaidizi wanaohitaji kusimamia masuala na ombi la kuvuta bila ufikiaji wa kuandika

  • Andika: Inapendekezwa kwa wasaidizi ambao wanasukuma kwa nguvu kwenye mradi wako

  • Simamisha: Inapendekezwa kwa wasimamizi wa mradi wanaohitaji kusimamia hifadhi bila ufikiaji wa vitendo nyeti au vya kuharibu

  • Msimamizi: Inapendekezwa kwa watu wanaohitaji ufikiaji kamili wa mradi, ikiwa ni pamoja na vitendo nyeti na vya kuharibu kama kusimamia usalama au kufuta hifadhi

Unaweza kulinganisha ruhusa 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 kuunda majukumu yako mwenyewe katika https://github.com/organizations/<org_name>/settings/roles

Teams

Unaweza orodhesha timu zilizoundwa katika shirika katika https://github.com/orgs/<org_name>/teams. Kumbuka kuwa ili kuona timu ambazo ni watoto wa timu nyingine unahitaji kufikia kila timu ya mzazi.

Users

Watumiaji wa shirika wanaweza orodheshwa katika https://github.com/orgs/<org_name>/people.

Katika taarifa za kila mtumiaji unaweza kuona timu ambazo mtumiaji ni mwanachama wa, na hifadhi ambazo mtumiaji ana ufikiaji.

Github Authentication

Github inatoa njia tofauti za kuthibitisha akaunti yako na kufanya vitendo kwa niaba yako.

Web Access

Kwa kufikia github.com unaweza kuingia kwa kutumia jina lako la mtumiaji na nenosiri (na 2FA huenda).

SSH Keys

Unaweza kuunda akaunti yako na funguo moja au kadhaa za umma zinazoruhusu funguo binafsi zinazohusiana kufanya vitendo kwa niaba yako. https://github.com/settings/keys

GPG Keys

Huwezi kujifanya kuwa mtumiaji kwa funguo hizi lakini ikiwa huzi tumii inaweza kuwa inawezekana kwamba unagundulika kwa kutuma commits bila saini. Jifunze zaidi kuhusu mode ya uangalizi hapa.

Personal Access Tokens

Unaweza kuunda token za ufikiaji wa kibinafsi ili kutoa ufikiaji wa programu kwa akaunti yako. Wakati wa kuunda token ya ufikiaji wa kibinafsi, mtumiaji anahitaji kueleza ruhusa ambazo token itakuwa nazo. https://github.com/settings/tokens

Oauth Applications

Programu za Oauth zinaweza kukuomba ruhusa za kufikia sehemu ya taarifa zako za github au kujifanya kuwa wewe ili kufanya vitendo fulani. Mfano wa kawaida wa kazi hii ni kitufe cha kuingia na github ambacho unaweza kukiona katika baadhi ya majukwaa.

Baadhi ya mapendekezo ya usalama:

  • OAuth App inapaswa kila wakati kufanya kazi kama mtumiaji aliyethibitishwa wa GitHub katika GitHub yote (kwa mfano, wakati wa kutoa arifa za mtumiaji) na kwa ufikiaji tu wa mipaka iliyotajwa.

  • Programu ya OAuth inaweza kutumika kama mtoa kitambulisho kwa kuwezesha "Ingia na GitHub" kwa mtumiaji aliyethibitishwa.

  • Usijenge OAuth App ikiwa unataka programu yako ifanye kazi kwenye hifadhi moja tu. Kwa mipaka ya repo, Programu za OAuth zinaweza kufanya kazi kwenye _zote_** za hifadhi za mtumiaji aliyethibitishwa**.

  • Usijenge programu ya OAuth ili kufanya kazi kama programu kwa timu au kampuni yako. Programu za OAuth zinathibitishwa kama mtumiaji mmoja, hivyo ikiwa mtu mmoja ataunda programu ya OAuth kwa kampuni kutumia, na kisha anaondoka kampuni, hakuna mtu mwingine atakuwa na ufikiaji wake.

  • Zaidi katika hapa.

Github Applications

Programu za Github zinaweza kuomba ruhusa za kufikia taarifa zako za github au kujifanya kuwa wewe ili kufanya vitendo maalum juu ya rasilimali maalum. Katika Programu za Github unahitaji kueleza hifadhi ambazo programu itakuwa na ufikiaji.

Baadhi ya mapendekezo ya usalama:

  • GitHub App inapaswa kuchukua hatua bila mtumiaji (isipokuwa programu inatumia token ya mtumiaji-kwa-server). Ili kuweka token za ufikiaji wa mtumiaji-kwa-server kuwa salama zaidi, unaweza kutumia token za ufikiaji ambazo zitakoma baada ya masaa 8, na token ya upya ambayo inaweza kubadilishwa kwa token mpya ya ufikiaji. Kwa maelezo zaidi, angalia "Kurefresh token za ufikiaji wa mtumiaji-kwa-server."

  • Hakikisha GitHub App inajumuisha hifadhi maalum.

  • GitHub App inapaswa kuunganishwa na akaunti binafsi au shirika.

  • Usitarajie GitHub App ijue na ifanye kila kitu ambacho mtumiaji anaweza.

  • Usitumie GitHub App ikiwa unahitaji tu huduma ya "Ingia na GitHub". Lakini GitHub App inaweza kutumia mchakato wa utambulisho wa mtumiaji kuingia watumiaji na kufanya mambo mengine.

  • Usijenge GitHub App ikiwa tu unataka kufanya kazi kama mtumiaji wa GitHub na kufanya kila kitu ambacho mtumiaji huyo anaweza kufanya.

  • Ikiwa unatumia programu yako na GitHub Actions na unataka kubadilisha faili za workflow, lazima uthibitishe kwa niaba ya mtumiaji kwa token ya OAuth ambayo inajumuisha mipaka ya workflow. Mtumiaji lazima awe na ruhusa za msimamizi au kuandika kwa hifadhi ambayo ina faili ya workflow. Kwa maelezo zaidi, angalia "Kuelewa mipaka kwa programu za OAuth."

  • Zaidi katika hapa.

Github Actions

Hii sio njia ya kuthibitisha katika github, lakini kitendo kibaya cha Github kinaweza kupata ufikiaji usioidhinishwa kwa github na kulingana na privileges zilizotolewa kwa Kitendo kadhaa shambulio tofauti zinaweza kufanywa. Tazama hapa chini kwa maelezo zaidi.

Git Actions

Vitendo vya Git vinaruhusu kuendesha utendaji wa msimbo wakati tukio linapotokea. Kwa kawaida msimbo unaotekelezwa ni kama vile unavyohusiana na msimbo wa hifadhi (labda kujenga kontena la docker au kuangalia kwamba PR haina siri).

Configuration

Katika https://github.com/organizations/<org_name>/settings/actions inawezekana kuangalia mipangilio ya vitendo vya github kwa shirika.

Inawezekana kukataa matumizi ya vitendo vya github kabisa, kuruhusu vitendo vyote vya github, au kuruhusu vitendo fulani tu.

Pia inawezekana kuunda nani anahitaji idhini ili kuendesha Kitendo cha Github na ruhusa za GITHUB_TOKEN za Kitendo cha Github wakati kinapotekelezwa.

Git Secrets

Kitendo cha Github kwa kawaida kinahitaji aina fulani za siri ili kuingiliana na github au programu za wahusika wengine. Ili kuepuka kuweka wazi katika hifadhi, github inaruhusu kuweka kama Siri.

Siri hizi zinaweza kuundwa kwa hifadhi au kwa shirika lote. Kisha, ili Kitendo kiweze kufikia siri unahitaji kuziandika kama:

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

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

Siri zinaweza kufikiwa tu kutoka kwa Github Actions ambazo zina matangazo yao.

Mara tu zinapowekwa kwenye repo au mashirika watumiaji wa github hawawezi kuzifikia tena, wataweza tu kuzibadilisha.

Hivyo, njia pekee ya kuiba siri za github ni kuwa na uwezo wa kufikia mashine inayotekeleza Github Action (katika hali hiyo utaweza kufikia tu siri zilizotangazwa kwa ajili ya Action).

Git Environments

Github inaruhusu kuunda mazingira ambapo unaweza kuhifadhi siri. Kisha, unaweza kutoa ufikiaji wa github action kwa siri ndani ya mazingira kwa kitu kama:

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

You can configure an environment to be accessed by all branches (default), only protected branches or specify which branches can access it. It can also set a number of required reviews before executing an action using an environment or wait some time before allowing deployments to proceed.

Git Action Runner

A Github Action can be executed inside the github environment or can be executed in a third party infrastructure configured by the user.

Several organizations will allow to run Github Actions in a third party infrastructure as it use to be cheaper.

You can list the self-hosted runners of an organization in https://github.com/organizations/<org_name>/settings/actions/runners

The way to find which Github Actions are being executed in non-github infrastructure is to search for runs-on: self-hosted in the Github Action configuration yaml.

It's not possible to run a Github Action of an organization inside a self hosted box of a different organization because a unique token is generated for the Runner when configuring it to know where the runner belongs.

If the custom Github Runner is configured in a machine inside AWS or GCP for example, the Action could have access to the metadata endpoint and steal the token of the service account the machine is running with.

Git Action Compromise

If all actions (or a malicious action) are allowed a user could use a Github action that is malicious and will compromise the container where it's being executed.

A malicious Github Action run could be abused by the attacker to:

  • Steal all the secrets the Action has access to

  • Move laterally if the Action is executed inside a third party infrastructure where the SA token used to run the machine can be accessed (probably via the metadata service)

  • Abuse the token used by the workflow to steal the code of the repo where the Action is executed or even modify it.

Branch Protections

Branch protections are designed to not give complete control of a repository to the users. The goal is to put several protection methods before being able to write code inside some branch.

The branch protections of a repository can be found in https://github.com/<orgname>/<reponame>/settings/branches

It's not possible to set a branch protection at organization level. So all of them must be declared on each repo.

Different protections can be applied to a branch (like to master):

  • You can require a PR before merging (so you cannot directly merge code over the branch). If this is select different other protections can be in place:

  • Require a number of approvals. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.

  • Dismiss approvals when new commits are pushed. If not, a user may approve legit code and then the user could add malicious code and merge it.

  • Require reviews from Code Owners. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)

  • Restrict who can dismiss pull request reviews. You can specify people or teams allowed to dismiss pull request reviews.

  • Allow specified actors to bypass pull request requirements. These users will be able to bypass previous restrictions.

  • Require status checks to pass before merging. Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).

  • Require conversation resolution before merging. All comments on the code needs to be resolved before the PR can be merged.

  • Require signed commits. The commits need to be signed.

  • Require linear history. Prevent merge commits from being pushed to matching branches.

  • Include administrators. If this isn't set, admins can bypass the restrictions.

  • Restrict who can push to matching branches. Restrict who can send a PR.

As you can see, even if you managed to obtain some credentials of a user, repos might be protected avoiding you to pushing code to master for example to compromise the CI/CD pipeline.

References

Support HackTricks
PreviousAccessible Deleted Data in GithubNextGitea Security

Last updated