Temel Github Bilgileri

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Temel Yapı

Büyük bir company için temel github ortam yapısı, bir enterprise’a sahip olmaktır; bu enterprise birden fazla organization’a sahip olur ve her biri birden fazla repository ve birden fazla team içerebilir. Daha küçük şirketler sadece bir organization’a sahip olup enterprise’ları olmayabilir.

Kullanıcı bakış açısından, bir user farklı enterprises ve organizationsın üyesi olabilir. Bunların içinde kullanıcı farklı enterprise, organization ve repository rollerine sahip olabilir.

Ayrıca, bir kullanıcı farklı teams’in parçası olabilir ve farklı enterprise, organization veya repository rollerine sahip olabilir.

Ve son olarak repositories özel koruma mekanizmalarına sahip olabilir.

Yetkiler

Enterprise Rolleri

  • Enterprise owner: Bu role sahip kişiler yöneticileri yönetebilir, enterprise içindeki organization’ları yönetebilir, enterprise ayarlarını yönetebilir, organization’lar arasında politika uygulayabilirler. Ancak, organizasyon ayarlarına veya içeriğe erişemezler; bunun için ya organization owner yapılmaları ya da organization’a ait bir repository’ye doğrudan erişim verilmesi gerekir.
  • Enterprise members: Enterprise’ınız tarafından sahip olunan organization’ların üyeleri otomatik olarak enterprise üyesi olurlar.

Organization Rolleri

Bir organization içinde kullanıcılar farklı rollere sahip olabilir:

  • Organization owners: Organization owners, organization üzerinde tam idari erişime sahiptir. Bu rol sınırlı tutulmalıdır, fakat organizasyonunuzda en az iki kişiden az olmamalıdır.
  • Organization members: Organization içindeki kişilerin varsayılan, idari olmayan rolü organization member’dır. Varsayılan olarak organization üyelerinin bir dizi izni vardır.
  • Billing managers: Billing managers, organizasyonunuz için ödeme bilgileri gibi fatura ayarlarını yönetebilen kullanıcılardır.
  • Security Managers: Organization owners tarafından bir team’e atanabilen bir roldür. Uygulandığında, takımın her üyesine organizasyon genelinde security alert’leri ve ayarları yönetme izinleri ve organizasyondaki tüm repository’ler için okuma izinleri verir.
  • Eğer organizasyonunuzun bir security team’i varsa, security manager rolünü kullanarak takım üyelerine organizasyona yönelik en az erişimi verebilirsiniz.
  • Github App managers: Bir organization tarafından sahip olunan GitHub Apps’leri yönetmelerine izin vermek için owner, kullanıcılara Github App manager izinleri verebilir.
  • Outside collaborators: Outside collaborator, organization üyesi olmayan fakat bir veya daha fazla organization repository’sine erişimi olan kişidir.

Bu rollerin izinlerini bu tabloda karşılaştırabilirsiniz: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Üye Yetkileri

in https://github.com/organizations/<org_name>/settings/member_privileges adresinde kullanıcıların organizasyonun parçası olmaktan dolayı sahip olacakları izinleri görebilirsiniz.

Burada yapılandırılan ayarlar, organizasyon üyelerinin aşağıdaki izinlerini gösterecektir:

  • Tüm organizasyon repository’leri üzerinde admin, writer, reader veya hiç izin sahibi olmama.
  • Üyelerin private, internal veya public repository oluşturup oluşturamayacağı.
  • Repository’lerin fork edilebilme durumu.
  • Outside collaborators davet etmenin mümkün olup olmadığı.
  • Public veya private sitelerin yayınlanıp yayınlanamayacağı.
  • Adminlerin repository’ler üzerindeki izinleri.
  • Üyelerin yeni teams oluşturup oluşturamayacağı.

Repository Rolleri

Varsayılan olarak repository rolleri oluşturulur:

  • Read: Projenizi görüntülemek veya tartışmak isteyen kod dışı katkıcılar için önerilir.
  • Triage: Yazma erişimi olmadan issue’ları ve pull request’leri proaktif olarak yönetmesi gereken katkıcılar için önerilir.
  • Write: Projenize aktif olarak push yapan katkıcılar için önerilir.
  • Maintain: Repository’yi yönetmesi gereken proje yöneticileri için önerilir; hassas veya yıkıcı işlemlere erişim olmadan.
  • Admin: Güvenlik yönetimi veya repository silme gibi hassas ve yıkıcı işlemler dahil olmak üzere projeye tam erişime ihtiyaç duyan kişiler için önerilir.

