Kisah pintu belakang baru-baru ini di perpustakaan NPM paling populer telah membuat banyak orang berpikir tentang seberapa besar kami mempercayai kode pihak ketiga dan seberapa berani kami menggunakannya dalam proyek-proyek kami (sehingga berpotensi menggantikan pengguna produk kami).
Tetapi bahkan berbulan-bulan sebelum "guntur melanda",
Felix Kraus (dikenal oleh pengembang ponsel sebagai pencipta Fastlane) berbicara di konferensi Pius 2018 Piter kami tentang hal yang serupa: kepercayaan pengembang ponsel kepada SDK pihak ketiga. Jika kita mengunduh SDK populer dari perusahaan terkenal, apakah semuanya baik-baik saja di sana, atau dapatkah terjadi kesalahan juga? Di mana vektor serangan dan apa yang harus kita pikirkan dalam hal ini?
Dan sekarang kami telah menyalin dan menerjemahkan laporannya - jadi di bawah potongan Anda setidaknya dapat menonton video asli, setidaknya membaca versi teks berbahasa Rusia. Karena Kraus terlibat dalam pengembangan iOS, semua contoh juga dari iOS, tetapi pengembang Android dapat mengabaikan contoh spesifik dan juga memikirkannya.
Keamanan SDK
Setelah melihat SDK mana yang paling populer dalam pengembangan iOS hari ini, saya memutuskan untuk menyelidiki seberapa rentan mereka terhadap serangan jaringan yang paling umum. Sebanyak 31% dari mereka ternyata menjadi korban potensial untuk serangan sederhana orang-di-tengah, yang berarti bahwa peretas menyuntikkan kode berbahaya ke dalam SDK.
Tetapi secara umum, apakah perlu takut? Apa hal terburuk yang dapat dia lakukan dengan SDK Anda? Apakah ini semua sangat serius? Anda harus memahami bahwa SDK yang termasuk dalam bundel aplikasi Anda berjalan dalam ruang lingkupnya - yaitu, SDK mendapatkan akses ke semua yang beroperasi pada aplikasi Anda. Jika pengguna mengizinkan akses aplikasi ke data geolokasi atau, katakanlah, foto, maka data ini juga tersedia untuk SDK (tidak diperlukan izin tambahan). Data lain yang dapat diakses dari SDK: data terenkripsi iCloud, token API, dan di samping itu, semua Tampilan UIKit berisi banyak informasi berbeda. Jika seorang hacker mencegat SDK yang memiliki akses ke data semacam ini, maka konsekuensinya, seperti yang Anda tahu, bisa sangat serius. Pada saat yang sama, semua pengguna aplikasi akan terpengaruh secara bersamaan.
Bagaimana tepatnya ini bisa terjadi? Mari kita mundur dan berbicara tentang hal-hal dasar jaringan dan penyalahgunaannya.
Jaringan
Saya memperingatkan Anda bahwa penjelasan saya tidak akan 100% akurat dan terperinci. Tujuan saya adalah menyampaikan esensi, jadi saya akan menyajikan semuanya dalam bentuk yang agak disederhanakan. Jika Anda tertarik dengan detailnya, maka saya sarankan Anda melihat blog saya atau menjelajahi topiknya sendiri.
Seperti yang Anda ingat, perbedaan utama antara protokol HTTPS dan protokol HTTP adalah enkripsi data selama transmisi. Kurangnya enkripsi dalam HTTP, pada umumnya, berarti bahwa setiap host yang terletak di dalam jaringan, jika diinginkan, dapat dengan bebas mendengarkan dan memodifikasi paket yang dikirimkan melalui itu; pada saat yang sama, tidak mungkin untuk memeriksa apakah integritas paket telah dilanggar. Semua ini berlaku untuk jaringan Wi-Fi publik, dan yang dilindungi kata sandi, serta jaringan Ethernet lokal.
Saat menggunakan HTTPS, host jaringan juga dapat mendengarkan paket yang dikirimkan, namun, mereka tidak memiliki kemampuan untuk membukanya - hanya metadata paket yang terlihat, khususnya, alamat host pengirim dan penerima. Selain itu, HTTPS memberikan verifikasi: setelah menerima paket, Anda dapat memeriksa apakah telah mengalami perubahan selama perjalanan.
Sebelumnya, semuanya bekerja sebagai berikut. Saat Anda memasukkan "google.com" di bilah alamat tanpa menentukan protokol, secara default browser mengirim permintaan Anda melalui HTTP. Tetapi karena server Google lebih memilih untuk berkomunikasi melalui HTTPS, maka Anda menerima tautan baru (redirect) dengan awalan "https: //". Berikut ini layar dari Charles Proxy (alat pemantauan lalu lintas HTTP / HTTPS) yang menunjukkan ini:
Namun, tautan baru itu sendiri dikirim melalui protokol HTTP. Mudah untuk memahami apa yang salah di sini: baik permintaan maupun responsnya dikirimkan melalui HTTP, yang berarti Anda dapat, misalnya, mencegat paket respons dan mengganti URL lokasi di dalamnya dengan "http: //". Jenis serangan sederhana ini disebut Strip SSL. Hingga saat ini, browser telah belajar bekerja dengan cara yang sedikit berbeda. Tetapi memahami apa arti strip SSL berguna bagi kita lebih jauh.
Terkadang Anda dapat mengingat model jaringan OSI. Saya menganggapnya sebagai sesuatu yang sangat membosankan. Tetapi kemudian dia menemukan bahwa, anehnya, model OSI tidak ada begitu saja dan bahkan dapat berguna.
Kami tidak akan mempertimbangkannya secara rinci. Hal utama yang harus dipahami: semuanya terdiri dari beberapa lapisan yang bertanggung jawab untuk hal-hal yang berbeda dan pada saat yang sama saling berinteraksi secara konstan.
Salah satu lapisan sedang mencoba untuk menentukan alamat MAC mana yang sesuai dengan alamat IP tertentu. Untuk melakukan ini, permintaan siaran khusus dibuat, perangkat yang ditanggapi pertama dicatat, dan kemudian paket dikirim ke sana.
Masalahnya adalah peretas dapat merespons permintaan dengan lebih cepat: "ya, kirim saya semua paket." Ini disebut spoofing ARP atau keracunan cache ARP. Dalam hal ini, skema interaksi Anda dengan Internet berubah menjadi ini:
Semua paket sekarang melewati perangkat peretas, dan jika lalu lintas tidak dienkripsi, itu akan dapat membaca dan menulis. Dalam kasus HTTPS, ada sedikit kemungkinan, tetapi Anda dapat melacak host mana yang Anda akses.
Menariknya, pada kenyataannya, kekuatan yang sama memiliki penyedia Internet dan VPN. Mereka adalah perantara dalam interaksi Anda dengan Internet dan dengan cara yang sama menimbulkan potensi ancaman spoofing ARP.
Tidak ada yang baru dalam pendekatan man-in-the-middle itu sendiri. Tetapi bagaimana tepatnya semua ini berlaku untuk SDK seluler?
Khusus seluler
CocoaPods adalah alat manajemen ketergantungan standar yang digunakan dalam pengembangan iOS. Menggunakan CocoaPods untuk kode sumber terbuka dianggap praktis aman - biasanya di-host di GitHub, biasanya akses melalui HTTPS atau SSH. Namun, saya berhasil menemukan kerentanan berdasarkan penggunaan tautan HTTP.
Faktanya adalah CocoaPods memungkinkan untuk menginstal SDK dengan kode sumber tertutup, dan Anda hanya perlu menentukan URL. Tidak ada verifikasi bahwa lalu lintas akan dienkripsi, dan banyak SDK menawarkan alamat HTTP.
Dalam hal ini, saya mengirim beberapa permintaan tarik ke pengembang CocoaPods, dan segera mereka menyelesaikannya. Sekarang, CocoaPods versi baru memeriksa tautan yang ditentukan pengguna, dan jika tidak terenkripsi, mereka akan menampilkan peringatan. Jadi saran saya adalah: selalu perbarui versi CocoaPods dan jangan abaikan peringatan.
Lebih menarik untuk mempertimbangkan bagaimana pemasangan SDK non-indera bukan dari CocoaPods. Ambil, misalnya, platform Localytics.
Halaman docs.localytics.com tidak dienkripsi. Tampaknya dalam hal ini hal ini dapat diabaikan, karena ini hanya dokumentasi. Tetapi perhatikan bahwa halaman tersebut, antara lain, berisi tautan untuk mengunduh binari. Tautan dapat dienkripsi, tetapi ini tidak menjamin keamanan apa pun: karena halaman itu sendiri akan dikirim melalui HTTP, itu dapat dicegat dan tautannya dapat diganti dengan yang tidak terenkripsi. Pengembang localytics diberitahu tentang kerentanan ini dan itu sudah diperbaiki.
Anda dapat melakukan sebaliknya: jangan mengubah tautan ke HTTP, tetapi tinggalkan HTTPS, tetapi ganti alamat itu sendiri. Menemukan ini akan sangat sulit. Lihatlah dua tautan ini:
Salah satunya milik saya. Yang mana dari pengembang sungguhan, dan mana yang bukan? Cobalah untuk mengerti.
Cek latihan
Kemudian saya memutuskan untuk menguji asumsi saya dengan mencoba pada kenyataannya untuk mengganti konten SDK menggunakan serangan MITM. Ternyata ini tidak begitu sulit. Untuk membangun dan mengoperasikan sirkuit saya, saya hanya perlu beberapa jam untuk menyiapkan alat publik yang paling sederhana.
Saya mempercayakan Raspberry Pi yang biasa untuk mencegat. Termasuk dalam jaringan lokal, dia bisa mendengarkan lalu lintas di dalamnya. Dalam paket yang dicegat, ia harus, pertama, mengganti semua tautan HTTPS dengan tautan HTTP, dan kemudian mengganti semua file .zip Localytics iOS dengan file hack.zip. Semua ini ternyata sederhana dan bekerja dengan keras.
File trollface.jpg muncul di arsip yang dihasilkan, dan baris "Dimodifikasi oleh KrauseFx" muncul di file Info.plist. Berapa banyak yang dibutuhkan untuk serangan seperti itu? Hanya dua syarat:
- Mereka berhasil mendapatkan akses ke jaringan Anda (ingat bahwa untuk penyedia Internet dan VPN ini bukan pertanyaan sama sekali). Berapa banyak rantai kopi dan hotel yang terhubung dengan kami?
- Pengunduhan yang dimulai tidak terenkripsi.
Anda berkata, "tapi saya hanya melihat ikon Secure di browser, yang berarti saya akan baik-baik saja." Dan jika Anda berada di Amazon, maka semuanya akan baik-baik saja, bukan?
Saya sarankan mempertimbangkan situs Amazon. AWS Mobile SDK adalah SDK pribadi mereka, yang mereka berikan kepada pengembang untuk berinteraksi dengan layanan.
Ikon "aman", sebuah situs terkenal, sepertinya tidak menunjukkan apa-apa. Tapi sayang - hanya pada pandangan pertama. Tautan untuk mengunduh SDK ditunjukkan tanpa awalan sama sekali (baik https: // maupun http: //). Dan pada saat yang sama, harus membawa pengguna ke host lain. Karenanya, browser akan beralih dari HTTPS ke HTTP. Seperti yang Anda lihat, di sini unduhan SDK tidak terenkripsi! Saat ini, kerentanan sudah diperbaiki oleh pengembang Amazon, tetapi benar-benar ada tempatnya.
Saya harus mengatakan bahwa pengembangan browser modern juga dilakukan bukan tanpa memperhatikan masalah keamanan. Misalnya, jika Anda memuat halaman menggunakan HTTPS, dan gambar apa pun ditentukan melalui tautan HTTP, maka Google Chrome akan memberi tahu Anda tentang apa yang disebut "konten campuran". Namun tindakan pengamanan semacam itu tidak disediakan untuk unduhan: browser tidak melacak protokol mana yang dipicu untuk tautan unduhan yang ditunjukkan pada halaman. Karena itu, sebagai bagian dari proyek ini, saya menulis kepada pengembang peramban dengan permintaan untuk menyediakan pelacakan konten campuran dan memberi tahu pengguna tentang hal itu.
Pencurian data ID Apple
Sekarang mari kita lihat masalah lain. Pengguna iPhone harus terbiasa dengan jendela sembul yang teratur ini:
Di sebelah kiri Anda melihat versi asli iOS, di sebelah kanan - salinan saya. Tentang betapa mudahnya mensimulasikan jendela yang serupa, saya
menulis di blog saya beberapa bulan yang lalu. Butuh 20 menit untuk membuat ulang tampilan.
iPhone sering meminta data autentikasi iCloud, dan untuk pengguna, alasan permintaan biasanya tetap tidak jelas. Pengguna sudah terbiasa sehingga mereka memasukkan kata sandi secara otomatis. Pertanyaan tentang siapa yang meminta kata sandi - sistem operasi atau aplikasi - tidak muncul begitu saja.
Jika Anda merasa sulit untuk mendapatkan alamat email tempat Apple ID dilampirkan, maka Anda melebih-lebihkan: ini dapat dilakukan baik melalui buku kontak maupun melalui wadah iCloud (jika Anda memiliki akses ke aplikasi iCloud, yang dapat Anda ketahui tentang dari UserDefaults aplikasi ini). Dan pilihan paling sederhana adalah meminta pengguna untuk secara pribadi memasukkan email mereka: secara teori, ini seharusnya tidak mengejutkannya, karena di iOS memang ada semacam jendela yang meminta tidak hanya kata sandi, tetapi juga email.
Saya berpikir: “Bagaimana jika saya mengambil kode ini dari formulir permintaan yang saya miliki dan, dengan bantuan spoofing SDK, menembus banyak aplikasi yang berbeda dengannya untuk mencuri semua kata sandi iCloud? Seberapa sulitkah tugas ini?
Misalkan kita memiliki Mac yang benar-benar bersih, tanpa VPN atau proksi yang diinstal di dalamnya, tetapi pada jaringan yang sama kita memiliki Raspberry Pi kita. Pada Mac dalam Xcode, kami memiliki proyek proyek iOS terbuka yang berisi kode minimum absolut - tampilan peta sederhana dari area tersebut dan tidak lebih.
Sekarang buka browser, pergi ke Amazon Web Services. Temukan halaman AWS Mobile SDK dan ikuti tautan unduhan. Buka paket biner yang diunduh dan seret semua kerangka kerja ke proyek kami di Xcode. Lalu kami mengimpor perpustakaan. Kami bahkan tidak diharuskan untuk memanggil kode apa pun - cukup kode itu akan diunduh. Saya perhatikan bahwa selama seluruh proses Xcode tidak memberikan peringatan apa pun.
Apa yang terjadi ketika mengkompilasi ulang aplikasi? Salinan jendela yang sama muncul di layar, meminta saya untuk masuk ke iTunes Store. Saya memasukkan kata sandi, jendela hilang. Pada saat yang sama menonton log aplikasi, saya melihat bagaimana kata sandi yang saya masukkan langsung ditampilkan di dalamnya - intersepsi data ID Apple selesai. Mudah mengirim data ini ke suatu tempat ke server.
Di sini Anda dapat mengatakan, "Ya, selama pengembangan saya akan segera melihat formulir input ini dan memahami bahwa ada sesuatu yang salah." Tetapi jika Anda memiliki audiensi jutaan pengguna, Anda dapat membuatnya merangkak hanya sekali per seribu, dan tidak diperhatikan selama pengujian.
Dan lagi, berapa banyak yang kami butuhkan untuk melakukan serangan? Itu perlu bahwa komputer kita ada di jaringan (dan Raspberry Pi sudah cukup). HTTP atau HTTPs - dalam hal ini tidak masalah, enkripsi tidak akan menyelamatkan situasi. Semua alat perangkat lunak yang saya gunakan - yang paling sederhana, diambil oleh saya dari akses publik. Pada saat yang sama, saya adalah pengembang biasa, tanpa banyak pengetahuan dan pengalaman peretasan.
Pengambilalihan manajemen
Contoh sebelumnya memperkenalkan kode berbahaya ke dalam aplikasi iOS. Tetapi bagaimana jika kita bisa mengendalikan komputer pengembang secara umum? Kemampuan untuk menjalankan kode pada perangkat Anda, seperti yang Anda tahu, memberi kekuatan luar biasa bagi peretas. Dia akan dapat mengaktifkan akses jarak jauh melalui SSH, menginstal keylogger, dll. Dia akan dapat mengamati Anda kapan saja, merekam tindakan Anda, menggunakan sistem file. Dia juga akan dapat menginstal sertifikat SSL baru dan menggunakannya untuk mencegat semua permintaan yang Anda buat ke jaringan. Singkatnya, seseorang memiliki kesempatan untuk menjalankan kode di komputer Anda - dan Anda sepenuhnya dikompromikan.
Saya berpikir, "SDK iOS mana yang dapat saya gunakan untuk ini?" Ada layanan yang memberi SDK perintah curl dan tautan HTTP dengan output yang diarahkan ke perintah sh. Yaitu, terminal Anda akan mengunduh dan menjalankan skrip shell.
Dengan sendirinya, metode instalasi ini sudah menempatkan Anda pada risiko, jangan lakukan ini. Tetapi dalam kasus ini, protokol HTTP juga digunakan. Lalu apa yang bisa dilakukan?
Misalkan Anda adalah pengguna. Anda pergi ke halaman dokumentasi resmi. Perhatikan fakta bahwa halaman dienkripsi dengan protokol HTTPS - hebat! Anda menyalin perintah, jalankan di rumah. Perintah dijalankan dalam beberapa detik. Apa yang terjadi selama ini?
Dan selama waktu ini, mekanisme serangan sederhana yang melibatkan Raspberry Pi saya berhasil. Skrip shell updateSDK yang dimuat pengguna berisi sedikit kode saya sendiri. Dan sekarang saya diizinkan mengakses komputer Anda dari jarak jauh melalui SSH, dan Anda juga telah menginstal keylogger.
Di sebelah kiri Anda melihat terminal "Anda", dan di sebelah kanan adalah Raspberry Pi saya, yang secara real time sudah menunjukkan semua yang Anda masukkan pada keyboard. Setelah memulai dengan Raspberry Pi SSH, saya masuk menggunakan login dan kata sandi yang baru saja didaftarkan menggunakan keylogger, dan dengan cara ini saya mendapatkan akses penuh untuk mengontrol Mac Anda dan sistem file-nya. Dan juga, mungkin, perusahaan atasan Anda memiliki banyak akses.
Kesimpulannya
Seberapa besar kemungkinan ini terjadi pada Anda? Lagi pula, pengembang masih mencoba menggunakan Wi-Fi aman, membeli VPN.
Secara pribadi, saya juga berpikir bahwa saya berhati-hati sampai suatu hari saya membuka pengaturan Mac saya dan menemukan dalam sejarah lebih dari 200 koneksi ke jaringan Wi-Fi yang tidak aman. Setiap koneksi semacam itu merupakan ancaman potensial. Dan bahkan menggunakan jaringan tepercaya, Anda tidak dapat 100% yakin akan keamanan Anda, karena Anda tidak dapat mengetahui apakah ada perangkat di jaringan ini yang disusupi (seperti yang baru saja kita lihat).
Serangan terhadap jaringan Wi-Fi yang tidak aman sangat umum terjadi. Mereka mudah dipegang di tempat-tempat umum, seperti hotel, kafe, bandara dan, omong-omong, konferensi :) Bayangkan seorang pembicara berbicara tentang beberapa jenis SDK, dan, seperti biasa, sebagian audiens mencoba menginstalnya secara paralel dengan menghubungkan ke Wi-Fi yang diberikan di sini . Dan seperti yang saya katakan, sangat mudah untuk menyalahgunakan hak Anda untuk penyedia jaringan.
Dengan cara yang sama dengan VPN - Anda hanya menyerahkan diri Anda ke penyedia. Dan siapa yang lebih baik untuk percaya - penyedia VPN atau jaringan lokal Anda dan penggunanya? Tidak jelas.
Pada November 2017, saya melakukan penelitian dan menganalisis keberadaan kerentanan yang terdaftar di 41 SDK terpopuler untuk iOS (tidak termasuk SDK dari Google dan Facebook, semuanya dilindungi).
Seperti yang Anda lihat, 31,7% SDK tidak lulus tes. Saya berhasil menginformasikan tentang hampir semua pemasok tentang masalah yang ada. Dari jawaban yang saya terima secara harfiah langsung, masalahnya diselesaikan dalam waktu tiga hari. Lima tim juga bereaksi, tetapi menghabiskan lebih banyak waktu untuk revisi - sekitar sebulan. Tujuh tidak repot-repot menjawab laporan saya sama sekali dan belum mengoreksi apa pun hingga hari ini. Biarkan saya mengingatkan Anda bahwa ini bukan tentang beberapa proyek yang kurang dikenal. Semuanya adalah salah satu SDK paling terkenal dan memiliki puluhan ribu pengguna yang mengembangkan aplikasi iOS menggunakan SDK ini, yang, pada gilirannya, digunakan oleh jutaan pengguna iPhone.
Penting untuk dipahami bahwa pengguna aplikasi tertutup selalu menghadapi risiko yang lebih besar, sementara pengguna aplikasi open source menggunakan lebih sedikit. Anda tidak dapat memeriksa cara kerja aplikasi yang ditutup. Sangat sulit untuk menilai apakah ia memiliki solusi yang aman. Anda dapat membandingkan hash dan jumlah hash, tetapi dengan melakukannya Anda akan dapat memverifikasi keberhasilan unduhan. Sebaliknya, Anda dapat meneliti produk-produk open source secara menyeluruh, di sepanjang dan di seberang, yang berarti Anda dapat memberi Anda perlindungan lebih.
Selain serangan man-in-the-middle, ada juga yang lain. Seorang hacker dapat menyerang server dari mana SDK sedang diunduh. Juga terjadi bahwa perusahaan yang memasok SDK dengan sengaja memasukkan apa yang disebut sebagai backdoors dalam kode yang kemudian dapat membuat akses tidak sah ke perangkat pengguna (mungkin pemerintah daerah memerlukan instalasi backdoors, atau mungkin ini adalah inisiatif dari perusahaan itu sendiri).
Dan kami bertanggung jawab atas produk yang kami suplai. Kami harus yakin bahwa kami tidak mengecewakan pengguna dan mematuhi GDPR. Serangan melalui SDK serius karena mereka besar - mereka tidak ditujukan pada satu pengembang, tetapi pada satu juta perangkat pengguna sekaligus. Serangan-serangan ini hampir tidak diperhatikan oleh Anda. Kode sumber terbuka membantu Anda melindungi diri dari hal ini, dengan sumber tertutup semuanya jauh lebih rumit - gunakan hanya ketika Anda dapat memercayainya dengan aman. Terima kasih atas perhatian anda
Jika Anda menyukai laporan ini, perhatikan: St. Petersburg Mobius berikutnya akan diadakan pada 22-23 Mei, tiket sudah dijual , dan secara bertahap harganya menjadi lebih mahal.