Melewati certificate pinning Meta Messenger di macOS

 (texts.blog)
1 poin oleh GN⁺ 2024-03-06 | 1 komentar | Bagikan ke WhatsApp
  • Tim Texts.com ingin menganalisis Meta Messenger untuk macOS, sebuah aplikasi desktop mandiri yang mirip dengan produk mereka, tetapi analisis MITM berbasis proksi terhalang oleh certificate pinning
  • Certificate pinning Meta membuat aplikasi hanya mempercayai sertifikat yang diizinkan aplikasi, sehingga memblokir cara mencegat dan mendekripsi permintaan menggunakan otoritas sertifikat buatan pengguna
  • Instrumentasi dinamis berbasis Frida menyebabkan crash di Messenger dan menambah kompleksitas distribusi, sehingga tim memilih patch biner yang lebih kecil dan mudah direproduksi
  • Analisis Hopper menunjukkan bahwa dengan mengubah 4 byte agar IsUsingSandbox() mengembalikan true, mereka bisa masuk ke jalur kode yang mematikan verifikasi SSL saat menggunakan custom sandbox
  • Setelah mengganti biner asli dengan executable yang telah dipatch dan menangani penandatanganannya, mereka dapat melihat header, isi respons, dan informasi permintaan di alat proksi

Mengapa Texts.com menganalisis Messenger

  • Batuhan İçöz, yang menangani proyek platform Meta di Texts.com, menilai aplikasi Messenger untuk macOS layak dianalisis karena merupakan aplikasi desktop mandiri yang modelnya dekat dengan milik mereka
  • Mencegat permintaan jaringan memiliki hambatan masuk yang rendah, sehingga cocok digunakan sebagai langkah awal untuk memahami perilaku aplikasi
  • Namun Meta menerapkan certificate pinning pada aplikasinya untuk memperkuat model keamanan, dan bahkan memblokir analisis MITM yang dilakukan pengguna terhadap dirinya sendiri

Apa yang diblokir oleh certificate pinning

  • Untuk mencegat permintaan dengan klien proksi, pengguna harus menyiapkan dan mempercayai otoritas sertifikat buatan sendiri
  • Dengan sertifikat yang diterbitkan oleh otoritas tersebut, informasi permintaan dapat dicegat dan didekripsi
  • Jika suatu layanan menerapkan certificate pinning, aplikasi hanya akan menerima sertifikat yang diterbitkan oleh otoritas sertifikat tertentu
  • Dalam kasus ini, sertifikat buatan pengguna tidak dianggap valid sehingga permintaan tidak dapat dicegat

Kondisi sebelum patch dan tujuannya

  • Jika certificate pinning tidak dimatikan, semua permintaan akan mengembalikan “Internal Error”
  • Perangkat lunak proksi menampilkan “SSL Handshake Failed”, dan siklus hidup permintaan tidak berjalan sampai selesai
  • Dalam kondisi ini, sulit untuk menyimpulkan isi permintaan
  • Tujuannya adalah memungkinkan permintaan, respons, dan header dibaca langsung di alat debugging jaringan

Opsi bypass yang gagal dan pilihan akhir

  • Salah satu metode yang pernah berhasil sebelumnya adalah mengganti string URL di dalam biner ke endpoint self-hosted yang tidak mengimplementasikan TLS
    • Endpoint ini meneruskan permintaan dan respons antara klien dan server
    • Metode ini lebih cocok untuk aplikasi kecil daripada aplikasi besar seperti Messenger
  • Library instrumentasi dinamis seperti Frida juga sempat dipertimbangkan, tetapi stabilitasnya rendah pada Messenger
    • Crash sering terjadi saat memasang hook
    • Karena overhead, sulit menemukan titik yang menjadi sumber masalah
    • Lingkungan eksekusi dan konfigurasi alat yang dibutuhkan membuat distribusinya ke anggota tim menjadi rumit
  • Mereka juga mencoba skrip Frida yang telah dipelihara selama bertahun-tahun
    • Skrip ini digunakan untuk library certificate pinning umum dan metode bypass yang lazim, dan bekerja di sebagian besar aplikasi
    • Keluarga aplikasi Meta tidak termasuk dalam “sebagian besar” itu
  • Pada akhirnya, mereka memilih cara untuk mematikan certificate pinning sepenuhnya dengan patch biner yang mudah dibagikan ke anggota tim

Titik patch yang ditemukan dengan Hopper

  • Setelah mengunduh Messenger dan memindahkannya ke folder Applications, mereka membuka biner ARM yang telah dikompilasi di /Applications/Messenger.app/Content/MacOS/Messenger dengan Hopper
  • Hopper dapat melakukan disassembly, dekompilasi, rekompilasi, debugging, dan visualisasi terhadap biner yang telah dikompilasi
  • Setelah biner dan referensi dimuat, mereka mencari istilah seperti certificate, ssl, dan pinning
  • String "SSL pinning verification failed for host:" menjadi titik awal analisis
  • Karena biner yang telah dikompilasi bisa crash jika dimodifikasi berlebihan, mereka menggunakan strategi perubahan sekecil mungkin
    • Perubahan ideal adalah patch dengan dampak sempit seperti membalik nilai boolean, membalik kondisi, atau mengubah beberapa instruksi