Her rolün izinlerini bu tabloda karşılaştırabilirsiniz: https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Ayrıca kendi rollerinizi https://github.com/organizations/<org_name>/settings/roles adresinde oluşturabilirsiniz.

Teams

Organization’da oluşturulmuş teams’leri https://github.com/orgs/<org_name>/teams/ adresinde listeleyebilirsiniz. Not: başka team’lerin alt takımları olan team’leri görmek için her bir üst team’e erişmeniz gerekir.

Users

Organization kullanıcıları https://github.com/orgs/<org_name>/people adresinde listelenebilir.

Her kullanıcının bilgisi içinde kullanıcının üye olduğu teams ve kullanıcının erişimi olan repos görülebilir.

Github Authentication

Github, hesabınıza kimlik doğrulaması yapmak ve sizin adınıza işlem gerçekleştirmek için farklı yollar sunar.

Web Erişimi

github.com’a erişerek kullanıcı adı ve parola (ve potansiyel olarak 2FA) ile giriş yapabilirsiniz.

SSH Keys

Hesabınızı bir veya birkaç public key ile yapılandırabilir, böylece ilgili private key sizin adınıza işlem yapabilir. https://github.com/settings/keys

GPG Keys

Bu anahtarlarla kullanıcıyı taklit edemezsiniz, ancak eğer kullanmazsanız imzasız commit göndermekten dolayı keşfedilmeniz mümkün olabilir. vigilant mode hakkında daha fazla bilgi için buraya bakın.

Personal Access Tokens

Bir uygulamaya hesabınıza erişim vermek için personal access token oluşturabilirsiniz. Bir personal access token oluştururken kullanıcı, token’ın sahip olacağı izinleri belirtmelidir. https://github.com/settings/tokens

Oauth Applications

Oauth uygulamaları, github bilgilerinize erişmek veya sizi taklit ederek bazı işlemler yapmak için izin isteyebilir. Bu işlevselliğe yaygın bir örnek, bazı platformlarda bulabileceğiniz login with github butonudur.

Bazı güvenlik önerileri:

  • Bir OAuth App, belirtilen scope’larla sınırlı erişimle, her zaman kimlik doğrulanmış GitHub kullanıcısı gibi davranmalıdır (örneğin, kullanıcı bildirimleri sağlarken).
  • Bir OAuth App, kimliği doğrulanmış kullanıcı için “Login with GitHub” etkinleştirerek kimlik sağlayıcı olarak kullanılabilir.
  • Repo OAuth scope’u ile OAuth Apps, kimlik doğrulanmış kullanıcının tüm repository’leri üzerinde hareket edebilir, bu yüzden eğer uygulamanızın sadece tek bir repository üzerinde davranmasını istiyorsanız OAuth App oluşturmayın.
  • Bir şirket veya takım için bir OAuth App oluşturmayın. OAuth Apps bir tek kullanıcı olarak kimlik doğrular; bir kişi şirket için OAuth App oluşturup şirketten ayrılırsa, kimse ona erişemez.
  • Daha fazla bilgi için bakınız: here.

Github Applications

Github applications, belirli kaynaklar üzerinde github bilgilerinize erişmek veya sizi taklit etmek için izin isteyebilir. Github Apps içinde uygulamanın erişeceği repository’leri belirtmeniz gerekir.

  • Bir GitHub App’i yüklemek için organization owner olmanız veya bir repository üzerinde admin izinlerine sahip olmanız gerekir.
  • GitHub App bir kişisel hesap veya bir organization ile ilişkilendirilmelidir.
  • Kendi Github uygulamanızı https://github.com/settings/apps adresinde oluşturabilirsiniz.
  • Hesabınıza erişimi olan tüm Github applications’ı https://github.com/settings/apps/authorizations adresinde görebilirsiniz.
  • Bunlar Github Applications için API Endpoints’dir: https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Uygulamanın izinlerine bağlı olarak bazılarına erişim sağlanabilir.
  • Bir organization içinde yüklü uygulamaları https://github.com/organizations/<org_name>/settings/installations adresinde görebilirsiniz.

