Check Point Research menemukan kerentanan dalam SQLite yang memungkinkan peretasan iPhone

Check Point Research menemukan kerentanan dalam SQLite yang memungkinkan peretasan iPhone.

• SQLite adalah sistem manajemen basis data tempat kontak iPhone disimpan
• Sistem lain yang menggunakan SQLite adalah Windows 10, MacOS, Chrome, Safari, Firefox dan Android

Periksa Point® Software Technologies Ltd. (NASDAQ: CHKP), penyedia cybersecurity global terkemuka, telah menemukan kerentanan yang memengaruhi SQLite, sistem manajemen basis data yang paling banyak digunakan secara global. Melalui kerentanan ini, kejahatan dunia maya bisa mendapatkan kendali atas iPhone, karena kontak perangkat ini disimpan dalam jenis database ini.

“Terlepas dari kepercayaan yang tersebar luas bahwa iPhone adalah perangkat yang lebih aman, kerentanan ini menunjukkan bahwa mereka juga dapat diretas. Penting bagi pengguna untuk mempertimbangkan keamanan komputer dan ponsel mereka, karena pengguna dapat mengambil kendali dan mencuri semua informasi yang tersimpan. ", kata Eusebio Nieva, direktur teknis Check Point untuk Spanyol dan Portugal.

SQLite Ini adalah sistem manajemen basis data yang tersedia di semua sistem operasi, komputer dan ponsel. Sebagai contoh Windows 10, MacOS, iOS, Chrome, Safari, Firefox dan Android adalah pengguna SQLite yang populer. Menjadi salah satu perangkat lunak yang paling banyak digunakan di dunia, banyak program memasukkannya untuk tujuan yang berbeda. Misalnya, selain kasing iPhone, Mac juga menyimpan beberapa kata sandi pada sistem ini. Melalui kerentanan ini, dimungkinkan untuk mengontrol sistem apa pun yang meminta basis data yang dikontrol oleh SQLite.

Mengingat fakta bahwa SQLite sangat populer, ada kemungkinan tak terbatas untuk mengeksploitasi kerentanan ini. Check Point telah membuat demo untuk membuktikannya di iOS iPhone, yang telah dipresentasikan pada acara Def Con 2019. Dengan mengambil keuntungan dari kerentanan ini, akan mungkin untuk menghindari mekanisme boot aman Apple dan dapatkan izin administrator di iPhone terbaru. Check Point telah menjadi pelopor dalam mendemonstrasikan kerentanan SQLite yang tidak bergantung pada browser.

“Sampai sekarang, berkonsultasi dengan basis data tidak pernah dianggap berbahaya, tetapi penelitian kami telah menunjukkan hal itu bisa terjadi. Karena SQLite sangat populer, kerentanan ini telah menjadi peluang besar untuk dieksploitasi. Kesalahan serius dalam SQLite adalah kesalahan serius di beberapa teknologi yang paling banyak digunakan di dunia, seperti iPhone, Dropbox, Adobe atau Skype", simpul Nieva.

Check Point termasuk dalam solusi keamanannya sistem pencegahan intrusi (IPS) yang memastikan pengguna tidak terpengaruh oleh jenis pelanggaran perangkat lunak.

Untuk informasi lebih lanjut tentang kerentanan ini, silakan kunjungi: https://research.checkpoint.com/select-code_execution-from-using-sqlite/

Kami meninggalkan Anda entri yang diterjemahkan.

Dapatkan eksekusi kode menggunakan database SQLite berbahaya Penelitian oleh: Omer Gull

SQLite adalah salah satu perangkat lunak yang paling banyak diterapkan di dunia. Namun, dari sudut pandang keamanan, itu hanya diperiksa melalui lensa WebSQL dan eksploitasi browser. Kami percaya ini hanyalah puncak gunung es.

Dalam penyelidikan jangka panjang kami, kami bereksperimen dengan eksploitasi masalah korupsi memori dalam SQLite tanpa mengandalkan lingkungan apa pun selain bahasa SQL. Menggunakan pembajakan kueri inovatif dan teknik pemrograman berorientasi permintaan, kami menunjukkan bahwa adalah mungkin untuk mengeksploitasi masalah korupsi memori secara andal di mesin SQLite. Kami mendemonstrasikan teknik ini dalam beberapa skenario dunia nyata: membuat server pencuri kata sandi dan mencapai kegigihan iOS dengan hak istimewa yang lebih besar.

