Bu makale, Grup-IB uzmanlarının birkaç yıl önce gerçekleştirdiği çok başarılı bir sızma testine dayanılarak yazılmıştır: Bollywood'da filme uyarlanabilecek bir hikaye yaşanmıştır. Şimdi muhtemelen okuyucunun tepkisi şöyle olacaktır: “Ah, yine bir PR yazısı, yine bunlar anlatılıyor, ne kadar iyiler, pentest almayı unutmayın.” Bir yandan öyle. Ancak bu makalenin ortaya çıkmasının başka nedenleri de var. Pentester'ların tam olarak ne yaptığını, bu çalışmanın ne kadar ilginç ve önemsiz olabileceğini, projelerde ne gibi komik durumların ortaya çıkabileceğini ve en önemlisi canlı materyali gerçek örneklerle göstermek istedim.
Dünyadaki tevazu dengesini yeniden sağlamak için bir süre sonra pek de iyi gitmeyen bir sızma testi hakkında yazacağız. Bir şirketteki iyi tasarlanmış süreçlerin, sırf bu süreçler var olduğu ve gerçekten çalıştığı için, iyi hazırlanmış olsalar bile çok çeşitli saldırılara karşı nasıl koruma sağlayabileceğini göstereceğiz.
Bu makaledeki müşteri için, bizim duygularımıza göre, genel olarak her şey mükemmeldi, en azından Rusya Federasyonu'ndaki pazarın% 95'inden daha iyiydi, ancak uzun bir olaylar zincirini oluşturan bir dizi küçük nüans vardı; çalışmayla ilgili uzun bir rapora ve ardından bu makaleye yol açtı.
O halde patlamış mısır stoklayalım ve dedektif hikayesine hoş geldiniz. Kelime - Pavel SuprunyukGrup-IB'nin “Denetim ve Danışmanlık” bölümünün teknik müdürü.
Bölüm 1. Pochkin doktoru
2018 Bir müşteri var - kendisi de birçok müşteriye hizmet veren yüksek teknolojili bir BT şirketi. Şu sorunun cevabını almak istiyor: Herhangi bir ön bilgi ve erişim olmadan, İnternet üzerinden çalışarak Active Directory etki alanı yönetici haklarını elde etmek mümkün müdür? Hiçbir sosyal mühendislikle ilgilenmiyorum (), işe bilerek müdahale etmek niyetinde değiller, ancak yanlışlıkla örneğin garip çalışan bir sunucuyu yeniden yükleyebilirler. Ek bir amaç, dış çevreye karşı mümkün olduğu kadar çok sayıda başka saldırı vektörünü tanımlamaktır. Şirket bu tür testleri düzenli olarak yapıyor ve artık yeni bir test için son tarih geldi. Koşullar neredeyse tipik, yeterli ve anlaşılır. Başlayalım.
Müşterinin bir adı var - ana web sitesiyle birlikte “Şirket” olsun . Elbette müşteriye farklı bir ad veriliyor ama bu yazıda her şey kişisel olmayacak.
Ağ keşfi yapıyorum - müşteriye hangi adreslerin ve alan adlarının kayıtlı olduğunu öğrenin, bir ağ şeması çizin, hizmetlerin bu adreslere nasıl dağıtıldığını öğrenin. Sonucu alıyorum: 4000'den fazla canlı IP adresi. Bu ağlardaki alanlara bakıyorum: Neyse ki büyük çoğunluğu müşterinin müşterilerine yönelik ağlardır ve biz resmi olarak onlarla ilgilenmiyoruz. Müşteri de aynısını düşünüyor.
256 adresli bir ağ kalıyor, bu ana kadar etki alanlarının ve alt etki alanlarının IP adreslerine göre dağıtımı zaten anlaşılmış durumda, taranan bağlantı noktaları hakkında bilgi var, bu da ilginç olanlar için hizmetlere bakabileceğiniz anlamına geliyor. Buna paralel olarak her türlü tarayıcı mevcut IP adreslerinde ve web sitelerinde ayrı ayrı başlatılır.
Çok sayıda hizmet var. Genellikle bu, pentester için sevinç ve hızlı bir zafer beklentisidir, çünkü ne kadar çok hizmet olursa, saldırı alanı o kadar geniş olur ve bir eser bulmak o kadar kolay olur. Web sitelerine hızlı bir bakış, bunların çoğunun büyük küresel şirketlerin tanınmış ürünlerinin web arayüzleri olduğunu ve görünüşe bakılırsa bunların hoş karşılanmadığını gösteriyor. Bir kullanıcı adı ve şifre istiyorlar, ikinci faktörün girileceği alanı sallıyorlar, TLS istemci sertifikası istiyorlar veya bunu Microsoft ADFS'ye gönderiyorlar. Bazılarına internetten erişilemez. Bazıları için, üç maaş karşılığında özel bir ücretli müşteriye sahip olmanız veya girilecek tam URL'yi bilmeniz gerekir. Bilinen güvenlik açıkları için yazılım sürümlerini "kırmaya" çalışma, web yollarında gizli içerik arama ve LinkedIn gibi üçüncü taraf hizmetlerden sızdırılan hesapları arama ve bunları kullanarak şifreleri tahmin etmeye çalışma sürecindeki kademeli umutsuzlukla dolu bir haftayı daha atlayalım. kendi kendine yazılan web sitelerindeki güvenlik açıklarını kazmak gibi - bu arada, istatistiklere göre bu, günümüzde dış saldırıların en umut verici vektörüdür. Daha sonra ateşlenen film tabancasını hemen not edeceğim.
Böylece yüzlerce hizmet arasında öne çıkan iki site bulduk. Bu sitelerin ortak bir yanı vardı: Etki alanına göre titiz bir ağ keşfi yapmazsanız, açık bağlantı noktalarını doğrudan ararsanız veya bilinen bir IP aralığını kullanarak bir güvenlik açığı tarayıcısını hedeflerseniz, o zaman bu siteler taramadan kaçacak ve kesinlikle taranmayacaktır. DNS adını bilmeden görünür. Belki de en azından daha önce gözden kaçırılmışlardır ve otomatik araçlarımız, doğrudan kaynağa gönderilseler bile bunlarla ilgili herhangi bir sorun bulmamıştır.
Bu arada, daha önce başlatılan tarayıcıların genel olarak buldukları hakkında. Şunu da hatırlatayım: Bazı kişiler için “pentest”, “otomatik tarama” ile eşdeğerdir. Ancak bu projedeki tarayıcılar hiçbir şey söylemedi. Maksimum düzeydeki güvenlik açıkları Orta düzeydeki güvenlik açıkları tarafından gösterildi (önem derecesi açısından 3 üzerinden 5): bazı hizmetlerde kötü TLS sertifikası veya güncelliğini yitirmiş şifreleme algoritmaları ve çoğu sitede Clickjacking. Ancak bu sizi hedefinize ulaştırmayacaktır. Belki tarayıcılar burada daha faydalı olabilir, ancak size hatırlatmama izin verin: müşterinin kendisi bu tür programları satın alabilir ve onlarla kendini test edebilir ve kasvetli sonuçlara bakılırsa, zaten kontrol etmiştir.
“Anormal” sitelere dönelim. Birincisi, standart olmayan bir adresteki yerel Wiki gibi bir şeydir, ancak bu makalede bunun wiki.company[.]ru olmasına izin verin. Ayrıca hemen bir kullanıcı adı ve şifre istedi, ancak tarayıcıdaki NTLM aracılığıyla. Kullanıcı için bu, kullanıcı adı ve şifre girmesini isteyen münzevi bir pencereye benziyor. Ve bu kötü bir uygulamadır.
Küçük bir not. Çevre web sitelerindeki NTLM, çeşitli nedenlerden dolayı kötüdür. Birinci sebep Active Directory alan adının ortaya çıkmasıdır. Örneğimizde, tıpkı “harici” DNS adı gibi, sirket.ru olduğu da ortaya çıktı. Bunu bilerek, kötü amaçlı bir şeyi dikkatli bir şekilde hazırlayabilirsiniz, böylece bazı sanal alanda değil, yalnızca kuruluşun etki alanı makinesinde yürütülür. İkinci olarak, kimlik doğrulama, hesapların şifre girme girişimi sayısını aşmasının engellenmesi de dahil olmak üzere "dahili" ağ politikalarının tüm özellikleriyle birlikte NTLM aracılığıyla doğrudan etki alanı denetleyicisinden geçer (sürpriz, değil mi?). Bir saldırgan oturum açma bilgilerini öğrenirse, bunlar için şifreleri deneyecektir. Hesapların yanlış şifre girmesini engelleyecek şekilde yapılandırılmışsanız bu işe yarayacak ve hesap engellenecektir. Üçüncüsü, böyle bir kimlik doğrulamaya ikinci bir faktörün eklenmesi imkansızdır. Okuyuculardan herhangi biri hala nasıl yapılacağını biliyorsa, lütfen bana bildirin, bu gerçekten ilginç. Dördüncüsü, karma geçiş saldırılarına karşı güvenlik açığı. ADFS, diğer şeylerin yanı sıra tüm bunlara karşı koruma sağlamak için icat edildi.
Microsoft ürünlerinin kötü bir özelliği var: Böyle bir NTLM'yi özel olarak yayınlamamış olsanız bile, en azından OWA ve Lync'te varsayılan olarak yüklenecektir.
Bu arada, bu makalenin yazarı bir keresinde büyük bir bankanın yaklaşık 1000 çalışanının hesabını aynı yöntemi kullanarak sadece bir saat içinde yanlışlıkla bloke etmiş ve daha sonra biraz solgun görünüyordu. Bankanın BT hizmetleri de soluktu, ancak her şey iyi ve yeterli bir şekilde sonuçlandı, hatta bu sorunu ilk bulan ve hızlı ve kararlı bir düzeltmeyi teşvik eden biz olduğumuz için övüldük.
İkinci sitenin adresi "belli ki bir tür soyadı.company.ru" idi. Google'dan buldum, 10. sayfada buna benzer bir şey. Tasarım XNUMX'li yılların başlarından kalmaydı ve saygın bir kişi ona ana sayfadan bakıyordu, şöyle bir şey:
Burada “Köpeğin Kalbi”nden bir kare aldım ama inanın biraz benzerdi, renk tasarımı bile benzer tonlardaydı. Sitenin çağrılmasına izin verin preobrazhensky.company.ru.
Bir ürolog için kişisel bir web sitesiydi. Bir üroloğun web sitesinin bir yüksek teknoloji şirketinin alt alanında ne işi olduğunu merak ettim. Google'da hızlı bir araştırma, bu doktorun müşterimizin tüzel kişiliklerinden birinin kurucu ortağı olduğunu ve hatta kayıtlı sermayeye yaklaşık 1000 ruble katkıda bulunduğunu gösterdi. Site muhtemelen yıllar önce oluşturulmuştu ve müşterinin sunucu kaynakları barındırma olarak kullanılıyordu. Site uzun zamandır alaka düzeyini kaybetmiş, ancak bazı nedenlerden dolayı uzun süre çalışmaya bırakılmıştır.
Güvenlik açıkları açısından web sitesinin kendisi güvenliydi. İleriye baktığımda, bunun bir dizi statik bilgi olduğunu söyleyeceğim - böbrekler ve mesaneler şeklinde eklenmiş resimler içeren basit html sayfaları. Böyle bir siteyi "kırmanın" faydası yoktur.
Ancak altındaki web sunucusu daha ilginçti. HTTP Sunucusu başlığına bakılırsa IIS 6.0'a sahipti, bu da işletim sistemi olarak Windows 2003'ü kullandığı anlamına geliyor. Tarayıcı daha önce bu özel ürolog web sitesinin, aynı web sunucusundaki diğer sanal ana bilgisayarlardan farklı olarak PROPFIND komutuna yanıt verdiğini, yani WebDAV'ı çalıştırdığını tespit etmişti. Bu arada, tarayıcı bu bilgiyi Bilgi işaretiyle geri verdi (tarayıcı raporları dilinde bu en düşük tehlikedir) - bu tür şeyler genellikle atlanır. Kombinasyon halinde bu, ancak Google'da yapılan başka bir araştırmadan sonra ortaya çıkan ilginç bir etki yarattı: Shadow Brokers seti ile ilişkili nadir bir arabellek taşması güvenlik açığı, yani halihazırda hazır bir istismara sahip olan CVE-2017-7269. Başka bir deyişle, Windows 2003 kullanıyorsanız ve WebDAV IIS üzerinde çalışıyorsa sorun yaşanacaktır. Her ne kadar 2003'de Windows 2018'ü üretimde çalıştırmak başlı başına bir sorun olsa da.
Açıktan yararlanma Metasploit'te sona erdi ve kontrollü bir hizmete DNS isteği gönderen bir yük ile hemen test edildi - Burp Collaborator geleneksel olarak DNS isteklerini yakalamak için kullanılır. Şaşırtıcı bir şekilde, ilk seferde işe yaradı: DNS elemesi alındı. Daha sonra, 80 numaralı bağlantı noktası aracılığıyla bir geri bağlantı (yani, sunucudan saldırgana, kurbanın ana bilgisayarındaki cmd.exe'ye erişime sahip bir ağ bağlantısı) aracılığıyla bir geri bağlantı oluşturma girişiminde bulunuldu, ancak ardından bir fiyasko yaşandı. Bağlantı kurulamadı ve siteyi üçüncü kez kullanma girişiminden sonra tüm ilginç resimlerle birlikte sonsuza kadar ortadan kayboldu.
Genellikle bunu "müşteri, uyan, her şeyi bıraktık" tarzında bir mektup takip eder. Ancak bize sitenin iş süreçleriyle hiçbir ilgisinin olmadığı, tüm sunucu gibi hiçbir sebep olmadan orada çalıştığı ve bu kaynağı istediğimiz gibi kullanabileceğimiz söylendi.
Yaklaşık bir gün sonra site aniden kendi kendine çalışmaya başladı. IIS 6.0'da WebDAV'dan bir tezgah oluşturduktan sonra, varsayılan ayarın IIS çalışan işlemlerini her 30 saatte bir yeniden başlatmak olduğunu buldum. Yani, kontrol kabuk kodundan çıktığında IIS çalışan işlemi sona erdi, ardından birkaç kez kendini yeniden başlattı ve ardından 30 saat dinlenmeye geçti.
TCP'ye geri bağlantı ilk kez başarısız olduğundan, bu sorunu kapalı bir bağlantı noktasına bağladım. Yani, giden bağlantıların dışarıdan geçmesine izin vermeyen bir tür güvenlik duvarının varlığını varsaydı. Birçok tcp ve udp bağlantı noktasında arama yapan kabuk kodlarını çalıştırmaya başladım, hiçbir etkisi olmadı. Metasploit'ten http(s) yoluyla yapılan ters bağlantı yüklemeleri işe yaramadı -meterpreter/reverse_http(s). Aniden aynı bağlantı noktası 80'e bir bağlantı kuruldu, ancak hemen kesildi. Bunu, sayaç trafiğinden hoşlanmayan, hala hayali olan IPS'nin hareketine bağladım. Bağlantı noktası 80'e saf bir tcp bağlantısının geçmediği, ancak bir http bağlantısının geçtiği gerçeğinin ışığında, sistemde bir http proxy'nin bir şekilde yapılandırıldığı sonucuna vardım.
DNS üzerinden Meterpreter'ı bile denedim (teşekkürler Çabalarınız için birçok projeyi kurtardık), ilk başarıyı hatırlatıyor, ancak standta bile işe yaramadı - kabuk kodu bu güvenlik açığı için çok hacimliydi.
Gerçekte şuna benziyordu: 3 dakika içinde 4-5 saldırı girişimi, ardından 30 saat beklemek. Ve böylece üst üste üç hafta boyunca. Zaman kaybetmemek için hatırlatıcı bile kurdum. Ek olarak, test ve üretim ortamlarının davranışlarında da farklılık vardı: Bu güvenlik açığı için biri Metasploit'ten, ikincisi ise Shadow Brokers sürümünden dönüştürülmüş İnternet'ten olmak üzere iki benzer istismar vardı. Yani, yalnızca Metasploit savaşta test edildi ve yalnızca ikincisi yedek kulübesinde test edildi; bu da hata ayıklamayı daha da zorlaştırdı ve beyinleri patlattı.
Sonunda, http aracılığıyla belirli bir sunucudan bir exe dosyasını indiren ve onu hedef sistemde başlatan bir kabuk kodunun etkili olduğu kanıtlandı. Kabuk kodu sığacak kadar küçüktü ama en azından işe yaradı. Sunucu TCP trafiğini hiç sevmediğinden ve http(s) Meterpreter varlığı açısından incelendiğinden, en hızlı yolun bu kabuk kodu aracılığıyla DNS-meterpreter içeren bir exe dosyasını indirmek olduğuna karar verdim.
Burada yine bir sorun ortaya çıktı: Bir exe dosyasını indirirken ve denemelerin gösterdiği gibi, hangisi olursa olsun indirme işlemi kesintiye uğradı. Yine sunucumla ürolog arasındaki bazı güvenlik cihazları, içinde exe bulunan http trafiğini beğenmedi. "Hızlı" çözüm, kabuk kodunu değiştirerek http trafiğini anında karartacak ve böylece exe yerine soyut ikili verilerin aktarılmasını sağlayacak gibi görünüyordu. Sonunda saldırı başarılı oldu ve ince DNS kanalı üzerinden kontrol alındı:
Hiçbir şey yapmama izin veren en temel IIS iş akışı haklarına sahip olduğum hemen anlaşıldı. Metasploit konsolunda şöyle görünüyordu:
Tüm pentest metodolojileri, erişim elde ederken hakları artırmanız gerektiğini kuvvetle önerir. İlk erişim yalnızca bir ağ giriş noktası olarak görüldüğünden ve aynı ağdaki başka bir makineyi tehlikeye atmak, mevcut bir ana bilgisayardaki ayrıcalıkları yükseltmekten genellikle daha kolay ve hızlı olduğundan, genellikle bunu yerel olarak yapmıyorum. Ancak burada durum böyle değil çünkü DNS kanalı çok dar ve trafiğin temizlenmesine izin vermiyor.
Bu Windows 2003 sunucusunun ünlü MS17-010 güvenlik açığı nedeniyle onarılmadığını varsayarak, localhost üzerindeki Meterpreter DNS tüneli aracılığıyla trafiği 445/TCP numaralı bağlantı noktasına yönlendiriyorum (evet, bu da mümkün) ve daha önce indirilen exe'yi üzerinden çalıştırmayı deniyorum. güvenlik açığı. Saldırı işe yarıyor, ikinci bir bağlantı alıyorum ancak SİSTEM haklarıyla.
Sunucuyu hâlâ MS17-010'dan korumaya çalışmaları ilginçtir; harici arayüzde güvenlik açığı bulunan ağ hizmetleri devre dışı bırakılmıştı. Bu, ağ üzerinden yapılan saldırılara karşı koruma sağlar, ancak localhost'ta SMB'yi hızlı bir şekilde kapatamayacağınız için localhost'un içinden yapılan saldırı işe yaradı.
Ardından yeni ilginç ayrıntılar ortaya çıkıyor:
- SİSTEM haklarına sahip olarak TCP üzerinden kolaylıkla geri bağlantı kurabilirsiniz. Açıkçası, doğrudan TCP'yi devre dışı bırakmak, sınırlı IIS kullanıcısı için kesinlikle bir sorundur. Spoiler: IIS kullanıcı trafiği bir şekilde yerel ISA Proxy'sine her iki yönde de sarılmıştı. Tam olarak nasıl çalıştığını çoğaltmadım.
- Belirli bir "DMZ" içindeyim (ve bu bir Active Directory etki alanı değil, bir ÇALIŞMA GRUBU) - kulağa mantıklı geliyor. Ancak beklenen özel ("gri") IP adresi yerine, daha önce saldırdığımla tamamen aynı olan tamamen "beyaz" bir IP adresim var. Bu, şirketin IPv4 adresleme dünyasında o kadar eski olduğu anlamına geliyor ki, Cisco'nun 128 kılavuzlarında tasvir edildiği gibi, şemaya göre NAT olmadan 2005 "beyaz" adres için bir DMZ bölgesini sürdürmeyi karşılayabiliyor.
Sunucu eski olduğundan Mimikatz'ın doğrudan bellekten çalışması garanti edilir:
Yerel yönetici şifresini alıyorum, RDP trafiğini TCP üzerinden tünelliyorum ve rahat bir masaüstüne giriş yapıyorum. Sunucuyla istediğimi yapabildiğim için antivirüsü kaldırdım ve sunucuya İnternet'ten yalnızca 80 ve 443 numaralı TCP bağlantı noktaları üzerinden erişilebildiğini ve 443'ün meşgul olmadığını gördüm. 443'te bir OpenVPN sunucusu kurdum, VPN trafiğim için NAT işlevlerini ekledim ve OpenVPN'im aracılığıyla DMZ ağına sınırsız biçimde doğrudan erişim elde ettim. Bazı devre dışı bırakılmamış IPS işlevlerine sahip olan ISA'nın, daha basit ve daha uyumlu bir RRAS ile değiştirilmesi gereken bağlantı noktası taramasıyla trafiğimi bloke etmesi dikkat çekicidir. Yani pentester'lar bazen hala her türlü şeyi yönetmek zorunda kalıyor.
Dikkatli bir okuyucu şunu soracaktır: "Hakkında çok şey yazılan, NTLM kimlik doğrulamalı bir wiki olan ikinci siteye ne dersiniz?" Bu konuda daha sonra daha fazla bilgi vereceğiz.
Bölüm 2. Hala şifrelemiyor musunuz? O zaman zaten buraya geliyoruz
Yani DMZ ağ segmentine erişim var. Alan adı yöneticisine gitmeniz gerekiyor. Akla gelen ilk şey, DMZ segmentindeki hizmetlerin güvenliğinin otomatik olarak kontrol edilmesidir, özellikle de pek çoğu artık araştırmaya açık olduğundan. Sızma testi sırasındaki tipik bir tablo: dış çevre, dahili hizmetlerden daha iyi korunur ve büyük bir altyapı içinde herhangi bir erişim elde edilirken, bir etki alanında genişletilmiş haklar elde etmek, yalnızca bu etki alanının yenilenmeye başlaması nedeniyle çok daha kolaydır. araçlara erişilebilir ve ikincisi, Birkaç bin ana bilgisayarın bulunduğu bir altyapıda her zaman birkaç kritik sorun olacaktır.
Tarayıcıları OpenVPN tüneli üzerinden DMZ aracılığıyla şarj ediyorum ve bekliyorum. Raporu açıyorum - yine ciddi bir şey yok, görünüşe göre birisi benden önce aynı yöntemi uygulamış. Bir sonraki adım, DMZ ağı içindeki ana bilgisayarların nasıl iletişim kurduğunu incelemektir. Bunu yapmak için önce her zamanki Wireshark'ı başlatın ve başta ARP olmak üzere yayın isteklerini dinleyin. ARP paketleri gün boyu toplandı. Bu segmentte birden fazla ağ geçidinin kullanıldığı ortaya çıktı. Bu daha sonra kullanışlı olacaktır. ARP istek-yanıtları ve port tarama verilerini birleştirerek, daha önce bilinen web ve mail gibi servislerin yanı sıra, yerel ağ içinden kullanıcı trafiğinin çıkış noktalarını da buldum.
Şu anda diğer sistemlere erişimim olmadığından ve kurumsal hizmetler için tek bir hesabım olmadığından, ARP Spoofing kullanarak trafikten en azından bir miktar hesap çıkarmaya karar verildi.
Cain&Abel üroloğun sunucusunda başlatıldı. Belirlenen trafik akışları dikkate alınarak, ortadaki adam saldırısı için en umut verici çiftler seçildi ve ardından sunucuyu yeniden başlatmak için bir zamanlayıcı ile 5-10 dakika boyunca kısa süreli başlatma yoluyla bir miktar ağ trafiği alındı. donma durumunda. Şakada olduğu gibi iki haber vardı:
- İyi: Pek çok kimlik bilgisi ele geçirildi ve saldırı bir bütün olarak işe yaradı.
- Kötü yanı: tüm kimlik bilgileri müşterinin kendi müşterilerine aitti. Destek hizmetleri sağlanırken müşteri uzmanları, her zaman trafik şifrelemesi yapılandırılmamış müşterilerin hizmetlerine bağlandı.
Sonuç olarak, proje bağlamında işe yaramayan ancak saldırı tehlikesinin bir göstergesi olarak kesinlikle ilginç olan pek çok kimlik belgesi elde ettim. Telnetli büyük şirketlerin sınır yönlendiricileri, http bağlantı noktalarındaki hata ayıklamayı tüm verilerle birlikte dahili CRM'ye iletti, yerel ağdaki Windows XP'den RDP'ye doğrudan erişim ve diğer belirsizlikler. Böyle çıktı .
Ayrıca trafikten mektup toplamak gibi komik bir fırsat da buldum. Bu, müşterimizden müşterisinin SMTP portuna yine şifreleme olmadan giden hazır bir mektubun örneğidir. Belirli bir Andrey, adaşı olan belgeleri yeniden göndermesini ister ve belgeler, bir yanıt mektubunda kullanıcı adı, parola ve bağlantıyla birlikte bir bulut diske yüklenir:
Bu, tüm hizmetleri şifrelemek için başka bir hatırlatmadır. Verilerinizi özellikle kimin ve ne zaman okuyup kullanacağı bilinmiyor - sağlayıcı, başka bir şirketin sistem yöneticisi veya böyle bir pentester. Pek çok kişinin şifrelenmemiş trafiği kolaylıkla ele geçirebileceği konusunda sessizim.
Görünen başarıya rağmen bu bizi hedefe yaklaştırmadı. Uzun süre oturup değerli bilgileri ortaya çıkarmak elbette mümkündü ama orada ortaya çıkacağı bir gerçek değil ve saldırının kendisi de ağın bütünlüğü açısından çok riskli.
Hizmetleri bir kez daha inceledikten sonra aklıma ilginç bir fikir geldi. Yayın isteklerini "zehirleyerek" SMB, HTTP, LDAP vb. gibi çeşitli protokoller aracılığıyla bağlantıları tetikleyen Responder adında bir yardımcı program vardır (bu ismin kullanım örneklerini bulmak kolaydır). Farklı şekillerde, daha sonra bağlanan herkesten kimlik doğrulamasını ister ve kimlik doğrulamanın NTLM yoluyla ve kurban için şeffaf bir modda gerçekleşmesini sağlayacak şekilde ayarlar. Çoğu zaman, bir saldırgan NetNTLMv2 anlaşmalarını bu şekilde toplar ve bir sözlük kullanarak bunlardan etki alanı kullanıcı şifrelerini hızla kurtarır. Burada da benzer bir şey istedim, ancak kullanıcılar "bir duvarın arkasında" oturuyorlardı, daha doğrusu bir güvenlik duvarı ile ayrılmışlardı ve WEB'e Blue Coat proxy kümesi aracılığıyla erişiyorlardı.
Active Directory alan adının “harici” alan adı ile çakıştığını, yani şirket.ru olduğunu belirttiğimi hatırlıyor musunuz? Bu nedenle, Windows, daha doğrusu Internet Explorer (ve Edge ve Chrome), sitenin bir tür "İntranet Bölgesi"nde bulunduğunu düşünmeleri durumunda kullanıcının NTLM aracılığıyla HTTP'de şeffaf bir şekilde kimlik doğrulaması yapmasına olanak tanır. Bir "İntranet" in işaretlerinden biri, "gri" bir IP adresine veya kısa bir DNS adına, yani noktasız erişimdir. “Beyaz” IP ve DNS adı preobrazhensky.company.ru olan bir sunucuları olduğundan ve etki alanı makineleri, basitleştirilmiş ad girişi için genellikle Active Directory alan adı son ekini DHCP aracılığıyla aldığından, yalnızca URL'yi adres çubuğuna yazmaları gerekiyordu. Böylece, ele geçirilen üroloğun sunucusuna giden doğru yolu bulabilirler, bunun artık "İntranet" olarak adlandırıldığını unutmadan. Yani, aynı zamanda kullanıcının bilgisi dışında NTLM tokalaşmasını da bana veriyor. Geriye kalan tek şey, istemci tarayıcılarını bu sunucuyla acil olarak iletişime geçme ihtiyacını düşünmeye zorlamak.
Harika Intercepter-NG yardımcı programı kurtarmaya geldi (teşekkürler ). Trafiği anında değiştirmenize olanak sağladı ve Windows 2003'te harika çalıştı. Hatta trafik akışındaki yalnızca JavaScript dosyalarını değiştirmek için ayrı bir işlevselliğe bile sahipti. Bir tür devasa Siteler Arası Komut Dosyası Oluşturma planlandı.
Kullanıcıların küresel WEB'e erişmesini sağlayan Blue Coat proxy'leri, statik içeriği periyodik olarak önbelleğe aldı. Trafiğe müdahale ederek, günün XNUMX saati çalıştıkları ve yoğun saatlerde içeriğin görüntülenmesini hızlandırmak için sürekli olarak sık kullanılan statik talepte bulundukları açıktı. Buna ek olarak BlueCoat'ın kendisini gerçek bir kullanıcıdan açıkça ayıran özel bir Kullanıcı Aracısı vardı.
Javascript hazırlandı ve Blue Coat için JS dosyaları ile Intercepter-NG kullanılarak her yanıt için gece bir saat süreyle uygulandı. Komut dosyası şunları yaptı:
- Geçerli tarayıcı Kullanıcı Aracısı tarafından belirlendi. Internet Explorer, Edge veya Chrome ise çalışmaya devam etti.
- Sayfanın DOM'u oluşana kadar bekledim.
- Formun src niteliğiyle DOM'a görünmez bir resim eklendi :8080/NNNNNNNN.png, burada NNN rastgele sayılardır, böylece BlueCoat bunu önbelleğe almaz.
- Enjeksiyonun tamamlandığını ve artık resim eklemeye gerek olmadığını belirtmek için genel bir bayrak değişkeni ayarlayın.
Tarayıcı bu görüntüyü yüklemeye çalıştı; ele geçirilen sunucunun 8080 numaralı bağlantı noktasında, aynı Yanıtlayıcının çalıştığı dizüstü bilgisayarıma giden bir TCP tüneli, tarayıcının NTLM yoluyla oturum açmasını gerektiriyordu.
Yanıtlayıcı kayıtlarına bakılırsa, insanlar sabah işe geldiler, iş istasyonlarını açtılar, ardından NTLM el sıkışmalarını "boşaltmayı" unutmadan topluca ve fark edilmeden üroloğun sunucusunu ziyaret etmeye başladılar. El sıkışmalar bütün gün yağdı ve şifreleri kurtarmaya yönelik açıkça başarılı bir saldırı için açıkça malzeme toplandı. Yanıtlayıcı günlükleri şöyle görünüyordu:
Kullanıcılar tarafından ürolog sunucusuna toplu gizli ziyaretler
Muhtemelen tüm bu hikayenin "her şey yolundaydı, ama sonra bir sıkıntı oldu, sonra bir üstesinden gelindi ve sonra her şey başarıya ulaştı" ilkesi üzerine inşa edildiğini zaten fark etmişsinizdir. Yani burada bir serserilik vardı. Elli benzersiz el sıkışmadan tek bir tane bile ortaya çıkmadı. Ve bu, ölü bir işlemciye sahip bir dizüstü bilgisayarda bile, bu NTLMv2 el sıkışmalarının saniyede birkaç yüz milyon deneme hızında işlendiği gerçeğini hesaba katıyor.
Kendimi şifre değiştirme teknikleriyle, bir video kartıyla, daha kalın bir sözlükle donatıp beklemek zorunda kaldım. Uzun bir süre sonra, "Q11111111....1111111q" şeklinde parolalara sahip birkaç hesap ortaya çıktı; bu, tüm kullanıcıların bir zamanlar farklı karakterlere sahip çok uzun bir parola bulmaya zorlandığını gösteriyor. karmaşık ol. Ancak deneyimli bir kullanıcıyı kandıramazsınız ve kendisi hatırlamayı bu şekilde kolaylaştırdı. Toplamda yaklaşık 5 hesap ele geçirildi ve bunlardan yalnızca birinin hizmetlere ilişkin değerli hakları vardı.
Bölüm 3. Roskomnadzor karşılık veriyor
Böylece ilk domain hesapları alındı. Uzun süre okuduktan sonra bu noktaya kadar uykuya dalmadıysanız, muhtemelen ikinci bir kimlik doğrulama faktörü gerektirmeyen bir hizmetten bahsettiğimi hatırlayacaksınız: Bu, NTLM kimlik doğrulamasına sahip bir wiki'dir. Tabii ilk iş oraya girmekti. Dahili bilgi tabanını derinlemesine incelemek hızlı bir şekilde sonuç getirdi:
- Şirketin, yerel ağa erişimi olan etki alanı hesaplarını kullanan, kimlik doğrulamalı bir WiFi ağı vardır. Mevcut veri seti ile bu zaten çalışan bir saldırı vektörüdür, ancak ofise ayaklarınızla gitmeniz ve müşterinin ofisi bölgesinde bir yerde bulunmanız gerekir.
- Kullanıcı yerel bir ağ içindeyse ve etki alanı kullanıcı adını ve şifresini güvenle hatırlıyorsa, "ikinci faktör" kimlik doğrulama cihazını bağımsız olarak kaydetmeye izin veren bir hizmetin bulunduğuna dair bir talimat buldum. Bu durumda “içerisi” ve “dışarısı” bu hizmetin portunun kullanıcıya erişilebilirliğine göre belirlendi. Bağlantı noktasına İnternet'ten erişilemedi, ancak DMZ aracılığıyla oldukça erişilebilirdi.
Elbette, ele geçirilen hesaba hemen telefonumdaki uygulama şeklinde bir "ikinci faktör" eklendi. Eylem için "onayla"/"onaylama" düğmeleriyle telefona yüksek sesle bir push isteği gönderebilen veya daha fazla bağımsız giriş için OTP kodunu ekranda sessizce gösterebilen bir program vardı. Üstelik talimatlara göre ilk yöntemin tek doğru yöntem olduğu varsayılmıştı, ancak OTP yönteminin aksine işe yaramadı.
"İkinci faktör"ün bozulmasıyla, Citrix Netscaler Gateway'de Outlook Web Access postasına ve uzaktan erişime erişebildim. Outlook'taki postada bir sürpriz vardı:
Bu nadir çekimde Roskomnadzor'un pentester'lara nasıl yardımcı olduğunu görebilirsiniz
Bunlar, binlerce adrese sahip tüm ağların amansız bir şekilde erişimden kaybolduğu Telegram'ın meşhur "hayran" engellemesinden sonraki ilk aylardı. Push'un neden hemen işe yaramadığı ve "kurbanımın" hesabını mesai saatleri içinde kullanmaya başlaması nedeniyle neden alarm çalmadığı anlaşıldı.
Citrix Netscaler'a aşina olan herkes, bunun genellikle kullanıcıya yalnızca bir resim arayüzü aktarılabilecek şekilde uygulandığını, ona üçüncü taraf uygulamaları başlatması ve veri aktarması için gerekli araçları vermemeye çalışarak, eylemleri mümkün olan her şekilde sınırladığını hayal eder. standart kontrol kabukları aracılığıyla. “Kurbanım” mesleği nedeniyle yalnızca 1C aldı:
1C arayüzünde biraz dolaştıktan sonra orada harici işlem modüllerinin olduğunu gördüm. Arayüzden yüklenebilirler ve haklara ve ayarlara bağlı olarak istemcide veya sunucuda yürütülürler.
1C programcısı arkadaşlarımdan bir dizeyi kabul edip onu çalıştıracak bir işlem oluşturmalarını istedim. 1C dilinde, bir işlemi başlatmak şuna benzer (İnternetten alınmıştır). 1C dilinin sözdiziminin Rusça konuşan insanları kendiliğindenliğiyle şaşırttığına katılıyor musunuz?
İşleme mükemmel bir şekilde gerçekleştirildi; pentester'ların "kabuk" dediği şeyin olduğu ortaya çıktı - Internet Explorer onun aracılığıyla başlatıldı.
Daha önce postada bölgeye geçiş siparişi vermenizi sağlayan bir sistemin adresi bulunmuştu. WiFi saldırı vektörü kullanmak zorunda kalmam durumunda geçiş izni sipariş ettim.
İnternette, müşterinin ofisinde hala lezzetli ve ücretsiz ikramların olduğu söyleniyor, ancak ben yine de saldırıyı uzaktan geliştirmeyi tercih ettim, daha sakin.
AppLocker, Citrix'i çalıştıran uygulama sunucusunda etkinleştirildi ancak atlandı. Aynı Meterpreter, http(s) sürümleri bağlanmak istemediğinden ve o sırada dahili proxy adresini bilmediğimden DNS aracılığıyla yüklendi ve başlatıldı. Bu arada, bu andan itibaren harici sızma testi esasen tamamen dahili bir teste dönüştü.
Bölüm 4. Kullanıcıların yönetici hakları kötüdür, tamam mı?
Bir pentester'ın bir etki alanı kullanıcı oturumunun kontrolünü ele geçirdiğinde ilk görevi, etki alanındaki haklarla ilgili tüm bilgileri toplamaktır. Kullanıcılar, bilgisayarlar, güvenlik grupları hakkındaki bilgileri bir etki alanı denetleyicisinden LDAP protokolü aracılığıyla ve SMB aracılığıyla otomatik olarak indirmenize izin veren bir BloodHound yardımcı programı vardır - hangi kullanıcının yakın zamanda nerede oturum açtığı ve yerel yöneticinin kim olduğu hakkında bilgiler.
Etki alanı yöneticisi haklarını ele geçirmeye yönelik tipik bir teknik, monoton eylemler döngüsü olarak basitleştirilmiş görünüyor:
- Halihazırda ele geçirilmiş etki alanı hesaplarına göre yerel yönetici haklarının bulunduğu etki alanı bilgisayarlarına gidiyoruz.
- Mimikatz'ı başlatıyoruz ve bu sisteme yakın zamanda giriş yapmış olan etki alanı hesaplarının önbelleğe alınmış şifrelerini, Kerberos biletlerini ve NTLM karmalarını alıyoruz. Veya lsass.exe işleminin hafıza imajını kaldırıp aynı işlemi kendi tarafımızda yapıyoruz. Bu, varsayılan ayarlarla 2012R2/Windows 8.1'den daha eski Windows'larda iyi çalışır.
- Ele geçirilen hesapların nerede yerel yönetici haklarına sahip olduğunu belirliyoruz. İlk noktayı tekrarlıyoruz. Bir aşamada tüm alan adı için yönetici hakları kazanırız.
1C programcılarının buraya yazacağı gibi “Döngünün Sonu”.
Böylece, kullanıcımızın, adında "VDI" veya "Sanal Masaüstü Altyapısı", yani kişisel sanal makineler bulunan Windows 7 işletim sistemine sahip tek bir ana bilgisayarda yerel yönetici olduğu ortaya çıktı. Muhtemelen VDI hizmetinin tasarımcısı, VDI kullanıcının kişisel işletim sistemi olduğundan, kullanıcı yazılım ortamını istediği gibi değiştirse bile ana bilgisayarın yine de "yeniden yüklenebileceğini" kastetmiştir. Ayrıca genel olarak fikrin iyi olduğunu düşündüm, bu kişisel VDI sunucusuna gittim ve orada bir yuva yaptım:
- Oraya, İnternet üzerinden sunucuma bir tünel oluşturan bir OpenVPN istemcisi kurdum. Müşterinin etki alanı kimlik doğrulaması ile aynı Blue Coat'tan geçmeye zorlanması gerekiyordu, ancak OpenVPN bunu "kutudan çıktığı gibi" yaptı.
- OpenSSH'yi VDI'ya yükledim. Peki, gerçekten SSH'siz Windows 7 nedir?
Canlıyken böyle görünüyordu. Tüm bunların Citrix ve 1C aracılığıyla yapılması gerektiğini hatırlatmama izin verin:
Komşu bilgisayarlara erişimi teşvik etmenin bir tekniği, eşleşme için yerel yönetici şifrelerini kontrol etmektir. Burada şans hemen onu bekliyordu: Varsayılan yerel yöneticinin (birden Yönetici olarak adlandırıldı) NTLM karmasına, birkaç yüz tane olan komşu VDI ana bilgisayarlarına bir karma geçirme saldırısı aracılığıyla yaklaşıldı. Tabii saldırı hemen onları da vurdu.
Burası VDI yöneticilerinin kendilerini iki kez ayağından vurduğu yer:
- İlki, VDI makinelerinin LAPS kapsamına alınmadığı, esas olarak VDI'ya büyük ölçüde dağıtılan görüntüdeki aynı yerel yönetici parolasının korunduğu zamandı.
- Varsayılan yönetici, karma geçiş saldırılarına karşı savunmasız olan tek yerel hesaptır. Aynı parolayla bile, karmaşık rastgele parolaya sahip ikinci bir yerel yönetici hesabı oluşturup varsayılan parolayı engelleyerek toplu güvenlik ihlallerini önlemek mümkün olacaktır.
Bu Windows'ta neden bir SSH hizmeti var? Çok basit: Artık OpenSSH sunucusu yalnızca kullanıcının işine müdahale etmeden kullanışlı bir etkileşimli komut kabuğu sağlamakla kalmıyor, aynı zamanda VDI üzerinde bir çorap5 proxy'si de sağlıyor. Bu çorap aracılığıyla SMB aracılığıyla bağlandım ve tüm bu yüzlerce VDI makinesinden önbelleğe alınmış hesapları topladım, ardından bunları BloodHound grafiklerinde kullanarak alan adı yöneticisinin yolunu aradım. Elimde yüzlerce sunucu varken bu yolu oldukça çabuk buldum. Alan adı yönetici hakları alınmıştır.
İnternetten benzer bir aramayı gösteren bir resim. Bağlantılar, yöneticinin kimin nerede olduğunu ve kimin nerede oturum açtığını gösterir.
Bu arada, projenin başlangıcındaki koşulu hatırlayın - "sosyal mühendislik kullanmayın." Bu nedenle, banal kimlik avını kullanmak hala mümkün olsaydı, tüm bu özel efektli Bollywood'un ne kadar kesileceğini düşünmeyi öneriyorum. Ama kişisel olarak tüm bunları yapmak benim için çok ilginçti. Umarım bunu okumaktan keyif almışsınızdır. Elbette her proje bu kadar ilgi çekici görünmüyor ancak iş bir bütün olarak oldukça zorlu ve durgunlaşmasına izin vermiyor.
Muhtemelen birisinin bir sorusu olacaktır: Kendinizi nasıl korursunuz? Bu makalede bile birçoğunun Windows yöneticilerinin bile bilmediği birçok teknik açıklanmaktadır. Ancak bunlara basmakalıp ilkeler ve bilgi güvenliği önlemleri perspektifinden bakmayı öneriyorum:
- Güncel olmayan yazılımları kullanmayın (Başlangıçta Windows 2003'ü hatırlıyor musunuz?)
- gereksiz sistemleri açık tutmayın (neden bir üroloğun sitesi vardı?)
- Güç açısından kullanıcı şifrelerini kendiniz kontrol edin (aksi takdirde askerler... Pentester'lar bunu yapacaktır)
- farklı hesaplar için aynı şifrelere sahip olmamak (VDI güvenliğinin ihlali)
- ve başka
Elbette bunu uygulamak çok zordur ancak bir sonraki yazımızda bunun oldukça mümkün olduğunu pratikte göstereceğiz.
Kaynak: habr.com