Risiko apa yang kita ambil saat memasang sistem "rumah pintar"? Salah satu yang menggerakkan bola lampu dan ketel dari aplikasi di smartphone, di dalam jaringan lokal dan jarak jauh. Jika manajemen keamanan dan kunci terkait dengan sistem pintar (seperti dalam kasus Amazon Key), maka jelas yang mana. Jika tidak, maka secara teoritis dimungkinkan untuk membayangkan bahaya kegagalan perangkat lunak mesin kopi dengan kebakaran berikutnya. Tetapi lebih baik tidak berfantasi, tetapi untuk mengetahui dengan pasti.
Spesialis tim ICS CERT dari Kaspersky Lab memutuskan untuk melakukan uji lapangan di rumah pintar salah satu karyawan perusahaan (
berita ,
posting blog ,
artikel teknis). Peretasan berhasil: pembuat kopi tidak menderita, tetapi mereka berhasil mengendalikan sistem, meskipun dengan beberapa asumsi (cukup realistis) selama percobaan. Salah satu konsekuensi yang tidak menyenangkan dari serangan ini adalah kebocoran data pribadi: koordinat rumah dan, yang paling menyedihkan, geolokasi smartphone. Namun, percobaan berakhir dengan catatan positif: pabrikan sistem rumah pintar berhasil menutup kerentanan.
Interpretasi artistik dari konsekuensi peretasanDalam sebuah artikel teknis, cukup banyak ruang yang didedikasikan untuk hal-hal yang relatif membosankan, tetapi penting: apa yang TIDAK berhasil dalam peretasan, dan bagaimana analisis sistem rumah pintar berjalan untuk kerentanan potensial. Sebelum memulai percobaan, para peneliti sudah mengetahui produsen sistem. Itu ternyata
Fibaro , yang menghasilkan bermacam-macam perangkat sendiri untuk rumah pintar modern, serta menyediakan integrasi dengan perangkat pihak ketiga. Selain itu, pemilik memberikan petunjuk penting - IP permanen untuk masuk ke panel admin. Omong-omong, Fibaro sendiri tidak merekomendasikan membuka akses ke pengontrol melalui IP - hanya melalui sistem cloud. Dalam percobaan ini, celah ini sengaja ditinggalkan oleh pemiliknya berperan.
Secara teoritis, sistem seperti itu dapat diserang dalam tiga arah utama: coba meretas perangkat kontrol dengan satu atau lain cara, mencari kerentanan di bagian cloud dari layanan, atau menyerang perangkat IoT yang terhubung ke controller itu sendiri. Dalam kasus terakhir, diperlukan untuk berada di dekat mereka, sehingga dua opsi pertama terlihat lebih menjanjikan.
Langkah selanjutnya adalah menganalisis firmware perangkat dan WebAPI. Biasanya, pada analisis seperti itu, semuanya berakhir, dan berita keluar dengan gaya "kata sandi kabel terdeteksi di perangkat." Tetapi dalam kasus Fibaro, tidak ada lubang keamanan yang jelas. Tetapi informasi yang berguna diterima tentang implementasi bagian dari logika kontrol dalam PHP. Tanpa otorisasi, pengontrol hanya memberikan nomor seri perangkat, dan informasi ini tidak berguna untuk memecahkan sepotong besi. Tetapi, ternyata, ini memungkinkan Anda untuk meretas bagian cloud dari layanan.
Akses ke cloud, pada gilirannya, memungkinkan Anda untuk mendapatkan cadangan basis data SQLite yang berisi semua pengaturan perangkat tanpa otorisasi dan mengunggah milik Anda. Secara teoritis, melewati otorisasi memungkinkan (sebelum memperbaiki kerentanan) untuk mengunduh salinan cadangan dari semua pengguna sistem cloud. Analisis basis nyata dari perangkat yang diserang memberikan akses ke informasi pribadi, termasuk koordinat rumah dan smartphone tempat aplikasi kontrol diinstal. Ini sudah merupakan masalah serius, karena (dengan beberapa batasan) ini memungkinkan Anda untuk menentukan kapan pemilik sistem tidak ada di rumah.
Selain itu, database memiliki informasi lengkap tentang perangkat IoT yang terhubung, serta kata sandi untuk mengakses pengaturan, tetapi hash dengan penambahan "garam". Analisis firmware menunjukkan bahwa "garam" tidak acak, tetapi dijahit dengan kuat ke dalam perangkat. Secara teoritis, kata sandi yang sangat sederhana dapat dipecahkan, tetapi dalam kasus ini tidak berhasil. Basis SQLite juga berisi kata sandi terbuka untuk menghubungkan ke perangkat lain dalam jaringan: jika kata sandi ini bertepatan dengan yang utama, pengontrol juga dapat dengan mudah dipecahkan.
Tetapi sekali lagi itu tidak berhasil: pemilik sistem terbiasa dengan rekomendasi keamanan dasar dan tidak menggunakan kata sandi yang sama untuk perangkat yang berbeda. Karena itu, saya harus menerapkan rekayasa sosial. Kerentanan dalam sistem cloud yang memungkinkan sejumlah tindakan dilakukan tanpa otorisasi, hanya mengetahui nomor seri perangkat (yang diberikan "gratis" jika ada akses ke panel admin dari luar), membuat skenario berikut ini mungkin. Cadangan perangkat yang disiapkan di mana skrip berbahaya ditanamkan diunggah ke "cloud". Pesan tentang perlunya "memperbarui" perangkat melalui kemampuan reguler sistem cloud dikirim ke pemilik (melalui email dan SMS).
Karena pemilik sistem tahu tentang percobaan, ia segera menyadari bahwa ini bukan tambalan nyata. Tetapi secara umum, ini adalah skenario yang sangat nyata, ketika pengguna menerima pesan yang masuk akal melalui saluran komunikasi yang biasa, sehingga cadangan dipasang. Kode berbahaya dieksekusi dengan hak sistem karena kesalahan pada kode PHP yang menyebabkan skrip bash dieksekusi:
Di sini, parameter yang ditetapkan oleh pengguna (dalam kondisi normal, bahkan administrator sistem tidak memiliki hak pengguna super pada perangkat) masuk ke argumen untuk baris perintah. Verifikasi argumen yang tidak memadai memungkinkan kami untuk mengeksekusi kode arbitrer dengan hak akses root dan akhirnya mendapatkan kontrol penuh atas perangkat. Secara paralel, kemungkinan injeksi SQL ditemukan, tetapi tidak digunakan:
Para peneliti tidak berencana untuk memecahkan pembuat kopi di rumah nyata, sehingga mereka mengubah melodi jam alarm sebagai "halo". Kerentanan yang disebutkan dalam sistem cloud dan dalam kode pengontrol ditutup. Untuk alasan yang jelas, metode khusus untuk menghindari perlindungan tidak diungkapkan dalam artikel teknis - untuk menghindari penggunaannya oleh penyerang nyata pada perangkat yang belum diperbarui. Namun dalam percobaan ini, apa yang biasanya tertinggal di luar tajuk utama ditunjukkan dengan baik dalam percobaan ini: ada banyak cara untuk menyelidiki perlindungan perangkat, yang sebagian besar berakhir tanpa hasil. Dalam pengalaman nyata, baik produsen perangkat dan pemiliknya dapat menghindari kesalahan keamanan yang paling sederhana, seperti kata sandi yang tertanam dan dapat digunakan kembali. Namun demikian, sejumlah masalah yang cukup diidentifikasi yang dapat menyebabkan setidaknya kebocoran data pribadi, dan dalam kasus terburuk, untuk memotong sistem keamanan.
Penafian: Pendapat yang diungkapkan dalam intisari ini mungkin tidak selalu bertepatan dengan posisi resmi Kaspersky Lab. Para editor yang terhormat umumnya merekomendasikan untuk memperlakukan setiap pendapat dengan skeptis yang sehat.