it-swarm-tr.com

GitLab hesabı saldırıya uğradı ve repo silindi

Bir proje üzerinde çalışıyordum, özel bir repo ve aniden tüm taahhütler kayboldu ve tek bir metin dosyası ile değiştirildi

Kayıp kodunuzu kurtarmak ve sızıntıdan kaçınmak için: Git girişiniz ve Ödeme Kanıtı ile bize Bitcoin adresimiz olan 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA 0,1 Bitcoin (BTC) gönderin ve bize e-posta ile [email protected] adresinden ulaşın. Verilerinizin elimizde olup olmadığından emin değilseniz, bizimle iletişime geçin, size bir kanıt göndereceğiz. Kodunuz indirilir ve sunucularımıza yedeklenir. Ödemenizi önümüzdeki 10 gün içinde almazsak, kodunuzu herkese açık hale getirir veya başka şekilde kullanırız.

Bu sırada Google arama hiçbir şey göstermedi, ancak bir saat içinde this ortaya çıkmaya başladı.

SourceTree (her zaman güncel) kullanıyorum ama bir şekilde SourceTree sorun veya sistemim (Windows 10) tehlikeye atılmış olduğundan şüpheliyim. Ben öyle değil demiyorum, sadece şüphe duyuyorum.

Bu sadece depolarımdan birine (hepsi özel) oldu ve diğerlerine dokunulmadı. Şifremi değiştirdim, 2 faktörlü kimlik doğrulamayı etkinleştirdim, yıllardır kullanmadığım bir erişim jetonunu kaldırdım ve saldırganın nereye/kimin girdiği hakkında bana bir şey söyleyebilecekleri umuduyla GitLab'a bir e-posta yazdım.

Parolam, kaba kuvvetle nispeten kolayca kırılabilen zayıf bir parolaydı (yaygın bir parola değil, "a" ile başlıyor ve içinde sadece az karakter var) ve eğer yapabileceklerini otomatik olarak kontrol ettiler hesaba erişip bazı git komutlarını çalıştırdı. E-posta adresimin ve söz konusu şifrenin sızdırılmış hesaplar listesinde olması da mümkündür. Birisi bu şekilde girildiyse, hesap kimlik bilgilerini basitçe değiştireceklerini, ancak İnternet'te arama yapmanın bu durumlarda GitLab/GitHub'ın kimlik bilgilerini basitçe geri yükleyeceğini ve bu nedenle bu şekilde yapma.

Bu eski erişim belirteci de olabilirdi, geçmişte ne için ve nerede kullandığımı hatırlayamıyorum - büyük olasılıkla daha önce sahip olduğum bir bilgisayarda kullanılmak üzere üretildi, bu yüzden sorunun bundan şüpheliydim.

Üzerinde çalışan 4 geliştirici de var, hepsi de depoya tam erişime sahip, bu yüzden hesaplarının tehlikeye girmesi de bir olasılık.

Bilgisayarımı BitDefender ile taradım ve hiçbir şey bulamadım ama internette gölgeli şeyler yapmıyorum, bu yüzden buna bir kötü amaçlı yazılım/trojan bulaştığımı düşünmüyorum.

GitLab'dan bir cevap bekliyorum ve belki de bu konuya ışık tutabilirler. Ben yerel Git kod tabanı var, bu yüzden bu bir sorun değil, ama henüz kodu henüz depoya geri itmiyorum. Ayrıca, kodun bir yerde yayınlanması durumunda, kaynakta bulunacak şifreleri değiştireceğim (veritabanları, IMAP hesapları)

