Cerita pengalaman pentesting

Sudah beberapa tahun terakhir saya melakukan pentesting eksternal, menjadi freelancer melalui salah satu perusahaan security di Jakarta. Kali ini saya ingin menuliskan cerita pengalaman, dari mulai kenapa pentesting itu fun, dan beberapa pelajaran yang bisa dipetik (lesson learned) dari pekerjaan pentesting ini. Mengenai pembahasan apa itu pentesting dan serba-serbinya (terutama untuk orang yang ingin produknya ditest), bisa baca tulisan saya sebelumnya serba serbi pentest.

Berbagi ilmu bukan berarti saya sudah jagoan. Saya tidak merasa diri saya sangat jago, dan tidak merasa bahwa apa yang saya pentest pasti sudah aman. Tapi saya merasa ada beberapa hal yang saya tahu yang bisa saya bagikan. Sebagian pentester sangat pelit dengan ilmunya supaya kelihatan jagoan (padahal ilmu pentesting ya itu-itu aja).

Karena pekerjaan saya lakukan secara remote, scopenya biasanya terbatas: web dan aplikasi mobile. Tapi kadang ada juga pekerjaan yang melibatkan hardware misalnya kartu NFC (bendanya dikirim ke sini dan dikirimkan balik setelah selesai), atau masuk ke jaringan internal via VPN (yang ini jarang).

Sejauh ini saya tidak pernah berhadapan langsung dengan client, kecuali membalas beberapa hal teknis via email. Jadi lesson learned di sini tidak akan mencakup interaksi dengan client. Saya juga tidak membuat laporan resmi atau melakukan presentasi untuk client, ini dilakukan orang lain, jadi itu juga tidak masuk ke scope.

Saya memulai pekerjaan pentest dengan dasar ilmu yang mungkin berbeda dengan orang lain:

  • Dulu saya pernah bandel waktu di semester pertama kuliah, belasan tahun yang lalu. Saya dan temen saya pernah melakukan beberapa keisengan digital di kampus, seperti mengeksploitasi sistem, memasang keylogger, dsb
  • Setelah hampir DO gara-gara kasus tersebut (bukan gara-gara nilai kuliah), saya menjadi administrator sistem, jadi setelah itu punya dasar sistem operasi dan juga jaringan yang baik untuk OS Linux dan Windows. Sejak saat itu saya hanya hacking for fun, misalnya crack software untuk dipakai sendiri atau mengakali website yang saya pakai
  • Saya punya hobi reverse engineering, tapi tidak benar-benar saya dalami. Contohnya tahun 2006 saya pernah menulis reverse engineering virus Brontok.¬†Saya¬†kerja dengan C++ dan sering kali dalam debugging perlu sampai ke level assembly, jadi masih dengan berbagai hal low level.
  • Saya punya hobi programming dan sudah membuat berbagai macam aplikasi dari mulai web app, mobile app, dan bahkan porting kernel FreeBSD

Ketika mulai pentesting:

  • Saya tidak punya sertifikasi apa-apa
  • Saya cuma kenal sedikit orang security
  • Saya tidak kenal banyak tool yang populer, bahkan waktu itu belum pernah memakai zaproxy ataupun burp suite

Dari hasil ngobrol dengan beberapa orang, kebanyakan pentester mulai dari otodidak. Ada yang mulai dari iseng positif (CTF), ada juga yang masuk dunia security karena hal negatif (tertangkap hacking sesuatu). Beberapa orang berkembang dengan belajar lebih banyak, ada yang kuliah IT, ada yang mengambil sertifikasi, dsb. Sebagian lagi ilmunya tidak berkembang

Kelebihan saya menurut saya adalah: kemampuan membaca kode (baik biner maupun tekstual) dan pengetahuan kriptografi yang cukup baik sehingga bisa menemukan bug kriptografi sejenis hashing bug Mastercard. Bug sejenis ini sudah saya temukan di beberapa payment gateway di Indonesia (sayangnya karena NDA, tidak bisa diceritakan, jadi untuk bug semacam ini saya hanya bilang: bug sejenis Mastercard, tanpa menyebut detail varian masalahnya).

Bug seperti Bug Gojek bisa dengan mudah ditemukan banyak pentester, tapi jika saya membuat aplikasi dengan bug sejenis bug MasterCard atau E-Money Mandiri, saya cukup yakin hanya sedikit pentester yang mampu menemukannya.

Kenapa pentesting?

Kenapa tidak melakukan software development saja? kenapa tertarik pentesting?

  1. Saya memang suka ngoprek apa aja, jadi bagus untuk penyaluran hobi
  2. Memaksa saya belajar banyak teknologi baru. Misalnya ketika ada Angular XSS injection, mau tidak mau saya perlu mengenal angular untuk belajar eksploitasi itu
  3. Pekerjaan pentest sifatnya singkat. Software development biasanya lama. Setelah selesai pun perlu disupport
  4. Seru dan bangga jika bisa menemukan bug fatal. Ini terutama jika dilakukan pada sistem yang sudah live bertahun-tahun, dan baru ditemukan bugnya sekarang.

Apakah selalu menyenangkan?

Tidak ada hal yang semuanya fun, meskipun sebagian besar pekerjaan pentesting sifatnya fun tapi banyak juga yang membosankan. Contohnya jika kita perlu memeriksa sistem informasi yang punya form 10 halaman dan hanya jalan di tablet (jadi tidak bisa memakai skrip auto fill form, atau harus menulis sendiri skrip baru).

Terkadang developer juga membuat gemes karena tidak mengerti bug fatal yang sudah dijelaskan, sehingga kadang sampai perlu membuat video untuk menjelaskan bugnya. Lebih mengesalkan lagi jika mereka dikejar deadline, dan jadinya pentester ikutan dikejar deadline.

Di kasus lain, kadang aplikasinya belum selesai di tanggal yang dijadwalkan, jadi pentester malah jadi tester fungsionalitas aplikasi. Salah satu kasus terparah waktu diberi website dengan halaman HTML statik tanpa https, jadi hal yang bisa dicek sangat minim sekali.

Hal yang membuat sedih adalah Non Disclosure Agreement: kadang saya tidak bisa sharing bug-bug menarik ke orang lain jika itu menyangkut sistem mereka. Bug menarik di sini maksudnya bukan sekedar SQL Injection, XXE atau XSS. Jika bugnya di luar sistem mereka maka saya bisa sharing (contoh: bug alternatif firewall Palo Alto ini juga bisa dianggap bug di luar sistem mereka).

Lesson Learned

Ini adalah beberapa catatan random mengenai berbagai pelajaran yang saya petik

Belajarlah dari orang lain

Belajarlah dari orang lain karena ini cara yang baik untuk memulai. Pelajaran ini bisa didapat dari berbagai cerita orang ataupun dari berbagai tulisan/writeup di web. Setelah mendapatkan gambaran topiknya kita bisa mendalami topik dengan membaca berbagai macam buku atau mencoba berbagai tool.

Karena saya jarang melakukan testing internal (on site), saya juga masih terus belajar dengan melihat report dari orang lain yang mengerjakan testing internal. Tentunya jika kita belajar dari orang lain, kita sebaiknya juga mengajari orang lain, baik dengan memberikan ilmu via obrolan ataupun tulisan.

Saya belum pernah ketemu pentester atau hacker yang punya teknik luar biasa yang tidak diketahui siapapun. Semua ilmu mereka dipelajari dari berbagai writeup dan sharing yang dilakukan orang lain.

Satu orang biasanya tidak cukup

Banyak aplikasi bisa dipentest oleh satu orang, tapi untuk aplikasi super penting, misalnya yang melibatkan uang, sebaiknya pentest dilakukan oleh lebih dari satu orang.

Satu orang pentester bisa membuat kesalahan, dan sumbernya bisa banyak:

  • Skill orang tersebut memang kurang
  • Orang tersebut memiliki skill, tapi pada saat testing mungkin sedang mengantuk, kurang konsentrasi, dsb
  • Jumlah target ada banyak atau fungsionalitas aplikasi terlalu banyak
  • Ada masalah jaringan yang diakses dari jaringan orang tersebut sehingga tool yang dipakai tidak bekerja benar (contoh: bisa saja ISP tertentu menyisipkan iklan jadi eksploitasi gagal), tapi pentester dari jaringan lain ternyata berhasil mengeksploitasi
  • Masalah juga bisa ada di komputer pentester atau tool yang dipakai pentester. Contoh nyata yang pernah saya alami adalah: semua tool berbasis Java (burp suite dan zaproxy) selalu gagal melakukan koneksi ke server tertentu, tapi pentester lain yang memakai Fiddler ternyata bisa melakukan koneksi dengan normal.

Beberapa perusahaan menyewa beberapa group pentester, baik secara bersamaan, ataupun bergantian supaya yakin hasilnya aman. Pekerjaan pentest biasanya dibatasi waktu yang singkat, jadi jumlah bug yang ditemukan terbatas. Harapannya bug-bug besar ditemukan oleh pentester, tapi bukan jaminan bahwa nanti ada hacker atau bug hunter yang berusaha berminggu-minggu bisa tembus ke sebuah aplikasi.

