Kursus MIT "Keamanan Sistem Komputer". Kuliah 8: Model Keamanan Jaringan, Bagian 3

Institut Teknologi Massachusetts. Kursus Kuliah # 6.858. "Keamanan sistem komputer." Nikolai Zeldovich, James Mickens. Tahun 2014

Keamanan Sistem Komputer adalah kursus tentang pengembangan dan implementasi sistem komputer yang aman. Ceramah mencakup model ancaman, serangan yang membahayakan keamanan, dan teknik keamanan berdasarkan pada karya ilmiah baru-baru ini. Topik meliputi keamanan sistem operasi (OS), fitur, manajemen aliran informasi, keamanan bahasa, protokol jaringan, keamanan perangkat keras, dan keamanan aplikasi web.

Kuliah 1: “Pendahuluan: model ancaman” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 2: "Kontrol serangan hacker" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 3: “Buffer Overflows: Exploits and Protection” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 4: “Pemisahan Hak Istimewa” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 5: "Dari mana sistem keamanan berasal?" Bagian 1 / Bagian 2
Kuliah 6: “Peluang” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 7: “Kotak Pasir Klien Asli” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 8: “Model Keamanan Jaringan” Bagian 1 / Bagian 2 / Bagian 3

Pemirsa: mengapa token acak selalu disertakan dalam URL, dan tidak di badan permintaan?

Profesor: HTTPS digunakan dengan cara ini, tetapi tidak ada alasan kuat untuk tidak memasukkan variabel acak ke dalam tubuh permintaan. Hanya saja ada beberapa bentuk warisan yang bekerja seperti itu melalui URL. Namun dalam praktiknya, Anda dapat menempatkan informasi ini di tempat lain dalam permintaan HTTPS, kecuali untuk header.

Namun, perhatikan bahwa hanya memindahkan informasi ini ke badan permintaan berpotensi tidak aman jika ada sesuatu di sana yang dapat ditebak penyerang. Kemudian penyerang masih bisa memanggil URL yang dibutuhkannya. Misalnya, ketika saya membuat permintaan HTTP HTTP, dan kemudian secara eksplisit memasukkan beberapa konten ke dalam tubuh yang dapat ditebak penyerang.



Jika Anda cukup mengatur frame di URL, maka penyerang dapat mengendalikannya. Tetapi jika Anda menggunakan permintaan HTTP XML dan penyerang dapat menghasilkan salah satunya, maka antarmuka HTTP XML memungkinkan Anda untuk mengatur isi permintaan. Permintaan HTTP XML terbatas pada sumber yang sama. Namun, jika penyerang dapat melakukan sesuatu seperti:

<script> var x = “ntrusted”; </script> 

Kemudian dia akan dapat mengimplementasikan permintaan HTTP XML, yang akan dieksekusi dengan otoritas halaman yang disematkan.

Itu semua tergantung pada apa yang penyerang akses. Jika itu dapat memaksa halaman untuk menjalankan skrip yang tidak dicentang, seperti yang ditunjukkan di atas, maka ia dapat menggunakan properti JavaScript yang disebut HTML internal dan mendapatkan semua konten HTML halaman tersebut. Jika penyerang dapat atau tidak dapat menghasilkan permintaan AJAX, ini adalah satu hal, jika ia dapat atau tidak dapat melihat kode HTML yang benar, ini adalah hal lain, dan seterusnya. Singkatnya, token yang dibuat secara acak ini dapat mencegah serangan CSRF.

Ada satu hal lagi yang perlu Anda perhatikan adalah alamat jaringan. Mereka berhubungan dengan bagian dari percakapan kami yang mengatakan siapa penyerang tidak dapat berkomunikasi melalui permintaan HTTP XML.

Mengenai alamat jaringan, frame dapat mengirim permintaan HTTP dan HTTPS ke (host + port) sesuai dengan asalnya. Perhatikan bahwa keamanan kebijakan yang sama dari sumber yang sama sangat erat terkait dengan keamanan infrastruktur DNS, karena semua kebijakan semacam ini didasarkan pada apa yang Anda sebut.

