Basic Github Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Muundo wa msingi wa mazingira ya github ya kampuni kubwa ni kumiliki biashara ambayo inamiliki mashirika kadhaa na kila moja yao inaweza kuwa na hifadhi kadhaa na timu kadhaa. Kampuni ndogo zinaweza kumiliki tu shirika moja na hakuna biashara.
Kutoka kwa mtazamo wa mtumiaji, mtumiaji anaweza kuwa mwanachama wa biashara na mashirika tofauti. Ndani yao, mtumiaji anaweza kuwa na majukumu tofauti ya biashara, shirika na hifadhi.
Zaidi ya hayo, mtumiaji anaweza kuwa sehemu ya timu tofauti zikiwa na majukumu tofauti ya biashara, shirika au hifadhi.
Na hatimaye, hifadhi zinaweza kuwa na mifumo maalum ya ulinzi.
Mmiliki wa biashara: Watu wenye jukumu hili wanaweza kusimamia wasimamizi, kusimamia mashirika ndani ya biashara, kusimamia mipangilio ya biashara, 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 biashara: Wajumbe wa mashirika yanayomilikiwa na biashara yako pia ni wanachama wa biashara kiotomatiki.
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
Katika https://github.com/organizations/<org_name>/settings/member_privileges unaweza kuona ruhusa ambazo watumiaji watakuwa nazo kwa 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
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
Unaweza orodhesha timu zilizoundwa katika shirika katika https://github.com/orgs/<org_name>/teams. Kumbuka kwamba ili kuona timu ambazo ni watoto wa timu nyingine unahitaji kufikia kila timu ya mzazi.
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 inatoa njia tofauti za kuthibitisha akaunti yako na kufanya vitendo kwa niaba yako.
Kwa kufikia github.com unaweza kuingia kwa kutumia jina lako la mtumiaji na nenosiri (na 2FA huenda).
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
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.
Unaweza kuunda token za ufikiaji wa kibinafsi ili kutoa programu ufikiaji wa akaunti yako. Wakati wa kuunda token ya ufikiaji wa kibinafsi, mtumiaji anahitaji kueleza ruhusa ambazo token itakuwa nazo. https://github.com/settings/tokens
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.
Unaweza kuunda programu zako za Oauth katika https://github.com/settings/developers
Unaweza kuona programu za Oauth ambazo zina ufikiaji wa akaunti yako katika https://github.com/settings/applications
Unaweza kuona mipaka ambayo Programu za Oauth zinaweza kuomba katika https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Unaweza kuona ufikiaji wa wahusika wengine wa programu katika https://github.com/organizations/<org_name>/settings/oauth_application_policy
Baadhi ya mapendekezo ya usalama:
Programu ya OAuth 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 Programu ya OAuth ikiwa unataka programu yako ifanye kazi kwenye hifadhi moja. 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 aondoke kampuni, hakuna mtu mwingine atakayekuwa na ufikiaji wake.
Zaidi katika hapa.
Programu za Github zinaweza kukuomba 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.
Ili kufunga GitHub App, lazima uwe mmiliki wa shirika au uwe na ruhusa za msimamizi katika hifadhi.
GitHub App inapaswa kuunganishwa na akaunti binafsi au shirika.
Unaweza kuunda programu yako mwenyewe ya Github katika https://github.com/settings/apps
Unaweza kuona programu zote za Github ambazo zina ufikiaji wa akaunti yako katika https://github.com/settings/apps/authorizations
Hizi ni API Endpoints za Programu za Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Kulingana na ruhusa za Programu itakuwa na uwezo wa kufikia baadhi yao
Unaweza kuona programu zilizofungwa katika shirika katika https://github.com/organizations/<org_name>/settings/installations
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 unataka tu 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 ya msimamizi au kuandika kwa hifadhi ambayo ina faili ya workflow. Kwa maelezo zaidi, angalia "Kuelewa mipaka kwa Programu za OAuth."
Zaidi katika hapa.
Hii si 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.
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).
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.
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:
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).
Github inaruhusu kuunda mazingira ambapo unaweza kuhifadhi siri. Kisha, unaweza kutoa ufikiaji wa github action kwa siri ndani ya mazingira kwa kitu kama:
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.
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.
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 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.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