Bazı güvenlik önerileri:

  • Bir GitHub App, kullanıcıdan bağımsız olarak işlem yapmalıdır (uygulama bir user-to-server token kullanmıyorsa). User-to-server erişim token’larını daha güvenli tutmak için, 8 saat sonra süresi dolacak access token’ları ve yeni access token ile takas edilebilecek bir refresh token kullanabilirsiniz. Daha fazla bilgi için “Refreshing user-to-server access tokens.” başlığına bakın.
  • GitHub App’in belirli repository’lerle entegre olduğundan emin olun.
  • GitHub App bir kişisel hesap veya bir organization ile ilişkilendirilmelidir.
  • GitHub App’in bir kullanıcının bildiği ve yapabildiği her şeyi bilmesini veya yapmasını beklemeyin.
  • Sadece “Login with GitHub” servisine ihtiyacınız varsa GitHub App kullanmayın. Ancak bir GitHub App, kullanıcıları oturum açtırmak ve diğer şeyleri yapmak için bir user identification flow kullanabilir.
  • Eğer sadece bir GitHub kullanıcısı gibi davranıp o kullanıcının yapabildiği her şeyi yapmak istiyorsanız GitHub App oluşturmayın.
  • GitHub Actions ile uygulamanızı kullanıyor ve workflow dosyalarını değiştirmek istiyorsanız, kullanıcının adına OAuth token ile kimlik doğrulamanız gerekir ve token workflow scope’unu içermelidir. Kullanıcının workflow dosyasını içeren repository üzerinde admin veya write izni olmalıdır. Daha fazla bilgi için “Understanding scopes for OAuth apps.” başlığına bakın.
  • Daha fazla bilgi için bakınız: here.

Github Actions

Bu, github’da kimlik doğrulama yapma yolu değildir, fakat kötü niyetli bir Github Action github’a yetkisiz erişim elde edebilir ve Action’a verilen yetkilere bağlı olarak birçok farklı saldırı gerçekleştirilebilir. Daha fazla bilgi için aşağıya bakın.

Git Actions

Git actions, bir olay gerçekleştiğinde kodun çalıştırılmasını otomatikleştirir. Genellikle çalıştırılan kod, repository koduyla bir şekilde ilişkilidir (örneğin bir docker container oluşturmak veya PR’da gizli veri olup olmadığını kontrol etmek).

Yapılandırma

in https://github.com/organizations/<org_name>/settings/actions adresinde organization için github actions yapılandırmasını kontrol etmek mümkündür.

Github actions kullanımını tamamen yasaklamak, tüm github actions’lara izin vermek veya sadece belirli actions’lara izin vermek mümkündür.

Ayrıca kimlerin bir Github Action’ı çalıştırmak için onaya ihtiyaç duyduğunu ve bir Github Action çalıştırıldığında GITHUB_TOKEN’ın izinlerini yapılandırmak da mümkündür.

Git Secrets

Github Action’lar genellikle github veya üçüncü taraf uygulamalarla etkileşim için bazı secrets gerektirir. Bunları repoda açık metin olarak tutmamak için github, bunları Secrets olarak eklemeye izin verir.

Bu secret’lar repo için veya tüm organization için yapılandırılabilir. Ardından, Action’ın secret’a erişebilmesi için onu şu şekilde beyan etmeniz gerekir:

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

Bash kullanarak örnek 

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

Warning

Secrets sadece bunları beyan eden Github Actions üzerinden erişilebilir.

Repo veya organizasyon düzeyinde yapılandırıldıktan sonra github kullanıcıları onlara tekrar erişemeyecek, sadece değiştirebileceklerdir.

Bu nedenle, github secrets’i çalmanın tek yolu, Github Action’ı çalıştıran makineye erişebilmektir (bu senaryoda yalnızca Action için beyan edilmiş secrets’lara erişebilirsiniz).

Git Environments

Github, secrets’i saklayabileceğiniz environments oluşturmanıza izin verir. Ardından, github action’a environment içindeki secrets’e erişim verebilirsiniz, örneğin:

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.
Additionally, environment protections include:

  • Required reviewers: gate jobs targeting the environment until approved. Enable Prevent self-review to enforce a proper four‑eyes principle on the approval itself.
  • Deployment branches and tags: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the “Protected branches only” option applies to classic branch protections and may not behave as expected if using rulesets.
  • Wait timer: delay deployments for a configurable period.

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.

Caution

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

Note

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 approval of the most recent reviewable push. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
  • 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 need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., “@bot-name skip”).
  • 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.

Note

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.

Tag Protections

Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:

  1. On the tag protection rule, enable Require deployments to succeed and require a successful deployment to a protected environment (e.g., prod).
  2. In the target environment, restrict Deployment branches and tags to the release branch (e.g., main) and optionally configure Required reviewers with Prevent self-review.
  3. On the release branch, configure branch protections to Require a pull request, set approvals ≥ 1, and enable both Dismiss approvals when new commits are pushed and Require approval of the most recent reviewable push.

This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin