Konferensi DEFCON 20. Ambil dalam 60 detik: dari akun tamu hingga administrator domain Windows. Bagian 1

Hai, saya Zach Feysel, saya akan berbicara dengan cepat, jika terlalu cepat, Anda dapat memperlambat saya. Pada siang hari, saya seorang pentester, pada malam hari saya seorang DJ dan fotografer, saya dapat ditemukan di Twitter menggunakan nama panggilan @zfazel. Orang-orang selalu bertanya padaku tentang ijazah. Saya bukan salah satu dari orang-orang yang mendaftar beberapa derajat, jadi sebaiknya Anda menilai saya berdasarkan presentasi ini, dan bukan berdasarkan jumlah sertifikat yang saya miliki.



Sebuah komentar tanpa malu-malu: kita memiliki sedikit kompetisi di sini, saat ini orang-orang dari Chicago berada di jalur 4, kita semua dari Chicago, dengan cepat angkat tangan yang ada di sini dari Chicago. Jadi, saya pikir saya kehilangan taruhan. Saya akan menjadi DJ malam ini di kolam renang, jadi jika Anda bebas, selamat datang ke pertempuran dengan Kate Myers, setelah itu saya akan kembali ke Chicago untuk konferensi hacker lain. Tahun lalu, 500 orang hadir, tahun ini kami berharap akan ada lebih banyak tamu. 312 orang saya juga akan ada di sana, informasi lebih lanjut tentang konferensi ini dapat ditemukan di thotcon.org.

Jadi, agar tidak membuang waktu: kita akan berbicara tentang alternatif untuk serangan Pass-the-hash yang disebut NTLM-Relay, tentang seperangkat alat baru untuk antar-protokol Cross Protocol Relaying transmisi untuk permintaan otentikasi NTLM, tentang metode baru otentikasi klien otomatis dan tentang baru tujuan yang dapat Anda gunakan Pass-the-hash.
Mari kita mulai dengan NTLM, bagi mereka yang tidak tahu apa itu NTLM 101, keseluruhan poin dapat dinyatakan dalam waktu kurang dari 10 menit. Jadi apa itu LM / NTLM? Ini adalah repositori kata sandi dan protokol otentikasi jaringan yang dikembangkan oleh Microsoft untuk digunakan pada Windows. Sial, slide-slide saya rusak! Jadi, hash LM adalah format untuk menyimpan kata sandi pengguna yang panjangnya kurang dari 15 karakter, kata sandi dibagi menjadi 2 bagian dari 7 byte dan dikonversi ke huruf besar. Saya harap Anda bisa melihat seperti apa hash LM dan NTLM. Saya tidak akan membuang waktu untuk mengatakan betapa buruk dan lemahnya LM, Anda semua tahu ini, dan jika tidak, google saja.



Hash NTLM biasanya case sensitif, memiliki panjang tidak terbatas, tidak dibagi menjadi kelompok karakter, dan sedikit lebih kuat dari LM, tetapi juga bukan tanpa masalah. Sekarang saya akan berbicara tentang mereka. Kerentanan pertama adalah kemungkinan serangan Pass-the-hash, yang memungkinkan hacker untuk masuk ke server jauh yang menggunakan otentikasi klien berdasarkan protokol NTLM / LM. Maaf, teman-teman, saya mencampur slide, saya membuatnya 5 menit yang lalu, singkatnya, LM payah.

Jadi apa otentikasi NTLM? Ini adalah otentikasi jaringan untuk layanan jarak jauh. Dia diperlukan untuk membuktikan bahwa Anda benar-benar panggilan Anda sendiri. Layanan ini biasanya berjalan di komputer terpisah, di mana Anda ingin mengakses sumber daya yang ditawarkan oleh layanan, misalnya, file server adalah layanan, dan file adalah sumber daya. Sebentar lagi kita akan melihat apa layanan ini.

Kita dapat menjadi bingung ketika kita berbicara tentang NTLM v1, v2, NTLM 2, apakah ditandatangani atau tidak, jadi mari kita cepat pergi ke otentikasi NTLM. Selama otentikasi, 3 jenis pesan dikirim.



Tipe 1 adalah permintaan klien ke server untuk membuat kontak, sesuatu seperti "Saya ingin mengotentikasi". Anda melihat paket diambil berkeping-keping, ditangkap oleh Wireshark, ada bendera untuk mendukung otentikasi, nama workstation dan nama domainnya.