Jadi, jika Anda dapat mengontrol apa yang mereka sebut saya, Anda dapat membuat beberapa serangan yang agak berbahaya, misalnya, serangan pengikatan kembali DNS. Tujuan dari serangan ini adalah untuk meluncurkan JavaScript yang dikendalikan penyerang dengan otoritas (atau atas nama) situs korban, sebut saja dia korban.com. Dalam hal ini, penyerang menggunakan aturan kebijakan sumber yang sama dan akan meluncurkan kode yang ditulisnya dengan izin situs lain.

Ini dilakukan sebagai berikut. Pertama, seorang penyerang mendaftarkan nama domain, katakanlah attacker.com. Ini sangat sederhana, cukup bayar beberapa dolar - dan saat bepergian, Anda memiliki nama domain sendiri. Penyerang juga harus mengonfigurasi server DNS untuk menanggapi permintaan yang datang atas nama objek yang terletak di attacker.com.



Hal kedua yang harus terjadi adalah bahwa pengguna harus mengunjungi attacker.com. Secara khusus, ia harus mengunjungi beberapa situs yang tergantung pada nama domain ini. Tidak ada yang rumit di bagian serangan ini juga.

Lihat apakah Anda dapat membuat kampanye iklan, misalnya, menawarkan iPad gratis. Semua orang menginginkan iPad gratis, meskipun saya tidak tahu siapa pun yang pernah memenangkan iPad gratis. Jadi, mengklik pesan seperti itu di email phising, dan Anda sudah berada di situs penyerang. Tidak ada yang istimewa, bagian ini tidak rumit.

Jadi apa yang akan terjadi setelah itu? Browser akan mulai membuat permintaan DNS untuk attacker.com karena halaman yang Anda kunjungi berisi objek yang tertaut ke objek yang terletak di attacker.com. Tetapi browser akan mengatakan: "Saya belum pernah melihat domain ini sebelumnya, jadi izinkan saya mengirim permintaan DNS untuk izin untuk menghubungi attacker.com"!



Dan server DNS penyerang menjawab permintaan ini, tetapi tanggapannya berisi masa TTL yang sangat singkat, yang mencegah tanggapan dari di-cache. Oleh karena itu, browser akan berpikir bahwa itu valid hanya untuk jangka waktu yang sangat singkat sebelum harus keluar dan mengkonfirmasi ini, yang sebenarnya berarti melarang caching.

Ternyata segera setelah pengguna masuk ke domain peretas, server DNS penyerang pertama-tama mengembalikan alamat IP asli dari server web yang memberikan kode berbahaya kepada pengguna. Kode sisi klien ini mengakses attacker.com karena kebijakan asal memungkinkan permintaan tersebut. Pengguna menerima respons, dan sekarang situs web jahat dijalankan di sisi klien.

Sementara itu, penyerang akan mengkonfigurasi server DNS, yang ia kendalikan, untuk mengikat nama attacker.com dan alamat IP dari korban.com. Ini berarti bahwa jika browser pengguna meminta resolusi nama domain untuk sesuatu di dalam attacker.com, itu sebenarnya akan mendapatkan beberapa jenis alamat internal korban.com.



Mengapa DNS penyerang bisa melakukan ini? Karena peretas menyiapkannya untuk ini, dan server DNS si penyusup tidak perlu berkonsultasi untuk terhubung kembali dengan korban.com.

Selain itu, jika situs kami ingin mendapatkan objek baru melalui, katakanlah, AJAX, itu akan mempertimbangkan bahwa permintaan AJAX ini pergi ke attacker.com di suatu tempat di luar, tetapi sebenarnya permintaan AJAX ini masuk ke dalam, ke korban.com. Ini buruk, karena sekarang kami memiliki kode ini di sisi tempat halaman web attacker.com berada, yang sebenarnya mendapatkan akses ke data dari korban.com dengan sumber asal yang berbeda.