Kami berharap bahwa dengan meluncurkan penelitian dan metodologi kami, komunitas riset keamanan akan terinspirasi untuk terus memeriksa SQLite dalam skenario yang tak terhitung jumlahnya di mana itu tersedia. Mengingat fakta bahwa SQLite secara praktis terintegrasi ke dalam semua sistem operasi utama, komputer desktop atau perangkat seluler, lanskap dan peluang tidak ada habisnya. Selain itu, banyak primitif yang disajikan di sini tidak eksklusif untuk SQLite dan dapat diangkut ke mesin SQL lainnya. Selamat datang di dunia baru yang berani dalam menggunakan bahasa permintaan terstruktur yang sudah dikenal untuk primitif eksploitasi.

Motivasi

Investigasi ini dimulai ketika omriher dan saya sedang melihat kode sumber yang bocor dari beberapa pencuri kata sandi yang terkenal. Meskipun ada banyak pencuri kata sandi ( Azorult , Loki Bot dan Kuda poni, untuk beberapa nama), modus operandi nya hampir sama:

Komputer menjadi terinfeksi dan malware menangkap kredensial ketika kredensial tersimpan yang dikelola oleh beberapa klien digunakan atau dikumpulkan.
Tidak jarang perangkat lunak klien menggunakan database SQLite untuk tujuan tersebut.
Setelah malware mengumpulkan file-file SQLite ini, ia mengirimkannya ke server C2 di mana mereka dianalisis menggunakan PHP dan disimpan dalam database kolektif yang berisi semua kredensial curian.

Membaca kode sumber yang disaring dari pencuri kata sandi tersebut, kami mulai berspekulasi pada permukaan serangan yang dijelaskan di atas.
Bisakah kita mengambil keuntungan dari pemuatan dan konsultasi dari basis data yang tidak dapat diandalkan untuk keuntungan kita?
Kemampuan seperti itu bisa memiliki implikasi yang jauh lebih besar dalam skenario yang tak terhitung jumlahnya SQLite adalah salah satu perangkat lunak yang paling banyak diimplementasikan .

Basis kode yang sangat kompleks, tersedia di hampir semua perangkat yang bisa dibayangkan. Itu semua motivasi yang kami butuhkan, dan perjalanan kami pun dimulai.

Pengantar SQLite

Ada banyak kemungkinan saat ini Anda menggunakan SQLite, bahkan jika Anda tidak mengetahuinya.
Mengutip penulisnya:

SQLite adalah pustaka bahasa-C yang mengimplementasikan mesin basis data SQL kecil, cepat, otonom, keandalan tinggi, berfitur lengkap. SQLite adalah mesin basis data yang paling banyak digunakan di dunia. SQLite terintegrasi ke semua ponsel dan sebagian besar komputer dan termasuk dalam aplikasi yang tak terhitung jumlahnya yang digunakan orang setiap hari.

Tidak seperti kebanyakan database SQL lainnya, SQLite tidak memiliki proses server yang terpisah. SQLite membaca dan menulis langsung ke file disk normal. Database SQL lengkap dengan beberapa tabel, indeks, pemicu, dan tampilan terkandung dalam satu file disk.

Serang permukaan

Fragmen berikut adalah contoh umum dari backend pencurian kata sandi.

Karena kami mengontrol basis data dan kontennya, permukaan serangan yang tersedia bagi kami dapat dibagi menjadi dua bagian: pemuatan dan analisis awal dari basis data kami, dan kueri SELECT yang dibuat menentangnya.

Beban awal yang dibuat oleh sqlite3_open sebenarnya adalah area yang sangat terbatas; Pada dasarnya sejumlah besar kode instalasi dan konfigurasi untuk membuka database. Permukaan kami terutama analisis menuju yang diuji dalam pertempuran melawan AFL.

Segalanya menjadi lebih menarik ketika kita mulai berkonsultasi dengan basis data.
Menggunakan kata-kata penulis SQLite:

"Pernyataan SELECT adalah perintah yang paling rumit dalam bahasa SQL."

Meskipun kami tidak memiliki kontrol atas permintaan itu sendiri (karena dikodifikasikan dalam tujuan kami), mempelajari proses SELECT dengan hati-hati akan bermanfaat dalam pencarian kami untuk eksploitasi.

Karena SQLite3 adalah mesin virtual, setiap pernyataan SQL pertama-tama harus dikompilasi dalam program kode byte menggunakan salah satu rutinitas sqlite3_prepare * .
Di antara operasi lain, fungsi persiapan melintasi dan memperluas semua subqueries SELECT. Bagian dari proses ini adalah untuk memverifikasi bahwa semua objek yang relevan (seperti tabel atau tampilan) benar-benar ada dan menempatkannya dalam skema master.

