Kursus MIT "Keamanan Sistem Komputer". Kuliah 21: Pelacakan Data, 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
Kuliah 9: "Keamanan Aplikasi Web" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 10: “Eksekusi simbolik” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 11: “Bahasa Pemrograman Web / Web” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 12: Keamanan Jaringan Bagian 1 / Bagian 2 / Bagian 3
Kuliah 13: "Protokol Jaringan" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 14: "SSL dan HTTPS" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 15: “Perangkat Lunak Medis” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 16: “Serangan Saluran Samping” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 17: “Otentikasi Pengguna” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 18: “Penjelajahan Pribadi di Internet” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 19: “Jaringan Anonim” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 20: "Keamanan Ponsel" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 21: “Melacak Data” Bagian 1 / Bagian 2 / Bagian 3

Mahasiswa: Jadi, dukungan arsitektur adalah solusi yang ideal?

Profesor: ya, ada metode untuk ini juga. Namun, ini agak rumit karena, seperti yang Anda lihat, kami menyoroti kondisi taint di sebelah variabel itu sendiri. Karena itu, jika Anda berpikir tentang dukungan yang diberikan oleh peralatan itu sendiri, bisa sangat sulit untuk mengubah tata letak perangkat keras, karena semuanya dipanggang menjadi silikon di sini. Tetapi jika itu mungkin pada tingkat tinggi di mesin virtual Dalvic, orang dapat membayangkan bahwa itu akan mungkin untuk menempatkan variabel dan infeksi mereka berdampingan pada tingkat perangkat keras. Jadi jika Anda mengubah tata letak dalam silikon, maka Anda mungkin dapat melakukan pekerjaan itu.



Mahasiswa: apa yang dilakukan TaintDroid dengan informasi yang dibangun berdasarkan izin cabang git, izin Cabang?

Profesor: kita akan kembali ke ini sebentar lagi, jadi tahan saja pikiran ini sampai kita selesai.

Mahasiswa: Saya bertanya-tanya apakah buffer overflows dapat terjadi di sini, karena hal-hal ini - variabel dan infeksi mereka - bertumpuk bersama?

Profesor: Ini pertanyaan yang bagus. Orang akan berharap bahwa dalam bahasa seperti Java tidak ada buffer overflow. Tetapi dalam kasus bahasa C, sesuatu yang dahsyat dapat terjadi, karena jika Anda entah bagaimana membuat buffer overflow, dan kemudian menulis ulang tag noda untuk variabel, maka nilai nolnya diatur di tumpukan dan data mengalir dengan bebas ke jaringan.

Mahasiswa: Saya pikir semua ini dapat diprediksi?

Profesor: benar sekali. Masalah buffer overflows dapat diselesaikan dengan bantuan "canaries" - indikator stack, karena jika Anda memiliki data ini di stack, maka Anda tidak ingin membuatnya tidak ditimpa atau Anda tidak ingin nilai yang sudah ditimpa retak dengan beberapa cara. Jadi Anda benar sekali - Anda bisa mencegah buffer overflows.

Singkatnya, pelacakan noda dapat disediakan pada tingkat x86 / ARM yang rendah ini, meskipun bisa sedikit mahal dan agak sulit untuk diterapkan dengan cara yang benar. Anda mungkin bertanya mengapa kami pertama-tama menyelesaikan masalah pelacakan infeksi alih-alih memantau bagaimana program mencoba mengirim sesuatu melalui jaringan, hanya dengan memindai data yang tampaknya rahasia bagi kami. Ini kelihatannya agak mudah, karena dengan begitu kita tidak perlu memonitor secara dinamis semua yang dilakukan oleh program.



Masalahnya adalah ini hanya akan bekerja pada level heuristik. Bahkan, jika seorang penyerang tahu bahwa Anda melakukan hal itu, ia dapat dengan mudah memecahkan Anda. Jika Anda hanya duduk di sana dan mencoba untuk mendapatkan nomor jaminan sosial, penyerang hanya dapat menggunakan pengkodean base 64 atau melakukan hal bodoh lainnya, seperti kompresi. Memotong jenis filter ini cukup sepele, jadi dalam praktiknya ini sama sekali tidak cukup untuk memastikan keamanan.