Dari mengerjakan berbagai pekerjaan bareng orang lain, saya jadi belajar memperhatikan bug-bug tertentu yang kadang terlewat oleh saya dan juga tahu tools-tools yang populer dipakai.

Belajar terus informasi terbaru

Di awal kita bisa bertanya secara langsung pada seseorang untuk belajar berbagai hal dasar, tapi setelah itu saatnya kita perlu belajar sendiri “langsung dari sumbernya”. Biasanya sumber awal berbagai teknik baru adalah dari presentasi di security conference. Berbagai security conference akan mengupload file dan video presentasinya sehingga bisa kita baca, jadi tidak perlu ikutan untuk mendapatkan ilmunya.

Berbagai varian dari teknik yang sudah ada juga bisa dibaca dari writeup orang-orang yang melakukan bug bounty. Terkadang isinya membosankan, bug yang sudah sangat sering ditemukan (misalnya XSS), tapi sesekali ada teknik eksploitasi yang menarik yang bisa diambil ilmunya.

Sumber saya mendapatkan berbagai info security terbaru adalah dari reddit /r/netsec dan /r/reversengineering. Biasanya ini sudah cukup untuk merangkum berbagai informasi terbaru. Untuk info tambahan, saya subcribe ke security updates Debian (ada berbagai bug, kadang yang kurang signifikan saya ketahui dari adanya security update package tertentu)

Belajar mencari dan mendalami tool

Seperti saya ceritakan di awal: saya dulu kurang tahu banyak tool. Di awal saya banyak mengimplementasikan tool custom saya sendiri. Setelah memperhatikan pentester lain, jadi tahu berbagai tool yang sudah siap pakai dan lebih matang dari tool buatan saya.

Untuk satu tujuan, biasanya ada banyak sekali pilihan tool. Biasanya saya akan mencoba beberapa tool sejenis lalu memutuskan yang mana yang akan saya pakai, dan kadang saya pakai beberapa sekaligus. Contoh: untuk vulnerability scanner (yang sekedar mencari bug-bug sederhana) saya memakai Nexpose, OpenVAS, dan Arachni.

Sekedar catatan: Jika ada pentester yang hanya menyerahkan hasil scanner, tanpa melakukan testing manual, bisa dipastikan pentester tersebut tidak bekerja. Dalam kasus ini kemungkinan besar ada bug tidak ditemukan, dan Anda akan pusing membaca hasil scan yang masih butuh validasi lagi.

Untuk intercepting proxy, saya akhirnya memilih zaproxy dengan pertimbangan:

  • Gratis (burp professional tidak gratis, sementara versi free tidak bisa menyimpan session)
  • Open source. Fiddler dan burp suite (versi free) gratis tapi tidak open source
  • Cross platform (Fiddler tidak cross platform, belum lama ini baru ada versi beta untuk non Windows)

Setelah saya putuskan, saya kemudian berusaha mendalami jika tool tersebut cukup kompleks. Contohnya dalam kasus zaproxy di atas, setelah paham pemakaiannya, saya mencari tips dan trik di Internet dan ketemu bahwa kita bisa memakai berbagai list dari SecLists untuk input zaproxy dan kita bisa menambah berbagai skrip dan list kita sendiri.

Contoh skrip yang bisa kita buat misalnya:

  • skrip payload generator custom (mencoba-coba berbagai payload yang paling sering berhasil)
  • skrip untuk meng-exclude berbagai situs tidak penting (seperti facebook/google/dsb) dari log

Log IP saat ini

Saya melakukan testing dari rumah dengan IP dinamik, artinya IP eksternal bisa berubah setiap waktu. Kadang pihak yang ditest ingin mengecek apakah benar sebuah request berasal dari penyerang sesungguhnya atau dari kerjaan pentesting.

Dulu saya tidak mencatat ini, tapi untungnya saya masih bisa mengecek beberapa IP terakhir melalui log activity di Gmail. Sekarang supaya aman, saya membuat skrip yang mencatat setiap ada perubahan alamat IP.

Log semua sesi pentesting

Alasan saya tidak memakai burp versi gratis adalah karena tidak bisa menyimpan session. Kadang ada client yang menanyakan laporan beberapa bulan yang lalu, padahal website yang ditest sudah berubah. Dengan menyimpan semua sesi pentesting, bisa dilihat semua request yang pernah diberikan, dan juga bisa dijelaskan jika memang ada bagian website yang sudah berubah.

Lakukan otomasi

Banyak pekerjaan pentest sifatnya membosankan dan bisa diotomasi. Otomasi ini bisa dilakukan dengan menginstall berbagai software atau browser extension untuk tujuan khusus atau dengan membuat skrip sendiri. Contoh sederhana: beberapa aplikasi bank memiliki form yang terdiri atas beberapa halaman (misalnya form aplikasi kartu kredit). Dengan browser extension untuk mengisi form secara otomatis (atau menyimpan isian saat ini), maka kita bisa menghemat waktu ketika testing hal semacam itu.

