Code Obfuscation

Code Obfuscation adalah salah satu bentuk proteksi agar kode sulit dibongkar orang lain. Inti dari obfuscation adalah menyamarkan/membuat kode sulit dibaca. Obfuscation bisa dilakukan manual atau dengan tool yang disebut “obfuscator”. Sementara itu dari sisi reverse engineering, proses mengembalikan dari bentuk samar ini disebut “deobfuscation”.

Arti kata “samar” di KBBI

Meskipun kata “samar” sepertinya cukup berpadanan dengan “obfuscated” saya akan tetap menggunakan istilah inggrisnya di posting ini.

Di posting ini saya hanya ingin memberikan beberapa ilustrasi nyata seperti apa obfuscation ini. Untuk para programmer, ini bisa membantu memproteksi  program, dan untuk para reverse engineer bisa berusaha memahami bagaimana obfuscation dilakukan.

Contoh obfuscated code

Obfuscation

Jika kita punya dua fungsi sederhana seperti ini:

int search(int element, int *data, int count)
{
    for (int i =0; i < count; i++) {
          if (data[i] == count)
                return i;
    }
    return -1;
}

int replace_first(int element, int replacement, int *data, int count)
{
    int pos = search(element, data, count);
    if (pos !=-1) {
        data[pos] = replacement;
        return 1;
    }
    return 0;
}


Bentuk obfuscation pertama adalah dengan mengganti nama menjadi nama lain. Ini bisa jadi nama yang sangat singkat misalnya “a”. Pada kode yang dikompilasi menjadi bahasa mesin, nama ini bahkan tidak ada lagi karena tidak diperlukan. Pada bahasa lain yang tidak dicompile jadi bahasa mesin (seperti Java dan Python), nama ini akan tetap ada.

Tanpa membaca kodenya, sudah sulit menebak apa fungsinya ini

int a(int a1, int *a2, int a3);
int b(int a1, int a2, int *a2, int a3)

Bahasa tertentu (seperti Java/C++) mendukung overloading. Beberapa fungsi bisa memiliki nama sama asalkan parameternya berbeda:

int a(int a1, int *a2, int a3);
int a(int a1, int a2, int *a2, int a3)

Cara lain adalah dengan mengubah namanya menjadi menyesatkan, misalnya kedua nama seperti di atas diubah menjadi seperti ini (perhatikan bahwa sengaja count-nya dipindah ke depan untuk menyesatkan pembacanya).

int clear(int count, int *data, int position);
int remove_range(int start, int end, int *data, int element);

Selain penggunaan nama yang menyesatkan, cara lain adalah dengan mengubah control flow program. Contoh sederhananya seperti ini, kita memanggil beberapa fungsi berurutan:

verify_license();
initialize_printer();
initialize_camera();
connect_to_database();

Jika sebuah bahasa mendukung goto maka bentuk obfuscationnya bisa seperti ini:

verify_license();
goto label2;

label1:
initialize_camera();
connect_to_database();
goto label4;

label2:
initialize_printer();
goto label1;

label4:

Jika suatu bahasa tidak mendukung goto urutan operasi bisa disamarkan dengan loop dan switch:

int order[] = {3,1,2,0};
for (int i =0; i < 4; i++) {
   switch (order[i]) {
        case 0: connect_to_database(); break;
        case 1: initialize_printer(); break;
        case 2: initialize_camera(); break;
        case 3: verify_license(); break;
   }
}

Obfuscation kecil seperti contoh di atas masih mudah dimengerti untuk kode yang pendek. Untuk kode yang besar, jumlah “case”-nya bisa puluhan, dan masing-masing nama fungsinya tidak jelas.

Beberapa obfuscation bisa mudah dilihat jika data atau string terlihat jelas, misalnya jika ada kode seperti ini, meskipun kita tidak tahu apa itu kelas x, tapi terlihat bahwa fungsi saat ini berhubungan dengan enkripsi AES:

            throw new x("AES decrypt error");

Jadi bentuk obfuscation berikutnya adalah: string encryption supaya tidak mudah mencari string di dalam program dan mempersulit pemahaman. Tentunya string ini harus bisa didekrip ketika program berjalan, hanya mempersulit pemahaman program.

            throw new x(decrypt(ConstString.ERR1));

