Kursus MIT "Keamanan Sistem Komputer". Kuliah 20: Keamanan Ponsel, 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

Siswa: Sekarang di banyak aplikasi tidak ada cara untuk menghapus izin.

Profesor: ya, di Android versi baru ini bukan, hanya ada deskripsi izin. Tetapi Anda dapat menggunakan Android Permission Manager, atau Android permit manager, yang memungkinkan Anda melihat daftar semua izin untuk setiap aplikasi dan menghapus secara khusus yang Anda anggap tidak perlu. Tapi saya tidak tahu bagaimana hal ini populer di kalangan pengguna.

Siswa: jika label tidak cocok dengan izin yang diperlukan aplikasi, apakah ini menyebabkan kesalahan serius atau apakah semuanya terus berfungsi dengan baik?

Profesor: Saya pikir itu tergantung pada apa yang coba dilakukan aplikasi dan label apa yang memungkinkan. Misalnya, jika suatu aplikasi akan mengirim Intent dan mengirimkan niat ini memerlukan label tertentu dari jenis DIALPERM, maka pertama-tama akan beralih ke monitor tautan, yang mengatakan: "sayangnya, sistem tidak memiliki aplikasi yang siap menerima pesan Anda." Dan sebagai tanggapan atas aplikasi ini, diperlukan beberapa langkah yang masuk akal.



Kalau tidak, misalnya, ketika mengakses jaringan. Jika Anda tidak memiliki akses ke jaringan, dan Anda akan membuka soket atau memberikan perintah untuk terhubung ke alamat IP, kernel akan membalas Anda dengan pesan EPERM, "operasi tidak diizinkan", yaitu, Anda tidak bisa melakukan ini. Dan siapa yang tahu aplikasi apa yang akan dilakukan dalam kasus ini? Mungkin saja entah bagaimana itu akan melempar pengecualian pointer nol atau melakukan sesuatu seperti itu.

Salah satu argumen yang menentang hal ini adalah bahwa aplikasi Android, setidaknya pada awalnya, tidak mengharapkan beberapa panggilan mereka gagal, karena mereka diberitahu bahwa manifes adalah semua atau tidak sama sekali, yaitu, baik yang disetujui pengguna menginstal aplikasi atau tidak. Jadi pengembang aplikasi menulis kode dengan benar, yang crash atau melakukan sesuatu yang tidak terduga jika ditolak aksesnya. Mungkin dengan merampas penerapan izin akses yang dibutuhkan, Anda karenanya memprovokasi kegagalan operasinya.

Misalkan Anda memiliki aplikasi yang membutuhkan akses ke kamera. Dan jika Anda mengambil aksesnya dengan benar, template gambar hanya akan muncul di layar smartphone, atau mungkin aplikasi akan macet. Ini tidak terlalu bagus. Mungkin, akan mungkin untuk membuat sistem yang lebih kompleks, yang dalam hal perampasan akses ke kamera hanya akan menampilkan layar hitam sepanjang waktu. Android tidak melakukan ini, tetapi Anda dapat membayangkan situasi alternatif di mana ini bisa terjadi.

Jadi, kami memeriksa dari mana garis-garis ini berasal dari label aplikasi Android. Tapi siapa yang mendefinisikan garis-garis ini, dari mana mereka mendapatkan artinya? Anda dapat membuat daftar semua jenis baris dalam file manifes, tetapi bagaimana Anda memutuskan baris mana yang penting, dari mana baris INTERNET atau FRIENDVIEW berasal? Siapa yang memberi mereka makna dalam sistem?



Saya melihat Anda tidak punya ide. Saya pikir tidak satu pun dari garis-garis ini harus menjadi sesuatu yang ajaib atau telah ditentukan sebelumnya. Hampir semua baris ini pada dasarnya adalah perjanjian antara dua aplikasi, ketika salah satu aplikasi siap untuk memberikan sesuatu di bawah perlindungan beberapa baris Label, dan aplikasi lain ingin meminta izin untuk berbicara dengan aplikasi yang disediakan komponen ini.

Oleh karena itu, label ini biasanya ditentukan oleh aplikasi yang menyediakan beberapa layanan. Jika Anda memiliki izin DIALPERM, maka harus ditentukan dalam aplikasi, yang mendefinisikan apa artinya memanggil nomor telepon. Rupanya, aplikasi untuk melakukan panggilan pada ponsel Anda adalah apa yang mendefinisikan garis ini dan mengatakan bahwa, ya, hal DIALPERM ini ada, dan komponen saya akan dilindungi olehnya. Kemudian aplikasi lain yang ingin berinteraksi dengan aplikasi panggilan akan dapat meminta izin DIALPERM ini sendiri.

