Nama saya Rob Stackle, saya seorang konsultan keamanan dari Phoenix, Arizona, dan saya terutama bekerja sebagai pentester. Saya telah berpartisipasi dalam konferensi DefCon sejak 1996, saya menyukai fotografi ketinggian tinggi, dan akhir pekan ini adalah ulang tahun pernikahan kami yang kesebelas. Saya ingin berterima kasih kepada istri saya yang luar biasa dan pengertian Linda, yang tidak berharap bahwa partisipasi saya di DefCon berarti bahwa setiap tahun saya akan dipaksa untuk merayakan ulang tahun pernikahan kami di Vegas, yang saya minta maaf.
Saya akan berbicara dengan Anda tentang beberapa hal yang berkaitan dengan penelitian yang telah saya kerjakan selama beberapa tahun terakhir. Mereka disatukan oleh tema umum - jika Anda tidak memantau lalu lintas DNS Anda dan tidak mengerti apa yang terjadi di sana, ketika semuanya beres, maka Anda mungkin tidak akan memperhatikan ketika hal-hal buruk mulai terjadi padanya. Saya "memperkosa" DNS selama beberapa tahun dan ini selalu menjadi salah satu vektor serangan favorit saya. Anda dapat menghabiskan banyak uang untuk memperkuat perimeter jaringan, tetapi jika saya bisa mengendalikan salah satu perangkat Anda, percayalah, permainan Anda sudah berakhir.
Tidak adanya kerentanan di pasar untuk mendeteksi konfigurasi yang salah selalu memberi saya kesempatan untuk "menginjakkan kaki." Hari ini kita akan membahas berbagai topik di mana saya akan berbicara tentang petualangan saya dengan DNS dan trik saya pada orang-orang yang terkait dengan DNS.
Topik-topik ini ditujukan untuk salah memahami perilaku DNS oleh pengguna akhir jaringan, saya akan berbicara sedikit tentang orang-orang yang belum mendaftarkan domain mereka, dan tentang peretasan domain itu sendiri.
Pada konferensi Black Hat dan DefCon pada tahun 2011, Artyom Daineberg berbicara tentang apa yang disebutnya jongkok ketukan, atau "membalik ketukan." Mereka yang tidak terbiasa dengan penelitian ini, tetapi yang tertarik dengan masalah ini dalam DNS domain populer, dapat mengunduh materi presentasinya menggunakan tautan yang disediakan pada slide ini.
Halaman Proyek /
Presentasi /
Slide VideoKetika saya membaca pengumuman pidatonya, yang diterbitkan bahkan sebelum laporan tentang Black Hat, saya langsung tertarik pada bagaimana ini dapat digunakan untuk tujuan saya sendiri. Tanpa merinci, saya akan menjelaskan apa itu beat squatting, mengapa itu terjadi dan apa pengaruhnya. Saya akan menunjukkan kepada Anda beberapa contoh risiko flipping secara tidak sengaja dalam memori ketika 1 berubah menjadi 0 dan sebaliknya. Slide berikut menunjukkan bagaimana ini terlihat seperti contoh garis dalam memori yang menampilkan nama domain.
Di tengah garis seperti itu, unit berubah menjadi nol. Artyom menyelidiki fenomena di mana kesalahan bit tunggal di bagian memori yang benar pada waktu yang tepat memaksa klien untuk meminta nama domain yang benar-benar sah tetapi salah.
Ada banyak pembicaraan tentang kemungkinan dan penyebab kesalahan seperti itu, tetapi saya mulai mempelajari semua cara yang memungkinkan kesalahan ini digunakan untuk tujuan jahat. Jadi, jongkok DNS memungkinkan Anda mendistorsi nama domain, lalu mendaftarkan domain "salah" ini dan mengirimkan permintaan pengguna kepada mereka.
Slide berikut menunjukkan bahwa sebagai hasil jongkok dari nama domain Google, ketika proton berenergi tinggi dalam "hit" 1, yang berarti huruf g, mengubahnya menjadi 0, artinya huruf f, dan sebagai hasilnya, pengguna diarahkan ke goofle.com .
Jadi, browser Anda akan sepenuhnya mengarahkan Anda ke situs lain dan dengan senang hati akan mengambil jawabannya untuk Anda. Pada saat yang sama, DNS SEC tidak akan dapat membantu Anda dengan cara apa pun, dan pada kenyataannya ada sangat sedikit peluang untuk mencegah kesalahan ini dengan cara yang sama sekali tidak terlihat, kecuali untuk menggunakan memori ECC, yang secara otomatis mengenali dan memperbaiki kesalahan bit.
Namun, jenis memori ini tidak terlalu umum, dan bahkan jika Anda menggunakan ECC, masih ada banyak tempat di mana jongkok bit dapat terjadi dan di mana memori ECC tidak pernah digunakan, misalnya, dalam kartu jaringan atau dalam cache DRAM dari hard disk.
Deineberg menjelaskan secara rinci penyebab masalahnya, tetapi secara umum dapat dikatakan bahwa kesalahan memori terjadi, kadang-kadang merusak memori dan kadang-kadang memiliki efek pada DNS. Pada dasarnya, "flipping" dari sedikit disebabkan oleh kerusakan fisik pada memori, terlalu panas, masalah listrik, paparan radiasi dan bahkan radiasi kosmik.
Presentasi terganggu oleh penampilan di panggung penyelenggara DefCon, yang memberi selamat kepada pembicara dan istrinya Linda, yang hadir di konferensi untuk pertama kalinya, pada ulang tahun pernikahan kesebelas. Robert mengucapkan terima kasih atas ucapan selamat dan melanjutkan presentasi.
Radiasi kosmik adalah faktor yang sangat langka yang mempengaruhi jongkok bit, tetapi terlalu panas adalah penyebab yang sangat umum dari kesalahan memori. Saya perhatikan bahwa smartphone sangat rentan karena kondisi operasi yang ekstrem di mana mereka terpapar. Terlalu panas baterai smartphone adalah kejadian yang cukup umum. Sebagian besar perangkat lain memiliki pendinginan, tetapi bahkan mereka berhasil menciptakan kondisi operasi yang sulit.
Belum lama ini, Google menerbitkan informasi tentang pekerjaan pusat datanya. Salah satu hal menarik yang saya pelajari adalah pesan bahwa, untuk menghemat energi, mereka mengoperasikan pusat data mereka dalam kondisi yang sebagian besar dari kita anggap tidak masuk akal. Jika pusat data biasa beroperasi pada suhu maksimum 60-70 derajat Fahrenheit (15-20 ° C), maka pakar Google merekomendasikan perusahaan untuk mengoperasikan pusat data pada suhu setidaknya 80 derajat (27 ° C), dan satu pusat data Belgia Google mengoperasikan servernya pada suhu 95 derajat (35 ° C).
Keterangan: "Saya mendengar bahwa itu menghemat uang bagi kita."
Intel dan Microsoft mengklaim bahwa server mereka berperilaku baik pada suhu tinggi, dan Dell menjamin bahwa server mereka akan berjalan pada suhu 46 derajat Celsius. Saya pikir ini adalah ide yang buruk, karena suhu adalah faktor utama dalam memastikan operasi memori yang stabil, dan pusat data Google beroperasi pada suhu "api".
Saya mulai mempelajari keuntungan apa yang bisa diberikan ini dan domain mana yang paling rentan terhadap jongkok, yaitu, saya mencoba mencari nama yang paling sering diminta untuk meningkatkan kemungkinan bahwa saya akan menghadapi kesalahan seperti itu. Saya mulai mengumpulkan log DNS dari perusahaan besar untuk menemukan nama domain yang paling umum dan menemukan bahwa nama yang paling banyak diminta adalah gstatic.com. Ini adalah salah satu domain yang disediakan Google untuk memberikan informasi statis seperti file CSS, gambar, JavaScript, dan XML.
Saya menulis sebuah skrip untuk mengidentifikasi kemungkinan "pergolakan" bit dalam nama domain gstatic.com ini, dan saya mendapat daftar semua variasi nama ini dalam jumlah 34 buah. Lima di antaranya digunakan untuk tujuan hukum, 29 sisanya tersedia, jadi saya membeli semuanya.
Saya langsung mengenai target. Seseorang sedang mencari gambar di Google dan konten dari permintaan dikembalikan kepada mereka entah bagaimana rusak, karena browsernya meminta saya untuk menyajikan salah satu gambar dalam permintaan. Saya melihat alamat IP mereka, nama terdistorsi yang mereka minta, sumber daya yang mereka coba pulihkan menggunakan gambar ini, halaman yang terkait dengan konten ini, dan klien yang digunakan sebagai browser untuk mengirim permintaan ini.
Pada halaman tersebut Anda dapat melihat artefak yang menarik dalam bentuk permintaan nama tertentu Trisha Jones.
Lebih jauh, jumlah permintaan bertambah, semakin banyak nama yang terdistorsi, lebih banyak permintaan gambar dan lebih banyak tautan ke permintaan asli, sebagai akibatnya saya mengumpulkan lebih dari 50.000 permintaan unik, dan ini, ternyata, adalah kejadian yang umum.
Slide menunjukkan permintaan untuk gambar "difoto" aktris Selena Gomez, yang menyebabkan tawa di aula.
Jadi kadang-kadang beat squaking terjadi pada waktu yang tepat untuk mencocokkan salah satu permintaan Anda, dan jika ini tidak terlalu sering terjadi, Anda tidak perlu khawatir. Tetapi kadang-kadang ini terjadi pada saat ketika ada save ke hard drive, yang sudah lebih menarik. Ada kemungkinan jongkok bit akan terjadi di bawah kondisi operasi normal dari memori, tetapi sangat mungkin bahwa ini terutama terjadi di pusat data dengan suhu 95 derajat.
Sekarang log saya penuh dengan semua kebisingan, saya mendapatkan permintaan yang terdistorsi setiap hari dalam jumlah sedemikian rupa sehingga saya tidak dapat melihatnya secara manual.
Oleh karena itu, saya menulis skrip dalam upaya untuk menemukan pola kueri yang sama, dan yang terbesar yang saya dapatkan adalah banyak pertanyaan dari gambar yang sama untuk nama domain yang terdistorsi yang sama, dan semuanya berasal dari ponsel. Saya menerima permintaan ini setiap beberapa detik, karena semua ponsel ini mencoba menggunakan halaman pencarian situs web Google dan meminta saya untuk memberikan mereka gambar kecil dari logo halaman asli.
Saya menemukan satu server web dari seluruh cloud Google yang menyajikan konten dan terus-menerus mendistorsi nama domain, menunjuk ke salah satu server saya, tempat logo dengan nama itu kebetulan, dan pelanggan mengambilnya.
Slide menunjukkan bagaimana logo halaman pencarian Google pada layar perangkat mobile digantikan oleh logo Occupy, yang menyebabkan tawa apresiatif di aula.Selama dua tahun, ratusan ribu permintaan untuk logo ini datang ke server ini dengan nama DNS yang terdistorsi, bukan yang direncanakan Google untuk digunakan. Kemudian suatu hari mereka berhenti, karena Google menolak untuk mengubah konten untuk situs seluler, dan pesanan ini dibatalkan.
Jadi, saya terus mempelajari pola kueri dan mencoba mencari pola lainnya. Salah satu dari mereka muncul secara teratur dan terjadi secara alami dengan cara "membalik sedikit" dalam memori, dan bukan karena kesalahan jongkok yang disimpan.
Saya menerima permintaan yang ditunjukkan pada slide berikutnya dengan frekuensi satu per jam. Mereka tidak terlihat familier, mereka semua menggunakan klien Google Feedfetcher, mereka semua berasal dari perangkat di jaringan yang sama, dan semua permintaan terkait dengan file XML. Jadi saya mencari-cari sedikit dan menemukan Feedfetcher menjadi mekanisme yang digunakan Google untuk menangkap konten yang diperbarui untuk iGoogle, dan sumber alamat IP berada di Belgia.
Permintaan ini terkait dengan server Google sendiri, yang digunakan untuk menerima konten yang diperbarui untuk berbagai widget yang mempersonalisasi beranda iGoogle, portal Internet pribadi.
Setiap widget adalah file XML yang mendefinisikan konten, dan Google meminta saya untuk memberikan konten ini ke server presentasi saya (tepuk tangan dan hadirin tertawa).
Karena itu, saya berpikir bahwa jika Google secara tidak sengaja menginginkan konten dari saya yang dapat menyediakan penggunanya, maka ia akan menerimanya. Saya mengambil file XML yang ditanyakan Google dan membaginya menjadi beberapa bagian. Seperti yang Anda lihat, ada dua bagian: tajuk yang menjelaskan modul, dan blok C data yang dikemas dalam HTML CSS dan kode JavaScript yang membentuk widget.
Jadi saya hanya mengubah tautan ke gambar latar belakang, mengubah alamat gstatic.com menjadi grtatic.com, dan membiarkan sisanya tidak berubah, meletakkan file XML di baris dari tempat Feedfetcher mendapatkannya, dan menunggu sedikit.
Hampir segera setelah itu, Feedfetcher meminta saya untuk file XML, setelah itu saya segera mulai menerima permintaan dari banyak alamat IP Google untuk gambar latar belakang ini.
Oleh karena itu, saya menghapus file XML yang dimodifikasi oleh saya dan menunggu sampai permintaan berhenti, tetapi selama 35 hari berturut-turut, 61 perangkat terus bertanya kepada saya tentang gambar ini setiap hari. Dan yang lebih menarik, masing-masing perangkat ini adalah klien Virgin Media di Inggris.
Jadi file Google XML ini melayani 61 orang, dan selama setahun terakhir, 500 IP Feedfetcher unik telah meminta saya untuk menyediakan modul ini sebanyak 15.000 kali. Jadi saya bisa memberi pengguna saya sesuatu yang lebih berbahaya daripada hanya mengganti gambar latar belakang.
Berikut adalah beberapa trik yang dapat Anda lakukan dengan Google. Jika Anda tidak tahu, Postini adalah email perlindungan spam, keamanan web, dan layanan pengarsipan email terbaru dari Google.
Layanan ini memungkinkan Anda untuk mengubah DNS Anda untuk menunjukkan data MX Anda di domain mereka dan membuat domain Anda dengan mengubah 4 karakter MX sebelum psmtp.com. Hal yang paling menarik di sini adalah bahwa domainnya sangat pendek sehingga Anda dapat dengan mudah mendaftarkan semua versi yang mungkin dari nama tersebut dengan bit "terbalik". Hal lain yang menarik adalah bahwa banyak perusahaan menunjukkan catatan MX mereka untuk satu domain dan tidak ada yang berpikir itu adalah ide yang buruk.
Oleh karena itu, saya hanya mendaftarkan tiga jongkok bit yang mungkin untuk domain ini, dan pekerjaan psmtp.com ternyata sangat besar sehingga 4 slide berikutnya menunjukkan permintaan yang saya terima hanya dalam satu bulan.
Jadi jika Anda menggunakan surat Postini, permintaan Anda pada suatu saat akan datang ke server saya. Saya tidak berpikir ada yang bisa mengatakan bahwa Google tidak serius tentang keamanan Internet. Tetapi jika seseorang bertanya-tanya apa masalah overheating yang menyebabkan kesalahan memori dapat menyebabkan, ia akan dapat mengajukan pertanyaan mempertimbangkan kemungkinan kompensasi untuk hal-hal seperti itu. Karena itu, jangan biarkan nama domain Anda terlalu pendek, karena itu berdampak negatif pada bisnis Anda, seperti Postini, terutama jika domain Anda populer.
Saya sangat menyarankan agar orang menerapkan kebijakan manajemen nama domain internal yang memungkinkan mereka untuk memperbaiki kesalahan penyimpangan nama dan memahami dengan jelas bagaimana hal-hal seperti itu dapat memengaruhi Anda. Jika Anda memiliki gstatic.com dan pusat data yang beroperasi pada suhu 95 derajat, Anda mungkin ingin memastikan bahwa setiap kesalahan jongkok bit tidak akan memungkinkan klien untuk masuk ke jaringan eksternal berbahaya.
Omong-omong, di antara semua domain yang saya selidiki, satu-satunya perusahaan yang mendaftarkan semua kemungkinan penyimpangan nama saya adalah Yahoo.
Pada bagian selanjutnya dari presentasi, saya akan menunjukkan perilaku DNS, yang ternyata banyak orang, tidak sepenuhnya mengerti.
Jujur, Microsoft melakukan pekerjaan yang sangat buruk dalam mendokumentasikan, terutama karena perilaku DNS sering berubah. Ini mengarah pada kesalahpahaman tentang apa yang terjadi oleh pengguna akhir, terutama karena perilaku seperti itu sering bertentangan.
Oleh karena itu, saya akan mulai dengan fakta bahwa setiap orang harus memahami bagaimana perilaku perangkat ketika meminta DNS dan apa yang diharapkan dari mereka. Kemudian saya akan menjelaskan bagaimana perilaku ini menjadi tidak dapat diprediksi saat menggunakan jalur pencarian sufiks DNS, bagaimana dokumentasi yang tidak memadai memengaruhi semua ini, dan saya akan mengakhiri dengan tinjauan singkat tentang pelajaran yang dapat dipelajari dari semua ini. Tapi pertama-tama, saya akan menunjukkan betapa berbahayanya bagi pengguna akhir untuk salah paham tentang apa yang terjadi dengan DNS.
Jadi, setelah Anda mengetik
www.google.com di bilah alamat browser Anda, komputer Anda mengirimkan permintaan ke server DNS lokal, dan pekerjaan menemukan hal yang Anda butuhkan, mengembalikan permintaan dan menjawab sekarang ditugaskan untuk itu. Server lokal memanggil server root untuk akses ke server .com, dan server root mengirimkannya ke server .com. Dia memeriksa apakah server lokal diizinkan untuk permintaan ke google.com dan mengirimkannya ke server ns.google.com. Akhirnya, server lokal menerima respons dengan alamat IP sumber daya yang Anda butuhkan dan mengirimkannya kepada Anda.
Ini adalah perilaku DNS normal yang diharapkan semua orang darinya. Semua orang berpikir bahwa itu cukup dengan hanya mengirim permintaan dari perangkat ke server DNS lokal Anda sehingga melakukan semua kerja keras, dan kemudian mendapatkan jawaban untuk permintaan Anda. Tetapi tidak semua orang membayangkan bahwa proses ini terdiri dari banyak langkah penting.
Misalnya, perangkat Anda mencoba menemukan jawabannya di
www.google.com , tetapi seluruh proses, yang membawa kami sebanyak 8 slide, hanya akan terjadi jika Anda mengetikkan alamat ini di bilah permintaan browser -
www.google .com . Ini adalah nama domain yang sepenuhnya memenuhi syarat yang dikaitkan dengan root DNS. Banyak orang percaya bahwa nama domain yang memenuhi syarat berakhir dengan periode, yang tidak benar. Kehadiran sebuah titik di akhir nama lengkap masih dianggap, dan karena itu, masalah terjadi. Mari kita coba cetak 4 variasi nama:
www.google.comgoogle.com
www
www.google.commasing-masing berperilaku berbeda sehubungan dengan perilaku DNS. Semua ini dapat disesuaikan, tetapi biasanya tidak ada yang melakukannya.
Mari kita lihat apa yang sebenarnya terjadi dalam situasi seperti itu. Ada beberapa faktor yang mempengaruhi pengambilan keputusan klien sebelum mereka memutuskan untuk mengirim permintaan DNS. Dua di antaranya adalah jalur pencarian sufiks dan devolusi DNS.
Keduanya memiliki banyak parameter yang dapat disesuaikan yang memengaruhi perilaku mereka, dan berperilaku berbeda di versi Windows dan paket layanan yang berbeda.
Ini adalah bagaimana kebanyakan orang akan menggunakan akhiran jalur pencarian. Jika perusahaan Anda disebut foo dan Anda memiliki domain foo.com, dan nama direktori aktifnya adalah ad.foo.com, Anda dapat menggunakan akhiran jalur pencarian ad.foo.com atau foo.com dan “mendorongnya” ke bagian klien dari perakitan sistem atau di kebijakan kelompok.
Jika salah satu klien Anda mencoba menyelesaikan nama pendek www, maka perilaku default Windows XP akan seperti ini. Pertama dia akan mengirimkan permintaan DNS di sepanjang jalur
www.ad.foo.com , kemudian di sepanjang jalur
www.foo.com dan pada akhirnya permintaan NetBIOS akan mengikuti - hanya www.
www.phx ,
www.phx , ,
www.phx.ad.foo.com ,
www.phx.foo.com . 15 , NetBIOS,
www.phx .
Windows, XP sp.3, DNS —
www.phx NetBIOS —
www.phx , , .
, , , , , . , , Microsoft DNS.
XP , Microsoft XP, DNS Windows DNS . , www, Windows , , , DHCP Active Directory.
www.phx.ad.foo.com , ,
www.ad.foo.com ,
www.foo.com , ,
www.com .
18:30
DEFCON 21. DNS . Bagian 2, . ? ? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps hingga Desember secara gratis ketika membayar untuk jangka waktu enam bulan, 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 Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?