Sederhananya, ketika skrip dieksekusi di browser korban karena usang tanggapan DNS sebelumnya, permintaan DNS baru dibuat untuk domain ini, yang, karena larangan caching, dikirim ke server DNS penyerang. Dia menjawab bahwa sekarang attacker.com tampaknya memiliki alamat IP baru dari beberapa situs web lain, dan permintaan tersebut masuk ke server lain. Dan kemudian, untuk mengembalikan informasi yang dikumpulkan oleh kode, penyerang memberikan alamat IP yang benar di salah satu permintaan DNS berikut.

Hadirin: Bukankah lebih bijaksana untuk melakukan serangan sebaliknya, dari korban. Com untuk mendapatkan semua cookie penyerang dan sejenisnya?

Profesor: ya, opsi itu juga akan berhasil. Ini akan memungkinkan Anda melakukan hal-hal baik seperti pemindaian port. Maksud saya, pendekatan Anda akan bekerja dengan benar. Karena Anda dapat, selangkah demi selangkah, secara konstan menetapkan ulang attacker.com ke berbagai nama komputer dan port yang berbeda dalam jaringan korban. Dengan kata lain, halaman web attacker.com akan selalu berpikir bahwa itu masuk ke attacker.com dan menerima permintaan AJAX dari sana.

Bahkan, setiap kali server DNS terhubung kembali dengan attacker.com, ia mengirimkan permintaan ke beberapa alamat IP lain di dalam jaringan korban. Dengan begitu, ia cukup "berjalan" melalui alamat IP satu per satu dan melihat apakah seseorang merespons permintaan ini.

Pemirsa: tetapi pengguna yang Anda serang tidak harus memiliki akses internal ke jaringan korban.

Profesor: sebagai aturan, serangan ini adalah bahwa ada aturan firewall tertentu yang dapat mencegah situs eksternal attacker.com melihat alamat IP di dalam jaringan korban. Namun, jika Anda berada di dalam jaringan perusahaan seperti corp.net di belakang firewall perusahaan, maka komputer sering memiliki kemampuan untuk terhubung ke mesin di luar jaringan mereka.

Pemirsa: Apakah metode serangan ini berfungsi melalui HTTPS?

Profesor: ini pertanyaan yang menarik! Faktanya adalah bahwa HTTPS menggunakan kunci. Jika Anda menggunakan HTTPS, maka saat mengirim permintaan AJAX, mesin korban tidak akan memiliki kunci HTTPS penyerang, dan verifikasi enkripsi di korban.com akan menunjukkan ketidakcocokan kunci. Oleh karena itu, saya pikir HTTPS mengesampingkan kemungkinan serangan jenis ini.

Hadirin: bagaimana jika korban hanya menggunakan HTTPS?

Profesor: Saya pikir ini akan menghentikan penyerang.

Pemirsa: mengapa penyerang terutama merespons komputer korban dengan alamat IP-nya?

Profesor: karena penyerang entah bagaimana harus menjalankan kode sendiri pada mesin korban sebelum ia dapat mengambil tindakan lebih lanjut untuk menemukan sesuatu di dalam jaringan korban. Tapi jangan buang waktu, oleh karena itu, jika Anda memiliki pertanyaan tentang penugasan kembali DNS, datang kepada saya setelah kuliah.

Jadi bagaimana Anda bisa memperbaikinya? Salah satu cara untuk memperbaiki kerentanan ini adalah dengan memodifikasi resolver klien DNS sehingga nama host eksternal tidak pernah diizinkan untuk mengakses alamat IP internal.

Agak bodoh bahwa seseorang di luar jaringan Anda harus dapat membuat DNS yang terikat pada sesuatu di dalam jaringan Anda. Ini adalah solusi paling sederhana.