Teknik-teknik lain juga bisa ada banyak, saya tidak akan memberikan contoh kode satu persatu. Beberapa yang bisa dilakukan misalnya

  1. Obfuscation di level bahasa mesin/bytecode
  2. Menggunakan exception untuk control flow obfuscation
  3. Menyisipkan kode sampah, misalnya mengurutkan elemen, lalu mencari elemen tengah, menjumlahkan semua elemen, lalu hasilnya tidak dipakai
  4. Menggunakan thread untuk memecah algoritma menjadi beberapa bagian sehingga lebih sulit di mengerti
  5. Mengubah logika program, misalnya menambahkan angka 2312312 di awal, lalu di akhir dikurangi lagi 2312312
  6. Menggunakan enkripsi dan/atau kompresi untuk sebagian kode program yang diload secara dinamis
  7. Memakai custom virtual machine

Perlu diperhatikan bahwa obfuscation tertentu bisa membuat program jadi lebih lambat. Sekedar mengganti nama method tidak akan membuat lebih lambat (bahkan biasanya malah membuat sedikit lebih cepat), tapi mengganti control flow biasanya membuat kode menjadi lebih lambat. Obfuscation juga membuat debugging menjadi lebih sulit (karena memang itu tujuannya). Jadi sebaiknya obfuscation hanya dilakukan di akhir development.

Saya tidak bisa menyarankan tool obfuscator tertentu karena memang jarang melakukan obfuscation pada kode saya, silakan search “obfuscator” dan nama bahasa yang Anda pakai di search engine. Tool obfuscator yang banyak saya temui adalah  Proguard (gratis) yang dipakai untuk kode Java/Android.

Di dunia Javascript ada istilah minifier, yaitu tool untuk membuat kode Javascript mejadi lebih kecil. Ini dilakukan dengan mengganti nama variabel, menghapus spasi, komentar dsb. Secara umum ini juga berfungsi sebagai obfuscator sederhana.

Deobfuscation

Secara umum tidak ada cara generik yang membuat obfuscated code bisa dibaca dengan mudah. Tapi ada beberapa tool yang bisa membantu proses deobfuscation spesifik untuk bahasa/teknologi tertentu.

Contohnya jika bertemu dengan kode JavaScript yang sudah minified, maka kita bisa memakai JavaScript beautifier. Ini tidak bisa mengembalikan nama variabel, hanya membuat teks yang sulit dibaca menjadi lebih mudah dibaca (tool beautifier ini sekarang sudah built in di Developer Tools-nya Google Chrome).

Contoh lain: ada yang membuat tool untuk mendekrip String untuk APK yang ditulis dalam Java. Tapi tool ini tidak selalu jalan untuk semua protektor. Setiap kali ada yang membuat tool untuk otomasi sesuatu, pembuat obfuscator menambahkan satu hal kecil sehingga toolnya harus diupdate (atau bahkan ditulis ulang).

Cara yang pasti berhasil adalah kombinasi manual dengan debugger dan sedikit programming.  Hal utama adalah memahami obfuscation apa yang dilakukan: apakah stringnya dienkripsi, apakah nama methodnya diubah, apakah control flow-nya berubah, dsb.

Jika sekedar nama methodnya diubah, maka kita harus membaca kodenya dan melakukan renaming untuk mendapatkan nama yang benar. Ini bisa dilakukan berdasarkan beberapa hal, misalnya:

  • string yang muncul (misalnya “AES Error” mengindikasikan AES)
  • konstanta yang dipakai (misalnya 0x9E3779B9 mengindikasikan penggunaan enkripsi XTEA)
  • fungsi yang memanggil. Misalnya jika suatu fungsi dipanggil dari fungsi AES, maka kemungkinan itu hanyalah subrutin AES
  • fungsi yang dipanggil, misalnya jika aplikasi C memanggil “system” maka kemungkinan ini fungsi menjalankan command line lain
  •  algoritma yang dipakai. Beberapa algoritma sederhana (search, sort, traversal) mudah diidentifikasi

