tarafından SeerLight
Herhangi bir hizmetin oluşturulması mutlaka güvenlik konusunda sürekli çalışmayı içerir. Güvenlik, ürün güvenliğinin sürekli analizini ve iyileştirilmesini, güvenlik açıklarıyla ilgili haberlerin izlenmesini ve çok daha fazlasını içeren sürekli bir süreçtir. Denetimler dahil. Denetimler hem kurum içi hem de projeye dalmadıkları ve açık fikirli oldukları için güvenliğe radikal bir şekilde yardımcı olabilecek harici uzmanlar tarafından gerçekleştirilir.
Makale, Mail.ru Bulut Çözümleri (MCS) ekibinin bulut hizmetini test etmesine yardımcı olan harici uzmanların bu en basit görüşü ve buldukları hakkındadır. MCS, "dış güç" olarak bilgi güvenliği çevrelerindeki yüksek uzmanlığıyla bilinen Dijital Güvenlik şirketini seçti. Bu makalede, kendi bulut hizmetinizi oluşturduğunuzda aynı komisyondan kaçınmanız için, dış denetimin bir parçası olarak bulunan bazı ilginç güvenlik açıklarını analiz edeceğiz.
Описание продукта
bulutta sanal altyapı oluşturmaya yönelik bir platformdur. IaaS, PaaS ve geliştiriciler için hazır uygulama görsellerinden oluşan bir pazar yerini içerir. MCS mimarisi dikkate alındığında ürünün güvenliğinin aşağıdaki alanlarda kontrol edilmesi gerekiyordu:
- sanallaştırma ortamının altyapısını korumak: hipervizörler, yönlendirme, güvenlik duvarları;
- müşterilerin sanal altyapısının korunması: SDN'deki ağ ve özel ağlar da dahil olmak üzere birbirlerinden izolasyon;
- OpenStack ve açık bileşenleri;
- Kendi tasarımımız olan S3;
- IAM: rol modelli çok kiracılı projeler;
- Vizyon (bilgisayar görüşü): Görüntülerle çalışırken API'ler ve güvenlik açıkları;
- web arayüzü ve klasik web saldırıları;
- PaaS bileşenlerinin güvenlik açıkları;
- Tüm bileşenlerin API'si.
Belki de daha sonraki tarih için gerekli olan tek şey budur.
Ne tür çalışmalar yapıldı ve neden buna ihtiyaç duyuldu?
Güvenlik denetimi, kişisel verilerin sızmasına, hassas bilgilerin değiştirilmesine veya hizmet kullanılabilirliğinin kesintiye uğramasına yol açabilecek güvenlik açıklarını ve yapılandırma hatalarını belirlemeyi amaçlar.
Ortalama 1-2 ay süren çalışma sırasında denetçiler, potansiyel saldırganların eylemlerini tekrarlayarak, seçilen hizmetin istemci ve sunucu kısımlarındaki açıkları araştırıyor. MCS bulut platformunun denetimi kapsamında aşağıdaki hedefler belirlendi:
- Hizmetteki kimlik doğrulamanın analizi. Bu bileşendeki güvenlik açıkları, diğer kişilerin hesaplarına anında erişmeye yardımcı olacaktır.
- Farklı hesaplar arasındaki rol modelini ve erişim kontrolünü incelemek. Bir saldırgan için başka birinin sanal makinesine erişim sağlamak arzu edilen bir hedeftir.
- İstemci tarafı güvenlik açıkları. XSS/CSRF/CRLF/vb. Kötü amaçlı bağlantılar yoluyla diğer kullanıcılara saldırmak mümkün mü?
- Sunucu tarafı güvenlik açıkları: RCE ve her türlü enjeksiyon (SQL/XXE/SSRF vb.). Sunucu güvenlik açıklarının bulunması genellikle daha zordur ancak aynı anda birçok kullanıcının güvenliğinin ihlal edilmesine yol açar.
- Ağ düzeyinde kullanıcı segmenti yalıtımının analizi. Bir saldırgan için izolasyon eksikliği, diğer kullanıcılara karşı saldırı yüzeyini büyük ölçüde artırır.
- İş mantığı analizi. İşletmeleri kandırıp ücretsiz sanal makineler oluşturmak mümkün mü?
Bu projede çalışma "Gri kutu" modeline göre yürütüldü: denetçiler hizmetle sıradan kullanıcıların ayrıcalıklarıyla etkileşime girdi, ancak kısmen API'nin kaynak koduna sahipti ve geliştiricilerle ayrıntıları netleştirme fırsatı buldu. Bu genellikle en uygun ve aynı zamanda oldukça gerçekçi çalışma modelidir: dahili bilgiler hala bir saldırgan tarafından toplanabilir, bu sadece bir zaman meselesidir.
Bulunan güvenlik açıkları
Denetçinin çeşitli payloadları (saldırıyı gerçekleştirmek için kullanılan payload) rastgele yerlere göndermeye başlamadan önce işlerin nasıl çalıştığını ve hangi işlevlerin sağlandığını anlamak gerekir. Bunun işe yaramaz bir uygulama olduğu görünebilir, çünkü incelenen yerlerin çoğunda herhangi bir güvenlik açığı olmayacaktır. Ancak yalnızca uygulamanın yapısını ve çalışma mantığını anlamak, en karmaşık saldırı vektörlerini bulmayı mümkün kılacaktır.
Şüpheli görünen veya bir şekilde diğerlerinden çok farklı olan yerleri bulmak önemlidir. Ve ilk tehlikeli güvenlik açığı bu şekilde bulundu.
kimlik
IDOR (Güvensiz Doğrudan Nesne Referansı) güvenlik açıkları, iş mantığındaki en yaygın güvenlik açıklarından biridir ve gerçekte erişime izin verilmeyen nesnelere birinin veya diğerinin erişmesine olanak tanır. IDOR güvenlik açıkları, farklı derecelerde kritikliğe sahip bir kullanıcı hakkında bilgi edinme olasılığını yaratır.
IDOR seçeneklerinden biri, sistem nesneleri (kullanıcılar, banka hesapları, alışveriş sepetindeki öğeler) ile bu nesnelere erişim tanımlayıcılarını değiştirerek eylemler gerçekleştirmektir. Bu, en öngörülemeyen sonuçlara yol açar. Örneğin, parayı gönderenin hesabını, diğer kullanıcılardan çalabileceğiniz şekilde değiştirme olasılığı.
MCS örneğinde denetçiler, güvenli olmayan tanımlayıcılarla ilişkili bir IDOR güvenlik açığını keşfettiler. Kullanıcının kişisel hesabında, güvenlik uzmanlarının söylediği gibi etkileyici derecede güvensiz görünen (yani kaba kuvvet saldırılarına karşı korunan) herhangi bir nesneye erişmek için UUID tanımlayıcıları kullanıldı. Ancak bazı kuruluşlar için, uygulamanın kullanıcıları hakkında bilgi edinmek amacıyla düzenli tahmin edilebilir sayıların kullanıldığı keşfedildi. Kullanıcı kimliğini tek tek değiştirip, isteği tekrar göndererek ACL'yi (erişim kontrol listesi, işlemler ve kullanıcılar için veri erişim kuralları) atlayarak bilgi elde etmenin mümkün olduğunu tahmin edebilirsiniz.
Sunucu Tarafı İstek Sahteciliği (SSRF)
Açık Kaynak ürünlerinin iyi yanı, ortaya çıkan sorunların ayrıntılı teknik açıklamalarını ve eğer şanslıysanız çözümün açıklamasını içeren çok sayıda foruma sahip olmalarıdır. Ancak bu madalyonun bir de diğer yüzü var: bilinen güvenlik açıkları da ayrıntılı olarak açıklanıyor. Örneğin OpenStack forumunda güvenlik açıklarına ilişkin harika açıklamalar var и bazı nedenlerden dolayı kimse bunu düzeltmek için acele etmiyor.
Uygulamaların ortak bir işlevi, kullanıcının sunucuya, sunucunun tıkladığı bir bağlantıyı gönderme yeteneğidir (örneğin, belirli bir kaynaktan bir görüntü indirmek için). Güvenlik araçları, bağlantıları veya sunucudan kullanıcılara dönen yanıtları filtrelemiyorsa, bu tür işlevler saldırganlar tarafından kolaylıkla kullanılabilir.
SSRF güvenlik açıkları bir saldırının gelişimini büyük ölçüde ilerletebilir. Bir saldırgan şunları alabilir:
- saldırıya uğrayan yerel ağa sınırlı erişim, örneğin yalnızca belirli ağ bölümleri aracılığıyla ve belirli bir protokol kullanılarak;
- uygulama seviyesinden taşıma seviyesine geçiş mümkünse yerel ağa tam erişim ve bunun sonucunda uygulama seviyesinde tam yük yönetimi;
- sunucudaki yerel dosyaları okuma erişimi (file:/// şeması destekleniyorsa);
- ve çok daha fazlası.
OpenStack'te, doğası gereği "kör" olan bir SSRF güvenlik açığı uzun zamandır bilinmektedir: sunucuyla iletişim kurduğunuzda, ondan bir yanıt almazsınız, ancak isteğin sonucuna bağlı olarak farklı türde hatalar/gecikmeler alırsınız. . Buna dayanarak, iç ağdaki ana bilgisayarlarda, hafife alınmaması gereken tüm sonuçlarla birlikte bir bağlantı noktası taraması gerçekleştirebilirsiniz. Örneğin bir ürün, yalnızca kurumsal ağdan erişilebilen bir arka ofis API'sine sahip olabilir. Belgeleme sayesinde (içeridekileri unutmayın), bir saldırgan SSRF'yi dahili yöntemlere erişmek için kullanabilir. Örneğin, bir şekilde yararlı URL'lerin yaklaşık bir listesini elde edebildiyseniz, SSRF'yi kullanarak bunların üzerinden geçebilir ve bir isteği gerçekleştirebilirsiniz - nispeten konuşursak, hesaptan hesaba para aktarın veya limitleri değiştirin.
Bu, OpenStack'te bir SSRF güvenlik açığının keşfedildiği ilk sefer değil. Geçmişte VM ISO görüntülerini doğrudan bağlantıdan indirmek mümkündü ve bu da benzer sonuçlara yol açıyordu. Bu özellik artık OpenStack'tan kaldırıldı. Görünüşe göre topluluk bunu sorunun en basit ve en güvenilir çözümü olarak görüyordu.
Ve içinde HackerOne hizmetinin (h1) halka açık raporuna göre, artık kör olmayan bir SSRF'nin örnek meta verilerini okuma yeteneği ile kullanılması, Shopify altyapısının tamamına Kök erişimine yol açıyor.
MCS'de, benzer işlevlere sahip iki yerde SSRF güvenlik açıkları keşfedildi, ancak güvenlik duvarları ve diğer korumalar nedeniyle bunlardan yararlanılması neredeyse imkansızdı. Öyle ya da böyle, MCS ekibi topluluğu beklemeden bu sorunu yine de çözdü.
Kabukları yüklemek yerine XSS
Yazılan yüzlerce çalışmaya rağmen, her yıl XSS (siteler arası komut dosyası çalıştırma) saldırısı hala en yaygın olanı. web güvenlik açığı (veya ?).
Dosya yüklemeleri herhangi bir güvenlik araştırmacısının favori yeridir. Çoğu zaman, rastgele bir komut dosyası (asp/jsp/php) yükleyebileceğiniz ve pentester terminolojisinde - "kabuk yükle" işletim sistemi komutlarını çalıştırabileceğiniz ortaya çıkar. Ancak bu tür güvenlik açıklarının popülaritesi her iki yönde de işe yarıyor: Bunlar hatırlanıyor ve onlara karşı çareler geliştiriliyor, böylece son zamanlarda "kabuk yükleme" olasılığı sıfıra yaklaşıyor.
Saldıran ekip (Dijital Güvenlik tarafından temsil edilir) şanslıydı. Tamam, MCS'de sunucu tarafında indirilen dosyaların içerikleri kontrol edildi, yalnızca görsellere izin verildi. Ancak SVG aynı zamanda bir resimdir. SVG görüntüleri nasıl tehlikeli olabilir? Çünkü bunlara JavaScript parçacıkları gömebilirsiniz!
İndirilen dosyaların MCS hizmetinin tüm kullanıcılarına açık olduğu ortaya çıktı, bu da diğer bulut kullanıcılarına, yani yöneticilere saldırmanın mümkün olduğu anlamına geliyor.
Kimlik avı giriş formuna yapılan XSS saldırısı örneği
XSS saldırılarından yararlanma örnekleri:
- Yüklenen komut dosyası kaynak API'sine anında erişebiliyorsa neden bir oturumu çalmaya çalışalım (özellikle de artık Yalnızca HTTP çerezleri her yerde olduğundan, js komut dosyaları kullanılarak hırsızlığa karşı korunuyorsa)? Bu durumda veri, sunucu yapılandırmasını değiştirmek için XHR isteklerini kullanabilir; örneğin, saldırganın genel SSH anahtarını ekleyebilir ve sunucuya SSH erişimi sağlayabilir.
- CSP politikası (içerik koruma politikası) JavaScript'in eklenmesini yasaklıyorsa, saldırgan JavaScript olmadan da idare edebilir. Saf HTML kullanarak, site için sahte bir giriş formu oluşturun ve bu gelişmiş kimlik avı yoluyla yöneticinin şifresini çalın: Kullanıcının kimlik avı sayfası aynı URL'ye ulaşır ve kullanıcının bunu tespit etmesi daha zordur.
- Sonunda saldırgan ayarlayabilir — 4 KB'tan büyük Çerezleri ayarlayın. Kullanıcının bağlantıyı yalnızca bir kez açması gerekir ve kullanıcı tarayıcıyı özel olarak temizlemeyi düşünene kadar sitenin tamamına erişilemez hale gelir: çoğu durumda web sunucusu böyle bir istemciyi kabul etmeyi reddeder.
Bu sefer daha akıllı bir istismarla tespit edilen başka bir XSS örneğine bakalım. MCS hizmeti, güvenlik duvarı ayarlarını gruplar halinde birleştirmenize olanak tanır. Grup adı XSS'nin tespit edildiği yerdi. Özelliği, vektörün kurallar listesini görüntülerken değil, bir grubu silerken hemen tetiklenmemesiydi:
Yani senaryo şu şekilde ortaya çıktı: Saldırgan adında “load” yazan bir güvenlik duvarı kuralı oluşturuyor, bir süre sonra yönetici bunu fark ediyor ve silme işlemini başlatıyor. Kötü amaçlı JS'nin çalıştığı yer burasıdır.
Dijital Güvenlik ekibi, MCS geliştiricilerine, indirilen SVG görüntülerinde (eğer vazgeçilemezlerse) XSS'ye karşı koruma sağlamak amacıyla şunları önerdi:
- Kullanıcılar tarafından yüklenen dosyaları, "çerezlerle" hiçbir ilgisi olmayan ayrı bir alana yerleştirin. Komut dosyası farklı bir etki alanı bağlamında yürütülecek ve MCS için bir tehdit oluşturmayacak.
- Sunucunun HTTP yanıtında "Content-disposition:attach" başlığını gönderin. Daha sonra dosyalar tarayıcı tarafından indirilecek ve yürütülmeyecektir.
Ek olarak, artık geliştiricilerin XSS'den yararlanma risklerini azaltmak için kullanabilecekleri birçok yol var:
- “Yalnızca HTTP” işaretini kullanarak oturum “Çerezler” başlıklarını kötü amaçlı JavaScript'e erişilemez hale getirebilirsiniz;
- bir saldırganın XSS'den yararlanmasını çok daha zorlaştıracak;
- Angular veya React gibi modern şablon motorları, kullanıcı verilerini kullanıcının tarayıcısına göndermeden önce otomatik olarak temizler.
İki faktörlü kimlik doğrulama güvenlik açıkları
Hesap güvenliğini artırmak için kullanıcılara her zaman 2FA'yı (iki faktörlü kimlik doğrulama) etkinleştirmeleri önerilir. Aslında bu, kullanıcının kimlik bilgilerinin ele geçirilmesi durumunda saldırganın bir hizmete erişmesini önlemenin etkili bir yoludur.
Ancak ikinci bir kimlik doğrulama faktörünün kullanılması her zaman hesap güvenliğini garanti eder mi? 2FA'nın uygulanmasında aşağıdaki güvenlik sorunları vardır:
- OTP kodunun kaba kuvvetle aranması (tek seferlik kodlar). Operasyonun basitliğine rağmen OTP kaba kuvvetine karşı koruma eksikliği gibi hatalarla büyük şirketler de karşılaşıyor: , .
- Zayıf nesil algoritma, örneğin bir sonraki kodu tahmin etme yeteneği.
- Telefonunuzda başka birinin OTP'sini isteyebilme gibi mantıksal hatalar, bunun gibi Shopify'dan.
MCS durumunda 2FA, Google Authenticator'a dayalı olarak uygulanır ve . Protokolün kendisi zaten zaman açısından test edilmiştir, ancak uygulama tarafında kod doğrulamanın uygulanması kontrol edilmeye değerdir.
MCS 2FA çeşitli yerlerde kullanılır:
- Kullanıcının kimliğini doğrularken. Kaba kuvvete karşı koruma vardır: Kullanıcının tek kullanımlık şifreyi girmek için yalnızca birkaç denemesi vardır, ardından giriş bir süreliğine engellenir. Bu, OTP'nin kaba kuvvetle seçilmesi olasılığını engeller.
- 2FA gerçekleştirmek için çevrimdışı yedek kodlar oluştururken ve bunu devre dışı bırakırken. Burada kaba kuvvet koruması uygulanmadı; bu, hesap için bir şifreniz ve aktif bir oturumunuz varsa yedek kodları yeniden oluşturmanızı veya 2FA'yı tamamen devre dışı bırakmanızı mümkün kıldı.
Yedek kodların OTP uygulamasının ürettiği string değerleri ile aynı aralıkta yer aldığı dikkate alındığında kodun kısa sürede bulunma şansı çok daha yüksekti.
“Burp: Davetsiz Misafir” aracını kullanarak 2FA'yı devre dışı bırakmak için bir OTP seçme işlemi
sonuç
Genel olarak MCS bir ürün olarak güvenli görünüyor. Denetim sırasında sızma testi ekibi, istemci VM'lerine ve verilerine erişim sağlayamadı ve bulunan güvenlik açıkları, MCS ekibi tarafından hızla düzeltildi.
Ancak burada güvenliğin sürekli bir çalışma olduğunu belirtmekte fayda var. Hizmetler statik değildir, sürekli gelişmektedir. Ve tamamen güvenlik açıkları olmayan bir ürün geliştirmek imkansızdır. Ancak bunları zamanında bulabilir ve tekrarlanma olasılığını en aza indirebilirsiniz.
Artık MCS'de bahsedilen tüm güvenlik açıkları zaten düzeltildi. Yenilerin sayısını minimumda tutmak ve ömürlerini kısaltmak için platform ekibi şunu yapmaya devam ediyor:
- harici şirketler tarafından düzenli olarak denetimler yapmak;
- Katılımı desteklemek ve geliştirmek;
- güvenlikle meşgul olun. 🙂
Kaynak: habr.com