Tentu saja, ada beberapa hal bawaan, seperti izin untuk menggunakan Internet, kamera, dan sebagainya. Tetapi Anda dapat menganggapnya sebagai aplikasi sumber runtime Android, yang bertanggung jawab untuk menyediakan akses ke sumber daya ini dan menentukan garis yang akan melindungi sumber daya ini.

Apa artinya ini? Apa lagi yang terhubung dengan label di Android, selain fakta bahwa itu digunakan oleh aplikasi ketika perlu meminta izin? Ternyata ada beberapa hal yang terkait dengan label. Selain string, label memiliki beberapa properti menarik. Secara khusus, di Android ada 3 jenis tag. Yang pertama adalah izin reguler, yang kedua adalah izin yang tidak aman, dan yang ketiga adalah izin yang ditandatangani.



Aplikasi yang menentukan izin ini pertama-tama mendapat kesempatan untuk memilih jenis dan semua bidang lain untuk label, yang akan kita bicarakan dalam sedetik. Jadi apa jenis tag ini? Mengapa label Android perlu jenis?

Siswa: apakah mereka berfungsi sebagai peringatan bagi pengguna?

Profesor: tepatnya. Lalu mengapa tidak membuat semua tag dari jenis yang tidak aman? Apa semantik dari tipe-tipe ini? Sederhananya, label "berbahaya" digunakan untuk memungkinkan aplikasi yang dapat merusak sesuatu. Ini memperingatkan pengguna ketika menginstal aplikasi ketika aplikasi meminta akses ke izin tidak aman. Pada saat yang sama, pengguna harus melihat pesan ini dan berkata: "Ya, saya siap untuk memberikan izin tidak aman ke aplikasi baru ini." Jika aplikasi meminta label jenis yang biasa, maka pengguna tidak menerima pesan tentang perlunya memberi izin untuk tindakan ini. Apa arti dari izin biasa jika semua aplikasi menerimanya? Apakah ada alasan mengapa kita harus menggunakan label tipe biasa?

Salah satu contoh resolusi khas di Android adalah pengaturan wallpaper di layar. Jika Anda memiliki aplikasi yang akan memasang wallpaper, saya dapat, sebagai pengembang aplikasi, menunjukkan dalam manifes saya bahwa saya hanya ingin menginstal wallpaper untuk Anda. Dan jika Anda mengklik instal, tidak ada hal menarik yang akan terjadi, karena Anda tidak perlu memberikan izin kepada aplikasi ini.

Siswa: tetapi izin ini biasanya memerlukan konfirmasi dari Anda, bukan? Jika aplikasi ingin mengganti wallpaper desktop, sistem akan menanyakan apakah Anda ingin mengganti wallpaper.

Profesor: tidak.

Mahasiswa: tidak?

Profesor: tidak, itu hanya akan mengubah wallpaper karena itu hanya akses ke panggilan API. Jika saya memiliki izin ini, saya hanya membuat panggilan API.

Siswa: mungkin pengembang aplikasi ingin memastikan bahwa pengguna tidak melakukan ini secara tidak sengaja?

Profesor: ya, saya pikir ini adalah salah satu alasan mengapa Anda mungkin memerlukan izin ini, adalah keinginan untuk membantu pengembang menghindari kesalahan. Jika Anda khawatir bahwa aplikasi Anda mungkin secara tidak sengaja melakukan kesalahan atau ada kesalahan di dalamnya yang dapat digunakan, maka keberadaan seperangkat izin yang Anda mungkin atau mungkin tidak terima akan mengurangi kemungkinan penyalahgunaan aplikasi Anda. Jadi, jika Anda memiliki aplikasi yang tidak berbahaya yang tidak perlu memasang wallpaper apa pun, Anda tidak perlu meminta izin apa pun, karena lebih baik bagi pengguna yang ponselnya dipasang. Dalam batas tertentu, ini adalah semacam hak istimewa.

Hal lain adalah bahwa keberadaan label jenis biasa memungkinkan Anda untuk melakukan semacam audit, baik dari sisi pengembang dan dari sisi pengguna. Jika ponsel Anda mengubah wallpaper di layar setiap detik, maka Anda dapat masuk dan melihat aplikasi mana yang memiliki izin untuk ini. Bahkan jika Anda tidak menyetujui pemberian izin seperti itu, Anda masih bisa pergi dan memeriksa aplikasi mana yang saat ini terlibat dalam mengubah wallpaper.

Dengan demikian, izin umum ini tampaknya menjadi langkah pengamanan yang baik, atau, sebagian besar, peluang yang baik untuk mengaudit aktivitas aplikasi. Biasanya label jenis ini tidak digunakan untuk hal-hal yang sangat penting, seperti bekerja dengan data atau mengakses layanan yang membutuhkan biaya.

