Mengenal Scripting Zed Attack Proxy (ZAP)

Zed Attack Proxy (ZAP/Zaproxy) adalah intercepting proxy untuk pentesting aplikasi berbasis web. ZAP bisa dipakai untuk aplikasi web maupun aplikasi mobile/desktop yang memakai HTTP/HTTPS/Websocket. Jika belum mengenai ZAP, saya pernah menuliskan dasarnya di artikel hacking aplikasi web dengan zaproxy sekitar 2.5 tahun yang lalu. Sekarang saya ingin meneruskan dengan pengenalan scripting ZAP. Dengan scripting, kita bisa mengotomasi atau menambahkan fitur baru pada ZAP.

Sebenarnya tadinya saya ingin menampilkan banyak skrip, tapi setelah saya review lagi, sebagian besar skrip saya tertarget khusus untuk client tertentu dan tidak bisa saya sebarkan. Sebagian script lain hanya modifikasi kecil dari script komunitas yang sudah open source.

Add-ons vs Script

ZAP bisa ditambah fiturnya melalui dua cara: add-ons dan script. Add-on ditulis dalam Java tidak terbatas kemampuannya dan bahkan bisa dipakai untuk menambahkan bahasa scripting baru. Script lebih mudah dibuat dan dijalankan tidak perlu dicompile, mudah reload dan testnya, tapi kemampuannya terbatas.

Langkah untuk membuat Add-ons seperti ini: kita perlu menulis kode dalam bahasa Java, mengcompilenya, dan meload Add-on-nya. Contoh hal yang bisa dilakukan Add On: menambah berbagai fitur di menu ZAP, bisa mengubah tampilan, membuat dialog baru, menambah bahasa scripting baru, dsb.

Script sifatnya lebih sederhana: kita bisa mengedit dan menjalankan script langsung di dalam ZAP sendiri. Defaultnya script bisa ditulis dalam Javascript, dan Zest tapi kita bisa memakai bahasa lain jika menginstall add-on-nya (misalnya sudah ada add-on untuk Python dan Ruby).

Beberapa bahasa scripting yang disupport oleh ZAP

Script komunitas

Sebelum membuat script sendiri, sebaiknya cek dulu apakah sudah ada yang membuat skrip serupa. Saat ini sudah ada repositori skrip komunitas di:

https://github.com/zaproxy/community-scripts

Semua script komunitas sifatnya open source sehingga bisa dipelajari isinya seperti apa. Di ZAP kita bisa mensetup beberapa direktori yang berisi script. Contohnya di gambar berikut ini saya memiliki dua direktori script: satu dari komunitas, dan satu untuk script buatan saya sendiri. Karena direktori script bisa terpisah, maka saya bisa menggunakan versioning (git) pada script buatan saya.

Jenis script

Kali pertama memakai fitur script di ZAP, kebanyakan orang akan bingung: kok banyak sekali jenis scriptnya. Tapi setelah dibaca teliti, memang perlu ada banyak jenis script karena memang fungsinya berbeda. Akan saya bahas sebagian saja yang sering saya pakai.

Berbagai jenis script dalam ZAP

Payload Generator dan Payload Processor

Fuzzing merupakan bagian sangat penting dari testing aplikasi web. Umumnya lebih dari 50% mencari bug aplikasi web adalah via fuzzing. Inti dari fuzzing adalah: mencoba-coba secara otomatis.

Perkembangan seorang pentester biasanya seperti ini dari ketika belajar:

  • Pertama adalah mencoba-coba manual apakah jika saya beri input X maka akan keluar hasil Y (misalnya untuk testing SQL injection memakai tanda petik, XSS memakai tag <script>, dsb).
  • berikutnya lama-lama kita akan sadar: input yang kita coba ya biasanya ini saja terus, jadi kita bisa membuat file teks berisi daftar input yang akan kita coba secara otomatis (atau memakai list yang sudah ada dari internet).
  • berikutnya lagi kita kan belajar bahwa sering kali input fuzzing ini perlu diproses, kadang sekedar urlencode, kadang melalui base64 atau proses lain.