Untuk mendapatkan gambaran sebuah program seperti menyusun sebuah puzzle. Kita bisa mulai dari bagian-bagian yang jelas. Untuk puzzle bagian yang jelas adalah pinggiran puzzle, dan bagian-bagian yang unik. Untuk program kita bisa mulai dari titik awal program (main di sistem POSIX, Activity di Android, dsb), dan titik di mana program memanggil fungsi eksternal.

Jika string dienkripsi, kita bisa membuat breakpoint di method dekrip-nya agar bisa mendapatkan hasil string-nya. Jika control flow-nya obfuscated, kita bisa membuat beberapa breakpoint untuk berhenti di tiap titik, jadi kita bisa mengetahui urutan yang sebenarnya. Selain menggunakan breakpoint dan debugger, kita juga bisa menggunakan Frida atau tool sejenis.

Penutup

Walaupun obfuscator bisa membantu melindungi program, tapi faktor keamanan lain harus tetap diperhatikan. Attacker yang gigih akan bisa membuka segala jenis obfuscation, hanya akan memperlama saja. Di kasus tertentu kombinasi obfuscator dan pentester yang kurang berpengalaman justru bisa membuat aplikasi kurang aman karena testing aplikasi kurang optimal.

Contohnya begini: aplikasi memakai enkripsi, lalu kodenya diobfuscate.  Aplikasi ini ditest oleh pentester yang tidak bisa melakukan reverse engineering terhadap kode tersebut, dan pentester menganggap aplikasi tersebut aman karena dia tidak dapat melakukan tampering terhadap nilai yang dikirimkan. Ketika aplikasi dirilis dan dibongkar oleh seorang reverse engineer yang berpengalaman, dia dapat mengubah nilai yang dikirimkan dan ternyata tidak dicek di sisi server (aplikasinya jebol).

Jadi sebaiknya: pentester diberi akses pada kode yang belum obfuscated dan kode final yang sudah. Ini akan lebih optimal karena kerja pentester lebih cepat, tidak perlu membongkar obfuscation dan lebih aman (seluruh fungsi bisa ditest dengan baik). Ini dengan asumsi bahwa pentester memiliki keahlian untuk membaca kode dengan baik.

Semoga artikel singkat ini bisa memberikan gambaran mengenai apa itu code obfuscation dan berbagai batasannya.

XPosed: Framework sakti untuk modifikasi Android

Topik kali ini agak advanced, tapi juga pratis. XPosed  adalah sebuah framework open source yang memungkinkan kita membuat modul untuk memodifikasi sistem dan aplikasi Android yang ditulis menggunakan Java. Dari sudut pandang programming, framework ini menarik karena memungkinkan kita menambahkan dan mengintersepsi kode pada aplikasi closed source Android, sedikit mirip Aspect Oriented Programming.

Screenshot_2016-08-21-07-33-48.png

XPosed bekerja dengan memodifikasi runtime Android (Dalvik/Art) sehingga menjadi mungkin untuk memanggil kode custom di awal atau akhir sebuah method apapun. Perhatikan bahwa yang dimodifikasi adalah runtime Android saja, jadi hanya kode yang ditulis dalam Java dan diinterpretasikan oleh Dalvik atau Art runtime saja yang bisa diintersepsi, kode native tidak bisa. Ada framework lain, misalnya Cydia yang bisa mengintersepsi kode native juga, tapi Cydia versi Android ini agak lambat perkembangannya (saat ini belum mendukung Android 5 dan 6).

Untuk memakai XPosed, yang harus Anda lakukan adalah: menginstall recovery alternatif (CWM, TWRP, dsb) dan menginstall frameworknya (tergantung ponsel Anda, ini mungkin bisa membatalkan garansi). Anda juga perlu menginstall XPosed installer yang akan memanage modul mana saja yang aktif.

Mari kita mulai dengan contoh yang praktis tentang intersepsi kode. Jika kita punya kode seperti ini:

Kita bisa mengintersepsi ini dengan mengembalikan agar isValidLicense selalu menjadi true. Kita juga bisa memodifikasi agar  validateLicense segera kembali (tidak melakukan apapun, jadi tidak akan melempar exception). Dalam kasus yang sebenarnya, kita harus teliti, misalnya mungkin di dalam ada validateLicense kode lain untuk mensetup versi premium jika license valid (jadi tidak bisa kita patch agar selalu kembali).