Pesan tipe 2 adalah respons server. Jika Anda perhatikan dari pesan Tipe 1 yang belum kami ketahui siapa pengguna ini, ia hanya meminta untuk terhubung ke server dan ingin mencari tahu apakah permintaan tersebut didukung.



Anda lihat di sini respons server NTML Challenge sebagai sekumpulan angka yang berubah setiap saat. Tangkapan layar menunjukkan jawaban statis yang dapat digunakan untuk membuat "tabel pelangi". Jadi, server merespons dengan pesan dari tipe kedua: "ini yang saya dukung, ini nama domain saya, ini nama server saya". Jawaban ini digunakan untuk "memberi garam" hash kata sandi Anda, jadi setiap kali jawaban unik diperoleh, dan Anda tidak dapat mengulanginya lagi dan lagi dengan permintaan yang sama.

Pesan Tipe 3 - ini adalah pesan otentikasi klien.



Ini adalah respons dari server, yang di hash dengan hash kata sandi untuk hash NTML bersama dengan nama pengguna, nama workstation dan nama domain dan kunci sesi, jika Anda menandatangani sesi.

Ini adalah apa itu NTML versi 1. NTML versi 2 sangat mirip dengan itu, tetapi ada menambahkan parameter tambahan dalam kata sandi respons dan memanggil klien untuk melindungi terhadap penggunaan "tabel pelangi", yaitu, klien menggunakan elemen keacakan terhadap mereka.

Hal lain yang perlu kita bicarakan adalah otentikasi Windows terintegrasi. Diperlukan agar setiap kali Anda tidak harus memasukkan kembali sistem dengan kata sandi untuk menggunakan sumber daya dan layanan. Jika Anda terhubung ke server domain atau server web internal, Windows tidak meminta Anda untuk memasukkan kata sandi, itu hanya meminta API dan menerima informasi dari itu bahwa sistem harus digunakan untuk otentikasi.
Dalam konteks keamanan lokal, HTTP melindungi dengan menggunakan zona keamanan tepercaya, situs tepercaya, atau situs lokal dengan hanya memeriksa nama domain satu kata. Saya akan mencoba menyegarkan ingatan Anda dengan cepat. Satu kata domain pertama mencari nama DNS di server DNS, kemudian memeriksa host atau nama host DNS dan mengembalikannya. Ia memeriksa struktur nama lengkap Anda dan kemudian melakukan NBNS, yang merupakan permintaan siaran untuk nama domain ini. Bahkan, ia bertanya kepada jaringan: "Hei, saya mencari nama , apakah Anda kenal seseorang dengan nama itu?", Mendistribusikan permintaan ini melalui jaringan lokal dalam mode siaran multimedia MBNS.

Seperti yang saya katakan, karena kami menggunakan protokol SMB di mana-mana, tidak ada batasan, kami hanya memiliki autentikasi otomatis menggunakan SMB. Ini menyebabkan beberapa masalah.

Pertimbangkan metode Pass-the-hash. Dapat dilihat dari protokol bahwa NTML tidak menggunakan kata sandi asli untuk otentikasi, jadi yang kita butuhkan adalah hash NTML itu sendiri. Kita dapat mengakses hash NTML menggunakan berbagai alat Windows, yaitu, tarik hash ini dari penyimpanan lokal atau dari memori. Semua ini dijelaskan dalam pidato lain, saya akan segera mengingatkan Anda tentang esensi masalah ini untuk menunjukkan perbedaan antara kedua metode.
Faktanya adalah bahwa biasanya untuk Pass-the-hash ini Anda memerlukan akses di tingkat administrator sistem lokal, karena dengan akun tamu Anda tidak akan mendapatkan akses ke penyimpanan lokal atau memori lokal.

