Quick Android Review Kit

Linkedin punya repo yang menarik hati: https://github.com/linkedin/qark

serupa dengan mobile top 10 security vulnerabilities via owasp yang pernah saya bahas di tulisan sebelumnya.

Kali ini, saya mencoba sebuah tool bernama “QARK” (Quick Android Review Kit) yang terdapat di repo punya linkedin. Tool ini dikembangkan menggunakan python dan tool ini mampu menganalisis dengan mudah celah keamanan di aplikasi Android yang kita kembangkan.

Tanpa perlu memeriksa satu per satu, hanya dengan mengetik satu baris perintah (bisa dipakai untuk memeriksa apk ataupun sourcecode), dan output dari tool ini adalah memberitahukan persentase celah keamanan dan juga apa saja yang berbahaya dan harus dihindari.


Baru saja saya coba di laptop saya, dan sebagai bahan percobaan, saya mencoba salah satu sourcecode aplikasi project saya sebelumnya. Dan di screenshot di bawah ini, ada beberapa celah keamanan yang diperlihatkan dengan persentase. Setelah semua dicek satu per satu, di bawahnya dibahas satu per satu, apa saja yang menjadi celah agar dapat diperbaiki segera oleh developer.

Persentase tingkat celah keamanan di aplikasi yang dikembangkan
Beberapa “suggest” yang diberikan QARK ini agar saya bisa memperhatikan dan memperbaiki celah keamanan tersebut

Anda memerlukan Python terinstall di OS laptop/PC untuk mencoba Qark ini. Silahkan download python di sini. Setelah selesai download python. Bisa dicoba install qark melalui terminal dengan cara, download terlebih dahulu sourcecode qark tersebut dari github. Kemudian jalankan terminal, arahkan terminal ke folder tempat sourcecode qark tersebut disimpan di harddisk anda. Lalu ketikkan perintah berikut di terminal:

$ python qarkMain.py [enter]

Setelah berhasil, sebuah jendela qark akan muncul di layar, dan tinggal dipilih deh apa yang mau dilakukan dengan tool kit ini. Selamat mencoba.

Advertisements

Memperkuat keamanan di sisi aplikasi mobile Android