Dalam contoh di atas method checkRoot melakukan pemeriksaan apakah device di-root oleh pengguna, dan cara memeriksanya adalah dengan menggunakan XML yang berisi daftar command dan package yang harus diperiksa. Dalam kasus seperti ini (ini penyederhanaan dari kasus nyata yang saya temui), maka kita bisa juga mengganti parameter input XML menjadi XML kosong.

Berikut ini contoh kode untuk mem-patch agar isValidLicense selalu mengembalikan true.

Beberapa baris pertama hanya mengimpor package yang kita butuhkan. Berikutnya kita perlu mengimplementasikan IXposedHookLoadPackage. Di dalam handleLoadPackage, kita bisa memfilter untuk package aplikasi mana saja hooking ini akan kita lakukan. Dalam kasus ini saya hanya tertarik pada satu aplikasi saja. Dalam kasus tertentu kita ingin menghook semua aplikasi, misalnya kita bisa membuat modul untuk melakukan SSL Unpinning untuk semua aplikasi.

Berikutnya yang harus kita ketahui adalah signature dari method yang akan kita hook. Untuk aplikasi yang sourcenya terbuka, atau untuk aplikasi yang mudah didekompilasi karena tidak diobfuscate, hal ini mudah dicari. Jika aplikasi di-obfuscate, hal ini agak lebih sulit. Dalam contoh ini package yang dimaksud adalah es.yohan.example dan methodnya adalah isValidLicense yang memiliki parameter berupa String.

Ada dua hook yang tersedia: beforeHookedMethod dan afterHookedMethod. Dalam beforeHookedMethod, kita bisa mengubah parameter yang masuk ke program (atau bisa juga sekedar melakukan logging atau mengirimkannya ke tempat lain), dan dalam afterHookedMethod kita bisa menerima dan atau mengubah nilai kembalian method. Dalam contoh di atas, saya hanya mengeset agar hasilnya selalu true.

Mungkin sekarang Anda bisa melihat kelemahan XPosed: modifikasi hanya bisa dilakukan di awal dan di akhir method. Jika Anda ingin memodifikasi sesuatu di tengah-tengah, misalnya mengubah konstanta yang tertanam di logika program (misalnya if (x>2127)), atau sekedar mengubah “kurang dari” menjadi “lebih dari” maka sulit melakukannya dengan XPosed.

Jika masih ingin mengubah detail sebuah method dengan XPosed, caranya adalah dengan menulis ulang method itu, dan di beforeHookedMethod kita memberitahu XPosed framework agar tidak memanggil method aslinya. Dalam kasus tertentu lebih mudah mengedit file APK-nya.

Secara praktis apa saja yang bisa dilakukan dengan kemampuan XPosed ini? Sudah banyak orang menuliskan modul untuk Xposed, dari mulai sekedar mengubah kosmetik Android (mengubah tampilan ini dan itu), menambahkan fitur tertentu (misalnya menambahkan Zoom ke aplikasi Instagram), memblokir iklan di berbagai aplikasi (termasuk juga Youtube yang sekarang memasukkan iklan bukan hanya di awal video tapi juga di tengah video jika videonya panjang), memperbaiki offset GPS di China, dan masih banyak lagi.

Ada juga modul untuk meningkatkan privasi (misalnya XPrivacy dan PMP), dengan memblok berbagai request dari aplikasi Android yang nakal atau mengembalikan data palsu. Contoh: banyak sekali aplikasi yang meminta akses ke contact list, ternyata mengupload seluruh phonebook kita ke server mereka (dengan berbagai alasan, misalnya untuk fitur referal, dsb).

Penghematan batere juga bisa dilakukan, misalnya dengan memblok aplikasi agar tidak bisa auto start, membatasi akses sensor, dsb.

Kebanyakan modul di repository XPosed berguna untuk mengatasi masalah sangat spesifik yang dimiliki oleh pengguna (misalnya ada yang nggak suka jika app yang baru diinstall langsung memiliki shortcut di home screen, ada yang nggak suka jika VPN meminta konfirmasi, dsb). Menurut saya itu kelebihan utama XPosed: kita bisa memodifikasi Android dengan mudah sesuai kemauan kita. Sebagai programmer, modifikasi ini bisa dilakukan meskipun kita tidak memiliki source code aplikasinya.

