Artikel ini ditulis berdasarkan pentest yang sangat berjaya yang dijalankan oleh pakar Kumpulan-IB beberapa tahun yang lalu: sebuah kisah berlaku yang boleh diadaptasi untuk filem di Bollywood. Sekarang, mungkin, reaksi pembaca akan mengikuti: "Oh, satu lagi artikel PR, sekali lagi ini digambarkan, betapa bagusnya mereka, jangan lupa untuk membeli pentest." Nah, di satu pihak, ia adalah. Walau bagaimanapun, terdapat beberapa sebab lain mengapa artikel ini muncul. Saya ingin menunjukkan apa sebenarnya yang dilakukan oleh pentester, betapa menarik dan tidak remeh karya ini, apakah keadaan lucu yang boleh timbul dalam projek, dan yang paling penting, tunjukkan bahan langsung dengan contoh sebenar.
Untuk memulihkan keseimbangan kesederhanaan di dunia, selepas beberapa ketika kami akan menulis tentang pentest yang tidak berjalan lancar. Kami akan menunjukkan bagaimana proses yang direka bentuk dengan baik dalam syarikat boleh melindungi daripada pelbagai jenis serangan, malah yang disediakan dengan baik, semata-mata kerana proses ini wujud dan benar-benar berfungsi.
Bagi pelanggan dalam artikel ini, semuanya juga secara amnya sangat baik, sekurang-kurangnya lebih baik daripada 95% pasaran di Persekutuan Rusia, menurut perasaan kami, tetapi terdapat beberapa nuansa kecil yang membentuk rangkaian peristiwa yang panjang, yang pertama membawa kepada laporan panjang mengenai kerja itu, dan kemudian kepada artikel ini.
Jadi, mari kita membeli popcorn, dan selamat datang ke cerita detektif. Perkataan - Pavel Suprunyuk, pengurus teknikal jabatan "Audit dan Perundingan" Kumpulan-IB.
Bahagian 1. Doktor Pochkin
2018 Terdapat pelanggan - sebuah syarikat IT berteknologi tinggi, yang sendiri melayani ramai pelanggan. Ingin mendapatkan jawapan kepada soalan: adakah mungkin, tanpa pengetahuan dan akses awal, bekerja melalui Internet, untuk mendapatkan hak pentadbir domain Active Directory? Saya tidak berminat dalam mana-mana kejuruteraan sosial (), mereka tidak berniat untuk mengganggu kerja dengan sengaja, tetapi mereka mungkin secara tidak sengaja - memuat semula pelayan yang berfungsi aneh, sebagai contoh. Matlamat tambahan adalah untuk mengenal pasti seberapa banyak vektor serangan lain yang mungkin terhadap perimeter luar. Syarikat itu kerap menjalankan ujian sedemikian, dan kini tarikh akhir untuk ujian baharu telah tiba. Keadaannya hampir tipikal, mencukupi, boleh difahami. Mari kita mulakan.
Terdapat nama pelanggan - biarkan ia "Syarikat", dengan tapak web utama . Sudah tentu, pelanggan dipanggil secara berbeza, tetapi dalam artikel ini semuanya akan menjadi tidak peribadi.
Saya menjalankan tinjauan rangkaian - mengetahui alamat dan domain yang didaftarkan dengan pelanggan, lukis gambar rajah rangkaian, cara perkhidmatan diedarkan ke alamat ini. Saya mendapat keputusan: lebih daripada 4000 alamat IP langsung. Saya melihat domain dalam rangkaian ini: mujurlah, sebahagian besar adalah rangkaian yang ditujukan untuk pelanggan pelanggan, dan kami tidak berminat secara rasmi dengan mereka. Pelanggan juga berfikiran sama.
Masih terdapat satu rangkaian dengan 256 alamat, yang pada masa ini sudah ada pemahaman tentang pengedaran domain dan subdomain oleh alamat IP, terdapat maklumat tentang port yang diimbas, yang bermaksud anda boleh melihat perkhidmatan untuk yang menarik. Secara selari, semua jenis pengimbas dilancarkan pada alamat IP yang tersedia dan secara berasingan di tapak web.
Terdapat banyak perkhidmatan. Biasanya ini adalah kegembiraan bagi pentester dan jangkaan kemenangan cepat, kerana lebih banyak perkhidmatan yang ada, lebih besar medan untuk menyerang dan lebih mudah untuk mencari artifak. Semakan pantas pada tapak web menunjukkan bahawa kebanyakannya adalah antara muka web produk terkenal syarikat global yang besar, yang pada semua penampilan memberitahu anda bahawa mereka tidak dialu-alukan. Mereka meminta nama pengguna dan kata laluan, goncangkan medan untuk memasukkan faktor kedua, meminta sijil klien TLS atau menghantarnya ke Microsoft ADFS. Ada yang tidak boleh diakses dari Internet. Bagi sesetengah orang, anda jelas perlu mempunyai pelanggan berbayar khas untuk tiga gaji atau mengetahui URL yang tepat untuk dimasukkan. Mari kita melangkau satu minggu lagi keputusasaan secara beransur-ansur dalam proses cuba "menerobos" versi perisian untuk kelemahan yang diketahui, mencari kandungan tersembunyi dalam laluan web dan akaun bocor daripada perkhidmatan pihak ketiga seperti LinkedIn, cuba meneka kata laluan menggunakannya, juga sebagai menggali kelemahan dalam laman web yang ditulis sendiri β dengan cara ini, menurut statistik, ini adalah vektor serangan luar yang paling menjanjikan hari ini. Saya akan segera perhatikan pistol filem yang kemudiannya dilepaskan.
Jadi, kami menemui dua tapak yang menonjol daripada ratusan perkhidmatan. Tapak ini mempunyai satu persamaan: jika anda tidak melibatkan diri dalam peninjauan rangkaian yang teliti mengikut domain, tetapi melihat terus untuk port terbuka atau menyasarkan pengimbas kerentanan menggunakan julat IP yang diketahui, maka tapak ini akan terlepas daripada pengimbasan dan tidak akan menjadi kelihatan tanpa mengetahui nama DNS. Mungkin mereka terlepas lebih awal, sekurang-kurangnya, dan alat automatik kami tidak menemui sebarang masalah dengannya, walaupun ia dihantar terus ke sumber.
Ngomong-ngomong, mengenai perkara yang ditemui pengimbas yang dilancarkan sebelum ini secara umum. Biar saya ingatkan anda: bagi sesetengah orang, "pentest" bersamaan dengan "imbasan automatik". Tetapi pengimbas pada projek ini tidak berkata apa-apa. Nah, maksimum ditunjukkan oleh kerentanan Sederhana (3 daripada 5 dari segi keterukan): pada sesetengah perkhidmatan sijil TLS yang tidak baik atau algoritma penyulitan lapuk, dan pada kebanyakan tapak Clickjacking. Tetapi ini tidak akan membawa anda ke matlamat anda. Mungkin pengimbas akan lebih berguna di sini, tetapi izinkan saya mengingatkan anda: pelanggan itu sendiri dapat membeli program sedemikian dan menguji dirinya dengan mereka, dan, berdasarkan keputusan yang suram, dia telah pun menyemaknya.
Mari kembali ke tapak "anomali". Yang pertama ialah sesuatu seperti Wiki tempatan pada alamat bukan standard, tetapi dalam artikel ini biarkan ia menjadi wiki.company[.]ru. Dia juga segera meminta log masuk dan kata laluan, tetapi melalui NTLM dalam penyemak imbas. Bagi pengguna, ini kelihatan seperti tetingkap pertapa yang meminta untuk memasukkan nama pengguna dan kata laluan. Dan ini adalah amalan buruk.
Nota kecil. NTLM dalam tapak web perimeter adalah buruk atas beberapa sebab. Sebab pertama ialah nama domain Active Directory didedahkan. Dalam contoh kami, ia juga ternyata company.ru, sama seperti nama DNS "luaran". Mengetahui perkara ini, anda boleh menyediakan sesuatu yang berniat jahat dengan teliti supaya ia dilaksanakan hanya pada mesin domain organisasi, dan bukan dalam beberapa kotak pasir. Kedua, pengesahan berjalan terus melalui pengawal domain melalui NTLM (mengejutkan, bukan?), dengan semua ciri dasar rangkaian "dalaman", termasuk menyekat akaun daripada melebihi bilangan percubaan memasukkan kata laluan. Jika penyerang mengetahui log masuk, dia akan mencuba kata laluan untuk mereka. Jika anda dikonfigurasikan untuk menyekat akaun daripada memasukkan kata laluan yang salah, ia akan berfungsi dan akaun itu akan disekat. Ketiga, adalah mustahil untuk menambah faktor kedua kepada pengesahan tersebut. Jika ada pembaca yang masih tahu caranya, sila beritahu saya, ia sangat menarik. Keempat, kerentanan terhadap serangan pass-the-hash. ADFS dicipta, antara lain, untuk melindungi daripada semua ini.
Terdapat satu sifat buruk produk Microsoft: walaupun anda tidak menerbitkan NTLM sedemikian secara khusus, ia akan dipasang secara lalai dalam OWA dan Lync, sekurang-kurangnya.
By the way, penulis artikel ini pernah secara tidak sengaja menyekat kira-kira 1000 akaun pekerja sebuah bank besar dalam masa satu jam sahaja menggunakan kaedah yang sama dan kemudian kelihatan agak pucat. Perkhidmatan IT bank itu juga pucat, tetapi semuanya berakhir dengan baik dan mencukupi, malah kami dipuji kerana menjadi orang pertama yang menemui masalah ini dan mencetuskan penyelesaian yang cepat dan tegas.
Tapak kedua mempunyai alamat "jelas semacam nama keluarga.company.ru." Menemuinya melalui Google, seperti ini di halaman 10. Reka bentuknya adalah dari awal-pertengahan XNUMX-an, dan seorang yang dihormati sedang melihatnya dari halaman utama, seperti ini:
Di sini saya mengambil gambar daripada "Heart of a Dog", tetapi percayalah, ia adalah samar-samar serupa, malah reka bentuk warnanya dalam ton yang serupa. Biarkan tapak dipanggil preobrazhensky.company.ru.
Ia adalah laman web peribadi... untuk pakar urologi. Saya tertanya-tanya apa yang dilakukan oleh tapak web pakar urologi pada subdomain syarikat berteknologi tinggi. Kajian pantas Google menunjukkan bahawa doktor ini ialah pengasas bersama salah satu entiti undang-undang pelanggan kami dan malah menyumbang kira-kira 1000 rubel dalam modal dibenarkan. Tapak ini mungkin telah dicipta bertahun-tahun yang lalu, dan sumber pelayan pelanggan digunakan sebagai pengehosan. Laman web ini telah lama kehilangan kaitannya, tetapi atas sebab tertentu ia dibiarkan berfungsi untuk masa yang lama.
Dari segi kelemahan, tapak web itu sendiri adalah selamat. Melihat ke hadapan, saya akan mengatakan bahawa ia adalah satu set maklumat statik - halaman html mudah dengan ilustrasi yang dimasukkan dalam bentuk buah pinggang dan pundi kencing. Tidak berguna untuk "memecahkan" tapak sedemikian.
Tetapi pelayan web di bawah lebih menarik. Berdasarkan pengepala Pelayan HTTP, ia mempunyai IIS 6.0, yang bermaksud ia menggunakan Windows 2003 sebagai sistem pengendalian. Pengimbas sebelum ini telah mengenal pasti bahawa tapak web pakar urologi ini, tidak seperti hos maya lain pada pelayan web yang sama, bertindak balas kepada arahan PROPFIND, bermakna ia menjalankan WebDAV. Ngomong-ngomong, pengimbas mengembalikan maklumat ini dengan tanda Info (dalam bahasa laporan pengimbas, ini adalah bahaya paling rendah) - perkara seperti itu biasanya dilangkau. Secara gabungan, ini memberikan kesan yang menarik, yang didedahkan hanya selepas satu lagi penggalian di Google: kelemahan limpahan penimbal yang jarang dikaitkan dengan set Shadow Brokers, iaitu CVE-2017-7269, yang sudah mempunyai eksploitasi sedia dibuat. Dalam erti kata lain, akan ada masalah jika anda mempunyai Windows 2003 dan WebDAV sedang berjalan pada IIS. Walaupun menjalankan Windows 2003 dalam pengeluaran pada 2018 adalah masalah itu sendiri.
Eksploit itu berakhir di Metasploit dan segera diuji dengan beban yang menghantar permintaan DNS kepada perkhidmatan terkawal - Burp Collaborator secara tradisinya digunakan untuk menangkap permintaan DNS. Yang mengejutkan saya, ia berfungsi buat kali pertama: kalah mati DNS telah diterima. Seterusnya, terdapat percubaan untuk mencipta sambungan belakang melalui port 80 (iaitu, sambungan rangkaian dari pelayan ke penyerang, dengan akses kepada cmd.exe pada hos mangsa), tetapi kegagalan berlaku. Sambungan tidak berjaya, dan selepas percubaan ketiga untuk menggunakan tapak, bersama-sama dengan semua gambar yang menarik, hilang selama-lamanya.
Biasanya ini diikuti dengan surat dalam gaya "pelanggan, bangun, kami melepaskan segala-galanya." Tetapi kami diberitahu bahawa tapak itu tiada kaitan dengan proses perniagaan dan berfungsi di sana tanpa sebab sama sekali, seperti keseluruhan pelayan, dan kami boleh menggunakan sumber ini sesuka hati.
Kira-kira sehari kemudian tapak itu tiba-tiba mula berfungsi sendiri. Setelah membina bangku daripada WebDAV pada IIS 6.0, saya mendapati bahawa tetapan lalai adalah untuk memulakan semula proses pekerja IIS setiap 30 jam. Iaitu, apabila kawalan keluar dari shellcode, proses pekerja IIS berakhir, kemudian ia dimulakan semula sendiri beberapa kali dan kemudian berehat selama 30 jam.
Memandangkan sambungan belakang kepada tcp gagal buat kali pertama, saya mengaitkan masalah ini kepada port tertutup. Iaitu, dia mengandaikan kehadiran beberapa jenis tembok api yang tidak membenarkan sambungan keluar melalui luar. Saya mula menjalankan kod shell yang mencari melalui banyak port tcp dan udp, tiada kesan. Pemuatan sambungan songsang melalui http(s) daripada Metasploit tidak berfungsi - meterpreter/reverse_http(s). Tiba-tiba, sambungan ke port 80 yang sama telah diwujudkan, tetapi segera terputus. Saya mengaitkan ini dengan tindakan IPS yang masih khayalan, yang tidak menyukai trafik meterpreter. Memandangkan fakta bahawa sambungan tcp tulen ke port 80 tidak berjaya, tetapi sambungan http berjaya, saya membuat kesimpulan bahawa proksi http entah bagaimana dikonfigurasikan dalam sistem.
Saya juga mencuba meterpreter melalui DNS (terima kasih atas usaha anda, menyelamatkan banyak projek), mengingati kejayaan pertama, tetapi ia tidak berfungsi pada pendirian - kod shell terlalu besar untuk kelemahan ini.
Pada hakikatnya, ia kelihatan seperti ini: 3-4 percubaan pada serangan dalam masa 5 minit, kemudian menunggu selama 30 jam. Dan seterusnya selama tiga minggu berturut-turut. Saya juga menetapkan peringatan supaya tidak membuang masa. Selain itu, terdapat perbezaan dalam kelakuan persekitaran ujian dan pengeluaran: untuk kelemahan ini terdapat dua eksploitasi yang serupa, satu daripada Metasploit, yang kedua daripada Internet, ditukar daripada versi Shadow Brokers. Jadi, hanya Metasploit yang diuji dalam pertempuran, dan hanya yang kedua diuji di bangku simpanan, yang menjadikan penyahpepijatan lebih sukar dan mengganggu otak.
Akhirnya, shellcode yang memuat turun fail exe dari pelayan tertentu melalui http dan melancarkannya pada sistem sasaran terbukti berkesan. Kod shell cukup kecil untuk dimuatkan, tetapi sekurang-kurangnya ia berfungsi. Memandangkan pelayan tidak menyukai trafik TCP sama sekali dan http(s) telah diperiksa untuk kehadiran meterpreter, saya memutuskan bahawa cara terpantas ialah memuat turun fail exe yang mengandungi DNS-meterpreter melalui shellcode ini.
Di sini sekali lagi masalah timbul: apabila memuat turun fail exe dan, seperti yang ditunjukkan oleh percubaan, tidak kira yang mana satu, muat turun telah terganggu. Sekali lagi, beberapa peranti keselamatan antara pelayan saya dan pakar urologi tidak menyukai trafik http dengan exe di dalamnya. Penyelesaian "cepat" nampaknya adalah untuk menukar kod shell supaya ia mengaburkan trafik http dengan cepat, supaya data perduaan abstrak dipindahkan dan bukannya exe. Akhirnya, serangan itu berjaya, kawalan diterima melalui saluran DNS nipis:
Ia serta-merta menjadi jelas bahawa saya mempunyai hak aliran kerja IIS yang paling asas, yang membenarkan saya untuk melakukan apa-apa. Inilah rupanya pada konsol Metasploit:
Semua metodologi pentest amat mencadangkan bahawa anda perlu meningkatkan hak apabila mendapat akses. Saya biasanya tidak melakukan ini secara tempatan, kerana akses pertama dilihat hanya sebagai titik masuk rangkaian, dan menjejaskan mesin lain pada rangkaian yang sama biasanya lebih mudah dan lebih cepat daripada meningkatkan keistimewaan pada hos sedia ada. Tetapi ini tidak berlaku di sini, kerana saluran DNS sangat sempit dan ia tidak akan membenarkan trafik dibersihkan.
Dengan mengandaikan bahawa pelayan Windows 2003 ini tidak dibaiki untuk kelemahan MS17-010 yang terkenal, saya terowong trafik ke port 445/TCP melalui terowong DNS meterpreter ke localhost (ya, ini juga mungkin) dan cuba jalankan exe yang dimuat turun sebelum ini melalui kelemahan itu. Serangan berfungsi, saya menerima sambungan kedua, tetapi dengan hak SISTEM.
Adalah menarik bahawa mereka masih cuba melindungi pelayan daripada MS17-010 - ia mempunyai perkhidmatan rangkaian yang terdedah dilumpuhkan pada antara muka luaran. Ini melindungi daripada serangan melalui rangkaian, tetapi serangan dari dalam pada localhost berfungsi, kerana anda tidak boleh mematikan SMB pada localhost dengan cepat.
Seterusnya, butiran menarik baharu didedahkan:
- Mempunyai hak SYSTEM, anda boleh mewujudkan sambungan belakang dengan mudah melalui TCP. Jelas sekali, melumpuhkan TCP langsung adalah masalah untuk pengguna IIS terhad. Spoiler: trafik pengguna IIS entah bagaimana dibungkus dalam Proksi ISA tempatan di kedua-dua arah. Bagaimana sebenarnya ia berfungsi, saya belum menghasilkan semula.
- Saya berada dalam "DMZ" tertentu (dan ini bukan domain Active Directory, tetapi WORKGROUP) - bunyinya logik. Tetapi bukannya alamat IP peribadi (βkelabuβ) yang dijangkakan, saya mempunyai alamat IP βputihβ sepenuhnya, betul-betul sama seperti yang saya serang sebelum ini. Ini bermakna syarikat itu sudah lama dalam dunia pengalamatan IPv4 sehingga mampu mengekalkan zon DMZ untuk 128 alamat "putih" tanpa NAT mengikut skema, seperti yang digambarkan dalam manual Cisco dari 2005.
Memandangkan pelayan sudah lama, Mimikatz dijamin berfungsi terus dari ingatan:
Saya mendapat kata laluan pentadbir tempatan, terowong trafik RDP melalui TCP dan log masuk ke desktop yang selesa. Memandangkan saya boleh melakukan apa sahaja yang saya mahu dengan pelayan, saya mengalih keluar antivirus dan mendapati pelayan boleh diakses dari Internet hanya melalui port TCP 80 dan 443, dan 443 tidak sibuk. Saya menyediakan pelayan OpenVPN pada 443, menambah fungsi NAT untuk trafik VPN saya dan mendapatkan akses terus ke rangkaian DMZ dalam bentuk tanpa had melalui OpenVPN saya. Perlu diperhatikan bahawa ISA, yang mempunyai beberapa fungsi IPS yang tidak dilumpuhkan, menyekat trafik saya dengan pengimbasan port, yang mana ia terpaksa digantikan dengan RRAS yang lebih ringkas dan lebih patuh. Jadi pentester kadang-kadang masih perlu mentadbir pelbagai perkara.
Pembaca yang penuh perhatian akan bertanya: "Bagaimana dengan tapak kedua - wiki dengan pengesahan NTLM, yang telah banyak ditulis?" Lebih lanjut mengenai ini kemudian.
Bahagian 2. Masih tidak menyulitkan? Kemudian kami datang kepada anda sudah di sini
Jadi, terdapat akses kepada segmen rangkaian DMZ. Anda perlu pergi ke pentadbir domain. Perkara pertama yang terlintas di fikiran ialah menyemak keselamatan perkhidmatan secara automatik dalam segmen DMZ, terutamanya kerana banyak lagi perkhidmatan tersebut kini dibuka untuk penyelidikan. Gambar biasa semasa ujian penembusan: perimeter luaran lebih dilindungi daripada perkhidmatan dalaman, dan apabila mendapat sebarang akses di dalam infrastruktur yang besar, lebih mudah untuk mendapatkan hak lanjutan dalam domain hanya disebabkan oleh fakta bahawa domain ini mula menjadi boleh diakses oleh alatan, dan kedua, Dalam infrastruktur dengan beberapa ribu hos, akan sentiasa ada beberapa masalah kritikal.
Saya mengecas pengimbas melalui DMZ melalui terowong OpenVPN dan menunggu. Saya membuka laporan - sekali lagi tidak serius, nampaknya seseorang telah melalui kaedah yang sama sebelum saya. Langkah seterusnya adalah untuk memeriksa bagaimana hos dalam rangkaian DMZ berkomunikasi. Untuk melakukan ini, mula-mula lancarkan Wireshark biasa dan dengar permintaan penyiaran, terutamanya ARP. Paket ARP dikumpul sepanjang hari. Ternyata beberapa pintu masuk digunakan dalam segmen ini. Ini akan berguna nanti. Dengan menggabungkan data pada permintaan dan tindak balas ARP serta data pengimbasan port, saya menemui titik keluar trafik pengguna dari dalam rangkaian tempatan sebagai tambahan kepada perkhidmatan yang diketahui sebelum ini, seperti web dan mel.
Memandangkan pada masa ini saya tidak mempunyai apa-apa akses kepada sistem lain dan tidak mempunyai satu akaun untuk perkhidmatan korporat, ia telah memutuskan untuk memancing sekurang-kurangnya beberapa akaun daripada trafik menggunakan ARP Spoofing.
Cain&Abel telah dilancarkan pada pelayan pakar urologi. Dengan mengambil kira aliran trafik yang dikenal pasti, pasangan yang paling menjanjikan untuk serangan man-in-the-middle telah dipilih, dan kemudian beberapa trafik rangkaian diterima melalui pelancaran jangka pendek selama 5-10 minit, dengan pemasa untuk but semula pelayan dalam kes beku. Seperti dalam jenaka, terdapat dua berita:
- Baik: banyak bukti telah ditangkap dan serangan secara keseluruhannya berhasil.
- Yang buruk: semua bukti kelayakan adalah daripada pelanggan pelanggan sendiri. Semasa menyediakan perkhidmatan sokongan, pakar pelanggan berhubung dengan perkhidmatan pelanggan yang tidak selalu mempunyai penyulitan trafik dikonfigurasikan.
Akibatnya, saya memperoleh banyak kelayakan yang tidak berguna dalam konteks projek, tetapi pasti menarik sebagai demonstrasi bahaya serangan. Penghala sempadan syarikat besar dengan telnet, port http nyahpepijat yang dimajukan ke CRM dalaman dengan semua data, akses terus kepada RDP daripada Windows XP pada rangkaian tempatan dan kekaburan lain. Ternyata begini .
Saya juga menemui peluang lucu untuk mengumpul surat daripada trafik, sesuatu seperti ini. Ini ialah contoh surat siap yang dihantar daripada pelanggan kami ke port SMTP pelanggannya, sekali lagi, tanpa penyulitan. Andrey tertentu meminta namanya untuk menghantar semula dokumentasi, dan ia dimuat naik ke cakera awan dengan log masuk, kata laluan dan pautan dalam satu surat respons:
Ini adalah satu lagi peringatan untuk menyulitkan semua perkhidmatan. Tidak diketahui siapa dan bila akan membaca dan menggunakan data anda secara khusus - pembekal, pentadbir sistem syarikat lain, atau pentester sedemikian. Saya senyap tentang hakikat bahawa ramai orang boleh memintas lalu lintas yang tidak disulitkan.
Walaupun kejayaan yang nyata, ini tidak membawa kami lebih dekat kepada matlamat. Sudah tentu, mungkin untuk duduk lama dan menangkap maklumat berharga, tetapi bukan fakta bahawa ia akan muncul di sana, dan serangan itu sendiri sangat berisiko dari segi integriti rangkaian.
Selepas menggali lagi perkhidmatan, idea menarik muncul di fikiran. Terdapat utiliti sedemikian yang dipanggil Responder (mudah untuk mencari contoh penggunaan dengan nama ini), yang, dengan "meracuni" permintaan penyiaran, mencetuskan sambungan melalui pelbagai protokol seperti SMB, HTTP, LDAP, dll. dengan cara yang berbeza, kemudian meminta semua orang yang menyambung untuk mengesahkan dan menetapkannya supaya pengesahan berlaku melalui NTLM dan dalam mod yang telus kepada mangsa. Selalunya, penyerang mengumpul jabat tangan NetNTLMv2 dengan cara ini dan daripadanya, menggunakan kamus, memulihkan kata laluan domain pengguna dengan cepat. Di sini saya mahukan sesuatu yang serupa, tetapi pengguna duduk "di belakang dinding", atau sebaliknya, mereka dipisahkan oleh tembok api, dan mengakses WEB melalui kelompok proksi Blue Coat.
Ingat, saya menyatakan bahawa nama domain Active Directory bertepatan dengan domain "luaran", iaitu, ia adalah company.ru? Jadi, Windows, lebih tepat lagi Internet Explorer (dan Edge dan Chrome), membenarkan pengguna untuk mengesahkan secara telus dalam HTTP melalui NTLM jika mereka menganggap bahawa tapak itu terletak di beberapa "Zon Intranet". Salah satu tanda "Intranet" ialah akses kepada alamat IP "kelabu" atau nama DNS pendek, iaitu, tanpa titik. Memandangkan mereka mempunyai pelayan dengan IP "putih" dan nama DNS preobrazhensky.company.ru, dan mesin domain biasanya menerima akhiran domain Active Directory melalui DHCP untuk kemasukan nama yang dipermudahkan, mereka hanya perlu menulis URL dalam bar alamat , supaya mereka mencari jalan yang betul ke pelayan ahli urologi yang terjejas, tidak lupa bahawa ini kini dipanggil "Intranet". Iaitu, pada masa yang sama memberi saya jabat tangan NTLM pengguna tanpa pengetahuannya. Yang tinggal hanyalah memaksa pelayar klien memikirkan tentang keperluan mendesak untuk menghubungi pelayan ini.
Utiliti Intercepter-NG yang indah datang untuk menyelamatkan (terima kasih ). Ia membenarkan anda menukar trafik dengan cepat dan berfungsi dengan baik pada Windows 2003. Ia juga mempunyai fungsi berasingan untuk mengubah suai fail JavaScript sahaja dalam aliran trafik. Semacam Skrip Silang Tapak besar-besaran telah dirancang.
Proksi Blue Coat, yang melaluinya pengguna mengakses WEB global, menyimpan kandungan statik secara berkala. Dengan memintas lalu lintas, adalah jelas bahawa mereka bekerja sepanjang masa, tanpa henti meminta statik yang kerap digunakan untuk mempercepatkan paparan kandungan pada waktu puncak. Di samping itu, BlueCoat mempunyai Ejen Pengguna khusus, yang membezakannya dengan jelas daripada pengguna sebenar.
Javascript telah disediakan, yang, menggunakan Intercepter-NG, dilaksanakan selama sejam pada waktu malam untuk setiap respons dengan fail JS untuk Blue Coat. Skrip melakukan perkara berikut:
- Menentukan penyemak imbas semasa oleh Ejen Pengguna. Jika Internet Explorer, Edge atau Chrome, ia terus berfungsi.
- Saya menunggu sehingga DOM halaman dibentuk.
- Memasukkan imej halimunan ke dalam DOM dengan atribut src borang :8080/NNNNNNN.png, di mana NNN ialah nombor arbitrari supaya BlueCoat tidak menyimpannya di cache.
- Tetapkan pembolehubah bendera global untuk menunjukkan bahawa suntikan telah selesai dan tidak perlu memasukkan imej lagi.
Penyemak imbas cuba memuatkan imej ini; pada port 8080 pelayan yang terjejas, terowong TCP sedang menunggunya ke komputer riba saya, di mana Responder yang sama sedang berjalan, memerlukan penyemak imbas untuk log masuk melalui NTLM.
Berdasarkan log Responder, orang ramai datang bekerja pada waktu pagi, menghidupkan stesen kerja mereka, kemudian secara beramai-ramai dan tanpa disedari mula melawat pelayan pakar urologi, tidak lupa untuk "mengalirkan" jabat tangan NTLM. Jabat tangan turun sepanjang hari dan bahan terkumpul dengan jelas untuk serangan yang jelas berjaya memulihkan kata laluan. Beginilah rupa log Responder:
Lawatan rahsia besar-besaran ke pelayan urologi oleh pengguna
Anda mungkin telah perasan bahawa keseluruhan cerita ini dibina berdasarkan prinsip "semuanya baik-baik saja, tetapi kemudian ada kekecewaan, kemudian ada yang mengatasi, dan kemudian semuanya berjaya." Jadi, berlaku kekecewaan di sini. Daripada lima puluh jabat tangan unik itu, tiada satu pun yang didedahkan. Dan ini mengambil kira hakikat bahawa walaupun pada komputer riba dengan pemproses mati, jabat tangan NTLMv2 ini diproses pada kelajuan beberapa ratus juta percubaan sesaat.
Saya terpaksa mempersenjatai diri saya dengan teknik mutasi kata laluan, kad video, kamus yang lebih tebal dan tunggu. Selepas sekian lama, beberapa akaun dengan kata laluan dalam bentuk "Q11111111....1111111q" telah didedahkan, yang menunjukkan bahawa semua pengguna pernah dipaksa untuk menghasilkan kata laluan yang sangat panjang dengan kes aksara yang berbeza, yang juga sepatutnya menjadi kompleks. Tetapi anda tidak boleh menipu pengguna yang berpengalaman, dan ini adalah cara dia memudahkan dirinya untuk mengingati. Secara keseluruhan, kira-kira 5 akaun telah terjejas, dan hanya satu daripada mereka yang mempunyai sebarang hak berharga untuk perkhidmatan tersebut.
Bahagian 3. Roskomnadzor menyerang balik
Jadi, akaun domain pertama telah diterima. Jika anda belum tertidur pada ketika ini dari pembacaan yang panjang, anda mungkin akan ingat bahawa saya menyebut perkhidmatan yang tidak memerlukan faktor pengesahan kedua: ia ialah wiki dengan pengesahan NTLM. Sudah tentu, perkara pertama yang perlu dilakukan ialah masuk ke sana. Menggali pangkalan pengetahuan dalaman dengan cepat membawa hasil:
- Syarikat itu mempunyai rangkaian WiFi dengan pengesahan menggunakan akaun domain dengan akses kepada rangkaian tempatan. Dengan set data semasa, ini sudah menjadi vektor serangan yang berfungsi, tetapi anda perlu pergi ke pejabat dengan kaki anda dan berada di suatu tempat di wilayah pejabat pelanggan.
- Saya menjumpai arahan yang mengikutnya terdapat perkhidmatan yang membenarkan... mendaftarkan peranti pengesahan "faktor kedua" secara bebas jika pengguna berada di dalam rangkaian tempatan dan dengan yakin mengingati log masuk dan kata laluan domainnya. Dalam kes ini, "dalam" dan "luar" ditentukan oleh kebolehaksesan pelabuhan perkhidmatan ini kepada pengguna. Pelabuhan itu tidak boleh diakses dari Internet, tetapi agak boleh diakses melalui DMZ.
Sudah tentu, "faktor kedua" segera ditambahkan pada akaun yang terjejas dalam bentuk aplikasi pada telefon saya. Terdapat program yang sama ada boleh menghantar permintaan tolak dengan kuat ke telefon dengan butang "luluskan"/"tidak setuju" untuk tindakan itu, atau secara senyap menunjukkan kod OTP pada skrin untuk kemasukan bebas selanjutnya. Lebih-lebih lagi, kaedah pertama sepatutnya oleh arahan sebagai satu-satunya yang betul, tetapi ia tidak berfungsi, tidak seperti kaedah OTP.
Dengan "faktor kedua" rosak, saya dapat mengakses mel Outlook Web Access dan akses jauh dalam Citrix Netscaler Gateway. Terdapat kejutan dalam mel dalam Outlook:
Dalam tangkapan jarang ini, anda boleh melihat bagaimana Roskomnadzor membantu pentesters
Ini adalah bulan pertama selepas "peminat" menyekat Telegram yang terkenal, apabila keseluruhan rangkaian dengan beribu-ribu alamat tidak dapat dielakkan daripada akses. Ia menjadi jelas mengapa tolakan itu tidak berfungsi serta-merta dan mengapa "mangsa" saya tidak membunyikan penggera kerana mereka mula menggunakan akaunnya semasa waktu buka.
Sesiapa yang biasa dengan Citrix Netscaler membayangkan bahawa ia biasanya dilaksanakan dengan cara yang hanya antara muka gambar boleh disampaikan kepada pengguna, cuba untuk tidak memberinya alat untuk melancarkan aplikasi pihak ketiga dan memindahkan data, mengehadkan dalam setiap cara tindakan yang mungkin. melalui cengkerang kawalan standard. "Mangsa" saya, disebabkan pekerjaannya, hanya mendapat 1C:
Selepas berjalan di sekitar antara muka 1C sedikit, saya mendapati bahawa terdapat modul pemprosesan luaran di sana. Ia boleh dimuatkan daripada antara muka, dan ia akan dilaksanakan pada klien atau pelayan, bergantung pada hak dan tetapan.
Saya meminta rakan pengaturcara 1C saya untuk mencipta pemprosesan yang akan menerima rentetan dan melaksanakannya. Dalam bahasa 1C, memulakan proses kelihatan seperti ini (diambil dari Internet). Adakah anda bersetuju bahawa sintaks bahasa 1C memukau orang berbahasa Rusia dengan spontannya?
Pemprosesan telah dilaksanakan dengan sempurna; ia ternyata apa yang dipanggil oleh pentester sebagai "cangkang" - Internet Explorer dilancarkan melaluinya.
Terdahulu, alamat sistem yang membolehkan anda memesan pas ke wilayah ditemui dalam mel. Saya memesan pas sekiranya saya terpaksa menggunakan vektor serangan WiFi.
Terdapat cakap-cakap di Internet bahawa masih ada katering percuma yang lazat di pejabat pelanggan, tetapi saya masih lebih suka mengembangkan serangan dari jauh, ia lebih tenang.
AppLocker telah diaktifkan pada pelayan aplikasi yang menjalankan Citrix, tetapi ia telah dipintas. Meterpreter yang sama telah dimuatkan dan dilancarkan melalui DNS, kerana versi http(s) tidak mahu disambungkan, dan saya tidak tahu alamat proksi dalaman pada masa itu. Ngomong-ngomong, mulai saat ini, pentest luaran pada dasarnya bertukar sepenuhnya menjadi pentest dalaman.
Bahagian 4. Hak admin untuk pengguna adalah buruk, boleh?
Tugas pertama pentester apabila mendapat kawalan sesi pengguna domain adalah untuk mengumpul semua maklumat tentang hak dalam domain. Terdapat utiliti BloodHound yang secara automatik membenarkan anda memuat turun maklumat tentang pengguna, komputer, kumpulan keselamatan melalui protokol LDAP daripada pengawal domain, dan melalui SMB - maklumat tentang pengguna mana yang baru log masuk di mana dan siapa pentadbir tempatan.
Teknik biasa untuk merebut hak pentadbir domain kelihatan dipermudahkan sebagai kitaran tindakan membosankan:
- Kami pergi ke komputer domain yang mempunyai hak pentadbir tempatan, berdasarkan akaun domain yang telah ditangkap.
- Kami melancarkan Mimikatz dan mendapatkan kata laluan cache, tiket Kerberos dan cincang NTLM akaun domain yang log masuk ke sistem ini baru-baru ini. Atau kami mengalih keluar imej memori proses lsass.exe dan melakukan perkara yang sama di pihak kami. Ini berfungsi dengan baik dengan Windows lebih muda daripada 2012R2/Windows 8.1 dengan tetapan lalai.
- Kami menentukan di mana akaun yang terjejas mempunyai hak pentadbir tempatan. Kita ulangi point pertama. Pada peringkat tertentu kami mendapat hak pentadbir untuk keseluruhan domain.
"Tamat Kitaran;", seperti yang akan ditulis oleh pengaturcara 1C di sini.
Jadi, pengguna kami ternyata menjadi pentadbir tempatan pada hanya satu hos dengan Windows 7, namanya termasuk perkataan "VDI", atau "Infrastruktur Desktop Maya", mesin maya peribadi. Mungkin, pereka perkhidmatan VDI bermaksud bahawa memandangkan VDI ialah sistem pengendalian peribadi pengguna, walaupun pengguna menukar persekitaran perisian sesuka hati, hos masih boleh "dimuat semula". Saya juga berpendapat bahawa secara umum idea itu bagus, saya pergi ke hos VDI peribadi ini dan membuat sarang di sana:
- Saya memasang klien OpenVPN di sana, yang membuat terowong melalui Internet ke pelayan saya. Pelanggan terpaksa terpaksa melalui Blue Coat yang sama dengan pengesahan domain, tetapi OpenVPN melakukannya, seperti yang mereka katakan, "di luar kotak."
- Memasang OpenSSH pada VDI. Sebenarnya, apakah Windows 7 tanpa SSH?
Beginilah rupanya secara langsung. Biar saya ingatkan anda bahawa semua ini perlu dilakukan melalui Citrix dan 1C:
Satu teknik untuk mempromosikan akses kepada komputer jiran ialah menyemak kata laluan pentadbir tempatan untuk perlawanan. Di sini nasib segera menanti: cincangan NTLM pentadbir tempatan lalai (yang tiba-tiba dipanggil Pentadbir) telah didekati melalui serangan pass-the-hash kepada hos VDI jiran, yang terdapat beberapa ratus. Sudah tentu, serangan itu segera melanda mereka.
Di sinilah pentadbir VDI menembak diri mereka sendiri dua kali:
- Kali pertama ialah apabila mesin VDI tidak dibawa ke bawah LAPS, pada asasnya mengekalkan kata laluan pentadbir tempatan yang sama daripada imej yang digunakan secara besar-besaran ke VDI.
- Pentadbir lalai ialah satu-satunya akaun tempatan yang terdedah kepada serangan pass-the-hash. Walaupun dengan kata laluan yang sama, adalah mungkin untuk mengelakkan kompromi besar-besaran dengan mencipta akaun pentadbir tempatan kedua dengan kata laluan rawak yang kompleks dan menyekat yang lalai.
Mengapakah terdapat perkhidmatan SSH pada Windows itu? Sangat mudah: kini pelayan OpenSSH bukan sahaja menyediakan shell arahan interaktif yang mudah tanpa mengganggu kerja pengguna, tetapi juga proksi socks5 pada VDI. Melalui stoking ini, saya menyambung melalui SMB dan mengumpul akaun cache daripada semua ratusan mesin VDI ini, kemudian mencari laluan kepada pentadbir domain menggunakannya dalam graf BloodHound. Dengan beratus-ratus hos yang saya gunakan, saya menemui cara ini dengan cepat. Hak pentadbir domain telah diperolehi.
Berikut ialah gambar dari Internet yang menunjukkan carian serupa. Sambungan menunjukkan siapa di mana pentadbir berada dan siapa yang dilog masuk di mana.
Ngomong-ngomong, ingat keadaan dari permulaan projek - "jangan gunakan kejuruteraan sosial." Jadi, saya cadangkan untuk memikirkan berapa banyak Bollywood dengan kesan khas ini akan diputuskan jika masih boleh menggunakan pancingan data cetek. Tetapi secara peribadi, ia sangat menarik untuk saya melakukan semua ini. Saya harap anda seronok membaca ini. Sudah tentu, tidak setiap projek kelihatan begitu menarik, tetapi kerja secara keseluruhannya sangat mencabar dan tidak membenarkannya terbantut.
Mungkin seseorang akan mempunyai soalan: bagaimana untuk melindungi diri anda? Malah artikel ini menerangkan banyak teknik, kebanyakannya pentadbir Windows tidak mengetahuinya. Walau bagaimanapun, saya mencadangkan untuk melihatnya dari perspektif prinsip yang digodam dan langkah keselamatan maklumat:
- jangan gunakan perisian lapuk (ingat Windows 2003 pada mulanya?)
- jangan biarkan sistem yang tidak perlu dihidupkan (mengapa terdapat tapak web pakar urologi?)
- semak kata laluan pengguna untuk kekuatan sendiri (jika tidak askar... pentesters akan melakukan ini)
- tidak mempunyai kata laluan yang sama untuk akaun yang berbeza (kompromi VDI)
- dan lain-lain
Sudah tentu, ini sangat sukar untuk dilaksanakan, tetapi dalam artikel seterusnya kami akan menunjukkan dalam amalan bahawa ia agak mungkin.
Sumber: www.habr.com