Böcek ödülü avlamak ve keşfedilecek heyecan verici alanlar bulmak söz konusu olduğunda, satıcıların ve şirketlerin güvendiği teknolojilere aşina olmanız hayati önem taşır. Gözümüze çarpan özellikle ilginç bir ortam, çeşitli açık kaynaklı projeler tarafından, özellikle geliştirme yaşam döngülerinin bir parçası olarak kullanılan popüler entegrasyonlardı. Travis CI, Circle CI ve GitLab CI dahil olmak üzere sürekli entegrasyon hizmetlerinin (“CI hizmetleri”) bazı önemli örneklerinin, hata ödülü avcıları olarak bizler için son derece faydalı olduğu ortaya çıktı.
Bu CI hizmetlerinden büyük veri kümelerinin getirilmesini ve aranmasını otomatikleştirmek için yola çıktık. Bu teknik yazıda karşılaştığımız çok sayıda zorluğa, aramalarımızdaki hatalı pozitif sonuçların sayısını nasıl azalttığımıza, dikkate değer bulgulara değinecek ve son olarak yol boyunca yakaladığımız bazı püf noktalarını listeleyeceğiz.
Bu araştırmada çalışan ekipte Justin Gardner (@Rhynorater), Corben Leo (@hacker_) ve EdOverflow (@EdOverflow) – Karim Rahal’ın bazı test edici ve faydalı önerileriyle (@KarimPwnz), @streaak, @d0nutptrve BBAC.
Sürekli entegrasyon hizmetlerine giriş
Sürekli entegrasyon (CI), kod değişikliklerini gerçekleştirme ve her değişikliği otomatik olarak oluşturup test etme uygulamasıdır. Günümüzde geliştirme döngüsünün bir noktasında sürekli entegrasyon hizmeti kullanmayan açık kaynaklı bir projeye rastlamamak nadirdir. Piyasadaki çeşitli hizmetler, hızlı bir şekilde test etmek ve sürekli olarak kod oluşturmak için basit kurulum yapılandırma adımları ve güzel arayüzler sunar.
Örneğin, Security.txt projesi, bir taahhütte bulunulduğunda yeni taslak belgeler oluşturmak için Travis CI’yı kullanıyor. Bu, ekibin, spesifikasyonda yapılacak herhangi bir değişikliğin İnternet Taslağını kullanarak derlendiğinde potansiyel olarak bozulup bozulmayacağını hızlı bir şekilde belirlemesine olanak tanır. kramdown-rfc2629 — Markdown’da her şeyin yazılmasını ve ardından XML2RFC XML işaretlemesine dönüştürülmesini sağlayan bir araç.
Başımızdan neler geçti
Geçmişte okuyucuların talep ettiği bir şey de, burada sunduğumuz çalışma türü gibi yazarların araştırma konularını nasıl ortaya çıkardığına dair belirlenmiş bir bölümün bulunmasıydı. Bu bölümün bu fikrin başlangıçta nereden kaynaklandığını göstereceğini umuyoruz.
Bu yazının tüm yazarları GitHub’daki açık kaynaklı projeler üzerinde çalışma konusunda çok fazla deneyime sahiptir ve yıllar içinde açık kaynak proje sahipleri için geliştirme sürecini basitleştiren teknikler öğrenmişlerdir. GitHub, https://github.com/marketplace adresinde çok sayıda entegrasyon sunuyor ve burada belirli bir kategori öne çıkıyor: “Sürekli entegrasyon”. Pek çok açık kaynak ekibinin geliştirme sürecinde tam şeffaflık ve açıklık için çabalaması nedeniyle projelerin sürekli entegrasyon platformlarında derleme günlük verilerini gizleme konusunda tereddüt ettiğini işte burada keşfettik. Kuşkusuz, Travis CI gibi entegrasyonlar travis-ci.com’da birinci sınıf bir özellik olarak özel profiller sunuyor, ancak araştırmamız sırasında projelerin büyük çoğunluğunun yalnızca travis-ci.org genel örneğini kullandığı ortaya çıktı – “.org’a dikkat edin” ” üst düzey alan adı.
“Bir HackerOne çalışanının Travis CI oluşturma günlüklerinde açığa çıkan GitHub kişisel erişim belirteci” ve “altındaki API”de görüldüğü gibi, sürekli entegrasyon hizmetlerinin geçmişte hata ödülü avcıları ve üçüncü taraflarca hassas bilgiler için hedef alındığını belirtmekte fayda var. saldırı” Travis CI olay raporu:
“Şu anda genel API’mize yönelik, GitHub kimlik doğrulama belirteçlerini açığa çıkarmayı hedeflediğine inandığımız dağıtılmış bir saldırı altındayız. Karşı önlemler devam ediyor ve buna göre güncelleme yapacağız.”
— Travis CI (Eylül 2015)
Öyle ki Travis CI gibi platformlar, aşağıda görüldüğü gibi hassas bilgilerin kazara açığa çıkmasını önlemek için yerleşik sır tespitini tanıttı. [1]
Travis CI, potansiyel olarak hassas bilgileri, [secure] çalışma zamanında anahtar kelime.
Bu bileşenlerin neden olduğu sızıntıları önlemek için, çalışma zamanında üç karakterden uzun olan güvenli ortam değişkenlerini ve belirteçleri otomatik olarak filtreliyoruz, bunları derleme günlüğünden etkili bir şekilde kaldırıyoruz ve dizeyi görüntülüyoruz
[secure]yerine.
Sıkıcı görevleri otomatikleştirme
Travis CI’nın sunduğu gibi büyük bir saldırı yüzeyine manuel olarak yaklaşmak inanılmaz derecede sıkıcı bir iş olacaktır. Bu nedenle, bu CI satıcılarının sağladığı mevcut API belgeleriyle çalışmamız ve derleme günlüklerinin hızlı bir şekilde alınmasını otomatikleştirmek için araçlar geliştirmemiz gerekiyordu.
Bir hata ödül programından daha fazla araştırma için kapsamlı bir veri setine geçiş sürecini daha iyi göstermek amacıyla örnek olarak Travis CI’nın API belgelerini kullanacağız.
Sürecimizin ilk aşaması, hata ödül programlarının GitHub organizasyonlarını getirmekti. Bunu yapmanın birden fazla yolu vardı, ancak en iyi sonuçları elde etmek için Google’da “şirket adı” ve “GitHub” araması yeterli olacaktır. Daha sonra GitHub tanıtıcısının Travis CI’da olup olmadığını kontrol etmemiz gerekiyordu. Bu süreci daha sorunsuz hale getirmek için GitHub tanıtıcısını kullanarak bizi GitHub’dan Travis CI’ye yönlendirecek bir tarayıcı yer imi kullandık.
javascript:window.location="https://travis-ci.org"+window.location.pathname;
Hedef GitHub’da mevcutsa Travis CI’da projelerin API uç noktasına ulaşıyoruz ve tüm projelerin bir listesini alıyoruz.
https://api.travis-ci.org/owner/%s/repos?limit=100&offset=%d
Travis CI’nın API’si büyük/küçük harfe duyarlıdır; Neyse ki yer imi, API isteklerini gönderirken doğru tanıtıcıyı kullandığınızdan emin olmanızı sağlar. Derleme günlüklerinin içeriğini toplamak için derleme kimlikleri API uç noktasına ulaşmamız ve ardından /log.txt.
https://api.travis-ci.org/repo/%s/builds?limit=100&offset=%d
https://api.travis-ci.org/job/%d/log.txt
Artık hedefe ait tüm derleme günlüklerinin içeriği yerel olarak depolandığına göre, greplemeye başlayabiliriz. Analiz ettiğimiz verilerin büyüklüğü nedeniyle, aşağıdaki yöntemlere başvurduk: ripgrep günlükleri yerel olarak elerken.
$ rg -ia "$1" -j 12 --no-filename --no-line-number --pretty
Hata ödül programının GitHub hesaplarının yanı sıra yazarlar, GitHub organizasyonunun tüm üyelerine ait derleme günlüklerini de topladılar. Bazı üyelerin, sırlarının derleme günlüklerinde açığa çıktığının farkında olmadan, kendi hesaplarında derlemeler çalıştırdıkları ortaya çıktı.
#!/bin/bash
users=$(curl -s -H "application/vnd.github.hellcat-preview+json" -H "Authorization: token $GH_TOKEN" https://api.github.com/orgs/"$1"/members | jq -r .[].login);
while read -r hehe; do
secretz -t "$hehe";
done <<< "$users"
Bu projenin arkasındaki ekip, CI platformlarının performansındaki herhangi bir kesintiden doğrudan sorumlu olmak istemediğimizden, derleme günlüklerini getirmek için oluşturulan araçlardan herhangi birini yayınlamaktan kaçınmaya karar verdi. Bu yazı kaçınılmaz olarak bazı CI platformlarının mevcut geniş saldırı yüzeyine daha fazla dikkat çekecektir; bu nedenle yazarlar okuyucuya platformun API’sini kullanırken her uç noktayı aynı anda çok sayıda istekle doldurmamaya dikkat etmesini hatırlatmak isterler. Tüm süreç boyunca hiçbir hizmeti kaldırmama konusunda çok dikkatli davrandık ve başkalarına da aynı şeyi yapmalarını tavsiye ettik.
Sonuçlar ve dikkate değer bulgular
Genel olarak en etkili bulgular ağırlıklı olarak GitHub erişim belirteci sızıntılarıydı. Bu bölümde ekibimizin sunduğu dört önemli raporu ele alacağız.
Grammarly çalışanlarının Travis CI derleme günlüklerini incelerken, bir çalışanın Grammarly GitHub organizasyonuna okuma ve yazma erişimi olan GitHub erişim belirtecini keşfettik. Bu belirteç, Grammarly’nin GitHub sayfasında listelenen depolardan herhangi birine kod göndermemize olanak tanırdı. Grammarly, HackerOne’a göre bize bugüne kadarki en yüksek ödemeyi verdi “Program İstatistikleri”. [2]
Kapsamımızı genişletmek için birden fazla platformu değerlendirdik. Özel bir Bugcrowd programının 2013’teki Travis CI derleme günlüğünde bir GitHub erişim belirteci bulduk ve Bugcrowd’da mümkün olan en yüksek önem puanı olan P1 önem derecesine sahip bir ödemeyle ödüllendirildik. [3]
Bulguları bildirdiğimiz tüm satıcılardan gelen en şaşırtıcı yanıt Discourse’un hata ödül programıydı. Karim Rahal, Discourse GitHub organizasyonu altındaki tüm halka açık depolara okuma ve yazma erişimi olan bir çalışanın GitHub erişim belirtecini keşfetti. Bu sorunun olası etkisini göstermek amacıyla, çok fazla dikkat çekmemesi için zararsız bir dosyayı kuruluşun en az aktif olan depolarından birine gönderdik. Dosya daha sonra depodan kaldırıldı.
Discourse, Karim’e mümkün olan en düşük ödül olan 128 doları verdi. Ekibin ödül miktarını nasıl belirlediğine dair daha fazla açıklama talep ettik ancak Discourse ekibinden henüz bir yanıt alamadık; yani 60 gündür yanıt alamadık. [3]
HackerOne’daki halka açık bir kripto para programında başka bir kritik hata daha keşfedildi. Bu program, bir SSH anahtarı oluşturmak için Travis CI içindeki gizli değişkenleri kullanıyordu. Bu yapılandırmanın ayrıntılarına buradan ve buradan ulaşabilirsiniz. Binlerce kayıt incelendikten sonra Justin Gardner’ın yazdığı bir araç tarafından aşağıdaki satır tespit edildi:
-----BEGIN RSA PRIVATE KEY-----
Bir geliştirici eklemişti cat deploy_key Günlükte SSH anahtarını çıkaran CI yapılandırma dosyasında. Saldırgan, SSH anahtarıyla programın altyapısındaki birden fazla dağıtım sunucusuna giriş yapmış olabilir. Sunucuların üretim dışı olması nedeniyle 1000$ ödül verildi.
İpuçları ve püf noktaları
Genellikle basit bir grep export Derleme günlüklerindeki ifadeler iyi bir başlangıç noktası olabilir. export komutu, günlük isteminde ortam değişkenlerini ayarlamak için kullanılır ve bu nedenle hassas bilgileri açığa çıkarabilir.
$ rg -ia "export " -j 12 --no-filename --no-line-number --pretty
Tabii ki, kişi kendisini yalnızca aşağıdaki değişkenleri kullanarak belirlenen değişkenlerle sınırlamamalıdır: export emretmek; Arama terimlerini “belirteç”, “anahtar”, “şifre” ve “gizli” şeklinde hassaslaştırmak belirli sızıntıların ortaya çıkarılmasına yardımcı olabilir. Yanlış pozitiflerin sayısını azaltmak için şunu eklemenizi öneririz: = Ve : arama terimlerinize göre.
Okuyucuları tüm değişkenlerin bir listesini oluşturmaya teşvik ediyoruz. [secure] anahtar kelimeyi seçin ve ardından tüm projelerde bu değişken adlarını kullanarak arama yapın. Bu, ortak değişken adlandırma kurallarını kullanarak güvenli olmayan hassas veri örneklerini bulmanıza yardımcı olacaktır. Karim Rahal toplandı [secure] 5.302.677 derleme günlüğünden değişkenler; bunların en yaygın 50’si aşağıda görülebilir.
Ek olarak, en sevdiğiniz hata ödül programının CI derlemelerinin sürekli izlenmesini ayarlamak ve ekibin GitHub’a yeni bir taahhütte bulunduğu her seferde araçlarınızı çalıştırmak, ekibin harekete geçmesine zaman kalmadan açığa çıkan sırları gerçek zamanlı olarak yakalamanın harika bir yoludur.
Kendinizi anahtarlar ve jetonlarla sınırlamayın; CI platformları keşif için de harika bir bilgi kaynağıdır. Hedefe ait gizli uç noktaları ve URL’leri bulmak için günlükleri tarayın.
Hedefinizin hangi CI entegrasyonunu kullandığını belirlemek için GitHub’daki CI yapılandırma dosyalarını kontrol edin. Bu yazıda ele alınmayan, sırların açığa çıktığı başka CI platformları da olabilir.
Grep sürecimize dahil ettiğimiz eğlenceli bir görev, genellikle eksik veya bozuk bağımlılıklarla ilişkilendirilen dizeleri ve hata mesajlarını bulmaktı. Eksik npm paketlerinde bu durum bazen https://hackerone.com/reports/399166 adresinde gösterildiği gibi paket adının uzak bir kayıt defterinde talep edilmesiyle kod yürütülmesine yol açabilir. Bazı örnek hata mesajları şunları içerir:
- “npm kayıt defterinde değil.” (npm)
- “Eşleşen dağıtım yok” (PyPI)
- “Geçerli bir mücevher bulunamadı” (RubyGems)
Sonuç ve ileri araştırma
Bu araştırma, sürekli entegrasyon hizmetlerinin sunduğu (neredeyse göz önünde gizlenmiş) geniş saldırı yüzeyini daha iyi anlamamıza yardımcı oldu ve hata ödülü avcılığı konusunda son derece verimli olduğu ortaya çıktı.
Bu araştırmaya oldukça sınırlı sayıda platform dahil edildiğinden, gelecekteki çalışmalar ve projeler daha fazla CI platformunu ve entegrasyonunu kapsamayı düşünebilir.
Kullanıcıların hassas ortam değişkenlerini günlüklerinde gizlemelerine olanak tanıyan Travis CI gibi platformları takdir ediyoruz. Bize göre bu, karşılaştığımız türden güvenlik sızıntılarının önlenmesi açısından doğru yönde atılmış bir adımdır.
Bu çalışma bize yalnızca çok sayıda başarılı hata ödülü öyküsü ve geçerli bulgu sağlamakla kalmadı, aynı zamanda burada bu projede görüldüğü gibi işbirliğinin, hata ödülü avında uzun bir yol kat edebileceğini de gösterdi. ■
Güncelleme (19 Ağustos 2019): Bu yazının yayınlanmasından bu yana Corben Leo (@hacker_) serbest bırakıldı sırTravis CI’dan derleme günlüklerinin alınmasına yardımcı olacak bir araç: https://github.com/lc/secretz.