Secara praktis bagai saya pribadi: Sebagai pentester, saya kadang menemui aplikasi yang melakukan pengecekan root dengan cara yang unik dan modul XPosed seperti RootCloak tidak cukup. Saya kadang melakukan patching aplikasi langsung (jika masih testing tahap development), dan mengembangkan frameworknya (jika aplikasi sudah di appstore, karena biasanya sudah stabil)

Kadang saya juga perlu mengintersepsi komunikasi dengan enkripsi yang custom (misalnya memakai AES dua kali), dalam kasus ini intercept via proxy tidak cukup (datanya sudah dienkrip, dan tidak bisa dengan mudah didekripsi karena formatnya custom). Di dalam kodenya pasti ada sesuatu yang mengenkrip data sebelum dikirim dan mendekrip data yang diterima, dengan mengintercept titik tersebut, saya tidak perlu menulis program khusus untuk dekrip/enkrip ketika testing.

Saya juga pernah membuat modul khusus untuk intersepsi Blackberry Messenger (BBM). Cara kerja modulnya seperti ini: saya membuat web server di Android yang bisa menerima pesan untuk dikirimkan, dan pesan itu saya inject langsung ke proses BBM. BBM selalu menyimpan message dalam format internalnya setelah diterima, jadi kita bisa mengakses message dari conversation manapun. Perlu dicatat bahwa modul ini bisa saya kembangkan dengan mudah karena di versi awal mereka tidak melakukan obfuscation, dan ketika sudah diobfuscate, saya masih bisa melihat mapping class/methodnya berdasarkan berbagai pesan error yang ada di method tersebut.

Untuk membuat XPosed module sendiri, sudah ada berbagai tutorial di Internet, tapi saya akan memberikan panduan singkat, sekaligus sebagai catatan untuk diri sendiri.

Pertama: buat proyek baru dengan Android studio. Pastikan instant run dimatikan karena tidak kompatibel dengan Xposed. Tidak perlu template khusus untuk membuat modul XPosed.

Kedua: edit file gradle dengan menambahkan dependensi: provided 'de.robv.android.xposed:api:82'. Tentunya versi 82 bisa diganti dengan versi terbaru.

Ketiga: implementasikan IXposedHookLoadPackage, ini sudah dicontohkan di atas.

Keempat: buat file app/src/main/assets/xposed_init yang adalah file teks dan isinya adalah nama package + kelas yang mengimplementasikan IXposedHookLoadPackage tersebut. Ini akan dipakai oleh Xposed untuk mendari kelas mana yang akan diload saat booting.

Terakhir: edit file manifest agar dikenali sebagai modul XPosed. Pertama tambahkan atribut xmlns:tools="http://schemas.android.com/tools" di tag manifest (ini sekedar untuk menghilangkan warning). Lalu tambahkan beberapa metadata berikut di dalam tag application:

<meta-data  android:name="xposedmodule"
android:value="true" />

<meta-data  android:name="xposedminversion"
android:value="54" />

<meta-data  android:name="xposeddescription"
android:value="Joe Hack Module"
tools:ignore="ManifestResource" />

Tentu saja bagian tersulit adalah mencari tahu bagian mana yang perlu dihook untuk mengimplementasikan fungsionalitas tertentu. Tapi menurut saya ini juga sekaligus menjadi bagian yang paling menarik: kita jadi lebih mengerti internal sistem Android.

Modifikasi dengan XPosed framework melengkapi hack Android yang lain. Rooting aplikasi tidak cukup untuk mengubah internal program (contohnya untuk pentest aplikasi custom). Modifikasi dan compile ROM sendiri bisa mengubah hal-hal yang di luar kemampuan XPosed, tapi tetap tidak bisa mengubah aplikasi. Modifikasi aplikasi dengan cara patching manual bisa dilakukan, tapi cara ini lebih repot, dan akan sulit jika kita ingin mempatch banyak aplikasi sekaligus.

