Mayıs 2019 güvenlik olayına daha derin bir bakış: blog yayını geri bildirimi
Mayıs 2019'da meydana gelen güvenlik olayına ilişkin teknik ayrıntılar, nasıl olduğu ve benzer bir olayın tekrar olmasını önlemek için uyguladığımız düzeltmelerle ilgili bir güncelleme yayınladık . İşte gönderiden birkaç alıntı - ilk olarak girişten:
12 Mayıs 2019, 00:00 UTC civarında, topluluğun birden çok üyesi tarafından yeni bir kullanıcı hesabı için beklenmedik bir ayrıcalık artışı konusunda uyarı aldık. Kimsenin tanımadığı bir kullanıcı, Stack Exchange Network'teki tüm sitelerde moderatör ve geliştirici düzeyinde erişim kazanmıştı. Hemen yanıtımız, ayrıcalıkları iptal etmek ve bu hesabı askıya almak ve ardından olaya neden olan eylemleri belirleyip denetlemek için bir süreci harekete geçirmek oldu.
İlk keşfin ardından, ayrıcalığın artmasının buzdağının sadece görünen kısmı olduğunu ve saldırının aslında kaynak kodumuzun çalınmasına ve 184 kullanıcının PII'sinin (e-posta, gerçek ad, IP adresleri) yanlışlıkla açığa çıkmasına neden olduğunu gördük. Yığın Değişim Ağı'nın (tümü bilgilendirildi). Neyse ki, veritabanlarının hiçbiri - ne genel (okuma: Yığın Exchange içeriği) ne de özel (Ekipler, Yetenek veya Kurumsal) - dışarı sızmadı. Ek olarak, iç ağ altyapımıza doğrudan erişim olduğuna dair hiçbir kanıt bulunamamıştır ve saldırgan hiçbir zaman Teams, Talent veya Enterprise ürünlerindeki verilere erişememiştir.
Ve son paragraftan:
Bu olay bize herkesin izlemesi gereken bazı temel güvenlik uygulamalarını hatırlattı:
- Tüm gelen trafiğinizi günlüğe kaydedin. Tüm bağlı bağlantıların günlüklerini tutuyoruz. Bu, tüm araştırmalarımızı mümkün kıldı. Neyi kaydetmediğinizi araştıramazsınız.
- 2FA kullanın. Hala eski kimlik doğrulamasını kullanan kalan sistem, en büyük güvenlik açığınız olabilir.
- Sırları daha iyi koruyun. TeamCity'nin sırları korumanın bir yolu var, ancak bunu tutarlı bir şekilde kullanmadığımızı gördük. Mühendisleri "sırların sadece parola olmadığı" konusunda eğitin. SSH anahtarlarını ve veritabanı bağlantı dizelerini de koruyun. Şüpheye düştüğünüzde koruyun. Sırları bir Git deposunda saklamanız gerekiyorsa git-crypt veya Blackbox ile koruyun .
- Müşteri isteklerini doğrulayın. Bir müşteriden gelen bir talep ne kadar olağandışı olursa, talebin meşru olup olmadığını doğrulamak o kadar önemlidir.
- Güvenlik raporlarını ciddiye alın. Topluluğumuzun şüpheli etkinliği bu kadar çabuk bildirmesine minnettarız. Teşekkür ederim!
Blog gönderisinde çok daha fazlası var - lütfen aşağıdaki gönderi ile ilgili herhangi bir soru veya yorum sormaktan çekinmeyin; bunları yanıtlamak için elimizden gelenin en iyisini yapacağız. Devam eden soruşturmalar nedeniyle, blog gönderisinde yer alanların ötesinde saldırı ile ilgili başka ayrıntılar hakkında yorum yapamıyoruz.
Yanıtlar
Saldırganların niyetleri hakkında yorum yapabilir misiniz?
Belirli bir hedefin / belirli (kullanıcı) verilerinin peşinde oldukları anlaşılıyor mu?
Yoksa daha çok, ne kadar ileri gidebileceklerini görmek için sopalarla alay eden "meraklı bir genç" miydi?
PS, bu konudaki açıklık için teşekkürler, gerçekten takdir ediliyor!
Bu hat:
Yığın Değişim Ağı'nda bir şeyler arama (soruları ziyaret etme) eylemi sık görülen bir olay haline gelir ve önümüzdeki günlerde saldırganın metodolojisini tahmin etmemize ve anlamamıza olanak tanır . (vurgu benim)
Saldırı gerçekleşirken gerçek zamanlı gibi görünmesini sağlar , saldırganın gördüklerine (saldırıdan sonra) adli olarak bakarak yaptıklarına değil, Stack Overflow'da ziyaret ettiklerine dayalı olarak ne yapacağını belirleyebilirsiniz. Hangisini kastettin?
Çoğunlukla saldırganla ilgili birkaç soru:
- Saldırgana ne oldu?
- Hesaplarını askıya aldınız mı?
- SE saldırganla herhangi bir noktada temas kurdu mu?
- Neden saldırganın kimliğini ifşa etmiyorsunuz?
- Daha sonra başka biri aynı saldırı yöntemini kullanmayı denedi mi?
Olayların diğer ucunda tespit edilebilir bir uyku döngüsü var mıydı?
Açıklamak için düzenleyin:
Saldırganın farkına vardıktan sonra ve eylemlerinden bazılarını ortaya çıktıkça takip ettiğinize göre, hem günlük hem de geçmişe dönük olarak biyolojik bir döngüye benzeyen herhangi bir şey fark ettiniz mi? Örneğin: Yemek yemek (1-2 saat aralar), uyumak (8 saatlik hareketsizlik modeli), " uyku uykusu " (90 dakika), vb.?
Bu gerçekten olayın bir parçası değil, çalışan hesaplarıyla ilgili güvenlik önlemleriyle ilgili daha genel bir endişedir. Bu olayda pek çok adım vardı, ancak sonuncusu bir SE hesabının ayrıcalıklarını artırmaktı. Üretimde SQL'i yürütmek için dev örneği aracılığıyla CI sunucusuna yönetici erişimi elde etmekten çok daha basit yollar hayal edebiliyorum ve SE'nin daha basit kazanç girişimlerine karşı savunmak için uyguladığı azaltma ve güvenlik uygulamalarıyla ilgileniyorum. bir çalışan hesabına erişim.
Belli ki ana SE sitelerini güvenlik duvarının arkasına koyamazsınız, böylece her zaman açığa çıkacaklardır. Ve SE dahili oturum açma yöntemi, biraz ilgili bulduğum herhangi bir 2FA yöntemi sağlamıyor.
- çalışan hesapları 2FA başka yollarla (veya diğer oturum açma sağlayıcıları) korunuyor mu?
- Çalışan hesaplarına daha az güvenli olabilecek ve hesaba erişim sağlamak için kurtarma postaları almak için kullanılabilecek özel e-posta adreslerinin veya oturum açma sağlayıcılarının eklenmemesini sağlayacak herhangi bir önlem var mı?
- çalışan hesapları için yeni kaynaklardan giriş denemeleri izleniyor mu?
- Bir kişinin bir çalışan hesabının çalışan bir oturumuna erişim sağlaması durumunda tehlikeli çalışan araçları için ek korumalar var mı (örneğin, güvenlik açısından kritik araçlara erişirken tekrar parola ve / veya 2FA belirteci gerektirme)
Hedefli kimlik avı gibi bir şey, muhtemelen bir kişinin bir çalışan hesabına erişmeye çalışmasının en olası yollarından biridir.
Yaklaşık aynı zamanda, bu güvenlik olayı gerçekleşti, birkaç gün sonra, bazı kullanıcılar sohbette Twitter'da onebox'ın artık çalışmadığını fark etmeye başladı . Bir çalışan daha sonra gelecek yılın Şubat ayında , bu güvenlik olayı sonucunda “bazı boşlukları kapatmak” zorunda kaldığı için gerçekten kasıtlı olarak devre dışı bırakıldığını doğruladı .
Bu güvenlik olayının bir sonucu olarak sohbette Twitter'da onebox özelliğinin neden devre dışı bırakılması gerektiğine dair tam bir açıklama alabilir miyiz? O tarihte yayınlanan blog yazısı, o zaman "diğer potansiyel vektörlerin" kapatıldığını ve yukarıda bağladığım Şubat 2020 personel mesajında, Twitter onebox özelliğinin "kapattığımız boşluklardan birini kullandığını" belirtti. O şey neydi ve ne gibi bir güvenlik riski yarattı?
Son olarak, bu işlevselliğin güvenli bir şekilde yeniden uygulanmasının bir yolu var mı? Ağustos 2020'de, yukarıdaki personel mesajından birkaç ay sonra, o sırada dosyalanan hata raporu , başka bir çalışan tarafından duruma göre işaretlendi . Tasarımı (güvenli bir şekilde) değiştirmek için bir özellik talebi kabul edilir mi, yoksa bir saldırı vektörü açmadan bunu yapmak imkansız mı?
TeamCity'deki "şifre" parametre türlerinin o kadar güvenli sayılmadığını belirtmek isterim:
Parola değeri, TeamCity Veri Dizini altındaki yapılandırma dosyalarında saklanır. Sunucu Şifreleme Ayarlarına bağlı olarak, değer karıştırılır veya özel bir anahtarla şifrelenir.
Derleme günlüğü değeri basit bir ara ve değiştir algoritmasıyla gizlenir, bu nedenle önemsiz bir "123" şifreniz varsa, "123" ün tüm tekrarları değiştirilerek potansiyel olarak şifre açığa çıkarılır. Parametrenin parola türüne ayarlanması, ham değerin alınamayacağını garanti etmez. Herhangi bir proje yöneticisi onu alabilir ve derleme komut dosyasını değiştirebilen herhangi bir geliştirici, parolayı almak için potansiyel olarak kötü amaçlı kod yazabilir.
Geliştiricideki sihirli bağlantı neden CM'ler için görüntülenebilirdi (muhtemelen sadece geliştirmede) gerçek bir sihirli bağlantı?
Bu gerçekten harika bir olay raporu! Okuduğum en iyilerden biri.
Herkese açık yaptığınız için Stack'e ve harika bir yazı için Dean'e teşekkür ederiz!
Birkaç şeyi bilmek merak ediyorum:
- Olay müdahale ekibinin boyutu nedir?
- Soruşturma sırasında izlenen belirli protokoller var mıydı?
- Harici güvenlik tedarikçisini devreye sokmak için hangi kilit faktör dahil edildi? Bu satıcıyı seçerken dikkate alınan noktalar nelerdi?
- Harici güvenlik tedarikçisinden ne gibi dersler alındı? Denetim süreçleri ekip tarafından halihazırda kullanılandan farklı mıydı (etkili / etkisiz)?
Makale, Stack'in tüm mimarisi ve geliştirme süreçleri hakkında iyi bir fikir veriyor. Daha ayrıntılı bir okuma olur veya hakkında zaten bir makale varsa bağlantı harika olur.
"Başkalarına Tavsiye" altında:
Tüm gelen trafiğinizi günlüğe kaydedin. Tüm bağlı bağlantıların günlüklerini tutuyoruz. Bu, tüm araştırmalarımızı mümkün kıldı. Neyi kaydetmediğinizi araştıramazsınız.
Stack Exchange kadar meşgul bir ağ, gelen trafiğin tamamını nasıl günlüğe kaydedebilir? Bu günlükler web sunucusu girişleri mi yoksa IP akışları mı yoksa tam TCP oturumları mı?
Küçük ağımda çoğu girişi ve bağlantı girişimini kaydedebildim, ancak bu kadar büyük bir ağın bunu nasıl yaptığı hakkında hiçbir fikrim yok.
Aşağıdaki alıntıda "halka açık mülklerin" ne anlama geldiğini daha net bir şekilde açıklayabilir misiniz ?
herkesin erişebileceği mülklerimize gelen tüm trafiğin günlüğünü içeren bir veritabanımız var