[~ # ~] Güncelleme [~ # ~]

Kodun gitmediğini öğrendim. Bir taahhüdün karma işlemine erişmeye çalıştım ve işe yaradı. Kod orada ama KAFA ile ilgili bir sorun var. Bu konudaki bilgim çok sınırlı ama

git reflog

tüm taahhütlerimi gösterir.

Bunun anlamı benim için saldırganların büyük olasılıkla depoları klonlamamış olması (yine de tüm kurbanlar için bunu yapmak için lojistik bir kabus olurdu) ve onların gitme şansı hassas verileri arayan veya kodu herkese açık hale getiren kaynak kodu düşüktür. Aynı zamanda benim için bu bir hedefli saldırı değil, bir komut dosyası tarafından gerçekleştirilen rastgele, toplu bir saldırı anlamına gelir. Umarım bu bizim için geçerlidir!

GÜNCELLEME 2

Yani, eğer yaparsan

git checkout Origin/master

saldırganın taahhüdünü göreceksin

git checkout master

tüm dosyalarınızı göreceksiniz

git checkout Origin/master
git reflog # take the SHA of the last commit of yours
git reset [SHA]

orijin/master'ınızı düzeltir ...

git status

şimdi söyleyecek

HEAD detached from Origin/master

hala bu konuda bir düzeltme arıyor

GÜNCELLEME 3

Yerel olarak dosyalarınız varsa,

git Push Origin HEAD:master --force

her şeyi düzeltir. Bakınız Peter adlı kullanıcının yorumu

Yani soru, hangi komutların depomuzu yerel olarak repoya sahip olmadığınız varsayılarak önceki çalışma durumuna geri getireceği, saldırıya nasıl girdiğinde, GitLab'ın (varsa) cevabının bize yardımcı olacağını umuyorum Daha.

Bir tartışma var burada

Saldırı GitHub, BitBucket ve GitLab hesaplarını hedefliyor. Here GitHub'ın halka açık depolarındaki büyüklüğü

166
Stefan Gabos

Bir klonda git reflog Kullanabilirsiniz ve bu gerçekleşmeden önceki son işleme göz atabilirsiniz.

Bunun nedeni, web sunucunuzdaki (klonlanmış repo dizininde) .git/config Uzak URL'leri içermesi ve hiçbir zaman böyle olmaması gereken kullanıcı adı: şifre eklenmiş olması - insanların SSH kullanması, anahtarları dağıtması veya her çekme. Kimlik bilgilerinizi asla bir yapılandırma dosyasında saklamayın. Kimlik bilgisi yardımcılarını kullanın.

Kaynak: https://www.reddit.com/r/git/comments/bk1eco/comment/emg3cxg

merhaba, benim, yedeklerini alan adam ..

günahlarını açığa çıkaracağım

İşte 2015'ten daha ayrıntılı bir makale, https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-yoeb-websites-sourcecode-an-analysis -of-alexas-1m-28-07-2015 /

Internetwache tarafından bunun hakkında makale: https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas- 1 m-28-07-2015 /

Bunun bir noktadan başlayarak dizinlere erişimini engellemek için https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess#L528-L551 adresine bakın.

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# Block access to all hidden files and directories with the exception of
# the visible content from within the `/.well-known/` hidden directory.
#
# These types of files usually contain user preferences or the preserved
# state of an utility, and can include rather private places like, for
# example, the `.git` or `.svn` directories.
#
# The `/.well-known/` directory represents the standard (RFC 5785) path
# prefix for "well-known locations" (e.g.: `/.well-known/manifest.json`,
# `/.well-known/keybase.txt`), and therefore, access to its visible
# content should not be blocked.
#
# https://www.mnot.net/blog/2010/04/07/well-known
# https://tools.ietf.org/html/rfc5785

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} "!(^|/)\.well-known/([^./]+./?)+$" [NC]
    RewriteCond %{SCRIPT_FILENAME} -d [OR]
    RewriteCond %{SCRIPT_FILENAME} -f
    RewriteRule "(^|/)\." - [F]
</IfModule>

Veya .git Dizinini ve --separate-git-dir Kullanarak verileri ayırın.