Anda dapat membayangkan bahwa browser dapat melakukan sesuatu yang disebut "DNS pinning," atau DNS pinning. Akibatnya, jika browser menerima catatan DNS yang diselesaikan, maka ia akan selalu menganggap catatan ini dapat diterima, misalnya, untuk interaksi dalam waktu 30 menit, terlepas dari TTL mana yang diberikan penyerang, dan dengan cara ini dapat menahan serangan tersebut.
Solusi ini agak rumit, karena ada situs yang sengaja menggunakan DNS dinamis untuk hal-hal seperti menyeimbangkan beban server dan sejenisnya. Dengan demikian, solusi pertama dengan pinning DNS adalah pilihan terbaik.

Dan sekarang kita akan melihat apa yang dilindungi oleh kebijakan sumber yang sama. Bagaimana dengan piksel? Bagaimana kebijakan asal melindungi piksel?

Ternyata, piksel sebenarnya tidak memiliki asal. Dengan demikian, setiap frame mendapatkan kotak pembatas kecilnya sendiri, pada dasarnya hanya persegi, dan frame dapat menggambar di mana saja di dalam area itu.

Ini sebenarnya masalah karena itu berarti bahwa bingkai induk dapat menggambar di atas bingkai anak. Dan ini, pada gilirannya, dapat menyebabkan serangan yang sangat berbahaya.

Katakanlah penyerang membuat halaman yang mengatakan, "klik di sini untuk memenangkan iPad." Trik standar yang sama. Ini adalah kerangka induk.



Dan bingkai induk ini dapat membuat bingkai anak, yang sebenarnya adalah bingkai tombol Suka di situs Facebook. Dengan demikian, Facebook memungkinkan Anda untuk menjalankan kode Facebook kecil ini yang dapat Anda masukkan ke halaman Anda.

Anda tahu bahwa jika pengguna mengklik "suka", itu berarti bahwa ia akan pergi ke Facebook dan berkata: "Hei, saya suka halaman ini"! Jadi, sekarang kita memiliki bingkai anak dari tombol Suka.



Sekarang, seorang penyerang dapat menindih bingkai ini di area layar yang harus diklik pengguna untuk mendapatkan iPad gratis, dan juga membuat bingkai ini tidak terlihat, CSS mengizinkan ini.

Jadi apa yang akan terjadi? Seperti yang sudah kita instal, semua orang ingin mendapatkan iPad gratis. Pengguna akan pergi ke situs ini dengan mengklik area layar ini, memastikan bahwa ia mengklik persis apa yang iPad gratis akan berikan padanya. Tapi faktanya, dia mengklik tombol Like yang tidak terlihat. Ini seperti pelapisan di atas indeks C.

Ini berarti bahwa sekarang, mungkin, pengguna berakhir di profil Facebook, di mana ia mencatat bahwa ia menyukai attacker.com. Anda tahu, dia bahkan tidak akan ingat bagaimana itu terjadi. Jadi ini sebenarnya apa yang disebut serangan jacking klik - dukungan untuk serangan klik. Dengan cara yang sama, Anda dapat melakukan banyak hal buruk - mencuri kata sandi, mendapatkan data pribadi, singkatnya, ini gila. Saya tekankan - ini dimungkinkan karena fakta bahwa kerangka induk dapat menggambar apa pun di dalam kotak pembatas ini.

Jadi, kerangka induk adalah apa yang Anda lihat pada halaman, panggilan untuk mendapatkan tablet gratis, dan kerangka anak adalah tombol seperti, yang ditumpangkan secara transparan pada bingkai induk.

Ada berbagai solusi untuk masalah ini. Yang pertama adalah menggunakan kode penghilang bingkai. Dengan begitu, Anda dapat menggunakan ekspresi JavaScript untuk mengetahui apakah seseorang telah menyematkan bingkai mereka sendiri di bingkai Anda. Sebagai contoh, salah satu dari tes ini adalah perbandingan dari bentuk berikut: if (self! = Top).