sqlite_master dan DDL

Setiap database SQLite memiliki sqlite_mastertabel yang mendefinisikan skema untuk database dan semua objeknya (seperti tabel, tampilan, indeks, dll.).
Tabel sqlite_master didefinisikan sebagai:

Bagian yang menarik bagi kami adalah kolom sql.
Bidang ini adalah DDL (bahasa definisi data) yang digunakan untuk menggambarkan objek.
Dalam arti tertentu, perintah-perintah DDL mirip dengan file-file header C. Perintah-perintah DDL digunakan untuk mendefinisikan struktur, nama-nama dan tipe-tipe wadah data dalam suatu database, seperti halnya file header. Biasanya mendefinisikan definisi jenis, struktur, kelas dan struktur data lainnya.

Pernyataan DDL ini benar-benar muncul dalam teks biasa jika kita memeriksa file database:

Selama persiapan kueri, sqlite3LocateTable () mencoba menemukan struktur dalam memori yang menggambarkan tabel yang kami tertarik untuk berkonsultasi.

sqlite3LocateTable () membaca skema yang tersedia di sqlite_master, dan jika ini pertama kali terjadi, ia juga memiliki panggilan balik untuk setiap hasil yang memverifikasi bahwa deklarasi DDL valid dan membuat struktur data internal yang diperlukan yang menggambarkan objek dalam masalah.

Patch DDL

Kami ingin tahu apakah kami mengetahui tentang proses persiapan ini, dapatkah kami mengganti teks biasa DDL di dalam file? Jika kita bisa menyuntikkan SQL kita sendiri ke dalam file, mungkin kita bisa memengaruhi perilakunya.

Menurut cuplikan kode di atas, tampaknya instruksi DDL harus dimulai dengan "create."
Dengan keterbatasan ini, kami perlu mengevaluasi permukaan kami.
Memeriksa dokumentasi SQLite mengungkapkan bahwa ini adalah objek yang mungkin dapat kita buat:

Perintah CREATE VIEW memberi kami ide yang menarik. Sederhananya, VIEW hanya pernyataan SELECT yang telah dikemas sebelumnya. Jika kami mengganti tabel yang diharapkan dengan perangkat lunak target dengan VISTA yang kompatibel, peluang menarik terungkap.

Membajak permintaan apa pun

Bayangkan skenario berikut:
Database asli memiliki TABEL yang disebut dummy yang didefinisikan sebagai:

Perangkat lunak target mengonsultasikannya dengan yang berikut:

Bahkan, kami dapat membajak kueri ini jika kami membuat dummy sebagai VIEW:

"Jebakan" VIEW ini memungkinkan kita untuk membajak kueri, yang berarti kita menghasilkan kueri yang sama sekali baru itu Kami sepenuhnya mengendalikan.

Nuansa ini sangat memperluas permukaan serangan kami, dari analisis header yang sangat minimal dan permintaan yang tidak terkendali yang dibuat oleh perangkat lunak pemuatan, ke titik di mana kita sekarang dapat berinteraksi dengan bagian luas dari juru bahasa SQLite dengan menambal DDL dan menciptakan pandangan kita sendiri . dengan subqueries.

Sekarang kita dapat berinteraksi dengan interpreter SQLite, pertanyaan kita selanjutnya adalah primitif eksploitasi mana yang diintegrasikan ke dalam SQLite? Apakah itu memungkinkan perintah sistem untuk membaca atau menulis ke sistem file?

Karena kami bukan orang pertama yang melihat potensi besar SQLite dari perspektif eksploitasi, masuk akal untuk meninjau pekerjaan sebelumnya yang dilakukan di lapangan. Kami mulai dari dasar.

Injeksi SQL

Sebagai peneliti, sulit bagi kita untuk mengeja SQL tanpa "i", jadi sepertinya ini adalah tempat yang masuk akal untuk memulai. Bagaimanapun, kami ingin membiasakan diri dengan primitif internal yang ditawarkan SQLite. Apakah ada perintah sistem? Bisakah kita memuat pustaka yang sewenang-wenang?

Sepertinya Trik paling sederhana adalah melampirkan file database baru dan menulis ke sana menggunakan sesuatu seperti:

