Turkish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Basic Github Information

AWS hacklemeyi sıfırdan kahraman seviyesine öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı) ile!

HackTricks'ı desteklemenin diğer yolları:

Temel Yapı

Büyük bir şirketin temel github ortam yapısı, bir enterprise'a sahip olması ve her birinin birçok organizasyonu ve birçok depoyu ve birçok takımı içerebileceğidir. Daha küçük şirketler genellikle bir organizasyona ve hiçbir enterprise'a sahip değildir.

Bir kullanıcı açısından, bir kullanıcı, farklı enterprise'ların ve organizasyonların üyesi olabilir. Bunlar içinde kullanıcının farklı enterprise, organizasyon ve depo rolleri olabilir.

Ayrıca, bir kullanıcı farklı enterprise, organizasyon veya depo rollerine sahip olan farklı takımların bir parçası olabilir.

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

Yetkiler

Enterprise Roller

  • Enterprise sahibi: Bu role sahip kişiler, yöneticileri yönetebilir, enterprise içindeki organizasyonları yönetebilir, enterprise ayarlarını yönetebilir, organizasyonlar arasında politika uygulayabilir. Ancak, organizasyon ayarlarına veya içeriğine erişemezler, ancak bir organizasyon sahibi yapılırsa veya bir organizasyon tarafından sahip olunan bir depoya doğrudan erişim verilirse.

  • Enterprise üyeleri: Enterprise'a ait olan organizasyonların üyeleri aynı zamanda otomatik olarak enterprise üyesidir.

Organizasyon Roller

Bir organizasyonda kullanıcılar farklı rollerde olabilir:

  • Organizasyon sahipleri: Organizasyon sahipleri, organizasyonunuzda tam yönetici erişimine sahiptir. Bu rol, organizasyonunuzda en az iki kişiyle sınırlı olmalıdır.

  • Organizasyon üyeleri: Organizasyondaki kişilerin varsayılan, yönetici olmayan rolü organizasyon üyesidir. Varsayılan olarak, organizasyon üyelerinin bir dizi izni vardır.

  • Fatura yöneticileri: Fatura yöneticileri, organizasyonunuzun fatura ayarlarını yönetebilen kullanıcılardır, örneğin ödeme bilgileri gibi.

  • Güvenlik Yöneticileri: Bu, organizasyon sahiplerinin bir organizasyondaki herhangi bir takıma atayabileceği bir rol. Uygulandığında, takımın her üyesine organizasyonunuzdaki güvenlik uyarılarını ve ayarlarını yönetme izinleri ile birlikte organizasyondaki tüm depoları okuma izinleri verir.

  • Organizasyonunuzda bir güvenlik ekibi varsa, güvenlik yöneticisi rolünü kullanarak ekibin üyelerine organizasyona ihtiyaç duydukları en az erişimi verebilirsiniz.

  • Github Uygulama yöneticileri: Bir sahip, bir organizasyona ait olan GitHub Uygulamalarını yönetmek için ek kullanıcılara izin verebilir, GitHub Uygulama yöneticisi izinlerini verebilir.

  • Dış işbirlikçiler: Dış işbirlikçi, bir veya daha fazla organizasyon deposuna erişimi olan ancak açıkça organizasyon üyesi olmayan bir 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

https://github.com/organizations/<org_name>/settings/member_privileges adresinde, organizasyonun bir parçası olan üyelerin sahip olacağı izinleri görebilirsiniz.

Burada yapılandırılan ayarlar, organizasyonun üyelerinin aşağıdaki izinlerini belirtecektir:

  • Tüm organizasyon depoları üzerinde yönetici, yazar, okuyucu veya hiçbir izin olma.

  • Üyelerin özel, iç veya genel depolar oluşturabilmesi.

  • Depoların çatallanmasının mümkün olup olmadığı.

  • Dış işbirlikçileri davet etmenin mümkün olup olmadığı.

  • Genel veya özel sitelerin yayınlanabilmesi.

  • Yöneticilerin depolar üzerindeki izinleri.

  • Üyelerin yeni takımlar oluşturabilmesi.