Sekarang mari kita kembali ke pertanyaan Anda tentang bagaimana kami dapat melacak arus yang mengalir melalui cabang-cabang Cabang. Ini akan membawa kita ke topik yang disebut Aliran Implisit, atau Aliran Implisit. Aliran implisit biasanya terjadi ketika Anda memiliki nilai yang terinfeksi yang akan mempengaruhi cara Anda menetapkan variabel lain, bahkan jika variabel aliran implisit tidak menetapkan variabel secara langsung. Saya akan memberikan contoh nyata.
Misalkan Anda memiliki pernyataan if yang melihat IMEI Anda dan berkata, "jika lebih besar dari 42, maka saya akan menetapkan x = 0, kalau tidak saya akan menetapkan x = 1."

Yang menarik, pertama-tama kita melihat data IMEI rahasia dan membandingkannya dengan angka tertentu, tetapi kemudian, menugaskan x, kita tidak menetapkan apa pun yang akan diperoleh langsung dari data rahasia ini.



Ini adalah contoh dari salah satu utas implisit. Nilai x benar-benar tergantung pada perbandingan di atas, tetapi lawannya, jika dia pintar, dapat membangun kodenya sedemikian rupa sehingga tidak ada koneksi langsung yang dapat dilacak di dalamnya.

Harap dicatat bahwa bahkan di sini, alih-alih hanya menetapkan x = 0, x = 1, Anda dapat menempatkan perintah untuk mengirim sesuatu melalui jaringan, yaitu, Anda dapat mengatakan melalui jaringan bahwa x = 0 atau x = 1, atau sesuatu seperti itu. Ini adalah contoh dari salah satu utas implisit ini yang tidak dapat dikontrol oleh sistem seperti TaintDroid. Jadi, ini disebut aliran implisit, berlawanan dengan aliran eksplisit, misalnya, operator penugasan. Jadi pengembang menyadari masalah ini.
Jika saya mengerti dengan benar, mereka bertanya kepada saya apa yang akan terjadi jika kita memiliki beberapa jenis fungsi mesin yang melakukan sesuatu yang mirip dengan contoh di atas, dan karena itu sistem TaintDroid tidak perlu mengetahui hal ini, karena TaintDroid tidak akan dapat melihat kode mesin ini dan melihat hal-hal semacam itu. Omong-omong, pengembang mengklaim bahwa mereka akan mengontrol ini menggunakan metode berorientasi mesin yang ditentukan oleh mesin virtual itu sendiri dan mereka akan mempertimbangkan cara metode ini diimplementasikan. Misalnya, kami mengambil dua angka ini dan kemudian mengembalikan nilai rata-rata mereka. Dalam hal ini, sistem TaintDroid akan mempercayai fungsi mesin, jadi kita perlu mencari tahu apa kebijakan infeksi noda yang sesuai.

Namun, Anda benar bahwa jika sesuatu seperti ini disembunyikan di dalam kode mesin dan karena alasan tertentu tidak mengalami revisi terbuka, maka kebijakan manual yang ditemukan oleh penulis TaintDroid mungkin tidak menangkap aliran implisit ini. Bahkan, ini dapat membuat informasi entah bagaimana bocor. Selain itu, bahkan mungkin ada aliran langsung, yang tidak diperhatikan oleh penulis TaintDroid, dan kami mungkin memiliki kebocoran yang lebih langsung.



Mahasiswa: yaitu, dalam praktiknya tampaknya sangat berbahaya, bukan? Karena Anda benar-benar dapat menghapus semua nilai yang terinfeksi dengan hanya melihat 3 baris terakhir.