ZAP sudah memiliki beberapa fuzzer processor built in (urlencode, md5, base64, dsb) dan setiap kali fuzzing kita bisa memilih urutannya seperti apa. Contoh: mungkin ada parameter yang di-base64 lalu di-URL Encode.

Tapi aneka fitur ini tetap akan mentok atau tidak bisa dipakai jika aplikasi web memiliki parameter aneh. Misalnya ada parameter data yang isinya adalah JSON dan setelah itu JSON-nya diencode dengan base64.

Contohnya seperti ini:

data=eyJ1c2VyaWQiOjF9Cg

dan jika didecode ternyata menjadi:

{"userid":1}

Dalam kasus ini: misalnya kita ingin mengubah-ubah angka 1 dengan berbagai input, maka fitur dasar Fuzzing ZAP tidak bisa dipakai. Kita perlu menulis skrip sendiri.

Selain itu dengan skrip Payload generator, kita juga bisa membuat varian dengan mudah, misalnya kita bisa mencoba-coba:

  • input ditambah spasi
  • spasi diganti menjadi tab
  • dicoba diganti case hurufnya, misalnya jadi KAPITAL SEMUA, kecil semua, atau CamPUr

HTTP Sender dan Proxy

Skrip dalam kategori ini akan dipanggil untuk setiap request yang dikirimkan oleh ZAP. Banyak hal yang bisa dilakukan di sini, misalnya:

  • Mengubah user Agent
  • Menambah atau menghilangkan header tertentu
  • Menambahkan header hash/signature

Hal terakhir ini (menambah header/hash) yang paling sering saya pakai. Di berbagai mobile App yang aman, setiap request pasti diberi signature/hash. Jika hash tidak valid maka request ditolak. Cara ini memang cukup efektif menghentikan banyak serangan dasar: jika tidak bisa melakukan reverse engineering aplikasi, maka tidak bisa mengubah requestnya, hanya bisa melihat saja.

Setelah melakukan reverse enginering dan mengetahui hashnya seperti apa, beberapa hal yang biasanya dilakukan pentester adalah:

  • secara manual menghitung hash: request dicopy paste ke program, outputnya dicopy paste lagi, digabungkan lalu request dikirim
  • membuat program khusus untuk hashing

Tapi menurut saya cara yang lebih praktis adalah dengan membuat skrip HTTP Sendiri. Dengan skrip HTTP Sender kita bisa mengedit request, menekan send. Secara otomatis request akan dikirim ke skrip HTTP Sender yang sudah kita program untuk menghitung hash secara otomatis. Selain untuk input manual, input fuzzer juga akan diproses otomatis. Jadi semua list SQL injection, XSS dsb bisa ditest dengan cepat. Sekedar catatan: dalam kasus tertentu, kita bahkan bisa memakai frida untuk melakukan algoritma perhitungan hash secara langsung di mobile device dan dipanggil dari skrip HTTP Sender.

Ada varian skrip HTTP Sender yang bernama Proxy , tapi hanya akan dijalankan pada request yang datang dari browser/mobile dan lewat proxy. Request manual tidak lewat ke skrip Proxy, hanya ke HTTP Sender.

Berikut ini contoh salah satu script HTTP Sender yang saya miliki dengan key dan nama host target yang sudah saya sensor menjadi XXXX. Dalam contoh ini:

  • Request dihash menggunakan HmacSHA256
  • Header ts perlu diset dengan waktu saat ini
  • Header hash diset dengan nilai hash

Passive Rules dan Active Rules

Kadang bug tertentu bisa ditemukan hanya dengan mengamati request yang lewat saja (request dari pemakaian aplikasi biasa yang tidak diubah sama sekali). Contoh pengamatan: apakah memakai library Javascript versi tertentu, apakah cookie sudah secure, apakah versi software muncul, dsb. Berbagai pemeriksaan dasar ini sudah built in dalam ZAP, tapi jika terpikir ada sesuatu yang baru kita bisa menambahkan pengecekan ini sendiri di skrip Passive Rules.

Selain skrip Passive Rules, ada juga skrip Active Rules. Sesuai namanya, script jenis Active Rules hanya akan dijalankan hanya ketika kita melakukan active scan (klik kanan pada host, pilih Attack, pilih Active Scan). Dalam mode active scan, kita membuat request baru dan mengecek responsenya untuk tahu apakah ada bug tertentu.