Jadi, apa itu NTLM Relaying dan apa bedanya dengan metode Pass-the-hash? Mereka terus-menerus memberi tahu saya: "Ah, Anda berbicara tentang Pass-the-hash!", Dan saya menjawab: "Tidak, saya berbicara tentang NTLM Relaying!". Perbedaannya adalah bahwa NTLM Relaying tidak memerlukan hak administrator untuk mengakses jaringan atau sistem. Bahkan, Anda terhubung ke jaringan dari dalam atau luar dan mulai bekerja sebagai tamu. Tidak ada kredensial, tidak ada akses ke sistem, hanya permintaan yang dikonfirmasi jika Anda kembali ke jenis pesan 1,2,3 di atas. Tidak ada verifikasi ketika tuan rumah menanggapi permintaan Anda dan memastikan bahwa Anda adalah Anda.
Apa yang kami lakukan adalah membuat server penipuan untuk menerima permintaan otentikasi dan kemudian menyampaikannya ke server target.

Mari kita dengarkan ceritanya sehingga Anda memahami inti dari masalah ini. Kembali pada tahun 1996, ketika Dominic Brezinsky menemukan kerentanan dalam proses otentikasi menggunakan protokol akses CIFS, versi pertama dari protokol SMB. Setelah itu, mereka pertama kali berbicara tentang kemungkinan menggunakan NTLM Relay. Pada tahun 2001, NTLM berhasil menemukan lubang di SMB. Pertama, karyawan Veracode Christian Ryu (alias Dildog) mengatakan ini di konferensi DefCon, dan kemudian peretas Josh Bushbinder (alias Sir Dystic) menerbitkan kode eksploit yang bekerja dengan kerentanan ini. Kami menggunakan protokol Telnet dan kerentanan browser IE, di mana Anda bisa mengetikkan telnet: // ip dan secara otomatis mengautentikasi.



Setelah itu, metode NTLM Relaying mulai digunakan untuk mengarahkan permintaan SMB ke host lain atau ke host sendiri. Ini berlanjut sampai November 2008, ketika Microsoft Windows menambal lubang di mana mereka bisa, mencegah permintaan otentikasi NTLM kembali dengan patch MS08-068.

Jadi, kami kehilangan kemampuan untuk mengembalikan permintaan otentikasi ke host kami dan hanya bisa meneruskannya ke host lain karena fitur desain protokol. Pada tahun 2008, seorang pria dengan nama panggilan Grutz membuat pernyataan tentang kematian DefLon NTLM. Saya pikir ini adalah salah satu pertunjukan terbaik dalam beberapa tahun terakhir, karena memiliki dampak besar pada lingkungan perusahaan.



Dia menyebut instrumennya nama Pokemon Squirtle, dan teknologi - "monyet di tengah" dengan analogi dengan "manusia di tengah". Alat ini memungkinkan Relay NTLM untuk dieksekusi melalui HTTP dan juga bekerja dengan baik dengan SMB, menerima permintaan otentikasi.



Tangkapan layar ini diambil dua hari lalu, dan pengembangan aplikasi Squirtle-nya masih berlangsung. Saya memutuskan bahwa Anda semua akrab dengan kerentanan ini, masalah yang sedang kita bicarakan berulang-ulang, karena mereka tidak dapat diperbaiki dengan cara apa pun dan memanifestasikan diri di mana-mana. Saya termasuk dalam lingkungan perusahaan, oleh karena itu saya menyadari masalah yang terus saya keluhkan - bahwa situs tidak melakukan enkripsi SSL permintaan otentikasi, sama seperti mereka tidak mengenkripsi cookie mereka. Pada 2010, ekstensi browser Firefox bernama Firesheep dirilis.

Anda mungkin akrab dengan alat ini untuk mencegat cookie HTTP tidak terenkripsi dari situs web populer dan sesi lain dari bekerja dengan situs melalui Wi-Fi atau jaringan mengendus, menyamar sebagai pengguna lain.



Saya bertanya pada diri sendiri, dari mana orang mendapat dorongan untuk membuat alat seperti itu. Ternyata itu semua tentang kemudahan penggunaan. Cukup mudah untuk membuat aplikasi yang memungkinkan Anda menyamar sebagai orang lain. Jadi saya memutuskan untuk memulai dari yang sama dan membuat aplikasi yang akan memungkinkan menggunakan metode Relay NTLM untuk menunjukkan kepada orang-orang bahwa itu sesederhana Firesheep.