Jenis label ketiga adalah izin tanda tangan. Properti Android yang menarik adalah kemampuan untuk menyediakan akses hanya ke aplikasi yang ditandatangani dengan tanda tangan digital yang sama dengan aplikasi yang menyatakan hak aksesnya. Artikel kuliah menjelaskan contoh dengan FRIENDVIEW. Jika melihat teman memiliki izin yang ditentukan dengan jenis tag ini, maka aplikasi yang ditandatangani dengan kunci pengembang yang sama akan bisa mendapatkan izin yang sama. Apa gunanya hal ini? Mengapa tidak menandainya saja tidak aman? Mengapa kita membutuhkan label tipe ketiga?

Mahasiswa: Apakah itu memudahkan pengembang untuk mengelola aplikasi mereka?

Profesor: ya. Mungkin pengembang ini memiliki API internal yang ingin diisolasi dari efek program pihak ketiga, tetapi pada saat yang sama ingin menggabungkan aplikasi sendiri untuk interaksi produktif. Secara hipotesis, pembuat Facebook dapat menulis beberapa aplikasi. Mereka dapat memiliki satu aplikasi yang memuat konten dari server Facebook, aplikasi lain mencampur konten itu, yang ketiga melacak lokasi Anda dan semua komponen ini saling berinteraksi. Untuk kasus seperti itu, mereka dapat menggunakan izin yang ditandatangani.

Salah satu alasan mengapa Anda tidak ingin menetapkan aplikasi ini sebagai tidak aman adalah sebagai berikut. Jika Anda benar-benar tahu siapa yang bisa mendapatkan izin ini, Anda tidak ingin pengguna melakukan intervensi. Karena pengguna selalu dapat diperdayai dengan memaksakan izin untuk memberikan aplikasi jahat, oleh karena itu lebih baik ia tidak ikut campur sama sekali dengan ketentuan hak istimewa internal untuk beberapa aplikasi. Jadi dalam hal ini lebih baik menggunakan izin yang ditandatangani.

Label juga memiliki deskripsi izin pengguna. Ini adalah deskripsi tentang apa yang diperlukan izin ini. Deskripsi ini muncul ketika Anda diminta untuk menginstal aplikasi baru.



Dengan demikian, runtime Android akan melihat semua baris label dalam manifes aplikasi yang akan Anda instal, dan menampilkan pengguna dengan deskripsi semua baris yang ditandai ini, misalnya: "Anda akan memberikan aplikasi ini hak istimewa untuk melakukan panggilan, atau mengizinkan pengiriman SMS atas nama Anda" dan begitu seterusnya.

Pertanyaan yang menarik: apa yang terjadi jika aplikasi jahat mengubah label untuk beberapa aplikasi lain? Bagaimanapun, tanda-tanda ini hanyalah string bentuk bebas. Jadi apa yang terjadi jika Anda adalah aplikasi jahat yang mengatakan: “Oh, saya punya resolusi baru yang besar ini! Ini disebut DIALPERM. " Tidak memiliki label yang tidak aman, dan uraiannya tidak memberikan apa-apa. Apakah ini berbahaya?

Siswa: itu mungkin tidak akan dapat mempengaruhi struktur nama domain aplikasi.

Profesor: ya, ini bisa diharapkan, tetapi, sayangnya, ini tidak wajib. Biasanya, semua string izin harus memiliki nama domain gaya-Jawa, tetapi tidak ada hubungan ketat antara label yang didefinisikan oleh aplikasi dan nama aplikasi gaya-Jawa itu sendiri. Tidak ada yang memaksa nama aplikasi gaya Java untuk dikaitkan dengan sesuatu, jadi kami tidak memiliki kesempatan untuk mengetahui apakah kunci publik pengembang yang menandatangani aplikasi tertentu cocok dengan sesuatu di com.google.something atau edu. mit. sesuatu.

Ada satu kekurangan di Android, atau setidaknya ada ketika saya baru-baru ini menyelidiki pertanyaan ini. Jadi, ketika mendefinisikan label, prinsip "siapa yang datang pertama, dilayani". Yaitu, ketika Anda menginstal aplikasi, itu mendefinisikan label tertentu, dan Anda dapat memutuskan jenis label itu dan apa deskripsinya. Untuk izin sistem, ini mungkin bukan masalah besar, karena izin sistem atau aplikasi yang disematkan, seperti dialer, ditentukan di awal. Tetapi aplikasi yang diinstal kemudian tidak dapat mengesampingkan izin, karena ini karena kerangka kerja.