--separate-git-dir = <git dir>
Depoyu $ GIT_DIR veya ./.git/ dizinine bir dizin olarak başlatmak yerine, orada gerçek depo yolunu içeren bir metin dosyası oluşturun. Bu dosya veri havuzuna agnostik Git sembolik bağlantısı olarak işlev görür.

Bu yeniden başlatma ise, depo belirtilen yola taşınır.

Ancak en iyisi, bir dağıtımdan sonra rm -rf .git 'Ya yöneliktir; bu, bir yapı artefaktını hedefe rsync kullanarak kopyalamalıdır.

https://git-scm.com/docs/git-init#Documentation/git-init.txt---separate-git-dirltgitdirgt

--separate-git-dir = <git dir>
Klonlanmış depoyu olması gerektiği yere yerleştirmek yerine, klonlanmış depoyu belirtilen dizine yerleştirin, ardından dosya sistemine agnostik Git sembolik bağlantısı oluşturun. Sonuç Git deposu çalışma ağacından ayrılabilir.

https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---separate-git-dirltgitdirgt

https://stackoverflow.com/a/8603156/753676

Dağıtım anahtarları ve kimlik bilgisi yardımcıları hakkında bilgi:

https://developer.github.com/v3/guides/managing-deploy-keys/

Dağıtım anahtarları varsayılan olarak salt okunurdur, ancak bir havuza eklerken yazma erişimi verebilirsiniz.

https://Gist.github.com/zhujunsan/a0becf82ade50ed06115

https://help.github.com/en/articles/caching-your-github-password-in-git

Ana, etiketler vb. İçin tüm referansları uzaktan kumandaya göndermek ve ardından hesabınızda 2FA'yı etkinleştirmek için yerel klonunuzdan git Push -u Origin master -f && git Push --tags -f Kullanın.

Daha fazla şube etkilenirse git Push -u --all -f Kullanın

Ayrıca, bu tür saldırıların olasılığını azaltmak için lütfen 2FA'yı etkinleştirin.

Lütfen güvenliği ihlal edilmiş tüm giriş bilgilerini/şifreleri değiştirmeyi ve bilinmeyen oturumları iptal etmeyi unutmayın.

77
Daniel Ruf

Bilgisayar korsanlarının bir "tümünü sil" taahhüdünü zorladığından şüpheliyim, yoksa son taahhüdü geri alabilirsiniz. Aksine, ana dalın HEAD) notuyla farklı bir taahhüdü zorladılar, böylece tüm taahhüt geçmişiniz yok gibi görünüyor.

Diğerlerinin de belirttiği gibi, zorlamak için kolayca yerel bir repo kullanabilirsiniz. Git'in dağıtılmış doğası nedeniyle, her yerel repo hem taahhütler hem de kod dahil olmak üzere sunucunun tam bir klonuna sahip olduğundan, sunucunun silinip silinmediği her zaman çalışır. Elbette, kurtarma çabalarını denemeden önce sunucunun güvenli olduğundan emin olmalısınız. :-)

En son kesinleştirmeyi içeren yerel bir repo yoksa, kesinleştirme geçmişi (ve ilişkili tüm dosyalar) sunucuda bir süre daha kalır. Ancak, sunucu sonunda git gc, ulaşılamayan taahhütleri temizler. 2013 itibariyle GitHub, git gc en fazla günde bir kez ama aynı zamanda manuel olarak tetiklenebilir , BitBucket gerektiği gibi çalıştırır , ya da belki her Pushtan sonra . GitLab bunu varsayılan olarak çalıştırır 200 kez ittikten sonra veya manuel olarak tetiklenebilir.