Kami melampirkan database baru, membuat tabel tunggal dan menyisipkan satu baris teks. Database baru membuat file baru (karena database adalah file dalam SQLite) dengan web shell kami di dalamnya.
Sifat pemaaf dari penerjemah PHP menganalisis basis data kami hingga mencapai tag PHP terbuka "<?".
Menulis shell web jelas merupakan kemenangan dalam skenario pencuri kata sandi kami, namun, seperti yang Anda ingat, DDL tidak dapat memulai dengan «ATTACH»

Pilihan lain yang relevan adalah fungsinya load_extension . Meskipun fungsi ini memungkinkan kami untuk memuat objek bersama yang sewenang-wenang, namun dinonaktifkan secara default.

Kerusakan memori dalam SQLite

Seperti halnya perangkat lunak lain yang ditulis dalam C, masalah keamanan memori jelas merupakan sesuatu yang perlu dipertimbangkan ketika mengevaluasi keamanan SQLite.
Sangat hebat posting blog Michał Zalewski menggambarkan bagaimana ia bergabung dengan SQLite dengan AFL untuk mencapai beberapa hasil yang mengesankan: 22 kesalahan hanya dalam 30 menit fuzzing.

Menariknya, SQLite telah mulai menggunakan AFL sebagai bagian integral dari serangkaian tes yang luar biasa.

Korupsi ingatan ini diperlakukan dengan kerasnya yang diharapkan (Richard Hip dan timnya pantas banyak dihormati). Namun, dari sudut pandang penyerang, kesalahan-kesalahan ini akan terbukti sebagai jalan eksploitasi yang sulit tanpa kerangka kerja yang layak untuk memanfaatkannya.
Mitigasi modern merupakan hambatan utama untuk mengeksploitasi masalah korupsi ingatan dan penyerang perlu menemukan lingkungan yang lebih fleksibel.

Komunitas Riset Keamanan akan segera menemukan tujuan sempurna!

SQL web

Web SQL Database adalah API halaman web untuk menyimpan data dalam database yang dapat dikonsultasikan menggunakan varian SQL melalui JavaScript. Kelompok Kerja Aplikasi Web W3C berhenti bekerja pada spesifikasi pada bulan November 2010, mengutip kurangnya implementasi independen selain SQLite.

Saat ini, API masih kompatibel dengan Google Chrome, Opera dan Safari.
Mereka semua menggunakan SQLite sebagai backend dari API ini.

Entri yang tidak dapat diandalkan dalam SQLite, dapat diakses dari situs web mana pun di dalam beberapa peramban paling populer, menarik perhatian komunitas keamanan dan, sebagai akibatnya, jumlah kerentanan mulai meningkat.
Tiba-tiba, kesalahan dalam SQLite dapat dieksploitasi oleh penerjemah JavaScript untuk mencapai eksploitasi browser yang andal.

Beberapa laporan penelitian yang mengesankan telah diterbitkan:

• Buah rendah suka CVE-2015-7036
  • Dereferensi dari penunjuk no fts3_tokenizer yang dapat diandalkan ()
• Keterampilan lebih kompleks disajikan dalam Blackhat 17 oleh tim chaitin
  • Tulis kebingungan pada fts3OptimizeFunc ()
• Kesalahan terbaru Magellan dieksploitasi oleh Keluaran
  • Integer overflow dalam fts3SegReaderNext ()

Pola yang jelas dalam penelitian WebSQL sebelumnya mengungkapkan bahwa modul tabel virtual yang disebut "FTS" bisa menjadi tujuan yang menarik untuk penelitian kami.

FTS

Pencarian teks lengkap (FTS) adalah modul tabel virtual yang memungkinkan pencarian teks dalam satu set dokumen.
Dari perspektif pernyataan SQL, objek tabel virtual menyerupai tabel atau tampilan lainnya. Namun di balik layar, pertanyaan dalam tabel virtual memanggil metode panggilan balik dalam tabel bayangan alih-alih membaca dan menulis ke file database biasa.

Beberapa implementasi tabel virtual, seperti FTS, menggunakan tabel database nyata (non-virtual) untuk menyimpan konten.

Misalnya, ketika sebuah string dimasukkan ke dalam tabel virtual FTS3, beberapa metadata harus dihasilkan untuk memungkinkan pencarian teks yang efisien. Metadata ini disimpan dalam tabel nyata yang disebut "% _segdir" dan "% _segments", sementara konten itu sendiri disimpan dalam ""% _content "di mana"% "adalah nama dari tabel virtual asli.
Tabel bantu aktual ini yang berisi data untuk tabel virtual disebut "tabel bayangan"