Masalahnya adalah bahwa jika Anda pertama kali menginstal aplikasi jahat, dan kemudian beberapa aplikasi penting, maka aplikasi jahat tersebut berpotensi mendistorsi label yang digunakan kemudian oleh aplikasi yang bermaksud baik. Artikel kuliah menjelaskan kasus di mana seorang penyerang memaksa pengguna untuk menginstal aplikasi jahat yang mengubah jenis label untuk aplikasi FRIENDVIEW menjadi tipe normal dengan baris deskripsi seperti "tidak ada yang menarik sama sekali." Kemudian, ketika Anda menginstal applet FRIENDVIEW, itu tidak lagi dapat menimpa label ini, karena sudah didefinisikan, dan sekarang pengguna tidak akan dapat mencegah aplikasi lain dari menggunakan teman-teman melihat izin.

Siswa: mungkin sistem dapat memperingatkan upaya untuk mengubah resolusi?

Profesor: pada prinsipnya, kerangka kerjanya mampu melakukan ini, tetapi ketika saya mencoba melakukan ini, tidak ada pesan yang dikeluarkan. Jika Anda menginstal aplikasi yang mendefinisikan label yang sudah ditentukan, sistem tidak melakukan apa-apa, itu hanya mengabaikan definisi label baru dan menggunakan yang lama. Mungkin ini masalahnya, karena semuanya bisa salah. Paling tidak, sistem harus mengatakan: "Saya menolak untuk menginstal aplikasi ini karena memiliki definisi label yang sudah ada."

Mahasiswa: ... dan milik aplikasi lain.

Profesor: ya, dan bahkan mungkin milik kunci lain. Maka setidaknya berpotensi ada peluang untuk memperbaiki semuanya. Saya tidak melacak masalah ini, mungkin sudah diperbaiki. Bagaimanapun, ini adalah masalah yang menarik, ketika Anda benar-benar harus melacak nama-nama ini dan mencari tahu siapa yang memiliki nama ini, dan mendapatkan hak untuk melakukan tindakan tersebut sangat penting.

Masalah Android lain yang menarik terkait dengan penerima siaran, atau penerima pesan siaran. Ini menciptakan kemampuan untuk menerima dan menanggapi pesan dari aplikasi lain, mengimplementasikan sesuatu seperti mengirim pesan antar aplikasi. Pertama saya harus menjelaskan bagaimana pesan-pesan ini berinteraksi dengan penerima. Penerima siaran digunakan untuk satu aplikasi, yang dapat mengumumkan beberapa acara untuk aplikasi lain dalam sistem.



Seperti yang kita ketahui, niat biasanya ditujukan ke komponen tertentu, misalnya, penampil gambar JPEG. Tetapi tentang acara seperti pemuatan sistem atau "Teman saya yang dekat," Anda dapat mengumumkan ke setiap aplikasi yang terkait. Ini adalah tujuan dari penerima Siaran.

Ada dua hal yang menjadi perhatian Anda. Pertama, otentikasi sumber pesan, yaitu, Anda ingin tahu siapa yang mengirim pesan ini dan apakah Anda bisa mempercayainya. Kedua, Anda ingin mengontrol ke siapa pesan ini ditujukan dan siapa yang dapat menerimanya.

Sepertinya saya bahwa pengembang Android tidak menerapkan hal-hal ini dengan benar. Bagaimanapun, dalam versi awal Android, ketika Anda mengirim pesan siaran ke semua komponen lain dari sistem, aplikasi ini mungkin atau mungkin tidak mendukung pesan ini. Oleh karena itu, jika Anda memiliki aplikasi Lihat Teman, itu akan mendukung pesan-pesan ini dengan menggunakan komponen yang sesuai, seperti Aksi atau Tanggal / MIME, di filter Intent intent-nya. Tetapi sebagian besar aplikasi selalu dapat mendukung semua acara siaran dalam sistem, dan Anda dapat melihat semua yang terjadi di telepon, atau semua yang disiarkan.

Dengan demikian, kerangka kerja Android menambahkan argumen tambahan untuk aplikasi untuk menunjukkan siapa yang dapat melihat pesan siaran.



, , – , , . , , , , .

, , , , , , . Android, , , , .

, ? , « » , . , ? ?

: ? ?

: , . App 1 RM, , , App 2, , . , App 1 , ? Android ?

, . , , . , . ? , « »?

: , , ?
: . , — . , , « ».



Broadcast receiver, , , . , , , Label.

. Android , . « », . , . , , , .

RPC , RPC-, , . , .

: ?

: , , .

: , …

: , . – . . : « ».

: ?

: .

: , ?

: , , . . , , , . , — . , : « , », , , Dangerous Description.



, : „ , ». , , , , . , Android , .

, , Android. , , . , «», « ». , , .



, , . , , , , , . , Java. , , , , .

Android . - , , , , . «» , RPC . , .

, , . , Android , 5 6 . , , , - «». , , .

, Android , , Apple . , Apple iPhone , .

«», «», , , , , , , . , . , , Android, . , - .

, Android .


.

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