Ancak, tüm taahhütler ve dosyalar hala sunucuda olsa bile, geri yükleyebilmek için kesinliğin karmasını bulmanız gerekir. Refloglu yerel bir repo olmadan, geri yükleme için doğru taahhüdü bulmak zor. Deneyebileceğiniz bazı fikirler:

  • Çekme istekleri genellikle sonsuza kadar tutulur, bu nedenle ana dalda birleştirilen en son çekme isteğine bakabilmeniz gerekir. Şube karmasını değil, birleştirme taahhüdünün karmasını seçtiğinizden emin olun. (GitHub, birleştirme taahhüdü karmasının yanında yeşil bir onay işaretine sahiptir; GitLab, BitBucket'ten emin olmadığından "master ile birleştirildi" gösterir).
  • Bir oluşturma sunucunuz varsa, ana dalın en son derlemesinin ne olduğunu görün (belki derleme günlüğünde?)
  • Reponuzun çatallarını da kontrol etmek isteyebilirsiniz. GitHub bunları Forks veya Network görünümlerinde görmenizi sağlar.

Master için doğru karmayı bulduğunuzda, aşağıdaki komutları kullanarak sunucunuzu geri yükleyebilirsiniz ('Origin' adlı bir Git uzaktan kumandanız olduğu varsayılarak).

git fetch Origin <hash>
git checkout master
git reset --hard <hash>
git Push --force Origin master:master

Asla asla kullanmamalısınız git Push --force birinin çalışmalarının üzerine yazmak istemiyorsanız.

49
Matt

Daha fazla şube etkilenirse, git Push -u --all -f

for branch in `git branch -a | grep remotes | grep -v HEAD | grep -v master `; do
   git branch --track ${branch#remotes/Origin/} $branch
done

https://Gist.github.com/octasimo/66f3cc230725d1cf1421

6
Ron

Sanırım zaten daha açık olduğunu biliyorsun, ama yine de:

  1. Bundan sonra, kullanıcı adı + şifre yerine GitLab (ve bu konu için onu destekleyen başka bir uzaktan kumanda) ile iletişim kurmak içinSSHöğesini @ Daniel Ruf tavsiye etti.

  2. GitLab hesabınız için çok güçlü bir şifre(16+ rastgele oluşturulmuş karakter sırasıyla) yapılandırın veyönetmek için bir şifre yöneticisikullanın.

  3. Bilgisayarınızın güvenliğinin aşılmadığından emin olun. Her adımda bir adım daha ileri gider ve tüm çevrimiçi hesaplarımın şifrelerini değiştiririm.

Şimdi başka bir acil konuyu ele almak için:

Bunun benim için anlamı, saldırganların büyük olasılıkla depoları klonlamamış olmasıdır (yine de tüm kurbanlar için bunu yapmak için lojistik bir kabus olurdu) (varsayım # 1)
(...)
ve hassas verileri arayan kaynak kodu aşma veya kodu herkese açık hale getirme şanslarının düşük olması (...) (varsayım # 2)

Ayrıca benim için hedefli bir saldırı değil, bir senaryo tarafından gerçekleştirilen rastgele, toplu bir saldırı (...) (varsayım # 3)

Varsayım # 1 ve # 3 doğru olabilir veya olmayabilir (kişisel olarak planınız fidye için tahrif etmek olduğunda depoları klonlamanın lojistik bir kabus olduğunu düşünmüyorum - saldırganın bu göreve adanmış bir sunucusu olabilir, VPN veya sıralama aracılığıyla yapılandırılmış olabilir ve hedeflenmiş olabilirsiniz). Ama çok önemli değiller.

Ancak,# 2 varsayımı, şu anda yapamayacağınız bir varsayımdır.

Kod veya repo geçmişi özel bilgiler veya herhangi bir ticari sır içeriyorsa, acil durum adımlarını hemen uygulamaya başlayın.

Mesajlarının bir kısmını alıntılamak için:

Ödemenizi önümüzdeki 10 gün içinde almazsak, kodunuzu herkese açık hale getirir veya başka şekilde kullanırız.

Korkarım kifidye ödeyip ödemeyeceğiniziödeyip ödemeyeceğinizi varsayalım. Özellikle "aksi halde kullanın" biti.

3
Marc.2377