Profesor: Kami memiliki beberapa kelas yang memeriksa bagaimana aliran implisit melakukan hal-hal seperti itu. Ada beberapa cara untuk memperbaikinya. Salah satu cara untuk mencegah hal ini terjadi adalah dengan menetapkan tag noda ke PC, pada dasarnya menginfeksi dengan uji Cabang. Idenya adalah bahwa dari sudut pandang manusia, kita dapat mempertimbangkan kode ini dan mengatakan bahwa aliran implisit ini ada di sini, karena untuk sampai ke sini, kita harus menggali data rahasia.

Jadi apa artinya ini di tingkat implementasi? Ini berarti bahwa untuk sampai ke sini, PC harus memiliki sesuatu yang telah terinfeksi dengan data rahasia. Artinya, kita dapat mengatakan bahwa kami menerima data ini karena PC diinstal di sini - x = 0 - atau di sini - x = 1.

Secara umum, dapat dibayangkan bahwa sistem akan melakukan beberapa analisis dan mengetahui bahwa aliran implisit PC tidak terinfeksi di tempat ini, kemudian mengambil infeksi dari IMEI, dan pada titik ini x = 0, PC sudah terinfeksi. Pada akhirnya, yang terjadi adalah jika x adalah variabel yang awalnya ditampilkan tanpa noda, maka kita berkata: "OK, pada titik ini x = 0, kita mendapatkan infeksi dari PC, yang sebenarnya terinfeksi di atas, di IMEI". Ada beberapa kehalusan di sini, tetapi secara umum, Anda dapat melacak bagaimana PC diinstal dan kemudian mencoba untuk menyebarkan infeksi ke operator target.

Apakah itu jelas? Jika Anda ingin tahu lebih banyak, maka kita dapat berbicara tentang topik ini karena saya telah melakukan banyak penelitian semacam ini. Namun, sistem yang baru saja saya jelaskan mungkin terlalu konservatif. Bayangkan bahwa alih-alih x = 1, di sini, seperti di atas, kami juga memiliki x = 0. Dalam hal ini, tidak masuk akal untuk menginfeksi x dengan sesuatu yang berhubungan dengan IMEI, oleh karena itu tidak ada informasi yang dapat bocor dari cabang-cabang ini.

Tetapi jika Anda menggunakan skema infeksi PC terkomputerisasi, Anda bisa melebih-lebihkan berapa banyak variabel x yang telah rusak. Ada beberapa kehalusan yang dapat Anda lakukan untuk mengatasi beberapa masalah ini, tetapi akan sedikit sulit.

Siswa: ketika Anda keluar dari pernyataan if, Anda juga keluar dari Branch, dan Anda membersihkan diri dari infeksi?

Profesor: sebagai aturan, ya, begitu set variabel berakhir, PC akan dibersihkan dari infeksi. Infeksi hanya terjadi di dalam cabang-cabang ini dari x ke x. Alasannya adalah bahwa ketika Anda pergi ke sini Anda melakukannya tidak peduli apa IMEI itu.



Kami berbicara tentang bagaimana pelacakan infeksi pada tingkat yang sangat rendah ini berguna, meskipun cukup mahal, karena itu benar-benar memungkinkan Anda untuk melihat berapa umur data Anda. Beberapa ceramah yang lalu, kami berbicara tentang fakta bahwa cukup sering data kunci hidup dalam memori lebih lama daripada yang Anda pikirkan.

Anda dapat membayangkan bahwa sementara melacak infeksi x86 atau ARM cukup mahal, Anda dapat menggunakan ini untuk mengaudit sistem Anda. Misalnya, Anda dapat menginfeksi kunci rahasia yang telah dimasukkan pengguna dan melihat ke mana dan bagaimana ia bergerak di seluruh sistem. Ini adalah analisis offline, ini tidak memengaruhi pengguna, jadi itu normal jika lambat. Analisis semacam itu akan membantu untuk mengetahui, misalnya, bahwa data ini jatuh ke buffer keyboard, ini ke server eksternal, ini di tempat lain. Jadi, meskipun itu adalah proses yang lambat, itu masih bisa sangat berguna.