Karena sifat tepercaya mereka, antarmuka yang meneruskan data antara tabel bayangan menyediakan lahan subur untuk kesalahan. CVE-2019-8457, – kerentanan baca OOB baru yang ditemukan dalam modul tabel virtual RTREE, membuktikannya dengan baik.

Tabel virtual RTREE, yang digunakan untuk pengindeksan geografis, diharapkan dimulai dengan seluruh kolom. Oleh karena itu, antarmuka RTREE lain mengharapkan kolom pertama dari RTREE menjadi bilangan bulat. Namun, jika kita membuat tabel di mana kolom pertama adalah string, seperti yang ditunjukkan pada gambar berikut, dan meneruskannya ke antarmuka rtreenode () , pembacaan OOB terjadi.

Sekarang kita dapat menggunakan pembajakan kueri untuk mendapatkan kontrol atas kueri dan tahu di mana menemukan kerentanan, sekarang saatnya beralih untuk mengeksploitasi pengembangan.

SQLite Internal untuk mengeksploitasi pengembangan

Publikasi sebelumnya tentang eksploitasi SQLite jelas menunjukkan bahwa lingkungan pembungkus selalu diperlukan, baik itu penerjemah PHP yang terlihat menakjubkan ini. posting blog tentang penyalahgunaan tokenizers SQLite atau karya terbaru di Web SQL dari kenyamanan penerjemah JavaScript.

Karena SQLite praktis ada di mana-mana, sepertinya tidak meyakinkan akan potensi eksploitasi dan kami mulai mengeksplorasi penggunaan komponen SQLite internal untuk tujuan eksploitasi.
Komunitas penelitian menjadi cukup baik dalam menggunakan JavaScript untuk pengembangan eksploitasi. Bisakah kita mencapai primitif serupa dengan SQL?

Mengingat bahwa SQL sudah selesai Turing (( 1 ), ( 2 )), kami mulai membuat daftar keinginan primitif untuk pengembangan eksploitasi berdasarkan pengalaman pwning kami.
Eksploitasi modern yang ditulis secara eksklusif dalam SQL memiliki kemampuan berikut:

• Kehilangan memori
• Mengepak dan membongkar bilangan bulat ke pointer 64-bit.
• Penunjuk aritmatika
• Elaborasi objek palsu yang kompleks dalam memori.
• Heap Spray

Satu per satu, kami akan mengatasi primitif ini dan mengimplementasikannya menggunakan SQL.

Untuk mencapai RCE di PHP7, kita akan menggunakan 1 hari tanpa memperbaiki dari CVE-2015-7036 .

Tunggu sebentar? Bagaimana mungkin kesalahan 4 tahun tidak pernah diperbaiki? Ini benar-benar cerita yang menarik dan contoh yang bagus dari argumen kami.
Fitur ini hanya dianggap rentan dalam konteks program yang memungkinkan SQL sewenang-wenang dari sumber yang tidak tepercaya (Web SQL), sehingga dimitigasi sesuai.
Namun, penggunaan SQLite sangat fleksibel sehingga kami masih dapat mengaktifkannya dalam banyak skenario.

Rencana Permainan Eksploitasi

CVE-2015-7036 adalah kesalahan yang sangat nyaman untuk dikerjakan.
Sederhananya, fungsinya fts3_tokenizer () Rentan mengembalikan alamat tokenizer ketika dipanggil dengan argumen tunggal (seperti "simple", "porter" atau tokenizer terdaftar lainnya).

Ketika dipanggil dengan 2 argumen, fts3_tokenizer menimpa alamat tokenizer di argumen pertama dengan alamat yang disediakan oleh gumpalan di argumen kedua.
Setelah tokenizer tertentu diganti, instance baru dari tabel fts yang menggunakan tokenizer ini memungkinkan kita untuk membajak aliran program.

Rencana permainan eksploitasi kami:

• Kebocoran alamat Tokenizer
• Hitung alamat dasar
• Palsu tokenizer palsu yang akan mengeksekusi kode berbahaya kami
• Batalkan salah satu tokenizer dengan tokenizer berbahaya kami
• Buat instance tabel fts3 untuk mengaktifkan kode berbahaya kami

Sekarang mari kita kembali ke pengembangan exploit kita.

Pemrograman yang berorientasi pada permintaan ©

Kami bangga mempersembahkan pendekatan unik kami sendiri untuk pengembangan eksploit menggunakan bahasa query terstruktur yang sudah dikenal. Kami berbagi QOP dengan komunitas dengan harapan mendorong para peneliti untuk mencari kemungkinan tak terbatas dalam mengeksploitasi mesin basis data.
Masing-masing primitif berikut disertai dengan contoh shell sqlite3.