Membuat IsUsingSandbox() selalu true

  • Mereka memvisualisasikan alur eksekusi melalui control flow graph dan menelusuri referensi yang terhubung ke atas
  • Mereka menemukan string "Using custom sandbox -> turn off SSL verification"
  • Mereka mencari referensi fungsi yang menentukan flag ini di dalam file, lalu menemukan referensi tersebut di bagian atas prosedur
  • Mereka menelusuri titik tempat nilai kembalian ditetapkan di fungsi IsUsingSandbox()
    • Register w0 dipindahkan dari w19 lalu dikembalikan
    • w19 awalnya diisi melalui instruksi load byte
  • Jika w19 tidak dimuat dan selalu diset ke true, maka IsUsingSandbox() akan mengembalikan true
  • Sesuai string yang ditemukan sebelumnya, saat custom sandbox digunakan verifikasi SSL dimatikan, sehingga perubahan ini menonaktifkan certificate pinning
Original
ARM: ldrb w19, [sp, #0x40 + var_20]
HEX: F3 83 40 39

Rewritten
ARM: mov w19, #1
HEX: 33 00 80 52
  • Penggantian ini dilakukan dengan mengedit langsung bytecode aplikasi dalam mode hexadecimal

Hasil eksekusi dan penandatanganan ulang

  • Mereka mengekspor executable baru dengan opsi “Produce New Executable” di Hopper
  • Setelah menghapus tanda tangan executable, mereka mengganti biner Messenger asli dengan biner baru
  • Ketika Messenger dijalankan kembali, header, isi respons, dan informasi permintaan lainnya terlihat di alat proksi
  • Dari total ukuran biner 97,477,728 byte, hanya 4 byte yang diubah untuk memungkinkan pencegatan permintaan
  • Jika ingin melihat pendekatan serupa di iOS, lihat tulisan Hassan Mostafa tahun 2020 tentang bypass certificate pinning Instagram
    • Tulisan tersebut membahas kasus membalik instruksi percabangan bersyarat pada iPhone yang sudah di-jailbreak untuk mematikan certificate pinning Instagram
  • Biner yang telah dikompilasi kemudian diberikan kepada Batuhan
    • Batuhan memperoleh dan memasang sertifikat penandatanganan, lalu menandatangani aplikasinya
    • Setelah itu, ia dapat menggunakan biner tersebut di sistemnya sendiri untuk melihat permintaannya sendiri
codesign --force --deep -s CERTNAME_OR_ID /Applications/Messenger.app

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-06
Pendapat di Hacker News

  • Aku sempat menempuh jalur yang mirip, lalu menyerah begitu sampai pada tahap ingin decompile/modifikasi/recompile
    Pada level ini sudah soal kegigihan; aku penasaran sebenarnya berapa jam yang dihabiskan. Aku menetapkan batas kapan harus berhenti dan mematuhinya

    • Tulisan ini awalnya adalah tulisan internal Texts.com, dan bagian bahwa beberapa minggu sebelumnya aku juga mencoba pendekatan yang persis sama lalu menyerah karena mencapai batas waktu yang sudah kutetapkan, aku hapus saat merapikannya untuk dibagikan
      Awalnya aku menyerah setelah 2 jam mencoba mengubah berbagai command. Setelah itu aku melihat tulisan reverse engineer “Hassan Mostafa” (cyclon3) yang dulu berhasil dengan cara yang sama, yaitu tulisan tentang memakai Hopper Disassembler pada Instagram di iOS, lalu malam itu aku mencobanya lagi tetapi gagal. Aku juga mencari command yang sama dan mencoba mengubahnya
      Lalu aku memutuskan berhenti, dan beberapa minggu kemudian, dengan sedikit rasa mengganjal yang masih tersisa, aku mencobanya lagi secara spontan; setelah menemukan fungsi sandbox, semuanya selesai dalam sekitar 30 menit

  • Dengan eBPF, sepertinya data bisa dibaca sebelum enkripsi TLS: Debugging with eBPF Part 3: Tracing SSL/TLS connections https://blog.px.dev/ebpf-openssl-tracing/

    • Itu cara yang praktis, dan metode lain seperti hooking fungsi kirim/terima TLS dengan sesuatu seperti Frida hampir pasti juga memungkinkan. Namun jika bypass certificate pinning berhasil, keuntungannya peneliti bisa mengalirkan traffic melalui tool yang sudah ada seperti Burp Suite atau mitmproxy
      Merutekan traffic aplikasi nyata ke proxy yang mencegatnya bisa sangat memangkas waktu, tergantung tujuannya. Misalnya jika ingin otomatis mengubah satu parameter pada request yang baru muncul setelah autentikasi/penyiapan sesi, jauh lebih cepat membiarkan aplikasi berjalan sendiri lalu mengubah satu titik saja di proxy, daripada menulis client baru yang menjalankan seluruh proses awal atau membuat logika modifikasi dengan filter eBPF
    • Sebagai catatan, cara ini tidak berlaku untuk program Rust yang melakukan static linking terhadap rustls, library TLS Rust yang paling banyak digunakan

  • Cara yang sangat cerdas. Namun rasanya certificate pinning tetap bisa saja dipaksakan bahkan dalam mode sandbox
    Saat kuliah aku pernah mencoba melihat Snapchat lewat serangan man-in-the-middle, dan yang kuingat mereka juga memakai certificate pinning sehingga akhirnya tidak berhasil kubongkar

    • Aku juga mencoba hal yang sama, dan berhasil mem-patch aplikasinya sampai bisa mencegat request, tetapi menyerah saat mencoba melakukan reverse engineering shared object yang menangani penandatanganan request
      Aku bahkan tidak berhasil menemukan entry point-nya. Untuk aplikasi media sosial yang relatif kecil, keamanannya pada 2015 sudah luar biasa ketat
    • Jika pengguna bisa memodifikasi binary, pada dasarnya sulit memaksakan certificate pinning
      Sekalipun certificate pinning digunakan dalam mode sandbox, besar kemungkinan ada cara lain untuk menghapus pemeriksaan sertifikat yang di-pin
    • Benar. Itu mungkin saja diimplementasikan dengan membuat output fungsi flag sandbox di dalam fungsi consumer selalu di-assign true, tetapi dalam kasus ini cara yang sekarang pun sudah bekerja dengan baik :)
    • Lucu juga melihat begitu banyak orang yang pernah mencoba ini di aplikasi mobile lalu mentok
      Meski sekarang tidak lagi

  • Tulisan ini mengingatkanku pada masa +Orc. Sepertinya banyak pengetahuan yang dulu umum, seperti cara menemukan branch yang tidak diinginkan lalu menjadikannya NOP, kini sudah banyak menghilang
    Wajar juga, karena sekarang ada jauh lebih banyak teknologi yang harus dipelajari
    [1]: https://en.m.wikipedia.org/wiki/Old_Red_Cracker

    • Setiap melihat penyebutan +Orc atau Fravia (RIP), selalu terasa nostalgik
      Meski begitu menurutku masih banyak orang yang melakukan patch NOP. Hanya saja kompleksitasnya meningkat. Orang yang membongkar DRM atau meneliti aplikasi mobile sembarang dengan hex editor dan semacamnya masih tetap ada
      Program masa kini lebih kompleks sehingga lebih sulit untuk mulai, tetapi pada saat yang sama pengetahuan yang dibutuhkan juga lebih mudah diakses

  • Jika ingin mencegat traffic aplikasi Meta, sebenarnya tidak perlu melakukan sejauh itu
    https://www.facebook.com/whitehat/bugbounty-education/261571...

    • Ini hanya bekerja di Android. Kami tidak tertarik mencegat aplikasi Android

  • Aku penasaran apakah runtime binary checksum akan membantu membuat modifikasi semacam ini lebih sulit
    Bukankah itu praktik standar di aplikasi mobile? Apakah SDK iOS atau Android menyediakan fitur seperti ini? Sepertinya bisa dikaitkan dengan proses rilis resmi dan dipaksakan di platform masing-masing yang tidak di-jailbreak
    Ini memang pertanyaan mendasar, tetapi karena solusi akhirnya adalah mengubah beberapa byte pada binary, rasanya ini bisa dicegah

    • Ini macOS (desktop), bukan iOS (mobile)
    • Bagaimanapun, jika binary dimodifikasi, ia harus ditandatangani ulang, jadi efek yang sama tetap ada
      Di platform yang tidak di-jailbreak, biasanya ini dilakukan dengan sertifikat developer

  • Pertahanan Meta, setidaknya Messenger, terhadap reverse engineering tampaknya cukup longgar
    Bahkan tanpa obfuscation tingkat lanjut, seharusnya mudah menghapus IsUsingSandbox() sepenuhnya dari build production

    • Berdasarkan saat aku bekerja di sana, pertahanan terhadap reverse engineering tidak pernah menjadi tujuan
      Certificate pinning dimaksudkan untuk membuatnya sulit dimodifikasi oleh penyerang, bukan untuk membuatnya sulit dilakukan oleh pengguna
    • Aplikasi Meta bahkan menyertakan menu debug utuh di build production. String yang ditemukan penulis kemungkinan juga bagian dari menu semacam itu

  • Saat pertama kali membongkar aplikasi, aku mengira tentu saja akan gagal, tetapi ternyata menemukan titik JNE/JEZ yang mudah dimodifikasi seperti ini lebih gampang daripada yang kukira
    Kalau salah memilih pun tinggal kembali ke file asli dan mencoba titik lain
    Hal seperti ini rasanya bisa dengan mudah dilakukan otomatis oleh AI. Cukup balik JEZ/JNZ di beberapa titik kandidat, jalankan aplikasinya, lalu lihat apakah layar omelan muncul atau tidak

    • Ini bukan masalah AI secara khusus, lebih dekat ke fuzzing
      Jika kondisi gagalnya terdefinisi dengan baik, pada akhirnya tinggal mempersempit kandidat
      Kalau AI bisa membobol sesuatu seperti Denuvo secara zero-shot, itu baru cerita lain
    • Tool seperti itu sudah ada bahkan sejak era 90-an. Bukan AI, hanya brute force biasa

  • Saya penasaran mengapa aplikasi dari perusahaan sebesar ini tidak sepenuhnya diobfuscate, dan juga tidak memasang perlindungan yang cukup untuk mencegah eksekusi binary yang telah dimodifikasi

    • Berbicara sebagai orang yang dulu berada di posisi saat keputusan ini pertama dibuat di aplikasi Facebook: itu tidak sepadan
      Individu/kelompok/pemerintah yang cukup terampil atau punya motivasi kuat pada akhirnya akan tetap bisa membobolnya. Memang begitulah sifat mendistribusikan binary klien
      Kita bisa saja menghabiskan banyak sekali waktu dan uang untuk mencegahnya. Dulu Pinterest pernah mencoba mendistribusikan bahasa dan mesin virtual mereka sendiri, dan saya menentangnya. Atau, kita bisa menerima bahwa kode klien pada dasarnya sudah dianggap terkompromi, lalu menaruh logika di server dan lanjut
      Certificate pinning hampir gratis, dan mirip perangkat “hanya boleh naik jika minimal memakai kunci ini”. Itu tidak aman, tetapi menyaring berbagai upaya sembarangan
    • Obfuscation punya biaya, dan certificate pinning lebih bertujuan mempersulit serangan man-in-the-middle yang merugikan pengguna daripada mencegah reverse engineering
      Tentu saja itu juga berdampak pada reverse engineering, tetapi lebih sebagai bonus
      Pada akhirnya kode berjalan di perangkat pengguna, dan pengguna bisa mengamati apa yang dilakukan kode, jadi deobfuscation selalu mungkin dilakukan. Jika satu orang berhasil membongkarnya dan membagikan hasilnya, replikasinya juga menjadi sangat mudah. Bukan berarti obfuscation tidak berguna, tetapi itu bukan sesuatu yang layak diberi terlalu banyak waktu
    • Pada aplikasi mobile/frontend, melakukan hal seperti itu pun tidak banyak gunanya
      Jika penyerang punya akses fisik ke perangkat, pada titik itu tidak ada cara untuk menghentikannya. Yang bisa dilakukan hanyalah membuat prosesnya lebih merepotkan, dengan harapan mereka kesal lalu menyerah
    • Besar kemungkinan ini soal prioritas dan cost-effectiveness
      Obfuscation hampir tidak akan memengaruhi hasil eksperimen ini, dan pendekatannya mungkin hanya akan bergeser ke penggunaan dynamic instrumentation sedikit lebih banyak. Obfuscation paling efektif yang pernah saya lihat adalah VM obfuscation, tetapi dampaknya terhadap performa cukup besar. Obfuscation juga membuat debugging normal menjadi lebih sulit
      Pencegahan binary yang dimodifikasi dilakukan di tingkat sistem, dan juga bisa diimplementasikan di tingkat aplikasi serta cukup umum. Namun fitur itu sendiri juga bisa di-bypass, dan setelah pemeriksaan keamanan selesai, binary juga bisa dimodifikasi dengan library dynamic instrumentation seperti Frida
      Dari sudut pandang Meta, bermain kucing-kucingan dengan para reverse engineer tampaknya bukan pilihan terbaik
    • Mengapa tidak semua bank diamankan seperti Fort Knox?

  • Saya penasaran alat proxy apa yang dipakai dalam tulisan itu. Saat berjalan, apakah semua trafik aplikasi dirutekan ke sana?
    Maaf kalau ini pertanyaan bodoh

    • Pertanyaan bagus. Yang dipakai dalam tulisan itu adalah Proxyman
      Di macOS, semua trafik aplikasi dirutekan ke sana, dan perangkat iOS juga bisa diproxy dengan memasang sertifikat self-signed di perangkat lalu menghubungkannya ke proxy