Di sini, pernyataan diri mengacu pada bagian atas bingkai atas, yang dibandingkan dengan hierarki seluruh bingkai. Karena itu, jika Anda melakukan tes ini dan menemukan bahwa diri tidak sama dengan bagian atas kerangka induk, maka Anda akan mengerti bahwa Anda memiliki kerangka anak. Dalam hal ini, Anda dapat menolak untuk mengunduhnya.

Ini terjadi jika Anda mencoba membuat bingkai, misalnya, untuk CNN.com. Jika Anda melihat kode sumber untuk JavaScript, Anda dapat melihatnya melakukan tes ini karena CNN.com tidak ingin orang lain menggunakan kontennya. Karena itu, frame ini selalu menempati posisi tertinggi. Jadi, ini adalah salah satu solusi yang bisa digunakan di sini.

Solusi kedua adalah untuk server web Anda mengirim header HTTP yang disebut opsi x-Frame sebagai respons. Oleh karena itu, ketika server web mengembalikan respons, ia dapat mengatur tajuk ini, yang akan mengatakan: "Hei, browser, jangan biarkan siapa pun meletakkan konten saya di dalam bingkai!". Solusi ini memungkinkan browser untuk melakukan tindakan penegakan hukum.

Jadi itu sangat sederhana. Tetapi masih ada banyak serangan gila lainnya yang dapat Anda atur.

Seperti yang saya sebutkan sebelumnya, fakta bahwa kita sekarang hidup di Internet internasional menciptakan masalah menggunakan domain atau nama host.

Misalkan kita memiliki huruf C. Tetapi dalam bahasa apa? Dari alfabet apa huruf ini dari bahasa Latin ASCII atau apakah huruf C dalam bahasa Cyrillic? Ini memungkinkan Anda untuk mengatur serangan yang menggunakan interpretasi berbeda dan penggunaan huruf yang berbeda, tetapi tampaknya serupa. Misalnya, penyerang akan mendaftarkan nama domain cats.com. Dan pengguna akan pergi ke domain ini, berpikir bahwa mereka akan mengunjungi situs "cats.com", tetapi pada kenyataannya mereka akan sampai ke situs penyerang "sats.com", karena huruf pertama di sini bukan Latin, tetapi Cyrillic.

Seorang penyerang dapat mendaftarkan domain fcebook.com, tetapi orang-orang tidak memperhatikan, mereka akan menganggapnya sebagai facebook.com dan pergi ke sana. Jadi, jika Anda mengontrol Facebook.com, Anda akan mendapatkan banyak lalu lintas dari orang-orang yang berpikir mereka telah masuk ke Facebook.



Ada banyak serangan aneh dan berbeda yang dapat Anda luncurkan melalui sistem registrasi nama domain yang sulit dipertahankan, karena bagaimana Anda dapat mencegah pengguna membuat kesalahan ketik? Atau bagaimana peramban menunjukkan kepada pengguna: "Hei, ini Cyrillic, bukan Latin"!?

Jika peramban memperingatkan pengguna setiap kali font Cyrillic dihidupkan, itu akan membuat orang-orang yang menggunakan Cyrillic sebagai font asli mereka menjadi marah. Jadi tidak sepenuhnya jelas bagaimana masalah seperti itu dapat diselesaikan dari sudut pandang teknis, itulah sebabnya masalah keamanan yang sangat sensitif muncul di sini.

Hal lain yang menarik adalah plugin. Bagaimana plugin berinteraksi dengan kebijakan asal? Plugin sering memiliki ketidakcocokan dengan sisa browser sehubungan dengan sumber asal yang sama. Sebagai contoh, jika Anda melihat plug-in Java, maka diasumsikan bahwa nama host berbeda yang memiliki alamat IP yang sama juga memiliki asal yang sama.

Pada kenyataannya, ini adalah penyimpangan yang agak besar dari interpretasi standar kebijakan dari asal yang sama. Pendekatan ini berarti bahwa jika Anda memiliki sesuatu seperti xycom dan zycom dan mereka diproyeksikan ke alamat IP yang sama, maka Java akan menganggap bahwa mereka memiliki sumber asal yang sama. Ini bisa menjadi masalah, karena dalam kenyataannya satu situs memiliki sumber asal tepercaya, dan yang lainnya tidak. Ada banyak kesulitan lain yang terkait dengan plugin, yang dapat Anda temukan dari sumber yang tersedia untuk umum di Internet atau dari catatan kuliah.