Saya mulai mengerjakan Relay NTLM untuk melihat bagaimana dukungan multi-protokol dimungkinkan. Banyak orang berbicara tentang kemungkinan teoretis dari dukungan semacam itu, tetapi tidak ada yang mempraktikkannya. Jadi, tujuan saya adalah membuat Firesheep untuk NTLM.
Saya memutuskan untuk mulai belajar Ruby karena pada awalnya saya akan mengintegrasikan exploit saya ke Metasploit. Pada 2012, saya ingin membahas topik ini di konferensi Black Hat dan DefCon, tetapi laporan saya ditolak. Pidato saya tidak hanya ditolak, saya menerima email palsu bahwa DefCon menerima laporan saya. Seorang teman berpikir akan sangat lucu untuk menjebak saya, dia benar-benar idiot. Dia punya teman di sini yang kinerjanya disetujui, dan teman saya mengambil dan mengirimi saya isi emailnya. Saya tidak memperhatikan tajuk, yang bertuliskan "Dari Nikita" dan panik, menyadari bahwa saya harus berbicara di DefCon dalam satu setengah jam, tetapi kemudian saya menerima surat nyata dengan penolakan.

Apakah Anda pikir ini mengakhiri ceritanya? Tidak, tiga minggu kemudian Nikita memberi tahu saya: "hei, kita ada pembukaan pada hari Minggu, seseorang menolak untuk berpartisipasi, apakah Anda ingin berbicara di tempatnya?" Saya pikir itu baik-baik saja, tetapi kemudian saya menyadari bahwa saya memiliki waktu yang sangat sedikit sebelum pertunjukan, dan mulai membuat kode seperti orang gila, mencoba menyelesaikan semuanya tepat waktu.

Jadi apa masalah saya? Pertama, alat asing tidak dapat melakukan pekerjaan Pentester yang saya butuhkan, mereka sangat kekurangan berbagai protokol yang dapat mengembalikan permintaan otentikasi. Sebagian besar protokol terkait dengan penggunaan SMB dan HTTP, dan tidak ada satupun yang mendukung LDAP untuk otentikasi MySQL, atau setidaknya menguji remote desktop, VPN, dan sejenisnya.

Masalah lain adalah mereka semua meneruskan setiap permintaan ke tujuan yang sama. Artinya, kami menerima data pengguna, akun komputer, dan mengirim semua otentikasi ke satu tujuan, oleh karena itu, kami tidak dapat mengidentifikasi pengguna sebelum otentikasi, yaitu, sebelum menerima pesan Tipe 3. Jika Anda mengingat pesan-pesan ini dari tipe 1,2,3, maka pesan dari Tipe 2 adalah respons dari server. Ini unik untuk setiap sesi, dan saya tidak tahu siapa pengguna ini sampai mereka mengirim pesan Tipe 3 terakhir, dan saya tidak tahu jawaban mana dan dari server mana pengguna itu. Saya tertarik pada mengapa tidak ada alat yang akan melakukan ini, jadi saya melihat lebih dekat pada protokol seperti SMB dan HTTP, nanti kita akan membicarakan hal ini lebih detail.

Windows 8 dan Windows 2012 masih mendukung NTLM secara default. Ini menakutkan karena kita tahu tentang kerentanan protokol-protokol ini, tetapi NTLM belum hilang. Karena itu, kami, sebagai pentester, memberi tahu organisasi bahwa mereka harus melindungi diri dari serangan semacam itu.
Jadi, saya ingin menyelesaikan masalah ini dan membuat alat bernama ZackAttack. Saya tahu itu terlihat jelek, tapi kami melewati banyak nama, saya pribadi paling suka yang terakhir - “NTLMv2? Jalang Tolong ... ".



Apa yang terkandung dalam alat ini? Saya akan dengan cepat membahas slide ini, karena saya pikir Anda sudah cukup terhibur. Zacktttt terdiri dari beberapa komponen yang berbeda, kita akan berbicara tentang masing-masing komponen dan bagaimana mereka terkait satu sama lain.

Pertama-tama, ada server HTTP SMB - ini adalah server penipuan yang menerima permintaan otentikasi. Jadi klien menargetkan server ini, mengautentikasi, dan server membuat mereka tetap diautentikasi. Selanjutnya, kami memiliki seperangkat aturan untuk operasi otomatis.

Kami memiliki klien untuk eksploitasi otomatis semacam itu, serta API yang dapat kami asosiasikan dengan aplikasi pihak ketiga mana pun yang mentransfer permintaan Relay NTLM.



Akhirnya, kami memiliki generasi muatan yang memaksa pelanggan untuk mengotentikasi kami secara otomatis.