Fitur sejenis dirbuster berguna untuk mencari apakah URL tertentu ada atau tidak, atau responsenya apa, tapi tidak bisa memeriksa kontennya. Contoh: kita bisa yakin bahwa repository git terbuka jika ada url .git/config dan isinya adalah teks (bukan HTML). Ini adalah contoh di mana active scan diperlukan: mengirim request, dan mengecek konten hasilnya.

Skrip yang bisa dibuat untuk keduanya biasanya adalah untuk mengetes bug baru yang belum masuk ke tool terbaru. Mungkin ada CVE baru untuk aplikasi tertentu atau mungkin aga bug di aplikasi buatan lokal (buatan Indonesia) yang tidak ada CVE-nya.

Contoh kecilnya adalah skrip yang pernah saya buat sekitar 2017/2018 untuk bug primeface (bug ini sejak 2016). Ini merupakan pengecekan pasif paling sederhana adalah sekedar mengecek apakah URL mengandung string tertentu.. Bug ini hampir terlewat karena tidak berhasil dicek dan dieksploitasi otomatis. Dengan membuat skrip ini, saya bisa yakin kali lain saya tidak akan melewatkan bug ini.

Targeted

Skrip jenis Targeted digunakan untuk memproses request dalam history. Intinya adalah: kita bisa menelusuri satu per satu request yang sudah pernah dilakukan di masa lalu dan melakukan aksi tertentu. Beberapa contohnya begini:

  • Ada request/response dari yang terenkripsi secara custom dan ingin kita dekrip semuanya
  • Ada sesuatu yang ingin kita cari tapi kompleks, misalnya ingin mencari yang URL-nya mengandung kata download, dan headernya mengandung string tertentu
  • Ada bug baru dipublikasikan dan kita ingin tau apakah pentest yang pernah dilakukan sebelumnya mengandung string tertentu yang mengindikasikan bahwa ada bug yang baru tersebut
  • Kita ingin mengirim request baru berdasarkan beberapa request lama yang kita pilih, misalnya request yang tadinya memiliki content-type XML kita kirim ulang sebagai JSON, atau tadinya memakai User Agent Mozilla Firefox diganti dengan Chrome Mobile

Stand Alone

Sesuai namanya, skrip ini bisa dijalankan sendiri. Biasanya saya pakai ini untuk persiapan testing. Contoh: jika saya sedang testing app Android, saya ingin meng-exclude agar situs-situs tertentu langsung dilewatkan saja dan tidak diproses (misalnya crashlytics.com). Jadi scriptnya akan otomatis memasukkan daftar URL tertentu ke setting excluded URL.

Penutup

Masih ada beberapa jenis script lain yang tidak saya bahas di sini. Ini bisa dicek sendiri di dokumentasi ZAP karena sisanya jarang saya pakai. Berbagai contoh skrip tersedia di repository skrip komunitas.

Karena sudah cukup lama melakukan pentest, saya tidak ingin mengulangi manual hal yang sama tiap kali diberikan target baru, jadi banyak hal saya otomasi dengan ZAP. Saya menyarankan pentester yang belum menggunakan scripting untuk mencobanya.

Meskipun Anda bukan programmer yang jagoan dan skrip Anda belum sempurna, maka ini tetap bisa menghemat waktu. Saran saya begini:

  • Jalankan saja skrip Anda (meskipun masih belum sempurna)
  • Jika berhasil menemukan bug: bagus sekali
  • Teruskan pemeriksaan manual, jika ketemu bug yang tidak ditemukan script, coba perbaiki scriptnya supaya lain kali bug ini ketemu

Dengan menggunakan teknik scripting, akan semakin banyak waktu luang ekstra yang kita miliki dan ini bisa digunakan untuk belajar dan mencoba teknik tingkat lanjut yang baru kita pelajari.

Sebagai penutup: berbagai tool lain seperti Burp dan Fiddler juga punya fitur scripting, tapi menurut saya ZAP yang paling mudah dipakai. Apapun tool yang dipakai, cobalah kenali dan gunakan secara maksimal.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.