Sebagai pembuat aplikasi, mengobfuscate aplikasi Anda adalah salah satu cara untuk mempersulit hooking dengan XPosed framework. Contohnya: aplikasi Youtube sering diobfuscate dan sering diupdate sehingga modul seperti YoutubeAdaway tidak jalan.

Programming dan Penetration Testing

Pentest adalah kegiatan menyerang sistem komputer untuk mencari kelemahan security, atau dari Wikipedia:

A penetration test, or the short form pentest, is an attack on a computer system with the intention of finding security weaknesses, potentially gaining access to it, its functionality and data.

Pentesting dilakukan atas permintaan client, jadi bukan hacking ke sembarang website. Contoh sederhana pentesting seperti ini: coba jebol website perusahaan kami, apakah ada bug securitinya? atau: coba pergi ke lobi atau tempat parkir perusahaan kami, apakah ada WIFI terbuka, apakah dari situ bisa masuk ke sistem internal perusahaan kami?. Kami punya app mobile, apakah bisa “dijebol” (misalnya apakah kita bisa membuat request ke server supaya memberikan data user lain).

Karena ini blog mengenai programming, saya tidak akan membahas banyak mengenai pentesting, hanya ingin menunjukkan betapa keahlian programming bisa sangat berguna untuk pentesting. Dari contoh yang saya sebutkan di atas, scope dari pentesting bisa sangat banyak, mulai dari yang on site: datang dan mengecek kabel, wireless network, dsb, sampai ke level network dan aplikasi (baik web, desktop, mobile). Saya hanya ingin membahas aspek programming, untuk mendorong peminat bidang security agar mau belajar programming.

Perkiraan saya mungkin sekitar 70% pekerjaan pentesting bisa dilakukan dengan tools yang sudah tersedia, baik yang open source maupun komersial, tanpa butuh keahlian scripting ataupun programming. Sisanya bakal butuh programming. Bahkan saya yakin 100% beberapa jenis bug tidak bisa ditemukan tanpa keahlian programming.

Screenshot_2014-11-27-18-19-36

Kemampuan programming minimal yang dibutuhkan adalah bisa mengcompile atau menjalankan program dalam berbagai bahasa. Kadang di sebuah server tidak tersedia tool tertentu, jadi kita perlu mengcompile dari source karena OS di server itu sudah terlalu lama (misalnya masih banyak yang memakai RHEL 4). Jika tidak tahu bagaimana menjalankan sesuatu, maka sudah game over di titik ini. Pernah saya baca di blog pak Budi Rahardjo mengenai kompetisi CDC (Cyber Defense Competition):

Salah satu soal yang disampaikan adalah men-decode data base64 yang kemudian menjadi skrip Python, yang tinggal dijalankan. Lucunya ada banyak yang gak tahu Python. ha ha ha. Mereka kebingungan menjalankannya. Padahal tinggal “python namaskrip.py”. Mereka tidak perlu tahu bahasanya. hi hi hi. Ada yang pura-pura tahu dan me-rename menjadi bahasa C, menambahkan “#include ” dibagian awalnya, kemudian mencoba compile. Ya gak bakalan jalanlah. he he he.

Kejadian semacam di atas itu yang mendorong saya menulis tulisan seperti ini.

Keahlian lain adalah mencari program atau menulis program kecil dalam bahasa tertentu yang kadang tidak terlalu umum atau sudah kuno. Contoh: jika sebuah web server bisa menerima upload file, dan web server itu hanya bisa menjalankan ASP versi klasik, ya kita harus bisa mencari shell dalam ASP Classic (bukan ASP.NET). Berbeda dengan software development biasa di mana kita bisa memilih bahasa pemrograman atau teknologi yang ingin kita pakai, di sini kita dipaksa mengikuti apa yang tersetup di server.

Jika beruntung, sudah ada orang yang menuliskan program standar (web shell) yang memiliki fungsi seperti “file manager/file upload” (untuk mengupload tool tambahan), “shell” (untuk mengeksekusi command apapun di sisi server), dan “database shell” (untuk mengirimkan query apapun ke database). Jika tidak beruntung, atau ada batasan tertentu di server, mungkin kita perlu membuat tool baru. Contoh sederhana: jika server membatasi upload hanya 100 KB saja, sementara binary nmap yang ingin diupload (plus librarnya) besarnya beberapa megabyte, maka kita perlu membuat program kecil untuk mengupload parsial lalu menggabungkan hasil uploadnya.

