Artikel ini ditulis berdasarkan pentest yang sangat sukses yang dilakukan oleh spesialis Group-IB beberapa tahun yang lalu: sebuah cerita terjadi yang dapat diadaptasi untuk film di Bollywood. Sekarang mungkin reaksi pembaca akan seperti ini: “Oh, artikel PR lagi, lagi-lagi ini sedang digambarkan, bagus sekali, jangan lupa beli pentest.” Ya, di satu sisi memang demikian. Namun, ada sejumlah alasan lain mengapa artikel ini muncul. Saya ingin menunjukkan apa sebenarnya yang dilakukan pentester, betapa menarik dan tidak sepelenya pekerjaan ini, keadaan lucu apa yang bisa muncul dalam proyek, dan yang terpenting, menunjukkan materi langsung dengan contoh nyata.
Untuk mengembalikan keseimbangan kesopanan di dunia, sebentar lagi kami akan menulis tentang pentest yang tidak berjalan dengan baik. Kami akan menunjukkan bagaimana proses yang dirancang dengan baik di sebuah perusahaan dapat melindungi terhadap berbagai macam serangan, bahkan serangan yang telah dipersiapkan dengan baik, hanya karena proses ini ada dan benar-benar berfungsi.
Untuk pelanggan dalam artikel ini, semuanya juga secara umum sangat baik, setidaknya lebih baik dari 95% pasar di Federasi Rusia, menurut perasaan kami, tetapi ada sejumlah nuansa kecil yang membentuk rangkaian peristiwa yang panjang, yang pertama mengarah ke laporan panjang tentang pekerjaan tersebut, dan kemudian ke artikel ini.
Jadi, ayo beli popcorn, dan selamat datang di cerita detektif. Kata - Pavel Suprunyuk, manajer teknis departemen “Audit dan Konsultasi” di Group-IB.
Bagian 1. Dokter Pochkin
2018 Ada pelanggan - perusahaan IT berteknologi tinggi, yang melayani banyak klien. Ingin mendapatkan jawaban atas pertanyaan: apakah mungkin, tanpa pengetahuan dan akses awal apa pun, bekerja melalui Internet, untuk mendapatkan hak administrator domain Direktori Aktif? Saya tidak tertarik dengan rekayasa sosial apa pun (), mereka tidak bermaksud untuk mengganggu pekerjaan dengan sengaja, tetapi mereka mungkin secara tidak sengaja - memuat ulang server yang berfungsi secara aneh, misalnya. Tujuan tambahannya adalah mengidentifikasi sebanyak mungkin vektor serangan lain terhadap perimeter luar. Perusahaan secara rutin melakukan pengujian semacam itu, dan kini batas waktu pengujian baru telah tiba. Kondisinya hampir khas, memadai, dapat dimengerti. Mari kita mulai.
Ada nama pelanggan - biarlah "Perusahaan", dengan situs web utama . Tentu saja, pelanggan dipanggil secara berbeda, tetapi dalam artikel ini semuanya akan bersifat impersonal.
Saya melakukan pengintaian jaringan - mencari tahu alamat dan domain mana yang terdaftar pada pelanggan, menggambar diagram jaringan, bagaimana layanan didistribusikan ke alamat-alamat ini. Saya mendapatkan hasilnya: lebih dari 4000 alamat IP aktif. Saya melihat domain di jaringan ini: untungnya, sebagian besar adalah jaringan yang ditujukan untuk klien pelanggan, dan kami tidak tertarik secara formal pada domain tersebut. Pelanggan juga berpikiran sama.
Masih ada satu jaringan dengan 256 alamat, yang saat ini sudah ada pemahaman tentang distribusi domain dan subdomain berdasarkan alamat IP, ada informasi tentang port yang dipindai, yang berarti Anda dapat melihat layanan yang menarik. Secara paralel, semua jenis pemindai diluncurkan pada alamat IP yang tersedia dan secara terpisah di situs web.
Ada banyak layanan. Biasanya ini merupakan kegembiraan bagi pentester dan antisipasi kemenangan cepat, karena semakin banyak layanan yang ada, semakin besar bidang serangan dan semakin mudah menemukan artefak. Sekilas melihat situs-situs tersebut menunjukkan bahwa sebagian besar dari situs-situs tersebut adalah antarmuka web dari produk-produk terkenal dari perusahaan-perusahaan global besar, yang tampaknya memberi tahu Anda bahwa situs-situs tersebut tidak diterima. Mereka meminta nama pengguna dan kata sandi, menghapus kolom untuk memasukkan faktor kedua, meminta sertifikat klien TLS, atau mengirimkannya ke Microsoft ADFS. Beberapa tidak dapat diakses dari Internet. Bagi sebagian orang, Anda jelas perlu memiliki klien berbayar khusus dengan tiga gaji atau mengetahui URL pasti untuk masuk. Mari kita lewati satu minggu lagi keputusasaan bertahap dalam proses mencoba "menerobos" versi perangkat lunak untuk menemukan kerentanan yang diketahui, mencari konten tersembunyi di jalur web dan membocorkan akun dari layanan pihak ketiga seperti LinkedIn, mencoba menebak kata sandi yang menggunakannya, juga seperti menggali kerentanan di situs web yang ditulis sendiri — menurut statistik, ini adalah vektor serangan eksternal yang paling menjanjikan saat ini. Saya akan segera mencatat senjata film yang kemudian ditembakkan.
Jadi, kami menemukan dua situs yang menonjol dari ratusan layanan. Situs-situs ini memiliki satu kesamaan: jika Anda tidak melakukan pengintaian jaringan yang cermat berdasarkan domain, tetapi mencari port terbuka atau menargetkan pemindai kerentanan menggunakan rentang IP yang diketahui, maka situs-situs ini akan lolos dari pemindaian dan tidak akan terlacak. terlihat tanpa mengetahui nama DNS. Mungkin mereka telah terlewatkan sebelumnya, setidaknya, dan alat otomatis kami tidak menemukan masalah apa pun dengannya, bahkan jika mereka dikirim langsung ke sumbernya.
Ngomong-ngomong, tentang apa yang ditemukan pemindai yang diluncurkan sebelumnya secara umum. Izinkan saya mengingatkan Anda: bagi sebagian orang, "pentest" setara dengan "pemindaian otomatis". Namun pemindai pada proyek ini tidak mengatakan apa-apa. Nah, kerentanan maksimum ditunjukkan oleh kerentanan Sedang (3 dari 5 dalam hal tingkat keparahan): pada beberapa layanan, sertifikat TLS yang buruk atau algoritme enkripsi yang ketinggalan jaman, dan di sebagian besar situs Clickjacking. Tapi ini tidak akan membawa Anda ke tujuan Anda. Mungkin pemindai akan lebih berguna di sini, tapi izinkan saya mengingatkan Anda: pelanggan sendiri dapat membeli program tersebut dan menguji dirinya sendiri dengan program tersebut, dan, dilihat dari hasil yang buruk, dia sudah memeriksanya.
Mari kita kembali ke situs “anomali”. Yang pertama adalah sesuatu seperti Wiki lokal dengan alamat non-standar, tetapi dalam artikel ini biarlah wiki.perusahaan[.]ru. Ia pun langsung meminta login dan password, namun melalui NTLM di browser. Bagi pengguna, ini tampak seperti jendela pertapa yang meminta memasukkan nama pengguna dan kata sandi. Dan ini adalah praktik yang buruk.
Catatan kecil. NTLM di situs perimeter buruk karena sejumlah alasan. Alasan pertama adalah nama domain Active Directory terungkap. Dalam contoh kami, ternyata juga company.ru, sama seperti nama DNS “eksternal”. Mengetahui hal ini, Anda dapat dengan hati-hati mempersiapkan sesuatu yang berbahaya sehingga hanya dijalankan di mesin domain organisasi, dan bukan di kotak pasir. Kedua, otentikasi dilakukan langsung melalui pengontrol domain melalui NTLM (kejutan, bukan?), dengan semua fitur kebijakan jaringan “internal”, termasuk memblokir akun agar tidak melebihi jumlah upaya memasukkan kata sandi. Jika penyerang mengetahui login tersebut, dia akan mencoba kata sandinya. Jika Anda dikonfigurasi untuk memblokir akun agar tidak memasukkan kata sandi yang salah, ini akan berhasil dan akun akan diblokir. Ketiga, tidak mungkin menambahkan faktor kedua pada otentikasi tersebut. Kalau ada diantara pembaca yang masih tahu caranya, tolong beritahu saya, menarik sekali. Keempat, kerentanan terhadap serangan pass-the-hash. ADFS diciptakan, antara lain, untuk melindungi dari semua ini.
Ada satu sifat buruk dari produk Microsoft: meskipun Anda tidak secara khusus menerbitkan NTLM tersebut, setidaknya NTLM tersebut akan diinstal secara default di OWA dan Lync.
Ngomong-ngomong, penulis artikel ini pernah secara tidak sengaja memblokir kurang lebih 1000 rekening pegawai sebuah bank besar hanya dalam waktu satu jam dengan menggunakan cara yang sama dan kemudian terlihat agak pucat. Pelayanan IT bank juga pucat, namun semuanya berakhir dengan baik dan memadai, kami bahkan dipuji karena menjadi orang pertama yang menemukan masalah ini dan memicu perbaikan yang cepat dan tegas.
Situs kedua memiliki alamat “jelas semacam nama belakang.company.ru.” Ketemu lewat Google, kira-kira seperti ini di halaman 10. Desainnya berasal dari awal pertengahan tahun XNUMXan, dan orang terhormat melihatnya dari halaman utama, kira-kira seperti ini:
Di sini saya mengambil potongan gambar dari “Heart of a Dog”, tapi percayalah, itu agak mirip, bahkan desain warnanya memiliki nada yang mirip. Biarkan situs itu dipanggil preobrazhensky.perusahaan.ru.
Itu adalah situs pribadi... untuk seorang ahli urologi. Saya bertanya-tanya apa yang dilakukan situs web ahli urologi pada subdomain perusahaan teknologi tinggi. Penggalian sekilas ke Google menunjukkan bahwa dokter ini adalah salah satu pendiri salah satu badan hukum pelanggan kami dan bahkan menyumbangkan sekitar 1000 rubel ke modal dasar. Situs ini mungkin dibuat bertahun-tahun yang lalu, dan sumber daya server pelanggan digunakan sebagai hosting. Situs ini telah lama kehilangan relevansinya, tetapi karena alasan tertentu situs ini dibiarkan berfungsi untuk waktu yang lama.
Dalam hal kerentanan, situs web itu sendiri aman. Ke depan, saya akan mengatakan bahwa itu adalah kumpulan informasi statis - halaman html sederhana dengan ilustrasi sisipan dalam bentuk ginjal dan kandung kemih. Tidak ada gunanya “merusak” situs seperti itu.
Namun server web di bawahnya lebih menarik. Dilihat dari header HTTP Server, ia memiliki IIS 6.0, yang berarti menggunakan Windows 2003 sebagai sistem operasinya. Pemindai sebelumnya telah mengidentifikasi bahwa situs web ahli urologi ini, tidak seperti host virtual lainnya di server web yang sama, merespons perintah PROPFIND, yang berarti situs tersebut menjalankan WebDAV. Omong-omong, pemindai mengembalikan informasi ini dengan tanda Info (dalam bahasa laporan pemindai, ini adalah bahaya paling rendah) - hal-hal seperti itu biasanya dilewati begitu saja. Secara kombinasi, hal ini memberikan efek menarik, yang terungkap hanya setelah penggalian lain di Google: kerentanan buffer overflow yang jarang terjadi terkait dengan kumpulan Shadow Brokers, yaitu CVE-2017-7269, yang sudah memiliki eksploitasi siap pakai. Dengan kata lain, akan ada masalah jika Anda memiliki Windows 2003 dan WebDAV berjalan di IIS. Meskipun menjalankan Windows 2003 yang diproduksi pada tahun 2018 merupakan masalah tersendiri.
Eksploitasi tersebut berakhir di Metasploit dan segera diuji dengan beban yang mengirimkan permintaan DNS ke layanan terkontrol - Burp Collaborator secara tradisional digunakan untuk menangkap permintaan DNS. Yang mengejutkan saya, ini berhasil pertama kali: sistem gugur DNS diterima. Selanjutnya, ada upaya untuk membuat koneksi balik melalui port 80 (yaitu, koneksi jaringan dari server ke penyerang, dengan akses ke cmd.exe pada host korban), tetapi kemudian terjadi kegagalan. Koneksi tidak tersambung, dan setelah upaya ketiga menggunakan situs tersebut, bersama dengan semua gambar menarik, menghilang selamanya.
Biasanya ini diikuti dengan surat bergaya “pelanggan, bangun, kami meninggalkan semuanya”. Namun kami diberitahu bahwa situs tersebut tidak ada hubungannya dengan proses bisnis dan berfungsi di sana tanpa alasan sama sekali, seperti seluruh server, dan kami dapat menggunakan sumber daya ini sesuka kami.
Sekitar sehari kemudian situs tersebut tiba-tiba mulai bekerja dengan sendirinya. Setelah membangun bangku dari WebDAV di IIS 6.0, saya menemukan bahwa pengaturan defaultnya adalah memulai ulang proses pekerja IIS setiap 30 jam. Artinya, ketika kontrol keluar dari kode shell, proses pekerja IIS berakhir, kemudian dimulai ulang sendiri beberapa kali dan kemudian istirahat selama 30 jam.
Karena koneksi balik ke tcp gagal pertama kali, saya menghubungkan masalah ini dengan port yang tertutup. Artinya, ia mengasumsikan adanya semacam firewall yang tidak mengizinkan koneksi keluar keluar. Saya mulai menjalankan kode shell yang mencari melalui banyak port tcp dan udp, tidak ada efeknya. Koneksi terbalik memuat melalui http(s) dari Metasploit tidak berfungsi - meterpreter/reverse_http(s). Tiba-tiba, koneksi ke port 80 yang sama dibuat, tetapi langsung terputus. Saya mengaitkan hal ini dengan aksi IPS yang masih imajiner, yang tidak menyukai lalu lintas meterpreter. Mengingat fakta bahwa koneksi tcp murni ke port 80 tidak berhasil, tetapi koneksi http berhasil, saya menyimpulkan bahwa proxy http entah bagaimana dikonfigurasi dalam sistem.
Saya bahkan mencoba meterpreter melalui DNS (terima kasih atas usaha Anda, menyelamatkan banyak proyek), mengingat kesuksesan pertama, tetapi itu bahkan tidak berhasil - kode shell terlalu banyak untuk kerentanan ini.
Kenyataannya terlihat seperti ini: 3-4 percobaan serangan dalam waktu 5 menit, lalu menunggu selama 30 jam. Begitu seterusnya selama tiga minggu berturut-turut. Saya bahkan mengatur pengingat agar tidak membuang waktu. Selain itu, terdapat perbedaan dalam perilaku lingkungan pengujian dan produksi: untuk kerentanan ini terdapat dua eksploitasi serupa, satu dari Metasploit, yang kedua dari Internet, dikonversi dari versi Shadow Brokers. Jadi, hanya Metasploit yang diuji dalam pertempuran, dan hanya Metasploit kedua yang diuji di bangku cadangan, yang membuat proses debug menjadi lebih sulit dan menguras otak.
Pada akhirnya, kode shell yang mengunduh file exe dari server tertentu melalui http dan meluncurkannya pada sistem target terbukti efektif. Shellcode-nya cukup kecil untuk muat, tapi setidaknya berhasil. Karena server sama sekali tidak menyukai lalu lintas TCP dan http(s) diperiksa untuk mengetahui keberadaan meterpreter, saya memutuskan bahwa cara tercepat adalah mengunduh file exe yang berisi DNS-meterpreter melalui shellcode ini.
Di sini sekali lagi masalah muncul: saat mengunduh file exe dan, seperti yang ditunjukkan oleh upaya, tidak peduli yang mana, unduhan terhenti. Sekali lagi, beberapa perangkat keamanan antara server saya dan ahli urologi tidak menyukai lalu lintas http dengan exe di dalamnya. Solusi "cepat" tampaknya adalah mengubah kode shell sehingga mengaburkan lalu lintas http dengan cepat, sehingga data biner abstrak akan ditransfer, bukan exe. Akhirnya serangan berhasil, kendali diterima melalui saluran DNS tipis:
Segera menjadi jelas bahwa saya memiliki hak alur kerja IIS yang paling dasar, yang memungkinkan saya untuk tidak melakukan apa pun. Inilah tampilannya di konsol Metasploit:
Semua metodologi pentest sangat menyarankan Anda perlu meningkatkan hak saat mendapatkan akses. Saya biasanya tidak melakukan ini secara lokal, karena akses pertama dilihat hanya sebagai titik masuk jaringan, dan menyusupi mesin lain di jaringan yang sama biasanya lebih mudah dan cepat daripada meningkatkan hak istimewa pada host yang sudah ada. Namun hal ini tidak terjadi di sini, karena saluran DNS sangat sempit dan tidak memungkinkan lalu lintas dibersihkan.
Dengan asumsi bahwa server Windows 2003 ini belum diperbaiki untuk kerentanan MS17-010 yang terkenal, saya menyalurkan lalu lintas ke port 445/TCP melalui terowongan DNS meterpreter ke localhost (ya, ini juga mungkin) dan mencoba menjalankan exe yang diunduh sebelumnya melalui kerentanan. Serangannya berhasil, saya menerima koneksi kedua, tetapi dengan hak SISTEM.
Menariknya, mereka masih mencoba melindungi server dari MS17-010 - layanan jaringan rentan dinonaktifkan pada antarmuka eksternal. Ini memang melindungi terhadap serangan melalui jaringan, namun serangan dari dalam pada localhost berhasil, karena Anda tidak bisa dengan cepat mematikan SMB di localhost.
Selanjutnya, detail baru yang menarik terungkap:
- Memiliki hak SISTEM, Anda dapat dengan mudah membuat koneksi balik melalui TCP. Jelas, menonaktifkan TCP langsung merupakan masalah bagi pengguna IIS terbatas. Spoiler: lalu lintas pengguna IIS entah bagaimana dibungkus dengan Proxy ISA lokal di kedua arah. Bagaimana tepatnya cara kerjanya, saya belum mereproduksi.
- Saya berada di "DMZ" tertentu (dan ini bukan domain Direktori Aktif, tetapi KELOMPOK KERJA) - kedengarannya logis. Namun alih-alih alamat IP pribadi (“abu-abu”) yang diharapkan, saya memiliki alamat IP yang sepenuhnya “putih”, persis sama dengan yang saya serang sebelumnya. Ini berarti bahwa perusahaan tersebut sudah sangat tua dalam dunia pengalamatan IPv4 sehingga mampu mempertahankan zona DMZ untuk 128 alamat “putih” tanpa NAT sesuai skema, seperti yang digambarkan dalam manual Cisco tahun 2005.
Karena servernya sudah lama, Mimikatz dijamin bekerja langsung dari memori:
Saya mendapatkan kata sandi administrator lokal, menyalurkan lalu lintas RDP melalui TCP dan masuk ke desktop yang nyaman. Karena saya dapat melakukan apa pun yang saya inginkan dengan server, saya menghapus antivirus dan menemukan bahwa server hanya dapat diakses dari Internet melalui port TCP 80 dan 443, dan 443 tidak sibuk. Saya menyiapkan server OpenVPN di 443, menambahkan fungsi NAT untuk lalu lintas VPN saya dan mendapatkan akses langsung ke jaringan DMZ dalam bentuk tak terbatas melalui OpenVPN saya. Patut dicatat bahwa ISA, yang memiliki beberapa fungsi IPS yang tidak dinonaktifkan, memblokir lalu lintas saya dengan pemindaian port, sehingga harus diganti dengan RRAS yang lebih sederhana dan lebih sesuai. Jadi pentester terkadang masih harus mengatur segala macam hal.
Pembaca yang penuh perhatian akan bertanya: “Bagaimana dengan situs kedua - wiki dengan otentikasi NTLM, yang sudah banyak ditulis?” Lebih lanjut tentang ini nanti.
Bagian 2. Masih belum mengenkripsi? Maka kami akan mendatangi Anda di sini
Jadi, ada akses ke segmen jaringan DMZ. Anda harus pergi ke administrator domain. Hal pertama yang terlintas dalam pikiran adalah memeriksa keamanan layanan dalam segmen DMZ secara otomatis, terutama karena lebih banyak lagi layanan yang kini terbuka untuk penelitian. Gambaran khas selama uji penetrasi: perimeter eksternal lebih terlindungi daripada layanan internal, dan ketika mendapatkan akses apa pun di dalam infrastruktur besar, jauh lebih mudah untuk mendapatkan hak yang diperluas dalam suatu domain hanya karena domain ini mulai menjadi dapat diakses oleh alat, dan kedua, Dalam infrastruktur dengan beberapa ribu host, akan selalu ada beberapa masalah kritis.
Saya mengisi daya pemindai melalui DMZ melalui terowongan OpenVPN dan menunggu. Saya membuka laporan - sekali lagi tidak ada yang serius, rupanya seseorang mengalami metode yang sama sebelum saya. Langkah selanjutnya adalah memeriksa bagaimana host dalam jaringan DMZ berkomunikasi. Untuk melakukan ini, pertama-tama luncurkan Wireshark biasa dan dengarkan permintaan siaran, terutama ARP. Paket ARP dikumpulkan sepanjang hari. Ternyata ada beberapa gateway yang digunakan di segmen ini. Ini akan berguna nantinya. Dengan menggabungkan data respons permintaan ARP dan data pemindaian port, saya menemukan titik keluar lalu lintas pengguna dari dalam jaringan lokal selain layanan yang sudah dikenal sebelumnya, seperti web dan email.
Karena saat ini saya tidak memiliki akses ke sistem lain dan tidak memiliki satu akun pun untuk layanan korporat, diputuskan untuk mengeluarkan setidaknya beberapa akun dari lalu lintas menggunakan ARP Spoofing.
Cain&Abel diluncurkan di server ahli urologi. Dengan mempertimbangkan arus lalu lintas yang teridentifikasi, pasangan yang paling menjanjikan untuk serangan man-in-the-middle dipilih, dan kemudian beberapa lalu lintas jaringan diterima melalui peluncuran jangka pendek selama 5-10 menit, dengan pengatur waktu untuk me-reboot server jika terjadi pembekuan. Seperti dalam leluconnya, ada dua berita:
- Bagus: banyak kredensial yang ditangkap dan serangan secara keseluruhan berhasil.
- Keburukannya: semua kredensial berasal dari klien pelanggan itu sendiri. Saat memberikan layanan dukungan, spesialis pelanggan terhubung ke layanan klien yang tidak selalu memiliki enkripsi lalu lintas yang dikonfigurasi.
Hasilnya, saya memperoleh banyak kredensial yang tidak berguna dalam konteks proyek, namun jelas menarik sebagai demonstrasi bahaya serangan tersebut. Router perbatasan perusahaan besar dengan telnet, meneruskan port debug http ke CRM internal dengan semua data, akses langsung ke RDP dari Windows XP di jaringan lokal dan ketidakjelasan lainnya. Ternyata seperti ini .
Saya juga menemukan kesempatan lucu untuk mengumpulkan surat dari lalu lintas, kira-kira seperti ini. Ini adalah contoh surat siap pakai yang dikirimkan dari pelanggan kami ke port SMTP kliennya, sekali lagi, tanpa enkripsi. Andrey tertentu meminta senama untuk mengirim ulang dokumentasi tersebut, dan itu diunggah ke disk cloud dengan login, kata sandi, dan tautan dalam satu surat tanggapan:
Ini adalah pengingat lain untuk mengenkripsi semua layanan. Tidak diketahui siapa dan kapan akan membaca dan menggunakan data Anda secara spesifik - penyedia, administrator sistem perusahaan lain, atau pentester semacam itu. Saya diam tentang fakta bahwa banyak orang dapat mencegat lalu lintas yang tidak terenkripsi.
Meski tampak sukses, hal ini tidak membawa kami lebih dekat ke tujuan. Tentu saja, dimungkinkan untuk duduk dalam waktu lama dan mencari informasi berharga, tetapi informasi tersebut bukanlah fakta bahwa informasi tersebut akan muncul di sana, dan serangan itu sendiri sangat berisiko dalam hal integritas jaringan.
Setelah menggali lebih dalam tentang layanan tersebut, sebuah ide menarik muncul di benak saya. Ada utilitas yang disebut Responder (contoh penggunaan dengan nama ini mudah ditemukan), yang, dengan "meracuni" permintaan siaran, memicu koneksi melalui berbagai protokol seperti SMB, HTTP, LDAP, dll. dengan cara yang berbeda, kemudian meminta setiap orang yang terhubung untuk mengautentikasi dan mengaturnya sehingga otentikasi dilakukan melalui NTLM dan dalam mode transparan bagi korban. Paling sering, penyerang mengumpulkan jabat tangan NetNTLMv2 dengan cara ini dan dari mereka, menggunakan kamus, dengan cepat memulihkan kata sandi pengguna domain. Di sini saya menginginkan sesuatu yang serupa, tetapi pengguna duduk “di balik dinding”, atau lebih tepatnya, mereka dipisahkan oleh firewall, dan mengakses WEB melalui cluster proxy Blue Coat.
Ingat, saya menentukan bahwa nama domain Direktori Aktif bertepatan dengan domain "eksternal", yaitu company.ru? Jadi, Windows, lebih tepatnya Internet Explorer (dan Edge dan Chrome), memungkinkan pengguna untuk mengautentikasi HTTP secara transparan melalui NTLM jika mereka menganggap bahwa situs tersebut terletak di beberapa “Zona Intranet”. Salah satu tanda “Intranet” adalah akses ke alamat IP “abu-abu” atau nama DNS pendek, tanpa titik. Karena mereka memiliki server dengan IP "putih" dan nama DNS preobrazhensky.company.ru, dan mesin domain biasanya menerima akhiran domain Direktori Aktif melalui DHCP untuk entri nama yang disederhanakan, mereka hanya perlu menulis URL di bilah alamat , sehingga mereka menemukan jalur yang benar ke server ahli urologi yang disusupi, tanpa lupa bahwa ini sekarang disebut “Intranet”. Artinya, sekaligus memberi saya jabat tangan NTLM pengguna tanpa sepengetahuannya. Yang tersisa hanyalah memaksa browser klien untuk memikirkan kebutuhan mendesak untuk menghubungi server ini.
Utilitas Intercepter-NG yang luar biasa datang untuk menyelamatkan (terima kasih ). Ini memungkinkan Anda untuk mengubah lalu lintas dengan cepat dan bekerja dengan baik pada Windows 2003. Bahkan memiliki fungsi terpisah untuk memodifikasi hanya file JavaScript dalam arus lalu lintas. Semacam Cross-Site Scripting besar-besaran telah direncanakan.
Proksi Blue Coat, yang digunakan pengguna untuk mengakses WEB global, secara berkala menyimpan konten statis dalam cache. Dengan mencegat lalu lintas, jelas bahwa mereka bekerja sepanjang waktu, tanpa henti meminta statis yang sering digunakan untuk mempercepat tampilan konten selama jam sibuk. Selain itu, BlueCoat memiliki Agen Pengguna tertentu, yang secara jelas membedakannya dari pengguna sebenarnya.
Javascript telah disiapkan, yang menggunakan Intercepter-NG, diimplementasikan selama satu jam di malam hari untuk setiap respons dengan file JS untuk Blue Coat. Skrip melakukan hal berikut:
- Menentukan browser saat ini berdasarkan Agen-Pengguna. Jika itu Internet Explorer, Edge atau Chrome, itu terus berfungsi.
- Saya menunggu sampai DOM halaman terbentuk.
- Memasukkan gambar yang tidak terlihat ke dalam DOM dengan atribut src pada formulir :8080/NNNNNNNN.png, dengan NNN adalah angka arbitrer sehingga BlueCoat tidak menyimpannya dalam cache.
- Tetapkan variabel tanda global untuk menunjukkan bahwa injeksi telah selesai dan tidak perlu lagi menyisipkan gambar.
Browser mencoba memuat gambar ini; pada port 8080 dari server yang dikompromikan, terowongan TCP menunggunya ke laptop saya, di mana Responder yang sama sedang berjalan, mengharuskan browser untuk masuk melalui NTLM.
Dilihat dari log Responder, orang-orang datang bekerja di pagi hari, menyalakan stasiun kerja mereka, lalu secara massal dan tanpa disadari mulai mengunjungi server ahli urologi, tidak lupa “menguras” jabat tangan NTLM. Jabat tangan menghujani sepanjang hari dan jelas mengumpulkan materi untuk serangan yang jelas berhasil memulihkan kata sandi. Seperti inilah tampilan log Responder:
Kunjungan rahasia massal ke server ahli urologi oleh pengguna
Anda mungkin telah memperhatikan bahwa keseluruhan cerita ini dibangun di atas prinsip “semuanya baik-baik saja, tetapi kemudian ada kegagalan, kemudian ada yang dapat diatasi, dan kemudian semuanya menjadi sukses.” Jadi, ada yang mengecewakan di sini. Dari lima puluh jabat tangan unik, tidak ada satu pun yang terungkap. Dan ini memperhitungkan fakta bahwa bahkan pada laptop dengan prosesor mati, jabat tangan NTLMv2 ini diproses dengan kecepatan beberapa ratus juta upaya per detik.
Saya harus mempersenjatai diri dengan teknik mutasi kata sandi, kartu video, kamus yang lebih tebal, dan menunggu. Setelah sekian lama, beberapa akun dengan kata sandi berbentuk “Q11111111....1111111q” terungkap, yang menunjukkan bahwa semua pengguna pernah dipaksa untuk membuat kata sandi yang sangat panjang dengan karakter huruf yang berbeda, yang juga seharusnya menjadi rumit. Namun Anda tidak bisa membodohi pengguna berpengalaman, dan inilah cara dia membuatnya lebih mudah untuk mengingatnya. Secara total, sekitar 5 akun telah disusupi, dan hanya satu dari akun tersebut yang memiliki hak berharga atas layanan tersebut.
Bagian 3. Roskomnadzor menyerang balik
Jadi, akun domain pertama telah diterima. Jika Anda belum tertidur sampai saat ini setelah membaca lama, Anda mungkin ingat bahwa saya menyebutkan layanan yang tidak memerlukan faktor otentikasi kedua: ini adalah wiki dengan otentikasi NTLM. Tentu saja hal pertama yang harus dilakukan adalah masuk ke sana. Menggali basis pengetahuan internal dengan cepat membuahkan hasil:
- Perusahaan memiliki jaringan WiFi dengan otentikasi menggunakan akun domain dengan akses ke jaringan lokal. Dengan kumpulan data saat ini, ini sudah menjadi vektor serangan yang berfungsi, namun Anda harus pergi ke kantor dengan berjalan kaki dan berlokasi di suatu tempat di wilayah kantor pelanggan.
- Saya menemukan instruksi yang menurutnya ada layanan yang memungkinkan... untuk secara mandiri mendaftarkan perangkat otentikasi "faktor kedua" jika pengguna berada di dalam jaringan lokal dan dengan percaya diri mengingat login dan kata sandi domainnya. Dalam hal ini, “dalam” dan “luar” ditentukan oleh aksesibilitas port layanan ini kepada pengguna. Port tersebut tidak dapat diakses dari Internet, tetapi cukup dapat diakses melalui DMZ.
Tentu saja, “faktor kedua” segera ditambahkan ke akun yang disusupi dalam bentuk aplikasi di ponsel saya. Ada sebuah program yang dapat mengirimkan permintaan push dengan keras ke telepon dengan tombol "setujui"/"tolak" untuk tindakan tersebut, atau secara diam-diam menampilkan kode OTP di layar untuk entri independen lebih lanjut. Selain itu, metode pertama dianggap oleh instruksi sebagai satu-satunya yang benar, tetapi tidak berhasil, tidak seperti metode OTP.
Dengan rusaknya “faktor kedua”, saya dapat mengakses email Outlook Web Access dan akses jarak jauh di Citrix Netscaler Gateway. Ada kejutan dalam email di Outlook:
Dalam foto langka ini Anda dapat melihat bagaimana Roskomnadzor membantu pentester
Ini adalah bulan-bulan pertama setelah pemblokiran “penggemar” Telegram yang terkenal, ketika seluruh jaringan dengan ribuan alamat menghilang dari akses. Menjadi jelas mengapa push tidak langsung berhasil dan mengapa “korban” saya tidak membunyikan alarm karena mereka mulai menggunakan akunnya selama jam buka.
Siapa pun yang akrab dengan Citrix Netscaler membayangkan bahwa itu biasanya diimplementasikan sedemikian rupa sehingga hanya antarmuka gambar yang dapat disampaikan kepada pengguna, berusaha untuk tidak memberinya alat untuk meluncurkan aplikasi pihak ketiga dan mentransfer data, membatasi tindakan dengan segala cara yang mungkin. melalui shell kontrol standar. “Korban” saya, karena pekerjaannya, hanya mendapat 1C:
Setelah menjelajahi sedikit antarmuka 1C, saya menemukan ada modul pemrosesan eksternal di sana. Mereka dapat dimuat dari antarmuka, dan akan dijalankan di klien atau server, tergantung pada hak dan pengaturan.
Saya meminta teman programmer 1C saya untuk membuat pemrosesan yang akan menerima string dan menjalankannya. Dalam bahasa 1C, memulai suatu proses terlihat seperti ini (diambil dari Internet). Apakah Anda setuju bahwa sintaksis bahasa 1C memukau orang-orang berbahasa Rusia dengan spontanitasnya?
Pemrosesan dijalankan dengan sempurna; ternyata apa yang disebut oleh para pentester sebagai "shell" - Internet Explorer diluncurkan melaluinya.
Sebelumnya, alamat sistem yang memungkinkan Anda memesan tiket masuk ke wilayah tersebut ditemukan melalui pos. Saya memesan pass jika saya harus menggunakan vektor serangan WiFi.
Ada pembicaraan di Internet bahwa masih ada katering gratis yang enak di kantor pelanggan, tapi saya masih lebih suka mengembangkan serangan dari jarak jauh, lebih tenang.
AppLocker diaktifkan di server aplikasi yang menjalankan Citrix, tapi dilewati. Meterpreter yang sama dimuat dan diluncurkan melalui DNS, karena versi http(s) tidak ingin terhubung, dan saya tidak mengetahui alamat proxy internal pada saat itu. Ngomong-ngomong, mulai saat ini, pentest eksternal pada dasarnya berubah menjadi internal.
Bagian 4. Hak admin untuk pengguna buruk ya?
Tugas pertama seorang pentester ketika mendapatkan kendali atas sesi pengguna domain adalah mengumpulkan semua informasi tentang hak dalam domain. Ada utilitas BloodHound yang secara otomatis memungkinkan Anda mengunduh informasi tentang pengguna, komputer, grup keamanan melalui protokol LDAP dari pengontrol domain, dan melalui SMB - informasi tentang pengguna mana yang baru saja masuk, di mana dan siapa administrator lokalnya.
Teknik tipikal untuk mendapatkan hak administrator domain terlihat disederhanakan sebagai siklus tindakan yang monoton:
- Kami pergi ke komputer domain di mana terdapat hak administrator lokal, berdasarkan akun domain yang sudah diambil.
- Kami meluncurkan Mimikatz dan mendapatkan kata sandi cache, tiket Kerberos, dan hash NTLM dari akun domain yang baru saja masuk ke sistem ini. Atau kami menghapus gambar memori dari proses lsass.exe dan melakukan hal yang sama di pihak kami. Ini berfungsi baik dengan Windows yang lebih muda dari 2012R2/Windows 8.1 dengan pengaturan default.
- Kami menentukan di mana akun yang disusupi memiliki hak administrator lokal. Kami mengulangi poin pertama. Pada tahap tertentu kami mendapatkan hak administrator untuk seluruh domain.
“End of the Cycle;”, seperti yang ditulis oleh programmer 1C di sini.
Jadi, pengguna kami ternyata adalah administrator lokal di satu host dengan Windows 7, yang namanya menyertakan kata "VDI", atau "Virtual Desktop Infrastructure", mesin virtual pribadi. Mungkin maksud perancang layanan VDI adalah karena VDI adalah sistem operasi pribadi pengguna, meskipun pengguna mengubah lingkungan perangkat lunak sesuai keinginannya, host masih dapat "dimuat ulang". Saya juga berpikir bahwa secara umum idenya bagus, saya pergi ke host VDI pribadi ini dan membuat sarang di sana:
- Saya memasang klien OpenVPN di sana, yang membuat terowongan melalui Internet ke server saya. Klien harus dipaksa melalui Blue Coat yang sama dengan autentikasi domain, namun OpenVPN melakukannya, seperti yang mereka katakan, “out of the box.”
- Menginstal OpenSSH di VDI. Sebenarnya apa jadinya Windows 7 tanpa SSH?
Ini adalah apa yang tampak seperti siaran langsung. Izinkan saya mengingatkan Anda bahwa semua ini harus dilakukan melalui Citrix dan 1C:
Salah satu teknik untuk mempromosikan akses ke komputer tetangga adalah dengan memeriksa kecocokan kata sandi administrator lokal. Di sini keberuntungan segera menunggu: hash NTLM dari administrator lokal default (yang tiba-tiba disebut Administrator) didekati melalui serangan pass-the-hash ke host VDI tetangga, yang jumlahnya beberapa ratus. Tentu saja serangan itu langsung menimpa mereka.
Di sinilah administrator VDI menembak dirinya sendiri sebanyak dua kali:
- Pertama kali adalah ketika mesin VDI tidak dibawa ke dalam LAPS, pada dasarnya mempertahankan kata sandi administrator lokal yang sama dari gambar yang disebarkan secara besar-besaran ke VDI.
- Administrator default adalah satu-satunya akun lokal yang rentan terhadap serangan pass-the-hash. Bahkan dengan kata sandi yang sama, kompromi massal dapat dihindari dengan membuat akun administrator lokal kedua dengan kata sandi acak yang rumit dan memblokir kata sandi default.
Mengapa ada layanan SSH di Windows itu? Sangat sederhana: sekarang server OpenSSH tidak hanya menyediakan shell perintah interaktif yang nyaman tanpa mengganggu pekerjaan pengguna, tetapi juga proxy kaus kaki5 di VDI. Melalui kaus kaki ini, saya terhubung melalui SMB dan mengumpulkan akun cache dari ratusan mesin VDI ini, kemudian mencari jalur ke administrator domain yang menggunakannya dalam grafik BloodHound. Dengan ratusan host yang saya miliki, saya menemukan cara ini dengan cukup cepat. Hak administrator domain telah diperoleh.
Berikut adalah gambar dari Internet yang menunjukkan pencarian serupa. Koneksi menunjukkan siapa administrator di mana dan siapa yang login di mana.
Ngomong-ngomong, ingat kondisi sejak awal proyek - “jangan gunakan rekayasa sosial”. Jadi, saya mengusulkan untuk memikirkan seberapa besar semua Bollywood dengan efek khusus ini akan terpotong jika masih memungkinkan untuk menggunakan phishing dangkal. Tapi secara pribadi, sangat menarik bagi saya untuk melakukan semua ini. Saya harap Anda menikmati membaca ini. Tentu saja, tidak setiap proyek terlihat begitu menarik, namun pekerjaan secara keseluruhan sangat menantang dan tidak membiarkannya mandek.
Mungkin seseorang akan bertanya: bagaimana cara melindungi diri sendiri? Bahkan artikel ini menjelaskan banyak teknik, yang banyak di antaranya bahkan tidak diketahui oleh administrator Windows. Namun, saya mengusulkan untuk melihatnya dari sudut pandang prinsip-prinsip usang dan langkah-langkah keamanan informasi:
- jangan gunakan perangkat lunak yang ketinggalan jaman (ingat Windows 2003 di awal?)
- jangan biarkan sistem yang tidak diperlukan tetap menyala (mengapa ada situs web ahli urologi?)
- periksa sendiri kekuatan kata sandi pengguna (jika tidak, tentara... pentester akan melakukan ini)
- tidak memiliki kata sandi yang sama untuk akun yang berbeda (kompromi VDI)
- dan lainnya
Tentu saja, hal ini sangat sulit untuk diterapkan, tetapi pada artikel berikutnya kami akan menunjukkan dalam praktiknya bahwa hal ini sangat mungkin dilakukan.
Sumber: www.habr.com