Pengamanan serangan Man-in-the-Middle pada Mobile Application menggunakan metode Certificate Pinning

Standard

Mungkin ada beberapa dari Anda yang sudah membaca artikel tentang security vulnerability pada aplikasi Gojek dan Bank Mandiri isi ulang e-Money berbasis NFC yang ditulis oleh Yohanes Nugroho pada link berikut:

Gojek : http://blog.compactbyte.com/2016/01/02/bug-gojek-agustus-2015/

Bank Mandiri: http://blog.compactbyte.com/2016/01/02/bug-mandiri-e-money-isi-ulang-november-2015/

Pada kedua artikel tersebut, Pak Yohanes Nugroho melakukan analisis terhadap data yang dikirimkan dan diterima oleh aplikasi tersebut. Sedangkan untuk dapat mengetahui data yang dikirimkan dan diterima oleh aplikasi, terdapat beberapa cara yaitu:

  1. Menggunakan HTTP/HTTP debugger proxy seperti Fiddler, Burp Proxy, OWASP ZAP Proxy dan tools lain sejenisnya dengan metode MiTM
  2. Melakukan static analysis dengan membaca source code yang telah di-decompile (reverse engineering)
  3. Melakukan Log Analysis

Saya telah menanyakan terkait cara yang digunakan Pak Yohanes Nugroho melalui komentar di artikel beliau, namun saat artikel ini ditulis, Pak Yohanes Nugroho belum memberikan balasan. Jadi, mari kita bersasumsi bahwa cara pertama lah yang digunakan.

Seperti pada artikel yang Saya tulis sebelumnya : https://adefirmantriangga.wordpress.com/2016/08/01/dekripsi-https-menggunakan-fiddler-dan-dampaknya-pada-mobile-application/

Man-in-the-Middle pada HTTPS traffic ini dapat terjadi karena aplikasi yang berperan sebagai Client, “mempercayai” semua Certificate yang dikirimkan oleh Server, aplikasi tidak melakukan verifikasi terhadap Certificate, apakah Certificate tersebut diterbitkan oleh Certificate Authority yang sah atau tidak.

pinning-fig-2

sumber gambar: https://blogs.mcafee.com/wp-content/uploads/pinning-fig-2.jpg

Apa itu Certificate Pinning?

Secara default, saat sebuah Client akan terkoneksi menggunakan SSL, Client akan akan mengecek beberapa hal, seperti:

  1. Apakah certificate memiliki “chain of trust” ke trusted root certificate
  2. Apakah certificate tersebut memiliki requested hostname yang match

Nah, kemudian muncul pertimbangan:

Kalau Client memang hanya berkomunikasi dengan Server yang spesifik dan tertentu dalam setiap koneksi, kenapa tidak kita definisikan Certificate-nya secara spesifik sesuai dengan Server yang spesifik dan tertentu tersebut? 

Certificate Pinning adalah solusinya

Certificate Pinning dilakukan dengan mendefinisikan Certificate secara Hard-Code pada aplikasi, sehingga sifatnya statis. Aplikasi dapat mengacuhkan Trust Store pada Perangkat dan bergantung pada Trust Store sendiri. Dengan demikian, Aplikasi hanya mau berkoneksi apabila Certificate yang dikirimkan oleh Server, “MATCH” dengan Certificate yang di-hard code tersebut.

(Reminder: Trust Store sederhananya berisi daftar Certificate Authority yang dapat “dipercaya”. Sistem Operasi dan Aplikasi memiliki Trust Store sendiri-sendiri)

Mengapa aplikasi harus memiliki Trust Store sendiri??? Jawabannya adalah karena Trust Store pada perangkat, atau pada Android OS mudah sekali di”susupi” oleh Certificate yang berbahaya dan tidak diterbitkan oleh pihak yang semestinya.

Analogi sederhana tentang Certificate Pinning ini misalnya sebagai berikut:

Budi kita analogikan Client / Aplikasi, 

mari kita analogikan apabila aplikasi tidak menerapkan SSL secara optimal dan menerapkan parameter org.apache.http.conn.ssl.AllowAllHostnameVerifier atau SSLSocketFactory.ALLOWALLHOSTNAME_VERIFIER. pada aplikasi.

  1. Budi seorang siswa Sekolah Dasar, setiap hari ia dijemput Orang Tua nya.
  2. Namun hari ini, Budi diinformasikan oleh Orang Tuanya bahwa kedua Orang Tuanya tidak bisa menjemput Budi.
  3. Orang Tua Budi mengutus Andi yang merupakan saudara, untuk menjemput Budi.
  4. Saat ini, Budi belum pernah bertemu dengan Andi
  5. Sehingga apabila ada Penculik yang mengaku sebagai Andi, Budi akan percaya dan ikut dengan si Penculik dan menjadi korban penculikan.