Saya sendiri sekarang ini punya berbagai kategori skrip:

  • berbagai skrip python custom untuk target tertentu
  • berbagai skrip zaproxy
  • browser extension custom
  • skrip Frida untuk pentest Android dan iOS

Ilmu programming sangat terpakai

Secara umum ilmu programming sangat terpakai dalam pentesting. Selain untuk otomasi seperti yang disebutkan sebelumnya, juga terpakai untuk hal-hal berikut:

  • Source code review: keahlian membaca dan memahami program sangat diperlukan
  • API test. Beberapa perusahaan pernah meminta testing apakah API mereka bisa bocor (sejenis bug yang saya temui di kasus Mastercard), jadi mau tidak mau harus membuat program
  • memperbaiki eksploit (contoh: pernah saya temui eksploit Java yang hanya berjalan di Java versi baru karena memakai kelas yang hanya ada di Java terbaru, sedangkan client masih memakai Java versi sebelumnya)
  • Untuk modifikasi kode. Dalam pentest mobile app, kadang kode perlu dipatch untuk memudahkan testing

Dengan dasar programming yang baik, jumlah bug yang ditemukan dan dieksploitasi bisa lebih banyak.

Kreativitas CTF kadang diperlukan

Mungkin sekitar 90% eksploit dari Internet bisa langsung dijalankan, dan biasanya orang-orang akan menyerah jika eksploitnya tidak jalan hanya karena perbedaan versi software. Biasanya hal seperti ini justru jadi tantangan buat saya.

Hal-hal seperti ini bisa dipelajari dengan mengikuti CTF. Banyak soal CTF luar negeri adalah varian dari bug yang nyata. Dalam kasus ini kita perlu paham eksploitnya dan menerapkannya sesuai dengan situasi

Skill administrasi sistem sangat terpakai

Tidak selamanya kita bisa langsung testing ke target yang live. Kadang pentest dibatasi waktunya, kadang koneksi terlalu lambat dari Thailand ke Indonesia. Di saat seperti itu kadang saya perlu menginstall secara lokal berbagai software supaya bisa ditest eksplotasi secara lokal.

Selain contoh kasus di atas, kadang saya menemui mesin dengan sistem operasi yang sangat tua. Saya biasanya menginstall dulu versi yang sama di sistem lokal untuk mengetes eksploit supaya yakin apakah tidak akan membuat sistem crash.

Pengalaman dan ilmu administrasi sistem yang saya miliki ternyata sangat berguna untuk setup semacam ini. Saran saya jika Anda ingin jadi pentester, minimal bisa mensetup sistem operasi dan berbagai software secara lokal untuk ditest sendiri.

Penutup

Salah satu alasan saya dulu meninggalkan dunia security adalah: saya pikir software akan menjadi semakin aman. Ketika saya belajar mengenai SQL injection belasan tahun lalu, saya punya pikiran seperti ini: bug ini mudah sekali dihindari, dalam beberapa tahun ke depan pasti bug seperti ini sudah nggak akan ditemui lagi.

Bug sql injection ini baru saya temukan Januari 2019, di sebuah subdomain situs sebuah bank yang bisa diakses dari publik

Setelah melakukan pentesting beberapa tahun, ternyata saya salah besar, sampai saat ini bug SQL injection masih cukup sering saya temui. Bug buffer overflow dan sejenisnya juga masih ditemui. Sekarang ini banyak jenis bug baru yang sepertinya akan tetap ada sampai belasan tahun ke depan.

Jadi sepertinya sampai cukup jauh ke depan, pentester masih sangat dibutuhkan. Berbagai tools akan membuat beberapa pekerjaan pentesting jadi sederhana, tapi masih banyak yang lain yang tetap harus manual. Tentunya ilmu pentesting ini harus diupdate terus supaya mengikuti perkembangan teknologi. Tiap teknologi bisa membawa banyak masalah baru misalnya yang trend sekarang:

  • Cloud: sering ada misconfiguration
  • IOT: banyak masalah dasar seperti 20 tahun yang lalu (buffer overflow dsb) dan juga ada berbagai serangan menarik seperti glitch attack para microcontroller
  • BlockChain: masalah pada implementasi, pada enkripsi, pada smart contract
  • machine learning (adversarial machine learning)

Dilihat dari contoh di atas, di masa depan ilmu programming dan devops makin diperlukan untuk memahami masalah security yang lebih kompleks.

Tinggalkan Balasan

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