Apa itu server penipuan? Pertama, mereka mengotentikasi pengguna dan menyimpannya untuk kami, kemudian saya akan memberi tahu Anda bagaimana kami menggunakannya.



Kami membutuhkan semua orang ini untuk mempertahankan status otentikasi mereka. Ada banyak alat yang menonaktifkan pengguna setelah otentikasi pertama yang berhasil, tetapi alat ZackAttack kami membuat pengguna diautentikasi selama mungkin. Pada Windows LAN untuk SMB, ini sekitar 30 kali sebelum koneksi terputus. Jadi, kita perlu mencari tahu siapa pengguna ini, sambil tetap mengotentikasi dia.

Permintaan otentikasi pertama adalah panggilan statis tipe 112233. Anda yang terlibat dalam pentesting tahu bahwa ini adalah jenis tugas untuk "tabel pelangi". Seperti yang saya katakan, kita perlu mencari tahu siapa pengguna ini, tetapi kita tidak mengetahuinya, sampai kita sampai pada pesan Tipe 3, jadi kami mengirim banyak panggilan. Saya menyebutnya "elemen Alzheimer" ketika sistem lupa siapa pengguna itu dan memintanya untuk mengotentikasi setiap kali terhubung tanpa menutup sesi.

Alasan mengapa kami melakukan ini adalah karena HTTP, WPAD, dan permintaan lainnya tidak selalu mendukung cookie, selain itu, identifikasi SMB melalui IP atau port sumber Source Port tidak berfungsi jika Anda mencoba melakukannya dari jarak jauh melalui Internet.

Oleh karena itu, untuk server HTTP, kami menggunakan 302 redirect dengan parameter Keep-Alive, yang memungkinkan kami untuk menjaga sesi tetap terbuka saat soket ditutup, dan setelah kami mengautentikasi, kami tahu siapa mereka dan kami tahu ini sampai akhir sesi ini.

Dengan SMB itu lebih sulit, saya harus menulis server SMB kustom, itu agak buggy, tetapi tetap bekerja. Saya tidak akan menyelidiki mekanisme otentikasi protokol SMB, karena akan memakan waktu beberapa jam, jadi saya akan menjelaskan secara singkat. Setelah server menerima permintaan otentikasi, sepertinya lupa siapa pengguna ini dan berkata: "Oh, halo, senang bertemu dengan Anda!" "Keren, aku ingin terhubung!" "Tunggu, dan siapa kamu?" Dan sekali lagi membutuhkan permintaan otentikasi.

Jadi, kita perlu menerima permintaan otentikasi yang datang ke server HTTP dan SMB. Banyak orang bertanya bagaimana kita melakukan serangan "pria di tengah". Ada beberapa cara berbeda untuk membuat orang mengautentikasi dengan server kami, dan kemudian mengirim mereka untuk melakukan hal-hal lain. Karena itu, pertimbangkan berapa muatan dalam alat kami.

Pertama-tama, ini adalah WPAD - protokol untuk konfigurasi proxy otomatis, yang memungkinkan Anda untuk menentukan lokasi file konfigurasi. Di Windows, ketika Anda mencoba untuk terhubung, seperti yang Anda tahu, sebuah jendela muncul dengan tanda centang kecil "secara otomatis menemukan pengaturan koneksi saya" yang mengaktifkan WPAD. Protokol ini mengirimkan permintaan untuk memeriksa DNS dan siaran jaringan, sehingga Anda dapat memalsukan permintaan ini dan menanggapinya.

Secara default, di Windows, komputer akan secara otomatis mengotentikasi server WPAD melalui HTTP dengan kredensial pengguna saat ini.

18:00 mnt

Konferensi DEFCON 20. Ambil dalam 60 detik: dari akun tamu hingga administrator domain Windows. Bagian 2



Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikannya kepada teman-teman Anda, diskon 30% untuk pengguna Habr pada analog unik dari server entry-level yang kami temukan untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps dari $ 20 atau bagaimana membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps hingga musim semi gratis ketika membayar selama setengah tahun, Anda dapat memesan di sini .

Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV dari $ 249 di Belanda dan Amerika Serikat! Baca tentang Cara Membangun Infrastruktur kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?

Source: https://habr.com/ru/post/id436472/


All Articles