Hal ini tidak akan terjadi apabila Orang Tua Budi, mengirimkan foto Andi sebagai orang yang akan menjemput Budi di sekolah. atau paling tidak, Orang Tua Budi memberikan ciri-ciri yang jelas seperti apa Andi, misalnya warna rambut, warna kulit, bentuk rambut. dll.

Budi tidak akan terbujuk oleh si Penculik dan hanya akan ikut pergi apabila yang mengajak adalah seseorang yang benar, yaitu Andi.

Mungkin penjalasan diatas bisa digunakan untuk menganalogikan Certificate Pinning, memberikan informasi terlebih dahulu kepada Budi (Client) terkait ciri-ciri Andi si Penjemput dengan detil, baik menggunakan foto atau ciri-ciri fisik yang dijelaskan, mirip seperti pendefinisian Certificate secara hard-code pada aplikasi dalam implementasi Certificate Pinning.

Kelebihan

  1. Menambah Keamanan Aplikasi. – Certificate Pinning memang butuh effort lebih, tidak semua aplikasi harus mengimplementasikan metode ini, hanya aplikasi dengan tingkat kritikalitas yang tinggi seperti aplikasi banking, financial, dan beberapa game yang direkomendasikan untuk mengimplementasikan metode ini.
  2. Mengurangi Cost – Sebenarnya ada metode lain untuk menutup celah keamanan terkait penerapan SSL yang tidak optimal seperti yang dijelaskan sebelumnya, yaitu dengan menggunakan Certificate Berbayar yang diterbitkan oleh Certificate Authority yang komersil seperti Symantec, Comodo, Digicert dll. Ya, namun ini berbayar, berbeda dengan Certificate Pinning. Anda dapat menggunakan Self-Sign Certificate (Certificate yang diterbitkan oleh Server anda sendiri) sehingga tidak perlu berbayar, syaratnya anda harus mendefinisikan juga secara hard-code bahwa Server anda masuk sebagai Certificate Authority yang dapat dipercaya, dalam istilah umum, ini biasa disebut “Unknown CA” bagaimana caranya? dapat anda lihat disini: https://developer.android.com/training/articles/security-ssl.html#UnknownCa

Hal ini sudah umum dilakukan oleh organisasi dan perusahaan tertentu, seperti University of Washington. Contoh implementasi Certificate Pinning yang dilakukan oleh University of Washington dapat dilihat disini juga: https://developer.android.com/training/articles/security-ssl.html#UnknownCa

Kekurangan

  1. Kurang Fleksibel – dalam suatu kondisi, anda ingin mengubah SSL certificate pada aplikasi anda. Untuk melakukan ini, anda harus mengupdate aplikasi anda, upload ke Google Play dan “memaksa” User untuk mengupdate dan menginstall aplikasi yang baru. Jika tidak, Pengguna aplikasi yang lama tidak akan bisa terkoneksi karena Certificate yang sudah tidak lagi “MATCHED”
  2.  Perlu Pengamanan Lebih – masih ada ancaman yang harus dihadapi ketika anda “menanam sesuatu” secara hard-code pada aplikasi, yaitu Reverse Engineering. Metode, tools, dan penjelasan mengenai Reverse Engineering pada aplikasi Android sudah sangatlah populer, Sehingga ada potensi ancaman seorang Hacker untuk mengubah source code untuk membypass Certificate Pinning ini, entah dengan mengubah Logic, mengubah Keystore atau yang lainnya. Sehingga Developer perlu menerapkan pengamanan lebih untuk memproteksi binary aplikasi dan mencegah Reverse Engineering seperti code obfuscation, encryption, dan lain-lain

 

Seperti yang tertulis pada artikel yang ditulis oleh Pak Yohanes Nugroho, banyak sekali serangan lanjutan dan informasi yang didapatkan apabila seorang attacker telah mengetahui apa yang dikirim dan diterima oleh aplikasi. seperti replay attack, informasi bug-bug lain seperti pada session, otentikasi dan lainnya juga dapat diketahui.

 

 

Sumber dan Referensi:

Certificate Pinning Implementation Sample: https://github.com/ikust/hello-pinnedcerts

Official Android Explanation related to SSL Implementation: https://developer.android.com/training/articles/security-ssl.html#UnknownCa

OWASP Certificate & Public Key Pinning Guide: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

Infinum SSL Certificate Pinning Implementation Article: https://infinum.co/the-capsized-eight/articles/securing-mobile-banking-on-android-with-ssl-certificate-pinning

 

Disclaimer:

Semua tulisan Saya adalah berdasarkan eksplorasi dan pemahaman Saya yang terbatas sejauh ini, Pembaca bebas memberikan masukan apabila ada yang kurang tepat. CMIIW abis lah pokoknya.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s