Keahlian membaca kode dalam berbagai bahasa juga diperlukan. Dalam beberapa kasus, kita bisa mendapatkan akses ke source code aplikasi web (karena bug, karena salah konfigurasi, karena lupa ikut mengupload direktori “.git”, dsb). Setelah punya source code, kita bisa menemukan bug tambahan dengan membaca kodenya. Sebagai pentester, tentunya Anda tidak akan bilang: wah ternyata dia pake Python, saya nggak tau cara ngehack aplikasi web dengan Python.

Dengan membaca source code, hal paling minimal adalah mengerti di mana file konfigurasi supaya bisa mengekstrasi user/password database, berikutnya adalah mencari bug-bug tambahan seperti SQL Injection, hidden functionality, dsb.

Dengan maraknya OS Mobile, sekarang pentesting juga masuk ke ranah mobile. Di sini ilmu reverse engineering sangat diperlukan. Untuk OS Android, reverse engineering bisa dilakukan dengan decompiler yang bisa mengembalikan kode Java ke bentuk semula (kecuali sudah diobfuscate), jadi kembali keahlian membaca kode diperlukan.

Setelah mengetahui kodenya, biasanya kita perlu melakukan fuzzing request, alias mencoba-coba berbagai kemungkinan request. Untuk aplikasi berbasis HTTP, kita masih bisa memakai proxy (misalnya ZAP) dan mengubah-ubah request untuk tahu reaksi server (bagaimana jika nilaiya negatif, bagaimana jika nama file mengandung “../”, dsb). Tapi untuk aplikasi yang memakai protokol khusus via SSL, kita perlu memahami, lalu mengimplementasikan ulang client sendiri yang bisa melakukan fuzzing.

Pengetahuan mengenai best practice dalam sebuah bahasa juga diperlukan dalam membuat aplikasi yang aman. Contoh: untuk menghasilkan bilangan random untuk kriptografi di Java gunakan SecureRandom (jangan Random). Di Android untuk melakukan koneksi SSL menggunakan socket, jangan gunakan SSLFactory tapi gunakan SSLCertificateSocketFactory, dsb. Pekerjaan pentester cukup mudah di sini, hanya menyarankan saja, dan programmer yang akan mengimplementasikan saran tersebut.

Saya sudah banyak menemukan bug yang memerlukan banyak coding. Ada bug yang terkait dengan penyimpanan password (terenkripsi) yang disimpan lokal di device yang seharusnya aman, tapi ternyata saya bisa membuat tool yang cukup optimal untuk bisa mengcrack dalam 1 jam karena banyak hal kecil yang lupa dilakukan oleh programmer (lupa menginisialisasi IV, memakai EBC). Saya pernah menemukan bug fatal yang berhubungan dengan menggunakan algoritma hashing yang tidak aman (tidak memakai Cryptographic Hash Function). Dengan tools yang tersedia saja, tanpa pengetahuan programming (dan kriptografi), kedua bug itu tidak akan bisa ditemukan.

Jadi saran saya: untuk mereka yang tertarik di bidang security, pelajari juga bagian programmingnya. Ini saya masih bicara level pentesting yang kebutuhkan programmingnya masih minimal. Di bagian lagin security, keahlian programming lebih dibutuhkan lagi, misalnya membuat exploit butuh pemahaman yang lebih mendalam tentang sistem dan low level programming.

Dalam full security audit, selain pentesting kadang client menginginkan juga review kode mereka, jadi kita perlu bisa membaca, menjalankan, dan memberi saran yang berkaitan dengan security.

Buat saya sendiri sebagai programmer, saya jadi rajin membaca mengenai best security practice untuk berbagai bahasa dan framework. Jika ada yang bertanya: buat apa sih belajar bahasa X atau teknologi Y, saya bisa bilang: mungkin suatu saat ada sistem yang memakai teknologi itu yang perlu saya test.