Setelah rilis terbaru teknologi AirTags Apple, saya bertanya-tanya apakah sistem pencarian offline "Temukan Saya" dapat disalahgunakan untuk mengunggah data sewenang-wenang ke Internet dari perangkat yang tidak terhubung ke WiFi atau Internet seluler. Data ini dapat disiarkan melalui Bluetooth Low Energy dan diambil oleh perangkat Apple terdekat. Perangkat ini, segera setelah mereka terhubung ke Internet, akan segera meneruskan data ini ke server Apple, dari mana data tersebut nantinya dapat diambil. Teknik seperti itu dapat digunakan oleh sensor kecil di lingkungan yang tidak terkendali, agar tidak membuang energi ekstra menggunakan Internet seluler. Selain itu, mungkin menarik untuk mencuri data dari tempat yang dilindungi oleh sangkar Faraday, jika seseorang dengan iPhone hanya melihat ke sana.
Secara teoritis, ini seharusnya mungkin: jika Anda berhasil meniru dua AirTag, maka Anda dapat menyandikan data dengan mengaktifkan hanya salah satunya pada waktu tertentu. Dalam hal ini, perangkat penerima harus memeriksa AirTag mana yang aktif pada jam berapa dan mendekode data kembali ke bentuk aslinya. Namun, skema seperti itu tampaknya sangat tidak dapat diandalkan dan, mungkin, tidak cocok untuk digunakan dalam situasi praktis nyata karena bandwidth transmisi data yang sangat sempit (terutama dengan mempertimbangkan batasan 16 AirTag pada ID Apple , tampaknya jumlah data ditransfer tidak dapat melebihi beberapa bit per jam).
Oleh karena itu, kelayakan ide ini tergantung pada bagaimana sistem dirancang dan diimplementasikan. Ternyata keputusan untuk memastikan keamanan dan privasi yang dibuat saat merancang mekanisme offline menunjukkan bahwa kasus yang kami usulkan sangat efektif sebagai metode penetrasi, dan hampir tidak mungkin untuk mempertahankannya.
Hasil: Ekstrak data yang ditransfer / diunduh sebelumnya menggunakan aplikasi Mac khusus
- Anda dapat mengunduh data sewenang-wenang dari perangkat yang tidak terhubung ke Internet dengan menyiarkan pesan Cari Saya melalui teknologi BLE (Bluetooth Low Energy) ke perangkat Apple terdekat, yang kemudian mengunduh data untuk Anda
- ESP32, ( ) macOS, , : https://github.com/positive-security/send-my
- , - Find My, ,
Temukan modem Saya (ESP32) // Temukan modem Saya (ESP32)
Perangkat Apple Terdekat //
Menara Seluler Apple Terdekat atau Titik Akses Wifi // Menara Seluler atau Titik Akses Wifi
Perangkat macOS dengan aplikasi pengambilan data // perangkat macOS dengan aplikasi untuk mengambil data
Aliran data // aliran data
.
Deskripsi jaringan pencarian offline
Untungnya, protokol ini sebagian besar telah direkayasa balik oleh sekelompok peneliti dari Universitas Teknologi Darmstadt, yang menerbitkan artikel “Siapa yang Dapat Menemukan Perangkat Saya ? “Pada bulan Maret 2021 dan untuk bukti konsep merilis implementasi open source OpenHaystack . Dengan implementasi ini, Anda dapat membuat komponen Anda sendiri yang dilacak di jaringan Apple Find My. Terima kasih banyak untuk tim ini! Melalui pekerjaan merekalah pekerjaan kami dapat dilakukan, dan baik firmware kami (juga dilakukan untuk pembuktian konsep) dan aplikasi Mac didasarkan pada OpenHaystack.
Dalam bentuk yang sedikit disederhanakan, prinsip sistem pencarian offline Temukan Saya adalah sebagai berikut:
- AirTag Apple, , , AirTag ( )
- 2 AirTag Bluetooth, , ( 15 )
- , , .., Find My, , ( ECIES)
- Saat mencari perangkat, Perangkat Pemilik yang dipasangkan membuat daftar kunci publik yang dapat diganti yang harus digunakan AirTag dalam beberapa hari terakhir, dan meminta hash SHA256 dari Apple. Backend Apple mengembalikan laporan lokasi terenkripsi untuk kunci yang ID-nya diminta.
- Perangkat pemilik mendekode laporan lokasi dan mengeluarkan perkiraan lokasi.
Server Apple // Server Apple
Perangkat pencari // Mencari perangkat Perangkat
pemilik // Perangkat pemilik Perangkat
hilang // Perangkat hilang
- // Memasangkan pada pengaturan awal
- // Siaran. Presentasi kunci publik Bluetooth
- // Unduh laporan lokasi terenkripsi
- // Unduh dan dekripsi laporan lokasi
Ara. 1. Diagram alir yang disederhanakan dari tugas yang diselesaikan saat perangkat pencarian offline
Desain yang sangat indah ini memiliki karakteristik keamanan, khususnya:
- Melacak perlindungan terhadap penyerang terdekat dengan kunci publik yang dapat dilepas
- Ketidakmampuan untuk menentukan lokasi pengguna Apple
Namun, bagi kami dalam hal ini, yang paling menarik adalah ini: Apple tidak tahu kunci publik mana yang menjadi milik AirTag Anda, dan, karenanya, laporan lokasi mana yang ditujukan kepada Anda. Dengan demikian, titik akhir yang meminta laporan lokasi untuk id kunci tertentu tidak melakukan otorisasi apa pun (tetapi Anda harus mengautentikasi dengan ID Apple Anda untuk mengakses titik akhir).
Semua keamanan dipastikan pada tingkat enkripsi laporan lokasi: lokasi hanya dapat didekripsi dengan kunci pribadi yang benar, dan hanya disimpan di Perangkat Pemilik yang dipasangkan, dan tidak mungkin untuk mengambilnya dengan kekerasan sederhana. menyerang.
Merancang protokol pencurian data
Ini menunjukkan bahwa satu-satunya media yang dapat kita gunakan untuk mengenkripsi data adalah kunci publik EC siaran (misalnya, kita tidak dapat memengaruhi koordinat GPS, karena perangkat "pencari" menambahkannya).
Di bagian selanjutnya, kami akan mempertimbangkan backend Apple sebagai penyimpanan bersama nilai kunci publik, di mana hash SHA256 digunakan sebagai kunci, dan laporan lokasi terenkripsi digunakan sebagai nilai, apalagi, operasi utama adalah sebagai berikut:
- Anda dapat memeriksa apakah ada laporan lokasi untuk hash tertentu apakah SHA256
- Anda dapat menambahkan laporan lokasi ke hash SHA256 tertentu dengan menyiarkan kunci publik yang sesuai
Saya pikir Anda sudah memahami jalannya acara: Anda dapat mengatur bit sewenang-wenang di kunci bersama dan penyimpanan nilai dan menanyakannya lagi. Jika pengirim dan penerima menyetujui skema enkripsi seperti itu, maka data arbitrer dapat ditransmisikan dengan menggunakannya.
Saya memutuskan untuk membangun modem yang menerima pesan melalui antarmuka serial dan kemudian mengulang data itu sampai pesan baru diterima. Untuk memastikan bahwa kami dapat membedakan bit "0" dari bit yang tidak disetel, kami akan menyiarkan kunci publik yang berbeda tergantung pada nilai bit, dan akan meminta penerima untuk kedua kunci publik yang mungkin.
Tidak ada jaminan kapan (atau jika ada) pesan siaran tertentu akan diunggah ke backend Apple sebagai laporan lokasi. Intinya adalah bahwa beberapa paket mungkin tidak menjangkau perangkat Apple apa pun, dan perangkat pencarian mungkin memiliki penundaan yang sangat bervariasi antara menerima pesan siaran dan mengunduh laporan lokasi, yang mungkin bergantung pada konektivitas upstream atau mode daya. Dengan demikian, pengkodean data kami tidak boleh bergantung pada laporan posisi mana yang tiba dan dalam urutan apa, dan juga memungkinkan pemulihan aliran data yang diterima sebagian - yang sebagian bitnya benar-benar hilang. Untuk mencapai ini, saya memutuskan untuk mengenkripsi satu bit data per siaran, bersama dengan nilai indeks yang menunjukkan,bit pesan mana yang diatur. Berkat pesan tambahan dan ID modem, sistem ini cocok untuk banyak penggunaan oleh banyak pengguna, menangani banyak pesan.
Jadi, dengan mengirimkan bit tertentu, kita membuat array 28-byte seperti "[4b bit index] [4b message ID] [4b modem ID] [zeros padding ...] [bit value]", mengoperasikannya sebagai public kunci dan kirim representasi BLE, misalnya, untuk menyiarkan informasi "bit 0 dari pesan 0 adalah 1".
Untuk mengirim pesan lengkap, program hanya mengulangi semua bitnya dan mengirimkan representasi ke bit dengan kunci publik, di mana indeks dan nilai bit ini dienkripsi.
Pesan untuk dikodekan // Pesan untuk dikodekan
Kunci publik yang dibuat untuk disiarkan // Kunci publik yang dibuat untuk siaran
Indeks bit // Indeks
bit Nilai bit // Nilai bit
Enkode bit pesan ke dalam muatan siaran
Saat mengambil data, aplikasi penerima akan menghasilkan yang sama 28 -byte array (dua per bit, di mana nilai bit yang mungkin adalah 0 dan 1) dan meminta layanan Apple dengan hash SHA256 dari "kunci publik" ini. Hanya satu dari kunci ini yang harus memiliki laporan lokasi terlampir, yang kemudian dapat ditafsirkan (misalnya, bit dengan indeks 0 adalah 1).
Bit potensial untuk kueri // Bit yang berpotensi untuk ditanyakan
Kunci publik potensial untuk diuji // Kunci publik yang berpotensi dapat diuji
Kueri Apple Backend // Kueri
keberadaan kunci publik backend Apple Decode kembali ke data asli // Dekripsi kunci publik dengan mendapatkan data mentah
Mengambil data yang sebelumnya dikirim dari perangkat macOS yang terhubung ke Internet
Catatan: Anda dapat mengirim tidak hanya satu bit per pesan, tetapi, misalnya, mengirim seluruh byte, yang akan berisi 8 bit terakhir dari kunci publik. Sementara ini membutuhkan bandwidth transmisi data yang lebih luas, penerima sekarang harus meminta 255 ID kunci yang berbeda untuk memilih / brute force satu byte (bandingkan dengan 16 ID kunci saat pengkodean bitwise).
Penerapan
Sisi pengirim
Di sisi pengirim, saya memutuskan untuk menggunakan ESP32 - mikrokontroler yang benar-benar biasa dan murah (dan tes cepat menunjukkan bahwa itu dapat mengubah alamat MAC BT jauh lebih cepat daripada, katakanlah, Raspberry Pi berbasis Linux). Saat boot, firmware berdasarkan OpenHaystack menyiarkan pesan default yang di-hardcode dan kemudian mendengarkan antarmuka serial (sebagai loop) untuk melihat apakah ada data siaran baru yang tiba - dan seterusnya hingga pesan baru diterima ... Saat menyiarkan kunci publik, kunci tersebut harus dipecah dan dikodekan dalam 6 byte pertama di alamat MAC Bluetooth (semua kecuali dua bit pertama, karena standar Bluetooth mengharuskan dua bit pertama disetel ke 1). Kami merujuk Anda ke Lihat bagian 6.2 artikel Universitas Teknologi Darmstadt , di mana pengkodean buatan sendiri ini dijelaskan secara lebih rinci.
Saya menambahkan awalan statis ke muatan saya sehingga saya tidak akan mengalami masalah dengan spesifikasi BT, dan saya juga menyertakan indeks bit tambahan dalam 6 byte pertama dari kunci publik, sehingga setiap bit yang ditransmisikan memiliki BT MAC sendiri. alamat, untuk berjaga-jaga jika ada tarif berbasis alamat MAC yang membatasi di mana saja di tumpukan.
Keluaran modem ESP32 di konsol serial a
Sisi ekstraksi data
Aplikasi Mac juga didasarkan pada OpenHaystack dan menggunakan trik yang sama dengan plugin AppleMail untuk mengirim permintaan pengambilan lokasi yang diautentikasi dengan benar ke backend Apple. Pengguna diminta untuk memasukkan ID modem 4-byte (dapat diatur selama firmware ESP), setelah itu aplikasi akan secara otomatis memilih, mendekode dan menampilkan pesan dengan id 0. Kemudian pengguna dapat memilih pesan lain atau mengubah modem .
Pesan diambil 16 byte (128 bit) sekaligus (256 id kunci diminta) hingga tidak ada laporan yang tersisa (untuk seluruh byte).
Komplikasi kecil: kedaluwarsa kunci publik
Setelah menerapkan sisi pengirim dan penerima, saya menjalankan tes pertama dengan menyiarkan dan mencoba mendapatkan nilai 32-bit. Setelah beberapa menit, saya bisa mendapatkan 23 dari 32 bit, masing-masing pasti benar dan dengan sekitar 100 laporan lokasi, tetapi saya tidak mendapatkan laporan seperti itu untuk 9 bit yang tersisa.
Dicurigai bahwa beberapa kunci publik yang dihasilkan ditolak oleh perangkat Apple terdekat selama fase enkripsi ECIES sebagai kunci publik yang tidak valid - dan ini dengan cepat dikonfirmasi dengan mencoba memuat setiap muatan yang dihasilkan sebagai kunci publik yang disandikan SEC-1 pada kurva P224 menggunakan Paket fastecdsa Python: untuk setiap bit yang laporan lokasinya tidak saya miliki, mikrokontroler menyiarkan kunci publik, melemparkan pengecualian InvalidSEC1PublicKey saat mengimpor kunci fastecdsa.
Sedikit konteks enkripsi yang digunakan di sini:
- Publik EC 28-byte mewakili koordinat X dari titik tertentu, yang dikodekan dengan SEC1.
- Kunci publik SEC1 biasanya juga memiliki bit "tanda" yang menentukan yang mana dari dua kemungkinan koordinat Y untuk koordinat X tertentu yang harus dikodekan. Bit ini tidak ditransmisikan selama siaran dan tidak penting untuk tanggal kedaluwarsa kunci publik.
- Saat mendekode kunci publik terkompresi, koordinat Y yang sesuai dihitung menggunakan parameter kurva tetap dan diverifikasi jika kuncinya valid. Beberapa kunci publik yang dihasilkan gagal dalam pengujian ini. Untuk lebih jelasnya lihat bagian 3.2.2 dalam artikel " Validasi kunci publik pada kurva eliptik ":
Masalah dengan kunci publik yang tidak valid ini dapat diselesaikan setidaknya dengan dua cara:
Keuntungan dari opsi kedua adalah bahwa untuk setiap bit yang diterima, kami juga dapat mendekripsi laporan lokasi untuk menentukan pada titik mana bit yang diberikan diterima, tetapi ini memerlukan pemrosesan komputasi yang lebih sedikit. Saat menerapkan opsi ini, saya menemukan bahwa karena bug dalam implementasi perkalian kurva elips di perpustakaan uECC yang digunakan untuk ini, untuk beberapa kunci pribadi ESP menghitung kunci publik yang berbeda dari BoringSSL di Mac dan fastecdsa di Python (fuzzing diferensial secara tidak sengaja merayap masuk? ). Kunci publik ini bahkan dianggap tidak valid oleh fungsi uECC_valid_public_key() uECC sendiri. Oleh karena itu, dalam proyek percontohan ini, saya memilih opsi 1.
Pesan untuk dikodekan // Pesan yang disandikan
Hasilkan kunci publik untuk dikodekan // Buat kunci publik untuk menyandikan
alamat MAC BT // Alamat MAC BT
Uji validitas, penghitung kenaikan lain // Periksa apakah kuncinya valid, jika tidak, tingkatkan penghitung sebesar satu
Muatan iklan // Muatan untuk presentasi
Mengkodekan dan mengirim pesan
Pengujian / Kinerja
Ketika kami telah menerapkan pemeriksaan validasi kunci publik, semuanya bekerja dengan sempurna. Saya belum melakukan pengujian kinerja yang ekstensif atau melakukan pengukuran, tetapi berikut adalah beberapa perkiraan:
- ~3 . ,
- - Mac. 16 ~5
- 1 60 , , , . . , , , , ( , Apple)
CDF // Fungsi distribusi kumulatif
Median… min // Median… 26,3 menit.
Penundaan publikasi (min) // Penundaan sebelum publikasi (min.)
Gbr. 8. Keterlambatan penerimaan semua laporan, yang dipertimbangkan dalam 7.1 sebagai fungsi distribusi kumulatif
Keterlambatan penerimaan laporan, diukur oleh tim dari Universitas Teknologi Darmstadt, berdasarkan materi "Siapa yang Dapat Menemukan Perangkat Saya?"
Potensi Penggunaan
Sementara saya terutama tertarik untuk memeriksa kelayakan dari apa yang saya jelaskan, saya pikir aplikasi praktis yang paling umum adalah mengunduh pembacaan sensor atau data apa pun dari perangkat IoT tanpa modem broadband, kartu SIM, paket data, atau konektivitas Wifi. Mengingat Amazon menggunakan jaringan serupa yang disebut Trotoar menggunakan perangkat Echo, mungkin ada permintaan untuk teknologi semacam itu. Karena cache pencari mengakumulasi siaran yang diterima, tetap di sana sampai koneksi internet dibuat, sensor dapat mengirim data bahkan dari area tanpa jangkauan jaringan seluler, jika orang dengan perangkat berjalan di tempat tersebut.
Dalam dunia jaringan keamanan tinggi , di mana teknologi yang menggabungkan laser dan pemindai tampaknya menjadi trik yang menjanjikan untuk menutup celah udara, perangkat Apple yang dibawa pengunjung juga dapat bertindak sebagai perantara yang layak untuk mencuri data dari sistem celah udara .atau ruangan yang dilindungi oleh sangkar Faraday.
Tampaknya juga protokol penemuan offline dapat digunakan untuk mengalirkan lalu lintas di iPhone terdekat yang terhubung ke tarif tak terbatas . Dengan membatasi jumlah laporan lokasi yang dapat dikirim dari satu pencari (255 laporan / pengiriman karena jumlah byte adalah 1), dan dengan setiap laporan melebihi 100 byte, menyiarkan banyak kunci publik unik dapat menyebabkan peningkatan yang signifikan. dari smartphonenya. Meskipun saya tidak melihat adanya batasan frekuensi untuk laporan lokasi keluar, saya juga tidak menguji seberapa banyak data yang dapat dikonsumsi.
Bagaimana cara mengatasi masalah
Seperti yang saya sebutkan di awal, akan sulit bagi Apple untuk bertahan melawan penyalahgunaan semacam ini jika mereka memilih untuk melakukannya.
Apple merancang sistem dengan mempertimbangkan ekonomi data. Mereka tidak dapat membaca lokasi yang tidak dienkripsi dan tidak tahu kunci publik mana yang menjadi milik AirTag Anda, atau bahkan kunci publik mana yang dikaitkan dengan laporan lokasi terenkripsi tertentu (karena mereka hanya menerima hash SHA256 dari kunci publik).
Dalam hal ini, batas 16 AirTags yang disebutkan untuk ID Apple menarik, karena menurut saya saat ini Apple tidak dapat mewajibkan untuk menggunakannya.
Namun, pengetatan lebih lanjut dari sistem ini dimungkinkan, misalnya, di dua area berikut:
- BLE. , , AirTag OpenHaystack, AirTag . , , , BLE , , AirTag , , .
- Apple , id id AirTag, id , 15 16 id Apple ID ( id ). , , : Apple ID .
Pada artikel ini, kami menjawab pertanyaan apakah mungkin mengunduh data sewenang-wenang menggunakan perangkat Apple milik pengguna lain: pasti ya.
Firmware modem ESP32 dan aplikasi untuk mengekstrak data untuk macOS telah diimplementasikan, diposting di Github , Anda dapat bereksperimen dengannya.
Perhatikan bahwa implementasi ini hanyalah "bukti kelayakan", dan "protokol" itu sendiri tidak dienkripsi atau diautentikasi. Misalnya, Anda dapat memeriksa detail modem dengan ID 0x42424242 hanya dengan memasukkan ID-nya (mungkin sementara itu seseorang juga dapat menunjukkan bahwa tidak ada otentikasi dalam protokol ini).
Satu catatan terakhir: Saat mempersiapkan posting ini, saya perhatikan bahwa "status byte" yang disertakan dalam tampilan BLE jelas digunakan, misalnya, sebagai indikator level baterai. Dikombinasikan dengan kunci pribadi yang dihasilkan secara deterministik yang diputar, ini mungkin membuka lubang kebocoran data lain (byte per tampilan), tetapi saya belum menguji pendekatan ini.
Server cloud dari Macleod cepat dan aman.
Daftar menggunakan tautan di atas atau dengan mengklik spanduk dan dapatkan diskon 10% untuk bulan pertama menyewa server dengan konfigurasi apa pun!