Hal terakhir yang ingin saya diskusikan adalah serangan berbagi layar, atau serangan berbagi layar.

HTML5 sebenarnya mendefinisikan API baru tempat laman web dapat berbagi semua bitnya untuk dibagikan dengan browser atau server lain. Ini sepertinya ide yang sangat keren, karena memungkinkan beberapa pengguna untuk bekerja secara bersamaan pada dokumen yang sama. Ini bagus karena kita hidup di masa depan.

Tapi yang paling lucu adalah ketika mereka mengembangkan API baru ini, mereka sama sekali tidak memikirkan kebijakan sumber yang sama!

Misalkan Anda memiliki halaman di mana beberapa frame berada, dan masing-masing dari mereka memiliki hak untuk mengambil screenshot dari seluruh monitor Anda. Dia dapat mengambil tangkapan layar dari semua bingkai yang terletak di layar dan semua konten, terlepas dari sumber mana mereka berasal.



Jadi, pada kenyataannya, ini adalah cacat yang agak merusak dalam kebijakan sumber asal yang sama, jadi Anda harus mempertimbangkan memperbaikinya. Misalnya, jika seseorang dari bingkai kanan memiliki kemampuan untuk mengambil screenshot, maka ia akan dapat mengambil screenshot hanya dari frame yang tepat, dan bukan keseluruhan layar secara keseluruhan.

Mengapa pengembang browser tidak menerapkannya seperti ini? Karena mereka mengalami tekanan kompetitif dan dipaksa untuk memfokuskan upaya mereka pada pengembangan lebih banyak fungsi baru, fitur-fitur baru, alih-alih memperhatikan peningkatan hal-hal yang sudah dikembangkan.

Banyak pertanyaan yang diajukan siswa di Internet tentang kuliah ini adalah: “mengapa para pengembang tidak melakukan apa yang dapat mereka lakukan? Bukankah itu jelas? " atau: “Tampaknya skema khusus ini sudah mati. Bukankah yang lain lebih baik? " dan seterusnya.

Saya akan memberitahu Anda dengan jujur ​​- ya, itu sudah pasti, hampir semuanya akan lebih baik jika pengembang mengambil ini secara bertanggung jawab. Jadi saya malu bahwa saya terhubung dengan ini.

Tetapi kenyataannya adalah inilah yang kita miliki sebelumnya. Jika Anda melihat semua elemen yang ada sebelumnya, Anda akan melihat bahwa browser web sedang berkembang, dan orang-orang menjadi sedikit lebih peduli tentang keamanan. Tetapi tidak dalam hal berbagi layar, di mana pengembang sangat khawatir tentang kemampuan inovatif dari browser sehingga mereka benar-benar lupa tentang kemungkinan kebocoran sedikit.



Karena itu, saya meminta Anda untuk selalu memperhatikan hal-hal yang kita bahas hari ini. Bayangkan jika kita akan mulai dari awal, menghancurkan semua yang ada di hadapan kita, dan mencoba untuk membuat kebijakan keamanan yang lebih baik, bagaimana menurut Anda, berapa banyak situs yang akan bekerja untuk kita? Saya pikir tidak lebih dari 2%. Jadi pengguna mungkin akan mengeluh tentang kami.

Ada properti menarik lain yang terkait dengan keamanan.Setelah Anda memberikan fungsi kepada pengguna, sangat sulit untuk mengingatnya kembali, bahkan jika itu tidak aman untuk menggunakannya. Oleh karena itu, hari ini kami membahas banyak hal terkait dengan kebijakan asal, dan kami akan terus membicarakan hal ini dalam kuliah berikutnya.


.

, . ? ? , 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 , .

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?