Seperti yang saya katakan, fitur yang bermanfaat dari TaintDroid adalah membatasi "semesta" sumber infeksi dan penyerap informasi yang terinfeksi. Tetapi sebagai pengembang, Anda mungkin ingin memiliki kontrol yang lebih tepat atas tanda infeksi yang berinteraksi dengan program Anda. Karena itu, sebagai seorang programmer, Anda akan ingin melakukan hal berikut.
Jadi, Anda mendeklarasikan beberapa int dari jenis ini dan menyebutnya X, dan kemudian mengikat label padanya. Arti dari label ini adalah bahwa Alice adalah pemilik informasi yang ia izinkan untuk dilihat Bob, atau bahwa informasi ini ditandai untuk dilihat oleh Bob. TaintDroid tidak mengizinkan Anda melakukan ini, karena pada dasarnya mengontrol label-label ini, tetapi sebagai seorang programmer, Anda mungkin ingin melakukan ini.

Misalkan program Anda memiliki saluran input dan output, dan mereka juga diberi label. Ini adalah label yang Anda pilih sebagai programmer, tidak seperti sistem itu sendiri, mencoba mengatakan bahwa hal-hal seperti itu telah ditentukan sebelumnya. Katakan untuk saluran input yang Anda atur nilai baca yang mendapatkan label saluran.



Ini sangat mirip dengan cara kerja TaintDroid - jika nilai sensor GPS dibaca, mereka ditandai dengan tag noda pada saluran GPS, tetapi sekarang, sebagai programmer, Anda memilih sendiri label ini. Dalam hal ini, label saluran keluaran harus cocok dengan nilai label yang kami rekam.



Kebijakan lain dapat diperkenalkan di sini, tetapi gagasan utamanya adalah bahwa ada manajer program yang membiarkan pengembang memilih label seperti apa dan semantik mereka. Ini akan membutuhkan banyak pekerjaan dari programmer, yang hasilnya adalah kemampuan untuk melakukan pemeriksaan statis. Secara statis maksud saya adalah pemeriksaan yang dilakukan pada waktu kompilasi dan dapat "menangkap" banyak jenis kesalahan aliran informasi.

Jadi jika Anda dengan hati-hati memberi label semua saluran jaringan dan saluran layar dengan label dengan izin yang sesuai, dan kemudian dengan hati-hati menempatkan data Anda, yang diberikan sebagai contoh di papan tulis, maka selama kompilasi, kompiler akan dapat memberi tahu Anda: "hei, jika Anda menjalankan program ini, maka Anda mungkin mengalami kebocoran informasi karena bagian dari data akan melalui saluran yang tidak dipercaya. "

Pada level tinggi, pemeriksaan statis dapat menangkap banyak kesalahan ini, karena komentar int {Alice  Bob} x ini agak mirip tipe. Sama seperti kompiler dapat menangkap kesalahan terkait jenis dalam bahasa jenis, mereka juga dapat bekerja dengan kode yang ditulis dalam bahasa di atas, mengatakan bahwa jika Anda menjalankan program ini, itu bisa menjadi masalah. Karena itu, Anda perlu memperbaiki cara label bekerja, Anda mungkin perlu mendeklasifikasi sesuatu, dan sebagainya.

Jadi, tergantung pada bahasanya, label ini dapat dikaitkan dengan orang-orang, dengan port I / O, dan sejenisnya. TaintDroid memberi Anda kesempatan untuk membiasakan diri dengan prinsip-prinsip operasi arus informasi dan kebocoran informasi, namun, ada sistem yang lebih kompleks dengan semantik yang lebih jelas untuk mengelola proses ini.