Depo Rolleri

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 olarak yönetmek isteyen katkıda bulunanlar için önerilir.

  • Yazma: Projeye aktif olarak katkıda bulunan katkıda bulunanlar için önerilir.

  • Sürdürme: Hassas veya yıkıcı eylemlere erişim olmadan depo yönetimini yapması gereken proje yöneticileri için önerilir.

  • Yönetici: Güvenlik yönetimi veya bir depoyu silme gibi hassas ve yıkıcı eylemler de dahil olmak üzere projeye tam erişim gerektiren 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, https://github.com/organizations/<org_name>/settings/roles adresinde kendi rollerinizi oluşturabilirsiniz.

Takımlar

Bir organizasyonda oluşturulan takımları https://github.com/orgs/<org_name>/teams adresinde listeleyebilirsiniz. Diğer takımların alt takımlarını görmek için her bir üst takıma erişmeniz gerektiğini unutmayın.

Kullanıcılar

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

Her kullanıcının bilgilerinde kullanıcının üye olduğu takımları ve erişimi olan depoları görebilirsiniz.

Github Kimlik Doğrulama

Github, hesabınıza kimlik doğrulamak ve adınıza işlemler gerçekleştirmek için farklı yöntemler sunar.

Web Erişimi

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

SSH Anahtarları

Hesabınızı, ilgili **özel anahtarın adınıza işlemler yapmasına izin veren bir veya birkaç genel anahtar

Oauth Uygulamaları

Oauth uygulamaları, bazı işlemleri gerçekleştirmek için sizden izin isteyebilir, örneğin github bilgilerinizin bir kısmına erişim veya sizin yerinize hareket etmek. Bu işlevselliğin yaygın bir örneği, bazı platformlarda bulabileceğiniz "github ile giriş yap" düğmesidir.

Bazı güvenlik önerileri:

  • Bir OAuth Uygulaması, her zaman GitHub üzerindeki tüm işlemlerde kimlik doğrulaması yapılan GitHub kullanıcısı olarak hareket etmelidir (örneğin, kullanıcı bildirimleri sağlarken) ve yalnızca belirtilen kapsamlara erişim sağlamalıdır.

  • Bir OAuth Uygulaması, kimlik sağlayıcı olarak kullanılarak kimlik doğrulaması yapılan bir kullanıcı için "GitHub ile giriş yap" özelliğini etkinleştirebilir.

  • Uygulamanızın yalnızca bir depoda işlem yapmasını istemiyorsanız OAuth Uygulaması oluşturmayın. repo OAuth kapsamı ile OAuth Uygulamaları, kimlik doğrulanan kullanıcının tüm depolarında işlem yapabilir.

  • Takım veya şirketiniz için bir uygulama olarak hareket etmek için OAuth Uygulaması oluşturmayın. OAuth Uygulamaları, yalnızca bir kullanıcı olarak kimlik doğrulama yapar, bu nedenle bir kişi bir şirketin kullanması için bir OAuth Uygulaması oluşturursa ve daha sonra şirketten ayrılırsa, başka kimse buna erişemez.

  • Daha fazlası için buraya bakın.

Github Uygulamaları

Github uygulamaları, belirli kaynaklar üzerinde belirli işlemler gerçekleştirmek için github bilgilerinize erişim veya sizin yerinize hareket etme izni isteyebilir. Github Uygulamalarında, uygulamanın erişim sağlayacağı depoları belirtmeniz gerekmektedir.

Bazı güvenlik önerileri:

  • Bir GitHub Uygulaması, bir kullanıcıya bağımsız olarak hareket etmelidir (uygulama, kullanıcıdan-sunucuya bir token kullanıyorsa hariç). Kullanıcı-sunucu erişim belgelerini daha güvenli tutmak için, 8 saat sonra süresi dolacak bir erişim belgesi ve yeni bir erişim belgesi için değiştirilebilen bir yenileme belgesi kullanabilirsiniz. Daha fazla bilgi için "Kullanıcı-sunucu erişim belgelerini yenileme" bölümüne bakın.

  • GitHub Uygulamasının belirli depolarla entegre olduğundan emin olun.

  • GitHub Uygulaması, bir kişisel hesap veya bir kuruluşa bağlanmalıdır.

  • GitHub Uygulamasının bir kullanıcının bileceği ve 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ı oturum açmak ve diğer işlemler yapmak için bir kullanıcı kimlik doğrulama akışı kullanabilir.

  • Yalnızca bir GitHub kullanıcısı gibi hareket etmek ve kullanıcının yapabileceği her şeyi yapmak istiyorsanız bir GitHub Uygulaması oluşturmayın.

  • Uygulamanızı GitHub Actions ile kullanıyorsanız ve iş akışı dosyalarını değiştirmek istiyorsanız, kullanıcı adına yetkilendirme yapmak için workflow kapsamını içeren bir OAuth belirteciyle kimlik doğrulaması yapmanız gerekmektedir. Kullanıcının, iş akışı dosyasını içeren depoda yönetici veya yazma izni olmalıdır. Daha fazla bilgi için "OAuth uygulamaları için kapsamları anlama" bölümüne bakın.

  • Daha fazlası için buraya bakın.