Saat saya menerima hasil audit tahap pertama, saya kaget, ternyata aplikasi yang saya buat, datanya “telanjang”, kelihatan semua. Loh? padahal sudah saya enkripsi dengan RSA public-key, tapi kok URLnya keliatan, data yang di-POST keliatan, dan tidak rusak sama sekali datanya, padahal sudah pakai koneksi https (SSL). Saat itu ternyata masih belum cukup. Saya menerima hasil audit tersebut dan melihat software apa yang dipakai oleh IT Security Engineer-nya: ternyata yang dipakai adalah tool Burp Suite (https://portswigger.net/burp), Nmap, Charles proxy, dan beberapa baris script yang dijalankan di bash di HP rooted. Sama seperti tool security testing atau pentest (penetration test) lainnya seperti Wireshark, OWASP (Open Web Application Security Project) dan Back Track . Tools yang dipakai bertujuan untuk menguji beberapa standar pengujian di aplikasi mobile. Bisa dicek di web berikut ini dari M1 sampai dengan M10.

Beberapa aspek yang diuji yang menjadi mobile risk base line adalah:

  • improper platform usage (M1),
  • insucure data storage (M2),
  • insecure communication (M3),
  • insecure authentication (M4),
  • insufficient cryptography (M5),
  • insecure authorization (M6),
  • client code quality(M7),
  • code temparing (M8),
  • reverse engineering (M9),
  • dan extraneous functionality (M10)

Mari kita bahas satu per satu dengan singkat (saya sertakan link pelengkap di setiap bahasan agar bisa dijelajah lebih jauh)…

Untuk mengatasi issue M1, platform yang digunakan harus jelas, codingan yang kita gunakan juga harus terstandar sesuai dengan guideliness di SDK Android. Ini untuk meminimalisir improper platform usage.

Untuk M2, biasanya penyakit ini terjadi kalau developer menyimpan atau menampilkan data di Log, mungkin maksudnya biar mudah untuk debugging, tapi yang kayak gini biasanya akan jadi masalah ketika ada user yang test aplikasi kemudian membaca lognya dari tools seperti adb logcat atau ddms. Atau dia menyimpan data pengguna di db sqlite yang bisa di-extract dari APKnya dan dibaca pakai tools SQlite browser. Atau menyimpan ke dalam flat file XML yang ternyata itu data penting. Jadi, sebaiknya hal tersebut dihindari. Bagaimana caranya log tersebut hilang pada saat kita build APK tanpa perlu capek remove atau comment satu per satu line by line di source code. Tenaaang..di Android kan ada proguard, bisa matiin log pakai proguard tersebut dengan cara menambahkan line berikut di file proguard:

-assumenosideeffects class android.util.Log {
    public static boolean isLoggable(java.lang.String, int);
    public static int d(...);
    public static int w(...);
    public static int v(...);
    public static int i(...);
}

Atau lebih jelasnya cek di laman berikut.

Untuk kasus M3, insecure connection biasanya terjadi ketika kita menggunakan koneksi http (port 80), bukan https (port 443). Emang apa bedanya? jika masih belum paham bisa main ke web ini. Selain itu yang menjadi concern ialah koneksi https tidak sepenuhnya aman, karena bisa dinetralisir dengan menggunakan proxy atau vpn yang insecure. Jadi ketika aplikasi hit ke server, sebelum sampai ke server, datanya melalui proxy dulu atau vpn dulu, tidak langsung ke server. Ya kena tangkap deh datanya terbaca jelas. Apalagi kalau tidak dilengkapi dengan trusted SSL. Tambah ketahuan. Tadi saya mengira dengan saya menguji sendiri aplikasi yang saya kembangkan dengan menggunakan Charles Proxy di MacOS, saya install cert dari Charles, kemudian jalankan aplikasi di Android. Tadaa..saya senang ternyata datanya sudah tidak terbaca, tapi begitu teman bilang “jangan lupa SSLProxy-nya disetting, mas”, pas saya setting untuk host server yang digunakan di aplikasi, kemudian tekan OK, kemudian jalankan kembali aplikasi yang saya buat. “loh???? kok datanya terbaca 100% tidak ada yang kacau..waduh”. Ternyata masih ada celah. Untuk mengantisipasi hal tersebut, di Android sudah ada standar pinning SSL, bisa dilihat di web berikut. Jadi, ketika koneksi tersebut untrusted SSL, aplikasi dapat memutuskan hubungan koneksi sehingga tidak terhubung ke jaringan yang tidak aman. Bagaimana cara mengakali VPN atau proxy. Di android bisa diantisipasi dengan cara mem-bypass proxy. Caranya seperti ini:

try {
    conn = (HttpsURLConnection) url.openConnection(Proxy.NO_PROXY);
    try {
        sf = new SSLSocketFactory(ksTrust);
        sf.setHostnameVerifier(SSLSocketFactory.STRICT_HOSTNAME_VERIFIER);
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
    } catch (KeyManagementException e) {
        e.printStackTrace();
    } catch (KeyStoreException e) {
        e.printStackTrace();
    } catch (UnrecoverableKeyException e) {
        e.printStackTrace();
    }
} catch (SocketTimeoutException | java.net.ProtocolException e) {
    e.printStackTrace();
} catch (ConnectException e) {
    e.printStackTrace();
} catch (IOException e) {
    e.printStackTrace();
}finally{
    conn.disconnect();
}

Dari contoh code di atas, koneksi HTTPS tersebut diset parameter NO_PROXY untuk mem-bypass proxy di device Android ketika aplikasi terhubung internet. Selain itu terdapat SSLSocketFactory dengan menggunakan KTrust (ini contoh variable dari Keystore yang digenerate dari file certificated trusted SSL). Dengan begini ketika koneksi untrusted otomatis koneksi tersebut terputus (conn.disconnect() di bagian finally). Selain itu bisa juga koneksi tersebut diset DIRECT Connection dengan cara seperti ini. Tujuan bypass proxy ini juga agar tools pengujian penetrasi di atas semacam Charles Proxy dan SandroProxy tidak dapat bekerja dengan baik (karena kedua tools tersebut menggunakan proxy). Bacaan tambahan soal Socket Proxy.

Untuk kasus M4, insucure authentication, bisa diantisipasi dengan 2-step-verification, makanya saat ini standar di aplikasi Android seperti itu, dengan menggunakan PIN via SMS atu telepon, atau dengan menggunakan biometrik touchID (sidik jari). Selain itu perlunya memberitahukan pengguna soal level kuat tidaknya password yang ia gunakan. Makanya di form pendaftaran biasanya di bagian password dicantumkan level kekuatan password : very weak, weak, medium, strong, very strong. Dan jangan lupa, dihimbau agar jangan membuat fitur untuk menyimpan mpin atau password ke database local atau di-sharedPreferences. Bila ingin membuat fitur “remember password” ya perlu dibuat ada expirednya di kedua sisi (backend dan aplikasi mobile).

Untuk kasus M5, insuffienct cryptography.. rendahnya tingkat kriptografi membuat data yang terenkripsi dengan mudah didekripsi. Di aplikasi dapat ditambahkan mekanisme enkripsi dua arah (server dan aplikasi), jadi server mengirimkan public key atau bisa juga bikin API untuk generate userAPIKey yang akan digunakan aplikasi untuk enkripsi RSA, bisa menggunakan base64 atau yang lain. Contohnya banyak di stackoverflow, atau bisa lihat di sini. Ada juga yang sudah dalam bentuk lib yang bisa langsung dipakai di sini (saya rekomendasikan yang ini, karena sering saya pakai untuk beberapa aplikasi Android). Umumnya biar aman, publicKey dan userAPIKey digenerate dari server, tinggal user request via aplikasi ntah itu ketika splash screen atau ketika di landing screen (berjalan secara background ya..jangan ditampilin). Ketika userAPIKey dan publicKey diperoleh, aplikasi tinggal memakai publicKey, ditambah dengan deviceID, module, dan exponent untuk enkripsi dengan RSA, bisa dipakai untuk enkripsi pin, password, atau data penting lainnya. Cara mendapatkan value module dan exponent bisa berkunjung ke web berikut.

Untuk kasus M6, pernah tau gak kalau kita mau install aplikasi, akan dicantumkan popup permission? nah, di situ aplikasi memiliki otorisasi untuk mengakses beberapa komponen dari OS device kita. Contoh, ketika kamu install aplikasi kamera, maka ketika install dan jalankan akan muncul popup meminta permisi untuk mengakses kamera (camera permission), atau aplikasi sticky notes, ketika kita install dan jalankan, akan muncul pop-up meminta izin mengakses storage, dll. Nah, pentingnya bagi pengguna untuk waspada, aplikasi apa yang kita install dan izin apa saja yang kita berikan. Jangan sampai kita menginstall aplikasi senter, ternyata permissions yang diminta banyak: minta izin akses akun google, minta izin akses lokasi, dll…kan jadi aneh. Nah, dari sisi development, permission ini dicantumkan di manifest aplikasi. Dan ketika aplikasi hendak menjalankan suatu metode yang berhubungan dengan device, biasanya permission ini ikut triggered. Jangan sampai kita menambahkan permission yang tidak ada hubungannya dengan tujuan aplikasi tersebut.

Untuk kasus M7, pernah liat codingan orang lain yang acak-acakan? atau gak perlu jauh-jauh, cek aja codingan sendiri 5 tahun yang lalu, mesti masih berantakan..hehe. Nah, code yang jelek seperti ini akan jadi masalah, rawan bug, rawan celah keamanan. Maka berlatihlah menulis code dengan baik dan benar hehe. Apalagi sekarang sudah ada beberapa standar atau pattern di dalam penulisan code Android. Dulu kenal MVC -> Model, View, Controller? nah di Android, selain MVC, ada juga pattern MVVM dan MVP. Dengan menerapkan pattern tersebut, otomatis kita sudah membiasakan codingan yang lebih rapih dan baik.

Untuk kasus M8, pernah liat atau pernah melakukan install APK mod sebuah games yang duit/emerald/koinnya bisa 99999999. Mungkin pernah main Candy Crush atau game lain yang koinnya 999999 (unlimited)? nah, APK tersebut adalah apk yang sudah dimodifikasi alias sudah ditambahkan code lain yang tidak resmi. Biasanya, APK itu di-build tanpa obfuscatedJadi, ketika APK didecompile, ya codenya terbaca jelas. Ya sudah, akhirnya si penyusup dapat menambahkan code lain-lain yang berbahaya, tinggal compile ulang dan sebarkan. Nah, bahayanya, ketika kita sebagai pengguna tidak tau kalau APK tersebut disisipi code berbahaya, ntah itu mengambil data akun kita (facebook, dll), atau merekam aktivitas kita di HP. Untuk mengantisipasi agar ketika APK di-decompile, codenya rusak (obfuscated), bisa menggunakan ProGuard dan aktifkan minify APK dari gradle. Selain itu di sisi server juga ditambahkan pengecekan apakah APK tersebut original ataukah mod, bisa dengan generate appID setiap update, jadi ketika versinya outdated atau appID tidak valid, maka tidak dapat terhubung ke server. Atau mekanisme pengecekan apakah APK rooted ataukah resmi. Pernah lihat kan? gak bisa install apk tertentu (misal netflix), karena HP/device Android kamu rooted? nah itulah bagusnya sisi keamanan app. tersebut.

Reverse engineering (M9), sudah pernah install aplikasi android “Show Java” ? coba deh install di PlayStore, atau klik tautan ini. Aplikasi tersebut memungkinkan aplikasi yang terinstall di device Android untuk di-decompile. Jadi, inputnya APK, outputnya jadi source-code Java (di-reverse engineering). Nah, kalau tidak di-obfuscate, codingan kamu ya akan terbaca jelas semua melalui aplikasi reverse engineering tersebut. Jadi source-code java, xml, dan lain-lain dari aplikasi tersebut dapat dilihat, dipelajari dan bahkan bisa dicari celah keamanannya. Bahayanya, jika kamu menaruh API_KEY atau hal-hal lain yang mestinya bersifat rahasia, jadi ketahuan deh. Cara antisipasi ini ya dengan di obfuscate melalui proguard dan atau..dengan minifyEnabled diset “true” di gradle app. aplikasi kamu (di bagian buildTypes>release). Selain cara menggunakan app “show java” di atas, apk kamu sebenarnya bisa dengan mudah di-reverse engineering dengan mengganti extensi apk menjadi zip atau tar. Misal, nama filenya: app-release.apk, coba deh ganti jadi app-release.zip, terus extract… Tadaaa… keliatan semua tuh folder dan file java beserta xmlnya. Makanya perlu diantisipasi dengan obfuscate itu tadi. Cara modding apk yang banyak dilakukan cracker untuk beberapa games ya dengan cara inject file atau replace file yang ada di dalam package apk tersebut (diubah jadi ext .zip terlebih dahulu) dengan file yang sudah dimodifikasi. Nah ini dia celahnya, jadinya ya APKnya sudah tidak signed lagi. Makanya penting menginstall apk yang sudah signed. Di PlayStore juga kalau mau publish apk mesti signed menggunakan keystore. Jangan install apk sembarangan ya.

Extraneous Functionality (M10), hal yang fatal yang sering ditulis developer di code aplikasinya adalah mengakses API dengan menaruh parameternya pada URL (dengan method GET), yang terkadang, bila si cracker mampu melakukan debug aplikasi, kemudian membaca URL APInya, kemudian membuat “backdoor“, mencobanya di browser, tadaa..ternyata berhasil diakses. Nah, dari sisi backend semestinya hal ini bisa dihindari. Jangan sampai API bisa diakses via url. Dan di Android sendiri sudah ada cara yang aman, misal menggunakan retrofit atau okhttp, dengan method POST dan tentunya seperti yang dibahas sebelumnya, parameternya di-enkripsi. Selain itu, matikan semua debug atau Log yang dipasang di app agar tidak ada data di background yang terbaca oleh orang yang tidak seharusnya. Periksa semua API endpoint yang diakses dari mobile app, apakah sudah tertulis dengan benar dan periksa semua log statement di source-code, jangan sampai ada sesuatu dari backend terbaca jelas di log (walaupun tujuannya sekedar buat debugging, tapi yang seperti ini bisa jadi celah).

Sekian pembahasan dari saya. Semoga bermanfaat bagi semua, dan mampu membuat code yang well-written, dan ini juga menjadi pengingat bagi diri saya pribadi yang masih perlu banyak belajar.

 

 

Meninggalkan zona nyaman haruskah “resign” dari kantor?

Seseorang teman bilang: “yah, masa’ lo balik ke zona nyaman di kantor sebelumnya hanya krn lokasinya jauh?”
tak balas: “yg pgn balik ke zona nyaman siapa? itu pertimbangan jauh ya krn faktor kesehatan dan tingkat stress kalo macet. Tempat kerja baru, jauh sekali..trs saya minta balik ke kantor sebelumnya bukan berarti itu zona nyaman”

Meninggalkan lokasi kerja sebelumnya tidak sama dengan meninggalkan zona nyaman.
Zona nyaman jangan diartikan sempit sebatas tempat kerja.
Zona nyaman itu adalah tempat di mana seseorang merasa aman dan nyaman dan gak mau lagi mencoba hal baru, ragu mencoba sesuatu yang baru dan ragu buat belajar hal baru. Jadi zona seperti itu ya ditinggalkan, bukan kantornya yang ditinggalkan

Contohnya…misal orang tersebut posisi programmer, terus upgrade skill berbeda dengan “push” dan memotivasi diri sendiri untuk belajar sesuatu yang baru. Bisa juga dengan terjun langsung ke tantangannya. Misal: programmer kantoran, kerjaannya gitu2 aja, malah lbh banyak santai youtube-an di kantor, main game, terjun ke dunia proyek (bisa sambilan, bisa ngisi waktu pas liburan atau pas malam hari), walaupun dia belum punya pengalaman, dengan dia berani..dia sdh meninggalkan zona nyaman. Toh, dengan begitu dirinya tertantang buat belajar menghadapi klien, belajar berkomunikasi dengan orang yang berbeda, belajar mencari solusi dari permasalahan yang dihadapi klien dan bagaimana menyampaikannya dengan baik agar solusi tsb dapat diterima oleh orang lain, dan belajar pemrograman baru, teknologi baru, dll. Tanpa meninggalkan kantornya, dia sdh meninggalkan zona nyaman. Itu hanya sebagian contoh loh. Masih banyak contoh lain.

Contoh lainnya, misal dari programmer, tapi pengen naik tingkat ke level yang lebih tinggi, yaitu posisi analyst atau mungkin lebih tinggi lagi, posisi project manager. Jadi sembari dia kerja di kantor sebagai programmer, dia proactive, moving forward memperhatikan bagaimana analyst dan PM bekerja, dia gak malu bertanya, berdiskusi, ngajak makan bareng analyst atau PMnya, buat sekedar mendapatkan ilmunya dan menjalin komunikasi yang baik. Dia akhirnya punya inisatif tinggi di grup dan di kantor, tidak hanya menunggu bola, tapi juga menjemput bola sambil menyampaikan apa strateginya. Ini juga termasuk meninggalkan zona nyaman. 🙂 


Balik ke masalah lokasi, tempat lokasi itu jadi faktor penunjang performa kerja. Kalau tempat jauh, capek atau tua di jalan, performa menurun, boro-boro meninggalkan zona nyaman, buat dapet kenyamanan di kantor aja akan jadi sulit, lah sdh stress di jalan, kerja tentu jadi gak maksimal. Makanya tiap mulai kontrak kerja itu sebisa mungkin pro-active, nego, nanya, dan berdiskusi dengan baik agar ada jalan keluar dan solusi bersama, toh sama-sama butuh kan.


“Tapi kok kamu malah minta balik ke kantor lama sih, wid?” | “eittss, jangan salah..itulah strategi tarik ulur dalam negosiasi.. dengan klien-klienku juga tak pake cara serupa hehe..toh yang penting tiada yang dirugikan, dan kita tidak merugikan orang lain” (terinspirasi ibu-ibu yang nego harga di pasar..wkwkwk)