Meskipun ini akan memberi Anda petunjuk tentang apa yang ingin Anda capai, perlu diingat bahwa tujuan utama kami adalah menanam semua primitif di tabel sqlite_master dan membajak kueri yang dikeluarkan oleh perangkat lunak tujuan yang memuat dan menanyakan file db SQLite berbahaya kami

Kebocoran memori – Biner

Mitigasi seperti ASLR jelas mengangkat bar untuk eksploitasi korupsi memori. Cara yang umum untuk mengalahkannya adalah belajar sesuatu tentang desain ingatan yang mengelilingi kita.
Ini secara luas dikenal sebagai Memory Leak.
Kehilangan memori adalah subkelas kerentanannya sendiri, dan masing-masing memiliki konfigurasi yang sedikit berbeda.

Dalam kasus kami, kebocoran adalah kembalinya BLOB oleh SQLite.
Gumpalan ini adalah target pelarian yang baik, karena kadang-kadang berisi petunjuk memori.

Fts3_tokenizer () yang rentan disebut dengan argumen tunggal dan mengembalikan alamat memori tokenizer yang diminta. hex () apa Itu membuat manusia dapat dibaca.
Jelas kami mendapatkan beberapa alamat memori, tetapi dibalik karena endianitas rendah.
Tentunya kita dapat membaliknya menggunakan beberapa operasi string SQLite bawaan.

¡Substr () Tampaknya sangat cocok! Kita dapat membaca BLOB little endian, tetapi ini menimbulkan pertanyaan lain: bagaimana kita menyimpan barang?

Rantai QOP

Secara alami, menyimpan data dalam SQL memerlukan pernyataan INSERT. Karena verifikasi sqlite_master yang disempurnakan, kami tidak dapat menggunakan INSERT karena semua deklarasi harus dimulai dengan "CREATE". Pendekatan kami terhadap tantangan ini adalah hanya menyimpan pertanyaan kami di bawah VISTA yang bermakna dan mengaitkannya.
Contoh berikut ini membuatnya sedikit lebih jelas:

Ini mungkin tidak tampak seperti perbedaan besar, tetapi karena rantai kami menjadi lebih rumit, dapat menggunakan pseudovariables pasti akan membuat hidup kita lebih mudah.

Membongkar pointer 64-bit

Jika Anda pernah menghadapi tantangan pwning, konsep pengemasan dan pembongkaran petunjuk seharusnya tidak aneh.
Primitif ini harus memfasilitasi konversi nilai heksadesimal kami (seperti kebocoran yang baru saja kami capai) ke bilangan bulat. Dengan melakukan ini, kami dapat melakukan beberapa perhitungan pada petunjuk ini dalam langkah-langkah berikut.

Kueri ini mengulangi char rantai heksadesimal oleh char secara terbalik menggunakan substr ().

Terjemahan karakter ini dilakukan menggunakan ini trik cerdik dengan penyesuaian kecil instr () yang didasarkan pada 1.
Yang diperlukan sekarang adalah offset yang benar di sebelah kanan tanda *.

Aritmatika petunjuk

Aritmatika pointer adalah tugas yang cukup mudah dengan bilangan bulat di tangan. Misalnya, mengekstraksi basis gambar dari pointer kami dari tokenizer yang difilter semudah:

Kemasan pointer 64-bit.

Setelah membaca indikator yang difilter dan memanipulasinya sesuka kami, masuk akal untuk mengemasnya kembali dalam bentuk endian kecil sehingga kami dapat menuliskannya di suatu tempat.
SQLite char () Ini harus digunakan di sini, karena dokumentasinya menunjukkan bahwa "itu akan mengembalikan string yang terdiri dari karakter yang memiliki nilai titik kode Unicode dari sebuah integer."
Ternyata bekerja dengan cukup baik, tetapi hanya dalam kisaran bilangan bulat terbatas

Bilangan bulat yang lebih besar diterjemahkan ke titik kode 2-byte mereka.
Setelah memukul kepala kami terhadap dokumentasi SQLite, kami tiba-tiba mendapat pencerahan yang aneh: exploit kami sebenarnya adalah database.
Kami dapat menyiapkan terlebih dahulu tabel yang memberikan bilangan bulat ke nilai yang diharapkan.

Sekarang permintaan pengemasan pointer kami adalah sebagai berikut:

Elaborasi objek palsu yang kompleks dalam memori

Menulis satu pointer sudah pasti berguna, tetapi masih belum cukup. Banyak skenario eksploitasi masalah keamanan memori membutuhkan penyerang untuk memalsukan objek atau struktur dalam memori atau bahkan menulis string ROP.

Intinya, kita akan menghubungkan beberapa blok bangunan yang disajikan di atas.
Sebagai contoh, mari kita menempa tokenizer kita sendiri, seperti yang dijelaskan disini .
Tokenizer palsu kami harus sesuai dengan antarmuka yang diharapkan oleh SQLite yang didefinisikan di sini:

Dengan menggunakan metode yang dijelaskan di atas dan permintaan GABUNG sederhana, kita dapat memalsukan objek yang diinginkan dengan mudah.

Saat memverifikasi hasil dalam debugger tingkat rendah, kami melihat bahwa sebenarnya objek tokenizer palsu telah dibuat.

Tumpukan semprotan

Sekarang kita telah membuat objek palsu kita, terkadang berguna untuk menyemprot tumpukan itu.
Idealnya, ini harus menjadi bentuk berulang dari yang terakhir.

Sayangnya, SQLite tidak mengimplementasikan fungsi REPEAT () seperti MySQL.
Namun, ini Thread memberi kami solusi elegan.

Fungsi zeroblob (N) mengembalikan BLOB yang terdiri dari N byte saat menggunakan ganti () untuk mengganti angka nol dengan objek palsu kami.

Pencarian 0x41 tersebut menunjukkan bahwa kami juga mencapai konsistensi yang sempurna. Amati pengulangan setiap 0x20 byte.

Memori bocor: timbunan

Melihat rencana permainan eksploitasi kami, tampaknya kami bergerak ke arah yang benar.
Kita sudah tahu di mana gambar biner itu, kita bisa menyimpulkan di mana fungsi yang diperlukan berada dan menyemprot tumpukan dengan tokenizer berbahaya kami.

Sekarang saatnya untuk membatalkan tokenizer dengan salah satu objek yang disemprotkan. Namun, karena arah tumpukan juga acak, kami tidak tahu di mana semprotan kami ditugaskan.
Kebocoran di heap mengharuskan kita memiliki kerentanan lain.

Sekali lagi, kita akan menunjuk ke antarmuka tabel virtual.
Karena tabel virtual menggunakan tabel bayangan yang mendasarinya, sangat umum bagi pointer biasa untuk melewati antara antarmuka SQL yang berbeda.

Catatan: Jenis masalah yang tepat ini dikurangi di SQLite 3.20 . Untungnya, PHP7 dikompilasi dengan versi sebelumnya. Dalam hal versi yang diperbarui, CVE-2019-8457 juga dapat digunakan di sini.

Untuk memfilter alamat heap, kita perlu membuat tabel fts3 terlebih dahulu dan menyalahgunakan antarmuka MATCH-nya.

Seperti yang kita lihat pada kehilangan memori pertama kita, penunjuknya sedikit endian, jadi itu harus dibalik. Untungnya, kita sudah tahu bagaimana melakukannya dengan SUBSTR ().
Sekarang setelah kami mengetahui lokasi penyimpanan dinamis kami dan dapat menyemprot dengan benar, kami akhirnya dapat mengganti tokenizer dengan tokenizer berbahaya kami!

Menyatukan semuanya

Dengan semua primitif eksploitasi yang diinginkan, sekarang saatnya untuk kembali ke tempat kita mulai: mengeksploitasi pencuri kata sandi C2.

Seperti yang dijelaskan di atas, kita perlu mengkonfigurasi "trap" LIHAT untuk memulai exploit kita. Karena itu, kita harus memeriksa tujuan kita dan menyiapkan VISTA yang benar.

Seperti yang terlihat dalam cuplikan di atas, tujuan kami mengharapkan database kami memiliki tabel yang disebut Notes dengan kolom yang disebut BodyRich di dalamnya. Untuk membajak kueri ini, kami membuat VIEW berikut

Setelah berkonsultasi dengan Notes, 3 string QOP dieksekusi. Mari kita menganalisis yang pertama.

heap_spray

Rantai QOP pertama kami harus mengisi tumpukan dengan banyak tokenizer berbahaya kami.

p64_simple_create, p64_simple_destroy dan p64_system pada dasarnya semua rantai dicapai dengan kemampuan kebocoran dan pengemasan kami.

Misalnya, p64_simple_create dibuat sebagai:

Karena rantai ini menjadi sangat kompleks, sangat cepat, dan cukup berulang, kami membuat QOP.py .
QOP.py sedikit menyederhanakan hal dengan membuat kueri ini dalam gaya pwntools.
Membuat pernyataan di atas menjadi semudah:

Manifestasi

Untuk makan;

Sekarang kami telah menetapkan kerangka kerja untuk mengeksploitasi situasi apa pun di mana interogator tidak dapat memastikan bahwa database tidak berbahaya, mari kita telusuri kasus penggunaan lain yang menarik untuk eksploitasi SQLite.

Kegigihan iOS

Kegigihan sulit dicapai di iOS, karena semua file yang dapat dieksekusi harus ditandatangani sebagai bagian dari Boot Aman Apple. Untungnya bagi kami, database SQLite tidak ditandatangani.

Menggunakan kemampuan baru kami, kami akan mengganti salah satu database yang biasa digunakan dengan versi jahat. Setelah perangkat dinyalakan ulang dan database berbahaya kami dikonsultasikan, kami memperoleh eksekusi kode.

Untuk menunjukkan konsep ini, kami mengganti basis data kontak «AddressBook.sqlitedb». Seperti yang dilakukan pada exploit PHP7 kami, kami membuat dua pernyataan DDL tambahan. Satu pernyataan DDL menimpa tokenizer "sederhana" default, dan pernyataan DDL lainnya memicu kerusakan saat mencoba membuat instance tokenizer yang batal. Sekarang, yang harus kita lakukan adalah menulis ulang setiap tabel dalam database asli sebagai tampilan yang membajak setiap pertanyaan yang dibuat dan mengarahkannya ke DDL jahat kita.

Ganti kontak db dengan kontak db berbahaya kami dan mulai ulang hasilnya di blok iOS berikut:

Seperti yang diharapkan, proses kontak diblokir pada 0x41414141414141414149 di mana kami berharap dapat menemukan konstruktor xCreate dari tokenizer palsu kami.

Selain itu, kontak db dibagi di antara banyak proses. Kontak, Facetime, Springboard, WhatsApp, Telegram dan XPCProxy hanyalah beberapa proses yang mengkonsultasikannya. Beberapa proses ini lebih istimewa daripada yang lain. Setelah kami membuktikan bahwa kami dapat mengeksekusi kode dalam konteks proses konsultasi, teknik ini juga memungkinkan kami untuk memperluas dan meningkatkan hak istimewa kami.

Penelitian dan metodologi kami telah diungkapkan secara bertanggung jawab kepada Apple dan mereka diberi CVE berikut:

• CVE-2019-8600
• CVE-2019-8598
• CVE-2019-8602
• CVE-2019-8577

Pekerjaan di masa depan

Mengingat fakta bahwa SQLite secara praktis terintegrasi ke dalam hampir semua platform, kami percaya bahwa kami baru saja menggaruk ujung gunung es ketika sampai pada potensi eksploitasi. Kami berharap komunitas keamanan akan mengambil penelitian inovatif ini dan alat-alat diluncurkan dan mendorongnya lebih jauh. Beberapa opsi yang menurut kami mungkin menarik untuk diikuti adalah

• Membuat prestasi yang lebih fleksibel. Ini dapat dilakukan dengan membangun eksploit secara dinamis dengan memilih gadget QOP yang relevan dari tabel prefabrikasi menggunakan fungsi seperti sqlite_version () atau sqlite_compileoption_used () .
• Lograr primitivas de explotación más fuertes como R / W arbitrario.
• Busque otros escenarios en los que el interrogador no pueda verificar la confiabilidad de la base de datos.

Conclusión

Establecimos que simplemente consultar una base de datos puede no ser tan seguro como espera. Usando nuestras técnicas innovadoras de Secuestro de consultas y Programación orientada a consultas, demostramos que los problemas de corrupción de memoria en SQLite ahora pueden ser explotados de manera confiable. A medida que nuestras jerarquías de permisos se vuelven más segmentadas que nunca, está claro que debemos repensar los límites de la entrada SQL confiable / no confiable. Para demostrar estos conceptos, logramos la ejecución remota de código en un backend de robo de contraseñas que ejecuta PHP7 y obtuvimos persistencia con mayores privilegios en iOS. Creemos que estos son solo un par de casos de uso en el panorama interminable de SQLite.

El producto Check Point IPS protege contra esta amenaza: «SQLite fts3_tokenizer Ejecución remota de código de puntero no confiable (CVE-2019-8602)».