Github Actions

Bu, github'da kimlik doğrulamak için bir yol değildir, ancak kötü niyetli bir Github Action, izin alınmamış erişim elde edebilir ve Action'a verilen yetkilere bağlı olarak çeşitli farklı saldırılar gerçekleştirebilir. Daha fazla bilgi için aşağıya bakın.

Git Actions

Git eylemleri, bir olay gerçekleştiğinde kodun otomatik olarak yürütülmesine olanak tanır. Genellikle yürütülen kod, depodaki kodla bir şekilde ilişkilidir (örneğin bir docker konteyneri oluşturmak veya PR'nin gizli bilgiler içermediğini kontrol etmek).

Yapılandırma

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ırıldığında, kimin onayına ihtiyaç duyduğunu ve GITHUB_TOKEN'ın izinlerini yapılandırmak mümkündür.

Git Secrets

Github Eylemleri genellikle github veya üçüncü taraf uygulamalarla etkileşimde bulunmak için bazı gizli bilgilere ihtiyaç duyar. Bunları repo içinde açık metin olarak koymaktan kaçınmak için github, bunları Secrets olarak koymaya izin verir.

Bu sırlar, repo için veya tüm organizasyon için yapılandırılabilir. Ardından, Eylemin sırra erişebilmesi için onu şu şekilde bildirmeniz 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"

Sırlar, yalnızca bildirilen Github Eylemleri'nden erişilebilir.

Bir kez repo veya organizasyonlarda yapılandırıldığında, github kullanıcıları artık onlara erişemez, sadece değiştirebilirler.

Bu nedenle, github sırlarını çalmak için yalnızca Github Eylemini yürüten makineye erişebilme yoludur (bu senaryoda yalnızca Eylem için bildirilen sırlara erişebilirsiniz).

Git Ortamları

Github, ortamlar oluşturmanıza izin verir, burada sırları saklayabilirsiniz. Ardından, github eylemine ortamdaki sırlara erişim sağlayabilirsiniz, örneğin:

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

Tüm dallar tarafından erişilebilen bir ortamı yapılandırabilirsiniz (varsayılan), yalnızca korunan dallar veya hangi dalların erişebileceğini belirtebilirsiniz. Ayrıca, bir eylem kullanmadan önce gereken incelemelerin sayısını belirleyebilir veya dağıtımların devam etmesine izin vermeden önce belirli bir süre bekleyebilirsiniz.

Git Eylem Çalıştırıcısı

Bir Github Eylemi, github ortamında veya kullanıcı tarafından yapılandırılan üçüncü taraf bir altyapıda çalıştırılabilir.

Birçok kuruluş, Github Eylemlerini üçüncü taraf bir altyapıda çalıştırmaya izin verir çünkü daha ucuzdur.

Bir kuruluşun kendi barındırılan çalıştırıcılarını https://github.com/organizations/<org_name>/settings/actions/runners adresinde listeleyebilirsiniz.

Github Eylemi yapılandırma yaml dosyasında runs-on: self-hosted ifadesini arayarak, Github altyapısı dışında çalışan Github Eylemlerini bulabilirsiniz.

Farklı bir kuruluşun Github Eylemini kendi barındırdığı bir kutuda çalıştırmak mümkün değildir, çünkü çalıştırıcıyı yapılandırırken çalıştırıcının nereye ait olduğunu bilmek için benzersiz bir belirteç oluşturulur.

Özel Github Çalıştırıcısı örneğin AWS veya GCP içinde bir makinede yapılandırılmışsa, Eylem, makinenin çalıştığı hizmet hesabının belirteci olan meta veri uç noktasına erişebilir ve çalmak için kullanılabilir.

Git Eylem Saldırısı

Tüm eylemlere (veya kötü niyetli bir eyleme) izin verilirse, bir kullanıcı, kötü niyetli bir eylem olan ve çalıştırıldığı konteyneri tehlikeye atacak bir Github eylemi kullanabilir.

Saldırgan tarafından kötü niyetli bir Github Eylemi çalıştırıldığında, saldırgan tarafından aşağıdaki gibi istismar edilebilir:

  • Eylemin erişimi olan tüm gizli bilgileri çalmak

  • Eylem, SA belirteci kullanılarak çalıştırılan bir üçüncü taraf altyapısı içinde çalıştırılıyorsa, yan yana hareket etmek

  • Eylem tarafından kullanılan iş akışı tarafından kullanılan belirteci kötüye kullanmak ve Eylemin çalıştığı repo'nun kodunu çalmak veya değiştirmek.

Dal Koruma

Dal korumaları, kullanıcılara bir depoyu tam kontrol etme yetkisi vermemek için tasarlanmıştır. Amaç, bazı dallara kod yazmadan önce birkaç koruma yöntemi uygulamaktır.

Bir depodaki dal korumaları https://github.com/<orgname>/<reponame>/settings/branches adresinde bulunabilir.

Bir dal korumasını kuruluş düzeyinde ayarlamak mümkün değildir. Bu nedenle, tüm korumalar her bir repo için belirtilmelidir.

Bir dala (örneğin ana dala) farklı korumalar uygulanabilir:

  • Bir PR gerektirmek (bu nedenle kodu doğrudan dala birleştiremezsiniz). Bu seçilirse, farklı diğer korumalar da uygulanabilir:

  • Bir onay sayısı gerektirme. PR'nizi onaylamak için genellikle 1 veya 2 kişinin onayını gerektirir, böylece tek bir kullanıcı kodu doğrudan birleştiremez.

  • Yeni taahhütler gönderildiğinde onayları reddetme. Aksi takdirde, bir kullanıcı meşru kodu onaylayabilir ve ardından kötü niyetli kod ekleyebilir ve birleştirebilir.

  • Kod Sahiplerinden incelemeleri gerektirme. Repo'nun en az 1 kod sahibi PR'yi onaylamalıdır (bu nedenle "rastgele" kullanıcılar onaylayamaz)

  • Çekme isteği incelemelerini reddedebilecek kişileri sınırlama. Çekme isteği incelemelerini reddedebilecek kişileri veya ekipleri belirtebilirsiniz.

  • Belirtilen aktörlerin çekme isteği gereksinimlerini atlamasına izin verme. Bu kullanıcılar önceki kısıtlamaları atlayabilecektir.

  • Birleştirmeden önce durum kontrolünün geçmesini gerektirme. Birleştirmeye izin vermeden önce bazı kontrollerin geçmesi gerekmektedir (örneğin, açık metin bir gizli olmadığından emin olmak için bir github eylemi kontrolü).

  • Birleştirmeden önce konuşma çözümü gerektirme. Kod üzerindeki tüm yorumların çözülmesi gerekmektedir.

  • İmzalı taahhütler gerektirme. Taahhütlerin imzalanması gerekmektedir.

  • Lineer geçmiş gerektirme. Eşleşen dallara birleştirme taahhütlerinin gönderilmesini engeller.

  • Yöneticileri dahil etme. Bu ayarlanmazsa, yöneticiler kısıtlamaları atlayabilir.

  • Eşleşen dallara itme izni veren kişileri sınırlama. Bir PR gönderebilecek kişileri sınırlayabilirsiniz.

Görüldüğü gibi, bir kullanıcının bazı kimlik bilgilerini elde etmeyi başarsanız bile, CI/CD boru hattını tehlikeye atmak için örneğin ana dala kod göndermeyi engelleyen korumalar olabilir.

Referanslar

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olacak şekilde AWS hackleme öğrenin!

HackTricks'yi desteklemenin diğer yolları:

PreviousGh Actions - Context Script InjectionsNextGitea Security

Last updated