Basic Github Information
Last updated
Last updated
AWS Hacking öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
Büyük bir şirketin temel github ortam yapısı, birden fazla organizasyona sahip olan bir şirket sahibi olmaktır ve her biri birkaç depo ve birkaç takım içerebilir. Daha küçük şirketler sadece bir organizasyona ve hiçbir şirkete sahip olabilir.
Bir kullanıcı açısından, bir kullanıcı farklı şirketler ve organizasyonlar üyesi olabilir. Bu organizasyonlar içinde kullanıcı, farklı şirket, organizasyon ve depo rollerine sahip olabilir.
Ayrıca, bir kullanıcı farklı takımlarda farklı şirket, organizasyon veya depo rollerine sahip olabilir.
Ve nihayetinde, depolar özel koruma mekanizmalarına sahip olabilir.
Şirket sahibi: Bu role sahip kişiler, yönetici yönetimi, şirket içindeki organizasyonları yönetme, şirket ayarlarını yönetme, organizasyonlar arasında politika uygulama yetkisine sahiptir. Ancak, organizasyon ayarlarına veya içeriğine erişemezler; bunun için organizasyon sahibi olmaları veya bir organizasyona ait depoya doğrudan erişim verilmesi gerekir.
Şirket üyeleri: Şirketinizin sahip olduğu organizasyonların üyeleri de otomatik olarak şirketin üyeleridir.
Bir organizasyonda kullanıcılar farklı rollere sahip olabilir:
Organizasyon sahipleri: Organizasyon sahipleri, organizasyonunuza tam yönetim erişimine sahiptir. Bu rol sınırlı olmalı, ancak organizasyonunuzda en az iki kişi olmalıdır.
Organizasyon üyeleri: Varsayılan, yönetici olmayan rol organizasyon içindeki kişilerdir. Varsayılan olarak, organizasyon üyeleri bir dizi izne sahiptir.
Faturalama yöneticileri: Faturalama yöneticileri, organizasyonunuzun faturalama ayarlarını yönetebilen kullanıcılardır; örneğin, ödeme bilgileri.
Güvenlik Yöneticileri: Organizasyon sahiplerinin herhangi bir takıma atayabileceği bir roldür. Uygulandığında, takımın her üyesine organizasyon genelinde güvenlik uyarılarını ve ayarlarını yönetme izinleri ile organizasyondaki tüm depolar için okuma izinleri verir.
Eğer organizasyonunuzda bir güvenlik takımı varsa, güvenlik yöneticisi rolünü kullanarak takım üyelerine organizasyona en az erişimi verebilirsiniz.
Github Uygulama yöneticileri: Bir organizasyona ait GitHub Uygulamalarını yönetmek için ek kullanıcılara izin vermek üzere, bir sahibi onlara GitHub Uygulama yöneticisi izinleri verebilir.
Dış işbirlikçileri: Dış işbirlikçisi, bir veya daha fazla organizasyon deposuna erişimi olan ancak organizasyonun açıkça bir üyesi olmayan 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
https://github.com/organizations/<org_name>/settings/member_privileges adresinde, organizasyonun bir parçası olmanın getirdiği izinleri görebilirsiniz.
Burada yapılandırılan ayarlar, organizasyon üyelerinin aşağıdaki izinlerini gösterecektir:
Tüm organizasyon depoları üzerinde yönetici, yazar, okuyucu veya hiçbir izin olma.
Üyelerin özel, dahili veya genel depolar oluşturup oluşturamayacağı.
Depoların çatallanmasının mümkün olup olmadığı.
Dış işbirlikçilerinin davet edilip edilemeyeceği.
Genel veya özel sitelerin yayınlanıp yayınlanamayacağı.
Yöneticilerin depolar üzerindeki izinleri.
Üyelerin yeni takımlar oluşturup oluşturamayacağı.
Varsayılan olarak depo rolleri oluşturulur:
Okuma: Projenizi görüntülemek veya tartışmak isteyen kod katkıda bulunmayanlar için önerilir.
Triage: Yazma erişimi olmadan sorunları ve çekme isteklerini proaktif bir şekilde yönetmesi gereken katkıda bulunanlar için önerilir.
Yazma: Projenize aktif olarak katkıda bulunanlar için önerilir.
Sürdürme: Hassas veya yıkıcı eylemlere erişim olmadan depoları yönetmesi gereken proje yöneticileri için önerilir.
Yönetici: Proje üzerinde tam erişime ihtiyaç duyan kişiler için önerilir; bu, güvenliği yönetmek veya bir depoyu silmek gibi hassas ve yıkıcı eylemleri içerir.
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, https://github.com/organizations/<org_name>/settings/roles adresinde kendi rollerinizi oluşturabilirsiniz.
Bir organizasyonda oluşturulan takımları listeleyebilirsiniz https://github.com/orgs/<org_name>/teams. Diğer takımların alt takımlarını görmek için her ana takıma erişmeniz gerektiğini unutmayın.
Bir organizasyonun kullanıcıları https://github.com/orgs/<org_name>/people. adresinde listelenebilir.
Her kullanıcının bilgileri içinde, kullanıcının üyesi olduğu takımlar ve kullanıcının erişim sağladığı depolar görülebilir.
Github, hesabınıza kimlik doğrulaması yapmak ve sizin adınıza eylemler gerçekleştirmek için farklı yollar sunar.
github.com adresine erişerek kullanıcı adınız ve şifreniz (ve potansiyel olarak bir 2FA) ile giriş yapabilirsiniz.
Hesabınızı, ilgili özel anahtarın sizin adınıza eylemler gerçekleştirmesine izin veren bir veya daha fazla genel anahtar ile yapılandırabilirsiniz. https://github.com/settings/keys
Bu anahtarlarla kullanıcıyı taklit edemezsiniz, ancak kullanmıyorsanız, imzasız gönderim yaparken keşfedilme olasılığınız olabilir. Daha fazla bilgi için dikkatli mod hakkında burada öğrenin.
Bir uygulamanın hesabınıza erişim sağlaması için kişisel erişim jetonu oluşturabilirsiniz. Kişisel erişim jetonu oluştururken, kullanıcı jetonun sahip olacağı izinleri belirtmelidir. https://github.com/settings/tokens
Oauth uygulamaları, github bilgilerinize erişim sağlamak veya sizi taklit etmek için izin isteyebilir. Bu işlevselliğin yaygın bir örneği, bazı platformlarda bulabileceğiniz github ile giriş yap butonudur.
Kendi Oauth uygulamalarınızı https://github.com/settings/developers adresinde oluşturabilirsiniz.
Hesabınıza erişimi olan tüm Oauth uygulamalarını https://github.com/settings/applications adresinde görebilirsiniz.
Oauth Uygulamaların isteyebileceği kapsamları https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps adresinde görebilirsiniz.
Bir organizasyondaki uygulamaların üçüncü taraf erişimini https://github.com/organizations/<org_name>/settings/oauth_application_policy adresinde görebilirsiniz.
Bazı güvenlik önerileri:
Bir OAuth Uygulaması, her zaman tüm GitHub üzerinde kimlik doğrulaması yapılmış GitHub kullanıcısı olarak hareket etmelidir (örneğin, kullanıcı bildirimleri sağlarken) ve yalnızca belirtilen kapsamlarla erişim sağlamalıdır.
Bir OAuth Uygulaması, kimlik doğrulaması yapılmış kullanıcı için "GitHub ile Giriş Yap" özelliğini etkinleştirerek bir kimlik sağlayıcı olarak kullanılabilir.
Tek bir depo üzerinde hareket etmesini istiyorsanız bir OAuth Uygulaması oluşturmayın. repo OAuth kapsamı ile, OAuth Uygulamaları kimlik doğrulaması yapılmış kullanıcının tüm depolarında hareket edebilir.
Bir takım veya şirket için bir uygulama olarak hareket etmesi için bir OAuth Uygulaması oluşturmayın. OAuth Uygulamaları tek bir kullanıcı olarak kimlik doğrulaması yapar, bu nedenle bir kişi bir şirketin kullanması için bir OAuth Uygulaması oluşturursa ve ardından şirketten ayrılırsa, başka kimse buna erişemez.
Daha fazla bilgi için burada okuyabilirsiniz.
Github uygulamaları, github bilgilerinize erişim sağlamak veya sizi taklit etmek için izin isteyebilir ve belirli kaynaklar üzerinde belirli eylemler gerçekleştirebilir. Github Uygulamalarında, uygulamanın erişim sağlayacağı depoları belirtmeniz gerekir.
Bir GitHub Uygulaması yüklemek için, bir organizasyon sahibi olmalı veya bir depoda yönetici izinlerine sahip olmalısınız.
GitHub Uygulaması, kişisel bir hesap veya bir organizasyon ile bağlanmalıdır.
Kendi Github uygulamanızı https://github.com/settings/apps adresinde oluşturabilirsiniz.
Hesabınıza erişimi olan tüm Github uygulamalarını https://github.com/settings/apps/authorizations adresinde görebilirsiniz.
İşte Github Uygulamaları için API Uç Noktaları https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Uygulamanın izinlerine bağlı olarak, bunlardan bazılarına erişim sağlayabilir.
Bir organizasyondaki yüklü uygulamaları https://github.com/organizations/<org_name>/settings/installations adresinde görebilirsiniz.
Bazı güvenlik önerileri:
Bir GitHub Uygulaması, bir kullanıcıdan bağımsız olarak eylemler gerçekleştirmelidir (uygulama kullanıcıdan sunucuya jetonu kullanmıyorsa). Kullanıcıdan sunucuya erişim jetonlarını daha güvenli hale getirmek için, 8 saat sonra süresi dolacak erişim jetonları ve yeni bir erişim jetonu için değiştirilebilecek bir yenileme jetonu kullanabilirsiniz. Daha fazla bilgi için "Kullanıcıdan sunucuya erişim jetonlarını yenileme" kısmına bakın.
GitHub Uygulamasının belirli depolarla entegre olduğundan emin olun.
GitHub Uygulaması, kişisel bir hesap veya bir organizasyon ile bağlanmalıdır.
GitHub Uygulamasının, bir kullanıcının yapabileceği her şeyi bilmesini ve yapmasını beklemeyin.
Sadece "GitHub ile Giriş Yap" hizmetine ihtiyacınız varsa GitHub Uygulaması kullanmayın. Ancak bir GitHub Uygulaması, kullanıcıları giriş yapmaları için ve diğer şeyleri yapmak için bir kullanıcı tanımlama akışı kullanabilir.
Eğer uygulamanızı GitHub Actions ile kullanıyorsanız ve iş akışı dosyalarını değiştirmek istiyorsanız, workflow kapsamını içeren bir OAuth jetonu ile kullanıcı adına kimlik doğrulaması yapmalısınız. Kullanıcının iş akışı dosyasını içeren depoda yönetici veya yazma iznine sahip olması gerekir. Daha fazla bilgi için "OAuth uygulamaları için kapsamları anlama" kısmına bakın.
Daha fazla bilgi için burada okuyabilirsiniz.
Bu, github'da kimlik doğrulama yapmanın bir yolu değildir, ancak kötü niyetli bir Github Action, github'a yetkisiz erişim sağlayabilir ve verilen ayrıcalıklara bağlı olarak çeşitli farklı saldırılar gerçekleştirilebilir. Daha fazla bilgi için aşağıya bakın.
Git eylemleri, bir olay gerçekleştiğinde kodun yürütülmesini otomatikleştirmeye olanak tanır. Genellikle yürütülen kod, deponun koduyla bir şekilde ilişkilidir (belki bir docker konteyneri oluşturmak veya PR'nin gizli bilgiler içermediğini kontrol etmek).
https://github.com/organizations/<org_name>/settings/actions adresinde, organizasyon için github eylemlerinin yapılandırmasını kontrol etmek mümkündür.
Github eylemlerinin kullanımını tamamen yasaklamak, tüm github eylemlerine izin vermek veya yalnızca belirli eylemlere izin vermek mümkündür.
Ayrıca, bir Github Eylemi çalıştırmak için kimin onay alması gerektiğini ve bir Github Eylemi çalıştırıldığında GITHUB_TOKEN'un izinlerini yapılandırmak da mümkündür.
Github Action genellikle github veya üçüncü taraf uygulamalarla etkileşimde bulunmak için bazı gizli bilgilere ihtiyaç duyar. Gizli bilgileri açık metin olarak depoya koymaktan kaçınmak için, github bunları Gizli Bilgiler olarak koymanıza izin verir.
Bu gizli bilgiler, depo veya tüm organizasyon için yapılandırılabilir. Daha sonra, Eylemin gizli bilgiye erişebilmesi için bunu şu şekilde belirtmeniz gerekir:
Gizli anahtarlar yalnızca bunları tanımlayan Github Actions'tan erişilebilir.
Repo veya organizasyonlarda yapılandırıldıktan sonra github kullanıcıları onlara tekrar erişemeyecek, sadece değiştirebileceklerdir.
Bu nedenle, github gizli anahtarlarını çalmanın tek yolu, Github Action'ı yürüten makineye erişim sağlamaktır (bu senaryoda yalnızca Action için tanımlanan gizli anahtarlara erişebileceksiniz).
Github, gizli anahtarları saklayabileceğiniz ortamlar oluşturmanıza olanak tanır. Ardından, ortam içindeki gizli anahtarlara erişim vermek için github action'a şöyle bir şey verebilirsiniz:
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)