Ingatlah bahwa ketika kita berbicara tentang verifikasi statis, lebih baik bagi kita untuk menangkap sebanyak mungkin kegagalan dan kesalahan dengan bantuan verifikasi statistik, daripada verifikasi dinamis. Ada alasan yang sangat rumit untuk ini. Misalkan kita menunda semua pemeriksaan statis selama suatu program, yang pasti bisa kita lakukan.
Masalahnya adalah bahwa kegagalan atau keberhasilan pemeriksaan ini merupakan saluran implisit. Dengan demikian, penyerang dapat menyediakan program dengan beberapa informasi, dan kemudian memeriksa apakah ini menyebabkan program crash. Jika terjadi kegagalan, peretas mungkin berkata: "Ya, kami telah melalui beberapa verifikasi dinamis dari arus informasi, jadi ada beberapa rahasia di sini mengenai nilai-nilai yang mempengaruhi proses perhitungan." Oleh karena itu, Anda ingin mencoba membuat pemeriksaan ini se-statis mungkin.

Jika Anda ingin informasi lebih lanjut tentang hal-hal ini, Anda harus memeriksa Jif. Ini adalah sistem yang sangat kuat yang telah membuat label metode perhitungan label. Anda bisa mulai dengan itu dan bergerak ke arah itu lebih jauh. Kolega saya, Profesor Zeldovich, telah melakukan banyak hal baik di bidang ini, sehingga Anda dapat berbicara dengannya tentang topik ini.

Menariknya, TaintDroid sangat terbatas dalam kemampuannya untuk melihat dan menggambarkan tag. Ada sistem yang memungkinkan Anda melakukan hal-hal yang lebih kuat.

Akhirnya, saya ingin berbicara tentang apa yang dapat kita lakukan jika kita ingin melacak arus informasi menggunakan program tradisional atau menggunakan program yang ditulis dalam C atau C ++ yang tidak mendukung semua hal ini dalam proses eksekusi kode. Ada sistem TightLip yang sangat masuk akal, dan beberapa penulis artikel yang sama sedang mempertimbangkan cara melacak kebocoran informasi dalam suatu sistem di mana kami tidak ingin mengubah apa pun dalam aplikasi itu sendiri.

Ide dasarnya adalah bahwa konsep proses doppelganger, atau "rekan proses", digunakan di sini. TightLip menggunakan proses ganda secara default. Hal pertama yang dia lakukan adalah memindai sistem file pengguna secara berkala, mencari jenis file rahasia. Bisa jadi sesuatu seperti file email, dokumen teks, dan sebagainya. Untuk masing-masing file ini, sistem membuat versi "dibersihkan" -nya. Yaitu, dalam file pesan email, ia menggantikan informasi "ke" atau "dari" dengan string dengan panjang yang sama yang berisi data dummy, misalnya spasi. Ini berjalan sebagai proses latar belakang.

Hal kedua yang dilakukan TightLip saat proses dimulai adalah menentukan apakah proses tersebut mencoba mengakses file rahasia. Jika akses tersebut terjadi, TightLip menciptakan proses ganda ini. Ganda ini terlihat persis seperti proses asli, yang mencoba untuk mempengaruhi data sensitif, tetapi perbedaan mendasar adalah bahwa ganda, saya akan tunjuk sebagai DG, membaca data yang telah dihapus.



Bayangkan Anda sedang dalam proses mencoba mengakses file email Anda. Sistem ini memunculkan proses baru ini, doppelganger, persis sama dengan aslinya, tetapi sekarang ia membaca data yang telah dibersihkan alih-alih data sensitif nyata. Pada dasarnya, TightLip menjalankan kedua proses ini secara paralel dan mengawasi mereka untuk melihat apa yang mereka lakukan. , , , . , , - , , – , , , -, .



, , TightLip , . , . , , , , . , TaintDroid, , : «, , , , - ».

, , , - . TaintDroid, , - , . — , — . , , , , , .

: , - Word, , - .

: , . , . . Word. - , - , . .

: , , ? - .

: , . , , , - , . , . «» , , , .

, , , , , , , .



– , TightLip TCB, , -, . , . . , , . TightLip.
, . taint .

: , ? , ?

: ! - DG , , . , , , -, , .

, .


.

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

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?