Cheat dan Anti-Cheat pada Video Game

Salah satu tujuan banyak orang melakukan Reverse Engineering adalah mencurangi (cheating) game. Sudah banyak orang menanyakan ini ke saya, jadi akan saya bahas sekarang ini.

Cheat by Nick Youngson CC BY-SA 3.0 Alpha Stock Images
Cheat by Nick Youngson CC BY-SA 3.0 Alpha Stock Images

Tapi supaya tidak kecewa, saya tekankan dulu: cheating game modern dan populer saat ini (misalnya pubg) sangat sulit. Teknologi anti cheat selalu diupdate, dan tidak ada satu artikel di internet yang bisa membuat Anda bisa mencurangi game terbaru.

Sebagai catatan: banyak video sampah di Youtube yang mengajari cara cheat game padahal yang dijelaskan di situ tidak masuk akal sama sekali.

Cheating Game Jaman Dulu vs Sekarang

Mungkin Anda membaca beberapa artikel lama tentang cheating game dan berpikir cheating itu mudah. Sebelum membahas berbagai teknik cheat dan anti-cheat, saya tuliskan dulu tentang cheating jaman dulu dan sekarang.

Jaman dulu, terutama masa sebelum internet, cheating game relatif mudah. Berbagai perkembangan teknologi (termasuk juga kecepatan CPU, ketersediaan multi core) membuat cheating game makin sulit dilakukan.

Versi Game

Pertama adalah masalah update. Dulu Versi game tidak berubah sejak dirilis karena distribusinya sulit menggunakan CD-ROM/DVD, jadi jika ada game versi 1.0, kemungkinan tidak akan berubah sampe bertahun-tahun kemudian. Di masa awal internet, game juga masih didistribusikan via CD/DVD walau sudah bisa dimainkan online.

Dulu jika ada yang menemukan atau membuat cheat tertentu, maka pembuat game tidak bisa mengupdate kodenya. Sekarang: dalam hitungan hari sudah ada update di play store/app store/steam/dsb. Tentunya masih banyak game sederhana/tidak populer yang dibiarkan saja oleh pembuatnya..

Tulisan/Artikel tentang cheating

Dulu banyak orang dengan sukarela menuliskan ilmu tentang cheat yang dikembangkan, ini tidak apa-apa karena meskipun pembuat game membaca artikelnya, tidak ada yang bisa dilakukan sampai versi berikutnya beberapa tahun lagi atau beberapa bulan lagi.

Sekarang ini jika seseorang menemukan cheat game, mereka akan menyembunyikan atau tidak men-share tekniknya. Kalau dishare, maka pembuat game akan membaca artilel tersebut dan segera mengubah kodenya.

Resource Anti Cheat

Dulu teknik anti cheat dilakukan oleh pembuat game yang teamnya kecil. Mereka ini sering kali adalah programmer game yang bagus, tapi kurang mengerti teknologi cheating. Sekarang ini untuk game besar, sering ada team khusus yang melakukan development anti cheat.

Pekerjaan membuat anti cheat di berbagai perusahaan game yang besar gajinya mencapai puluhan/ratusan ribu USD/tahun (atau dalam rupiah 1-5 milyar/tahun). Game-game ini menghasilkan jutaan USD per bulan. Jadi mereka yang sudah dibayar mahal ini tidak tinggal diam melihat para cheater yang berpotensi mengurangi pendapatan mereka.

Sebagai pembanding: para pembuat cheat kebanyakan sukarela, karena ingin sekedar menang dalam game. Jika levelnya sudah terlalu sulit, mereka akan menyerah. Tapi ada juga group-group yang menjual cheat, motivasi mereka lebih besar dan tentunya mereka tidak mau sharing ilmu karena akan mengurangi pendapatan mereka.

Selain menyewa orang secara khusus, ada juga beberapa perusahaan yang mengembangkan teknologi anti cheat untuk dipakai oleh berbagai game lain. Contohnya adalah BattleEye. Mereka bahkan punya lowongan spesifik: membuat teknologi anti cheat.

Sebenarnya bukan cuma game yang butuh anti cheat. Contoh aplikasi non game yang sering dicurangi orang adalah Snapchat. Biasanya fitur yang diinginkan adalah bisa menyimpan/screencapture foto tanpa ketahuan. Snapchat bahkan sampai mengakuisisi sebuah perusahaan untuk meningkatkan keamanannya.

Kompleksitas Anti-Cheat

Ketika resource CPU masih sangat rendah, game harus sangat dioptimasi, jadi biasanya anti cheat hanya dijalankan sekali saja ketika game dimulai atau ketika pergantian level.

Sekarang ini dengan CPU multi core yang bahkan sudah ada di HP Android low end, bisa ada thread khusus yang melakukan pengecekan berkala. Jika satu pengecekan berhasil dibypass di awal, masih ada pengecekan lain yang dijalankan secara periodik.

Contoh aneka jenis teknik cheating

Jenis cheating untuk berbagai game beraneka ragam, tergantung jenis gamenya. Kadang-kadang cara cheating di satu game tidak berlaku sama sekali di game lain.

Untuk game jenis fighting, misalnya bisa dibuat aimbot yang otomatis mengarahkan (aim) senjata ke target, atau untuk melihat pemain lain meski terhalang dinding. Untuk game jenis puzzle bisa dibuat solver otomatis yang memberi tahu solusi gamenya.

Jadi tidak ada satu jenis cheat, dan teknik anti cheat untuk berbagai jenis cheat juga berbeda-beda. Di sini saya akan bahas contoh saja beberapa jenis cheating yang umum.

Memory/File Editing

Jaman dulu cheating game single player hanya sekedar mengubah jumlah koin di memori atau di file (untuk game yang ada savefile-nya), atau mengaktifkan sesuatu fitur yang seharusnya tidak aktif. Ini sangat mudah dilakukan dengan berbagai tool yang melakukan scanning memori, mencari value, lalu mengganti value tersebut.

Sekarang ini sebagian besar nilai sudah disimpan di server. Jadi meskipun kita mengganti nilai koin di game lokal, ketika gamenya dimulai (atau ketika akan membeli item) game akan meload lagi nilainya dari server via internet dan akan diverifikasi pembeliannya di internet.

Sebagian nilai kadang masih bisa disimpan lokal, misalnya beberapa game ada fitur agar profile kita memakai kostum tokoh tertentu dan pengecekan fitur ini dilakukan lokal/offline.

Logika cheat ini sangat sederhana: misalnya di layar tertampil koin kita 120500, kita search nilai 120500 di memori. Kemungkinan ada beberapa memori yang memiliki nilai itu, berikutnya: kita belanjakan uangnya, misalnya jadi 110000. Lalu kita search lagi nilai 110000 itu, hasilnya: akan ada daftar memori yang berkurang nilainya. Kalau masih ada kandidat lain, kita coba belanjakan koin lagi atau beli koin lagi, sampai ketemu: di memori ini tersimpan nilai koinnya.

Cheating jenis ini levelnya sangat mudah, berlaku untuk banyak game sederhana yang kurang populer. Tool yang dibutuhkan juga banyak tersedia di internet (misalnya Game Guardian untuk Android). Untuk mengedit savefile kadang hanya butuh hex editor saja. Biasanya tidak dibutuhkan coding untuk cheat jenis ini.

Function Hooking/Library Patching

Cheat level berikutnya butuh coding. Fungsi-fungsi tertentu bisa diganti implementasinya dengan milik kita sendiri. Contoh sederhana: jika ada fungsi bernama “isVisible()” yang gunanya untuk mengecek apakah sebuah objek terlihat atau tidak bisa diganti dengan fungsi yang selalu mengembalikan “true”.

Ada banyak library untuk function hooking, tergantung platform/sistem operasi yang dipakai. Contoh: di iOS ada fishhook (untuk hooking fungsi library), substrate (hooking fungsi sembarang). Di Android bisa memakai library Frida (butuh root). Di Windows ada banyak teknik hooking yang bisa dicari sendiri.

Contoh hooking yang lain adalah melakukan intercept terhadap paket jaringan. Sebelum data dikirim ke server, data bisa diubah (misalnya yang tadinya “miss” jadi “hit”). Sebaliknya: data dari server yang tidak ditampilkan oleh game, bisa ditampilkan ke user.

Di level ini cheating sudah butuh coding. Coding biasanya perlu dilakukan di level native code (biasanya C) tapi kadang sampai harus level assembly. Ini semua tergantung proteksi gamenya dan dalam bahasa apa game itu ditulis..

Banyak tutorial cheat di Youtube yang cuma sampah. Mereka memperlihatkan mengedit file .so dengan hex editor saja. Seringkali nilai yang diberikan ngawur, dan jelas tidak akan jalan di versi lain file .so tersebut. File .so isinya adalah kode mesin, untuk memahaminya diperlukan disassembler/decompiler.

Bentuknya apa function hooking ini? bisa berupa aplikasi baru yang melakukan injeksi ke aplikasi asli atau bisa berupa library (dll di Windows, .so di Linux/Android .dylib di OSX/iOS). Library ini bisa berupa library baru, atau hasil patch dari library lama.

Bot

Bentuk cheat lain yang umum adalah bot. Artinya: bukan manusia yang main gamenya, tapi program lain. Jenis bot ini bisa banyak: ada yang full bisa memainkan game dari awal, atau ada yang dipakai untuk melakukan aksi tertentu saja (mengumpulkan koin, dsb).

Bot ada yang bisa dijalankan di device, ada yang bisa dijalankan di PC. Bot ada yang butuh aplikasi gamenya, dan ada juga bahkan yang hanya berupa skrip yang langsung melakukan request ke server.

In App Purchase (IAP) Hack

Untuk game di mana pemain bisa membeli koin dengan in app purchase, maka ini bisa dicurangi untuk game yang tidak mengecek di sisi server. Semua game besar/populer punya server untuk mengecek receipt dari app store dan biasanya tidak bisa dicurangi.

Flow pembelian adalah: aplikasi meminta app store untuk meminta uang dari user. Setelah selesai, app store akan memberi tahu aplikasi bahwa pembelian selesai, dan ini tanda terima (receiptnya). Aplikasi kemudian bisa mengecek ke server app store untuk memeriksa apakah receiptnya valid. Nah masalahnya: jika aplikasi meminta langsung ke app store, fungsi ini bisa dihook dan hasilnya: “ok ini receiptnya valid”.

Anti Cheating

Setelah memberi contoh teknik cheating, saya akan menjelaskan “anti cheating” yang umum dilakukan. Saya akan mengambil contoh dari teknik cheating di atas.

Anti Memory/File Editing

Supaya savefile tidak dimodifikasi, filenya bisa dihash dengan digital signature. Jika signature tidak valid, maka game tidak mau meload savefile-nya. Jadi jika file diedit dengan hex editor, hasilnya: game tidak mau meload filenya karena signaturenya tidak valid lagi.

Bagaimana dengan nilai di memori? misalnya kita ingin menyimpan nilai score, bisa saja scorenya disamarkan, misalnya dengan minus N. Jadi jika nilai koin saat ini 100000, dengan N = 12000, maka tersimpan di memori: 88000. Ketika akan ditampilkan di layar, nilai N-nya ditambah dulu dengan 12000. Teknik anti cheating ini terlalu sederhana, dan beberapa engine cheating bisa mendeteksi seperti ini. Tentunya kita bisa juga menggunakan enkripsi yang lebih rumit seperti AES.

Sebagai programmer, tentunya banyak kreativitas yang bisa dilakukan untuk menyembunyikan nilai koin ini. Misalnya bisa saja nilainya disimpan di 10 tempat, masing-masing ditambah/dikurangi dengan nilai berbeda. Tiap kali gamenya dijalankan bisa juga dibuat nilai random untuk mengecoh fitur “value finder” dari sebuah cheat engine.

Cara paling efektif adalah: nilai koin disimpan di server, dan segala pembelian item diproses oleh server, sehingga cheat jenis ini tidak bisa dilakukan.

Anti Function Hooking/Library Patching

Jika sudah belajar teknik malware tingkat lanjut, kita akan tahu bahwa mengganti fungsi akan meninggalkan jejak. Cara termudah mengecek ini adalah: dengan melakukan checksum binary di memori, lalu nilainya dikirimkan ke server. Server bisa mengecek apakah nilai sesuai seharusnya.

Cara lain adalah dengan mengecek header tiap fungsi, apakah ada tanda-tanda bahwa fungsi tersebut sudah di-hook/intercept. Ketika melakukan patching kode, berbagai library akan mengubah header fungsi dengan instruksi assembly untuk “jump”. Jika ini terdeteksi, maka berarti fungsi sudah diubah.

Anti Bot

Ketika diluncurkan, banyak sekali orang yang membuat bot Pokemon Go. Versi pertama aplikasi ini proteksinya kurang bagus, jadi seseorang bisa mempelajari dengan mudah. Versi-versi berikutnya menjadi sangat sulit dan sekarang tidak ada lagi library yang bisa dipakai untuk melakukan koneksi ke server Pokemon Go.

Teknik anti bot yang mereka pakai adalah gabungan dari banyak hal. Mereka membuat koneksi yang dihash secara custom, versi pertama masih bisa dibongkar. Berikutnya mereka membuat versi berikutnya yang terenkripsi. Selain itu mereka mendeteksi berbagai macam perilaku (behavior) bot yang tidak masuk akal atau tidak konsisten. Ini digabung dengan berbagai cara untuk mendeteksi function hooking/library patching.

Anti IAP Hack

Jika sebuah aplikasi/game cukup sukses, developer bisa memiliki server yang bisa mengecek receipt In App Purchase dengan melakukan koneksi ke server. Jadi ketika seseorang membeli koin:

  • Transaksi dilakukan di device
  • Aplikasi mengirimkan receipt ke server pembuat aplikasi
  • Server pembuat aplikasi akan melakukan validasi ke server apple/google (koneksi langsung tidak bisa diintercept)
  • Status koin/fitur di server pembuat aplikasi akan diupdate jika valid
  • Aplikasi mendapatkan informasi dari server
  • Ketika akan menggunakan koin untuk membeli item, server memakai informasi yang ada di server, jadi tidak bisa diubah oleh aplikasi

Kadang masih ada kebocoran, terutama jika ada metode lain seseorang bisa mendapatkan koin misalnya jika pengguna aplikasi bisa mendapatkan koin/reward dari menonton iklan.

Anti-anti Cheating

Apakah para cheater segera menyerah dengan adanya berbagai teknologi anti cheat? Tentunya tidak. Tapi di level ini sudah dibutuhkan pemahaman kode yang dalam.

Anti-anti memory patching/editing

Jika sebuah nilai hanya disamarkan di memori, maka dengan melakukan reverse engineering (membaca disassembly dan hasil dekompilasi) bisa ditemukan nilai apa yang dikurangi/ditambah. Jika sudah tahu perubahannya, maka teknik pertama kembali bisa dilakukan, cukup dengan menambah/mengurangi/melakukan decrypt terhadap nilai di memori.

Jika aplikasi mendapatkan nilai dari server, mungkin nilainya bisa diintercept dengan function hooking agar bisa diubah sebelum sampai ke aplikasi.

Jika memang aplikasi butuh nilai di memori dan terlalu lambat untuk meminta nilainya dari server, apakah pembuat aplikasi akan menyerah di level ini? pembuat aplikasi bisa mengubah metodenya tiap rilis baru gamenya. Cheat yang berjalan di versi 1.0, tidak akan jalan lagi di versi minggu depan.

Anti-anti function patching

Dalam kasus anti function patching: ada kode yang memeriksa apakah fungsi ini diubah atau tidak. Kode pemeriksa ini bisa dipatch agar hasilnya selalu mengembalikan OK. Tentunya mencari kode pemeriksa ini juga tidak mudah, butuh reverse engineering lagi.

Lalu apa respond pembuat game? sekarang sebagian game memiliki kode (X) yang akan mengecek apakah ada patching. Lalu ada kode (Y) yang memeriksa apakah fungsi pengecek (X) tersebut tidak dipatch. Contoh lain: ada game yang memiliki dua fungsi yang saling mengecek satu sama lain.

Apakah para pembuat cheat menyerah? tidak juga, banyak teknik yang bisa dipakai misalnya emulasi kode menggunakan emulator tertentu (misalnya Unicorn Engine atau Qemu), merelokasi kode (misalnya dengan Gum Relocator bagian dari Frida) dan mempatch kode aslinya.

Anti-Anti IAP

Khusus untuk In App Purchase, di sini cheater memiliki keterbatasan. Untuk pengecekan di sisi server, tidak ada lagi yang bisa dilakukan, kecuali ada yang nekat menghack servernya.

Untuk game yang punya fitur voucher/kode: sering kali hacker membeli voucher dengan kartu kredit curian, lalu menjual vouchernya. Di dalam kasus lain, kadang server penjual voucher yang dihack untuk mendapatkan kode voucher gratis.

Anti Reverse Engineering

Berbagai teknik anti cheat bisa dipelajari jika kita bisa membaca kodenya. Untuk mempersulit, kebanyakan game memakai teknik Anti-RE. Biasanya yang paling dasar adalah obfuscation.

Obfuscation adalah teknik untuk membuat kode lebih sulit dibaca oleh manusia, dan tetap bisa dieksekusi langsung oleh mesin. Jangan kaget misalnya ketika melakukan reverse engineering berbagai aplikasi, bahkan IDA Pro bisa diakali agar tidak mengenali function boundary (mana awal/akhir fungsi). Decompiler juga bisa menghasilkan kode yang membuat kita pusing.

Untuk native code, standar yang dipakai saat ini adalah LLVM Obfuscator. Versi lama bisa ditangani dengan plugin khusus IDA Pro. Tapi banyak perusahaan memiliki varian khusus dari obfuscator ini sehingga tools deobfuscator sederhana tidak bisa digunakan.

Selain itu teknik RE yang lain adalah anti debugging. Dengan ini kode program tidak bisa dengan mudah dijalankan dalam debugger.

Anti-anti-anti …

Untuk setiap teknik cheat yang diciptakan, akan ada teknik anti-cheat. Dan untuk tiap teknik anti-cheat, akan ada teknik anti-anti-cheat, sampai batas tertentu.

Pembuat game bisa membuat anti cheat yang sangat hebat dan rumit, tapi jika terlalu rumit dan membuat gamenya terlalu lambat dimainkan atau butuh spec terlalu tinggi, atau membuat HP menjadi sangat panas, maka pemain akan berhenti bermain. Jadi pembuat game punya batasan pemeriksaan yang bisa dilakukan.

Tiap platform punya batasan masing-masing sehingga tidak semua teknik anti cheat bisa dipakai. Misalnya aplikasi iOS yang masuk ke app store tidak mungkin memiliki self modifying code seperti di Android

Sementara biasanya batasan pembuat cheat adalah kesabaran. Jika pembuat game mengubah anti cheatnya tiap bulan, lama-lama mereka akan lelah. Ingat: pembuat anti cheat dibayar mahal, sedangkan pembuat cheat biasanya pendapatannya tidak seberapa.

Tiap level baru membutuhkan skill baru. Untuk bisa melakukan hacking game modern, minimal perlu pengetahuan reverse engineering yang dalam, plus pengetahuan spesifik untuk platform tertentu (Android/iOS/yang lain).

Selain itu ada banyak teknologi spesifik yang perlu dipelajari, tergantung gamenya. Ada game yang dibuat menggunakan Unity, dan untuk patching gamenya kita perlu mengenai engine Unity. Game dengan Unity gampang diedit jika masih menggunakan mode .NET murni, tapi jadi sulit jika ditranslasikan ke C (dengan il2cpp) dan dilewatkan ke obfuscator. Ada game yang memakai game engine Corona yang memakai Lua jadi perlu mengenal bahasa pemrograman Lua.

Sampai di titik tertentu, ketika sudah paham berbagai hal low level, banyak hacker game yang akhirnya memilih jalan lain. Menjadi programmer atau melakukan pekerjaan security yang pendapatannya lebih besar. Di jangka panjang, menjadi pembuat cheat juga cukup membuat stress karena tiap versi bisa ada proteksi baru yang perlu dipelajari.

Resource

Saya bisa menyarankan resource-resource ini untuk mulai mengenal dunia hacking game:

Atau cari informasi spesifik mengenai teknik yang ingin Anda ketahui. Contohnya teknik anti reversing di Android ada di resource ini. Sebagai catatan: ini baru resource untuk memulai, ketika mulai berusaha cheating, akan ada banyak hal lain yang perlu dipelajari: tentang berbagai format data, tentang enkripsi, dan masih banyak lagi.

Jika ingin yang bentuknya video, sudah ada yang membuat serial belajar game hacking (ketik artikel ini ditulis, levelnya masih sampai level dasar, tidak akan bisa mencurangi game modern dengan yang diajarkan di level ini):

https://guidedhacking.com/threads/squally-cs420-game-hacking-course.14191/

Penutup

Saran saya buat yang ingin hacking game: cobalah dari game yang sederhana. Lebih bagus lagi kalau Anda mencoba membuat game sendiri supaya lebih paham mengenai struktur sebuah game.

Buat Anda yang ingin terjun sampai game yang sulit: silakan saja, tapi jika modalnya hanya ingin mengedit file dengan hex editor saja, Anda tidak akan sampai ke mana-mana. Keahlian Reverse Engineering wajib dikuasai.

Dan jangan tanya saya bagaimana memakai tools IDA Pro, Ghidra, Radare. Berbagai tools tersebut banyak tutorialnya di Internet. Tapi intinya bukan pada toolnya, tapi kemampuan membaca kode. Mengajari memakai microsoft Word bisa dilakukan dengan cepat, tapi mengajari cara membuat Novel yang indah dengan Microsoft Word akan butuh waktu sangat lama. Word di sini hanyalah sekedar tool.

Sebenarnya saya juga tidak keberatan berdiskusi mengenai berbagai teknik cheat/anti-cheat. Tapi kalau level ilmunya masih terlalu jauh, maaf saya nggak sabar, karena harus banyak sekali menjelaskan segala sesuatu. Seringkali yang bertanya:

  • Tidak menyebutkan apa gamenya, untuk platform apa (iOS/Android/PC), padahal tekniknya berbeda untuk berbagai OS
  • tidak pernah memakai IDA pro atau tool sejenis
  • tidak pernah memakai debugger
  • tidak tahu berbagai teknik cheat, hanya ingin tahu bagaimana bypass anti cheat. Padahal setiap bagian anti cheat itu dibuat karena jenis cheat tertentu

Ini seperti anak kelas 2 Sekolah Dasar yang minta dijelaskan matematika untuk pemrograman game 3D, tapi (sesuai kurikulum kelas 2 Sekolah Dasar ):

  • belum bisa mengalikan bilangan besar
  • belum tahu perpangkatan
  • belum tahu notasi matriks
  • belum tahu berbagai konsep geometri (koordinat 3D), fungsi trigonometri (sin, cos, tan), dsb.

Nah jika ada anak SD bertanya seperti itu, apakah Anda mau menjelaskan? apakah bisa punya kesabaran menjelaskan setiap bagian sampai anak SD-nya mengerti? dan andaikan bisa, kira-kira akan butuh berapa lama? bersedia menjelaskan itu semua tanpa dibayar? Atau Anda akan menyuruh anak SD itu untuk belajar dulu dasar-dasarnya?

Jika pertanyaannya sangat spesifik, maka saya bisa memberikan petunjuk, seperti misalnya bagaimana mendeteksi method swizzling di Objective C? (banyak dipakai untuk mencurangi game/aplikasi iOS) dan bagaimana membypass deteksinya?

Jangan juga meminta saya membuat cheat untuk game tertentu. Saya sudah pernah menulis biaya reverse engineering itu mahal. Kalau ingin gratis ya silakan belajar sendiri.

Jawaban di Reddit yang saya temukan ini cukup mewakili jawaban saya terhadap yang ingin bertanya tentang cara reverse engineering anti cheat pada sebuah game. Intinya adalah: “get good”.

Certificate pinning dan unpinning

Certificate pinning adalah suatu cara agar sebuah aplikasi bisa memastikan bahwa koneksi SSL/TLS dilakukan terhadap server yang seharusnya. Topik yang sering ditanyakan ke saya adalah bagaimana membypass SSL pinning agar dapat melakukan pentest terhadap sebuah aplikasi. Di sini saya akan membahas beberapa teknik unpinning, terutama untuk mobile OS (iOS dan Android).

Sebelum masuk ke topik pinning, saya review dulu sedikit mengenai komunikasi sebuah browser/ aplikasi ke sebuah server. Agar lebih singkat: browser dan aplikasi akan saya sebut sebagai aplikasi saja, karena browser juga adalah sebuah aplikasi.

DNS

Ketika kita mengunjungi blog.compactbyte.com, aplikasi akan bertanya: apa alamat IP untuk blog.compactbyte.com? pertanyaan ini ditujukan ke server DNS (domain name system). Dan setelah tahu alamat IP-nya aplikasi bisa melakukan koneksi ke server tersebut.

Dari proses awal ini saja sudah ada dua kemungkinan masalah: pertama adalah server DNS mana yang kita pakai?

Lanjutkan membaca “Certificate pinning dan unpinning”

Membongkar Ransomware

Rasanya tiap beberapa hari ada yang bertanya tentang bagaimana mengatasi ransomware tertentu di berbagai group, terutama di group reverse engineering. Jawaban saya untuk yang terkena ransomware tetap sama: buat backup, restore dari backup, atau jika beruntung mungkin sudah ada yang membuat dekriptornya.

Artikel ini untuk anda yang ingin membongkar ransomware dan ingin membuat dekriptor sendiri. Perlu saya peringatkan bahwa ini tidak mudah, dan seringkali mustahil membuat dekriptornya. Setelah membaca ini semoga Anda paham bahwa: meminta membuat dekriptor khusus untuk ransomware yang kena ke komputer Anda itu seperti minta uang semilyar dari orang di pinggir jalan.

Jumlah ransomware baru tiap hari sangat banyak. Mudah sekali membuat ransomware dari nol, atau memodifikasi dari yang sudah ada (banyak yang bisa dicari di github, saya tidak akan melink langsung). Jadi kemungkinannuya cukup besar Anda terkena ransomware yang belum pernah didengar orang lain atau tidak dibahas di Internet.

Dalam tulisan ini saya akan menggunakan contoh soal dari Flare On 2019, sebuah ransomware bernama Mugatu. Karena Mugatu hanyalah soal CTF, ini sengaja dibuat agar hanya mengenkrip file yang sangat spesifik dan memiliki kelemahan dalam enkripsinya. Ini merupakan contoh yang cukup baik untuk dipelajari karena:

  • Malwarenya memakai teknik anti analisis (seperti malware yang sesungguhnya)
  • Malwarenya tidak berbahaya untuk dianalisis oleh pemula (tidak akan menginfeksi PC lain di jaringan)
  • Memiliki contoh enkripsi yang lemah

Silakan dibaca writeup mugatu dari pembuatanya:

https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/FlareOn6_Challenge10_Solution_Mugatu.pdf

Inti dari membuat dekriptor ransomware adalah:

  • melakukan reverse engineering malware
  • memahami enkripsi dan membuat dekriptor

Sebelum membahas jauh dan memberi harapan palsu. Saya ingin menekankan dulu: tidak semua ransomware bisa dibuat dekriptornya, dan andaikan bisa dibuat dekriptornya, reverse engineering butuh waktu lama.

Tidak semua ransomware bisa dibuat dekriptornya

Kenapa sebuah ransomware bisa tidak ada dekriptornya? apakah tidak ada ahli yang mampu membuat dekriptornya? Ini bukan masalah keahlian, tapi batasan teknis.

Kalau misalnya ketemu ponsel rusak seperti gambar di bawah ini, kemungkinan tidak akan bisa diperbaiki tukang reparasi. Kalaupun bisa, waktu yang dibutuhkan untuk memperbaiki sangat besar, dan nggak sebanding dengan harga ponselnya. Tentunya di kasus seperti ini Anda tidak akan bilang: wah tukang reparasinya nggak jagoan.

Sumber https://www.flickr.com/photos/glenbowman/3511874961

Contoh masalah teknis:

  • Ada ransomware yang entah salah coding atau sengaja merusak file dan tidak bisa dikembalikan lagi (menimpa isi file dengan random)
  • Ada ransomware yang cara enkripsinya tidak memiliki kelemahan. Silakan baca artikel saya mengenai unbreakable encryption.

Kalau Anda benar-benar malas membaca berbagai tulisan dan buku mengenai dasar enkripsi, minimal bacalah artikel saya mengenai unbreakable encryption. Tulisan tersebut sudah saya usahakan sangat sederhana dan harusnya bisa dimengerti oleh orang awam sekalipun, supaya tidak ngeyel bahwa “tiap enkripsi pasti bisa dibongkar”.

Intinya begini: meskipun sudah mendapatkan source code lengkap dan penjelasan lengkap tentang bagaimana ransomwarenya bekerja, tetap saja beberapa ransomware mustahil dibuat dekriptornya (kecuali kita tahu keynya).

Reverse Engineering butuh waktu lama

Jangan kira sebuah ransomware bisa dipahami dan dibuat dekriptornya dalam hitungan jam saja. Mungkin ada ransomware sederhana yang bisa dibongkar dalam hitungan jam, tapi kebanyakan akan butuh beberapa hari sampai beberapa minggu, dan butuh beberapa orang. Saya juga pernah menulis tentang mahalnya biaya reverse engineering.

Jika membongkar ransomware bisa sangat mudah dan selesai dalam 1-2 hari oleh orang yang kemampuannya baru belajar RE, maka perusahaan security dan antivirus akan rame-rame mempekerjaan banyak pemula, dan produknya akan jadi yang paling banyak dicari orang untuk mengembalikan data dari ransomware. Kenyataannya sekarang ini kebanyakan perusahaan antivirus dan security hanya bisa membuat dekriptor untuk beberapa ransomware saja, karena butuh waktu dan keahlian yang tinggi.

Prioritas perusahaan security biasanya adalah pada malware yang populer (menyebar luas), dan biasanya mereka tidak akan menghabiskan banyak waktu untuk ransomware yang kurang populer atau menyebar di wilayah tertentu saja. Jadi jika Anda beruntung, mungkin Anda bisa mendapatkan dekriptor gratis, tapi kemungkinannya makin sedikit dengan banyaknya jumlah ransomware.

Fakta bahwa reverse engineering butuh waktu lama sangat penting, karena kebanyakan orang sudah menyerah duluan setelah beberapa jam atau beberapa hari belum bisa maju. Aplikasi yang tidak memiliki proteksi khusus saja bisa butuh waktu lama, contohnya saya butuh waktu sekitar sebulan untuk mereverse engineer Pokemon Go Plus.

Nah sekarang jika memang sudah sangat berniat, maka langkah berikutnya adalah:

  • Belajar dasar reverse engineering malware
  • Belajar dasar enkripsi

Dasar Reverse Engineering Malware

Topik reverse engineering malware sendiri sangat luas. Sudah ada banyak buku yang membahas ini misalnya:

Saya juga sudah pernah membuat tulisan mengenai pengantar reverse engineering (tapi tidak spesifik malware).

Jangan berharap bisa mengerti dari sekedar membaca jawaban singkat dari bertanya di group chat atau dari menonton satu dua video saja. Reversing malware ini butuh kesabaran dan banyak latihan.

Saran saya ketika memulai: gunakan virtual machine yang tidak terhubung ke jaringan (networking dimatikan). Jangan merasa jagoan ketika baru pertama kali berurusan dengan ransomware, jika Anda membuat kesalahan, semua PC di jaringan bisa terinfeksi (contoh kasus: WannaCry).

Ibaratnya seperti belajar kalkulus, 99.99% orang akan butuh waktu dan latihan selama beberapa semester untuk bisa memahaminya (mungkin ada 0.01% orang super jenius yang bisa belajar kalkulus sendiri dalam beberapa jam atau beberapa hari). Coba bayangkan apakah Anda bisa diminta menjelaskan kalkulus via chatting? mengajari integral dan differensial dasar bisa dilakukan relatif cepat, tapi ketika sudah masuk topik rumit, segala macam trik dasar tidak bisa dipakai lagi.

Sebuah program biasa biasanya tidak terlalu sulit dibongkar/reverse engineer. Tapi sebuah ransomware biasanya tidak mudah dibongkar, ada trik-trik yang mempersulit analisis, atau membuat analisisnya jadi salah. Di contoh CTF Mugatu ada trik supaya IAT (import address table) jadi kacau jika langsung dibuka dengan disassembler/decompiler.

The first-stage malware shouldn’t seem too difficult when looking at it in a disassembler. However, something should start to feel amiss after you’ve looked at the API calls and how they are used. While some seem legitimate, others seem completely wrong.
The malware uses a trick I designed that involves running code before WinMainCRTStartup.


This function is responsible for the C-runtime initialization. Most disassemblers will skip this
function and start in WinMain, which corresponds to the main function for the code you programmed. . By skipping WinMainCRTStartup, you may miss my insidious trick.

Writeup Mugatu

Jadi kalau baru sekedar bisa membongkar aplikasi dengan Ghidra atau IDA Pro, ketika membongkar Mugatu akan langsung bingung karena API call-nya kok semuanya salah. Perlu dicatat bahwa ini hanya satu obfuscation sederhana, masih ada puluhan teknik lain misalnya:

  • String encryption
  • Anti debugging
  • Anti disassembly
  • Anti decompilation
  • Virtual Machine based protection
  • Heaven’s Gate (hanya untuk Windows 8 ke bawah), salah satu teknik yang cukup rumit

Dasar ilmu Enkripsi

Ransomware adalah malware yang mengenkripsi file korbannya. Jadi langkah logis berikutnya adalah: memahami enkripsinya.

Pertama yang saya sarankan adalah: cobalah membuat program yang mengenkrip dan mendekrip file. Lebih bagus lagi kalau membuat enkriptor dalam satu bahasa dan dekriptor dalam bahasa lain, supaya lebih paham berbagai variasi API enkripsi dalam berbagai bahasa.

Contohnya begini: jika kita ingin mengenkrip file, maka ada banyak cara:

  • Kita mengimplementasikan sendiri algoritma AES/RSA atau bahkan algoritma custom
  • Kita menggunakan library yang sudah ada, misalnya: CryptoPP (C++), openssl (C dengan binding ke banyak bahasa), Bouncycastle (Java, .NET)
  • Kita bisa menggunakan library built in dari sistem operasi (misalnya wincrypt di Windows)

Jadi pembuat ransomware bisa memilih salah satu dari cara di atas. Bagaimana misalnya kalau dia memilih Wincrypt, dan kita sudah bisa mendekompilasi kodenya. Apakah Anda akan bisa memahami proses enkripsi dan membuat dekriptornya? jika ransomwarenya memakai CryptoAPITransform, apakah Anda bisa membuat dekriptornya?

Cobalah membaca dan memahami berbagai jenis enkripsi. Jika kita bahkan tidak tahu enkripsi apa yang dipakai oleh ransomware, bagaimana kita bisa tahu apa kelemahannya?

Kelemahan Implementasi Enkripsi

Ini adalah topik yang paling sulit saya jelaskan, karena kebanyakan yang bertanya tidak paham mengenai dasar enkripsi. Saya sebenarnya sudah menulis sebagian topik dasar ini, misalnya beberapa artikel ini, tapi belum lengkap dan menyeluruh (topik enkripsi ini sangat luas):

Beberapa contoh kelemahan dalam implementasi enkripsi ini misalnya:

  • Keynya ada di ransomware itu sendiri/fixed key
  • Keynya berdasarkan MAC address komputer (atau nomor seri harddisk, atau sesuatu yang lain yang bisa dicari)
  • Keynya random, tapi ada kelemahan dalam cara menghasilkan bilangan randomnya (tidak menggunakan secure random)
  • Salah memanggil fungsi enkripsi (misalnya salah parameter)
  • Salah mengimplementasikan algoritma enkripsi
  • Memakai stream cipher dengan key yang sama untuk setiap file

Di soal Flare On Mugatu, ternyata kelemahannya adalah: hanya 4 byte key yang dipakai untuk enkripsi. Dan ini bisa dibruteforce dengan cepat menggunakan C.

Salah satu cara untuk mendapatkan gambaran berbagai kelemahan enkripsi adalah dengan mengikuti CTF kategori crypto, atau minimal membaca berbagai writeup di kategori crypto. Untuk saat ini saya sarankan dari CTF di luar negeri, karena kebanyakan CTF di Indonesia masih basic sekali soal kriptografinya.

Contoh beberapa malware yang memiliki kelemahan enkripsi: LockCrypt dan ACCDFISA. LockCrypt memakai enkripsi lemah dan random number generator (RNG) yang lemah, sedangkan ACCDFISA yang membuat password dengan RNG yang lemah. Untuk contoh lain ransomware yang tidak bisa dibongkar tapi pembuatnya menyerah dan memberikan keynya: Teslaware.

Pernah juga ada kasus di mana kelemahan malware bukan di malware itu sendiri tapi di server pembayaran tebusan/ransom. Servernya berhasil di hack, dan keynya bisa diambil dari server.

Penutup

Mungkin sebagian tulisan ini terasa mengecewakan, dan mungkin sebagian akan berpikir: wah susah ya, kalau begitu gak jadi deh, saya menyerah aja. Kalau memang memiliki niat, sebaiknya jangan menyerah.

Tidak semua pembuat ransomware jagoan, mungkin ada ransomware buatan lokal dan hanya menyebar lokal di kota tertentu (bahkan sangat lokal, misalnya cuma area kampus tertentu), dan ada kemungkinan enkripsinya tidak rumit atau memiliki kelemahan. Anda bisa mencoba-coba membuat dekriptornya, dan menyelamatkan minimal orang-orang di sekitar Anda.

Semoga tulisan ini cukup untuk menjawab Anda yang ingin belajar membongkar sendiri ransomware. Jika ada pertanyaan lebih lanjut bisa ditanyakan ke saya (lihat side bar mengenai cara menghubungi saya).

Aneka bug bypass OTP (One Time Password)

Berbagai website memiliki fitur two factor authentication (2FA) dalam bentuk OTP (One Time Password) alias password sekali pakai yang biasanya dikirim via SMS atau email. Sering kali ini tidak diimplementasikan dengan sempurna dan bisa dibypass. Tulisan ini tidak membahas metode baru, hanya sekedar koleksi beberapa OTP bypass yang sering saya temukan. Tujuan tulisan ini:

  • Untuk pentester supaya jadi checklist ketika mengecek OTP
  • Untuk programmer supaya jadi checklist ketika mengimplementasikan OTP

Tulisan ini juga untuk memberi pencerahan, supaya user sadar bahwa meskipun sebuah website memiliki OTP tidak berarti 100% aman. OTP biasanya diminta ketika login kali pertama, dan kadang hanya diminta ketika akan melakukan transaksi (contoh: ketika akan transfer uang). Kadang bypass OTP bisa dilakukan di login saja, transaksi saja, atau keduanya.

Sebagai catatan: OTP hanyalah salah satu bentuk dari 2FA, contoh lainnya adalah penggunaan hardware key. Implementasi OTP yang baik seharusnya tidak bisa dibypass. Jadi jika sebuah website tidak bisa dibypass OTP-nya dengan cara di sini, maka ada beberapa kemungkinan

  • Implementasi OTP website/aplikasi tersebut sudah aman dan memang tidak bisa dibypass
  • Anda kurang kreatif memikirkan bug lain yang mungkin spesifik terhadap aplikasi tersebut

OTP kosong

Kadang sebuah website membuat OTP jadi opsional, user bisa mengaktifkan OTP jika ingin lebih aman. Beberapa website mengecek ini dari ada atau tidaknya OTP yang dikirimkan dan dengan meremove field otp kadang OTP bisa dibypass.

OTP Non Numerik/Non String

Ini bypass sangat sederhana. Program backend berharap OTP adalah string, tapi bagaimana jika kita beri input berupa array atau object? Contohnya di PHP, parameter otp=123456 bisa dicoba diganti dengan otp[]=12356. Contoh lain jika backend menerima JSON: {"userid": "x123", "otp":"123456"} lalu kita ganti menjadi {"userid": "x123", "otp":[]} .

Salah satu penyebab ini bisa terjadi adalah penggunaan strcmp di PHP untuk membandingkan string dan array. Ini adalah salah satu kelemahan type juggling di PHP. Sementara di NodeJS atau teknologi javascript lain, bisa juga memiliki bug prototype pollution.

Intinya adalah: input-input non numerik/non string atau bahkan string dengan format tertentu bisa saja membuat error pada pemrosesan di backend.

SQL Injection/Akses Database

Bug SQL injection memungkinkan kita mengintip nilai OTP saat ini. Bahkan dalam kasus tertentu field OTP itu sendiri yang memiliki SQL injection. Hal ini bisa parah jika OTP yang dipakai adalah berbasis TOTP (time based OTP), dan kita memiliki seed untuk OTP tersebut. Artinya kita bisa mendapatkan OTP untuk sembarang orang kapanpun juga.

Tentunya akses database tidak harus selalu melalui SQL Injection, bisa saja melalui noSQL injection atau melalui Remote Code Execution (RCE). Jika kita bisa mendapatkan RCE kita bisa mengupload shell yang bisa mengakses database.

Bruteforce OTP

Jika tidak dibatasi waktu dan jumlah percobaan, maka OTP bisa dibypass dengan bruteforce terutama jika hanya 4 digit. Hanya dibutuhkan maksimum 10 ribu percobaan. Dalam kasus tertentu jumlah request bisa sangat sedikit. Kasus menarik yang pernah saya temui: OTP dibutuhkan untuk menambahkan email, dan format requestnya seperti ini:

actions: [{"action": "add_email",  "email": "[email protected]", "otp":"1232"}]

Menariknya di sini adalah adanya array actions, artinya kita bisa mengirimkan banyak request sekaligus, seperti ini:

actions: [
{"action": "add_email",  "email": "[email protected]", "otp":"0001"},  
{"action": "add_email",  "email": "[email protected]", "otp":"0002"},
{"action": "add_email",  "email": "[email protected]", "otp":"0003"} 
] 

Saya beruntung karena aplikasi tersebut meneruskan memproses action berikutnya jika yang pertama gagal. Karena hanya ada 10 ribu kemungkinan, kita cukup mengirimkan 100 request dengan masing-masing request mencoba 100 OTP. Atau bahkan jika sistemnya mampu menerima, kita mungkin bisa mengirimkan 1000 OTP, dan hanya butuh 10 request.

OTP dicek di client

Ini adalah bug yang sangat aneh dan seharusnya tidak terjadi. Ketika aplikasi butuh OTP, server mengembalikan nilai OTP ke client. Client di sini artinya browser atau mobile app. Jadi jika kita bisa mengintercept hasil requestnya, kita tahu apa OTPnya. Bug ini mungkin terdengar konyol, tapi setidaknya sudah ada 3 aplikasi yang saya cek yang memiliki bug sejenis ini.

Memakai OTP user lain

Ada OTP yang diimplementasikan dengan aneh: OTP tidak diasosiasikan dengan user id, tapi dengan OTP token. Atau sederhananya: OTP sesorang bisa dipakai orang lain.

Dalam bug ini, ketika user melakukan aksi yang butuh OTP, aplikasi meminta ke server (generateOTP) dan server akan mengembalikan sebuah token OTP (bukan string OTPnya, hanya sekedar ID misalnya xyz123) ke aplikasi sambil mengirimkan nilai OTP ke SMS User (misalnya 7171). Ketika user mengetikkan OTP dari SMS yang diterimanya, maka yang dikirimkan ke server adalah: aksi user saat ini (misalnya transfer uang), token OTP (xyz123) dan OTP-nya (7171).

Masalahnya token OTP ini bisa dipakai di user lain, jadi dengan mengirimkan transaksi sebagai user B, tapi memakai nilai OTP dari user A (dengan token OTP dan nilai OTP user A) kita bisa membypass OTP user B. Jadi dalam kasus ini: attacker A memiliki account juga di website target agar bisa menerima OTP di ponselnya.

OTP spamming

Terkadang SMS tidak langsung sampai, jadi user meminta OTP sampai beberapa kali. Kadang jika kita meminta OTP 3 kali, yang sampai ke HP malah hanya 2 OTP pertama (sementara OTP terakhir masih “nyangkut”). Karena ingin berbaik hati, sebagian programmer menerima tidak hanya OTP terakhir, tapi beberapa OTP sebelumnya. Kadang ini tidak berdasarkan jumlah (n OTP sebelumnya), tapi berdasarkan waktu, misalnya OTP yang dihasilkan 10 menit terakhir akan dianggap valid.

Kita bisa menspam server dengan meminta OTP sebanyak-banyaknya. Misalnya OTP hanya 4 digit dan selama 10 menit kita bisa meminta 1000 OTP, maka kemungkinan OTP kita benar adalah 1 banding 10.

Bug IDOR update profile/phone number

Biasanya kita bisa mengubah nomor telepon via aplikasi atau via web. Jika ada bug indirect object references (IDOR) sehingga kita bisa mengupdate/menimpa profil atau ponsel orang lain ketika kita melakukan aksi profile (yang seharusnya mengupdate profile kita sendiri), maka ini bisa digunakan untuk bypass OTP karena OTP akan dikirimkan ke nomor ponsel kita.

Sebagai catatan: kebanyakan bank (termasuk yang saya pakai) hanya mengijinkan perubahan nomor ponsel dengan datang langsung ke banknya. Sementara perubahan email berbeda kebijakannya (ada bank yang mengijinkan online, ada yang tidak, ada yang butuh OTP dan ada yang tidak).

Weak Random Number Generator

Ini hanya bisa ditemukan jika kita bisa mendapatkan akses ke source code melalui bug lain (atau mungkin adminnya lupa sehingga direktori .git bisa diakses). Kadang OTP dihasilkan hanya dari random number generator yang memakai waktu saat ini sebagai seed.

Logic Reset Password

Dalam banyak aplikasi, setelah kita reset password, maka kita otomatis login. Jika ada kelemahan dalam mekanisme reset password (ini mungkin akan saya bahas di kesempatan lain), maka kita bisa memanfaatkan ini untuk bypass OTP.

Cara lain (bukan bug aplikasi)

Sebagai pelengkap, saya akan menuliskan beberapa bypass OTP yang bukan bug aplikasi dan biasanya di luar scope sebuah bounty ataupun pentest.

Kebanyakan orang jahat memakai social engineering agar korban membacakan OTP. Ini menurut saya bukan bug aplikasi, terutama jika ada instruksi yang jelas di SMS: jangan berikan OTP ini pada siapapun. Jika instruksinya tidak ada atau tidak jelas, maka itu bisa disarankan kepada developernya.

Simjacking atau SIM swap adalah serangan social engineering ke perusahaan telekomunikasi. Intinya penyerang mengumpulkan data orang lain, dan menghubungi perusahaan telekomunikasi: “Maaf SIM card saya hilang, tolong buatkan SIM card baru dengan nomor yang sama, berikut ini data pribadi saya”. Dengan data yang cukup lengkap, penipu bisa meyakinkan agar diberikan SIM Card baru.

Cara lain bypass OTP adalah dengan mengakses sistem telekomunikasi, baik itu bug di level SS7 maupun di sistem lain yang berhubungan dengan SMS. Sebagai catatan: serangan ini cukup kompleks dan rawan ketahuan. Jadi biasanya hanya dilakukan jika targetnya nilainya cukup besar.

Cara berikutnya adalah dengan malware: jika ada malware yang terinstall di HP korban, maka semua SMS bisa diakses oleh attacker. Dengan cara ini OTP aplikasi apapun yang berbasis SMS bisa diakses oleh attacker. Agar korban menginstall aplikasi malware ini, korban bisa ditipu dengan social engineering tertarget (“bapak perlu menginstall aplikasi kami terbaru agar dapat mengakses layanan ini”) atau sekedar membuat aplikasi palsu dan disebar ke web ( misalnya: “APK terbaru cheat Mobile Legends”).

Jika OTP dikirim via email, dan email sudah diambil alih oleh attacker, maka attacker akan bisa mengakses OTP. Berbagai serangan untuk mengakses email orang bisa dilakukan, dan mungkin akan saya bahas juga di tulisan lain.

Penutup

Mungkin masih ada bug-bug lain yang tidak tercantum di sini, jadi jangan cuma terpaku pada list yang tercantum di sini. Intinya pikirkan dari mulai OTP dibuat, dikirimkan, sampai divalidasi di sisi server.

Ketika saya mendapatkan source code sebuah aplikasi, kadang saya terpikir beberapa bug yang tidak terpikirkan sebelumnya. Misalnya ternyata programmernya memiliki backdoor OTP, yaitu OTP sakti berupa string khusus yang bisa dipakai di sembarang transaksi (mungkin digunakan ketika testing tapi tidak dihapus dalam production).

Artikel singkat ini sekedar menjadi checklist ketika pentest untuk mengetahui serangan apa saja yang bisa dilakukan untuk bypass OTP. Saya juga berharap programmer membaca ini agar membuat sistem yang aman. Saya suka sistem yang aman karena membuat pekerjaan pentest saya jadi lebih cepat, dan saya jadi bisa memikirkan bug lain yang lebih kreatif.

HITB PRO CTF 2019

Ini cerita khusus mengenai HITB CTF di Abu Dhabi, sedangkan cerita jalan-jalan saya tuliskan di posting lain. Dari websitenya acaranya, rencananya ada 20 tim tingkat dunia yang diundang, pemenang dari berbagai CTF lain di dunia tapi akhirnya hanya 19 team yang berkompetisi. Di akhir kami akhirnya peringkat 9 dari 19.

Tim PDKT yang lolos di HITB tercantum di CTF Time. Saya tidak akan bercerita detail tentang tim ini, silakan kunjungi website/sosmed/github masing-masing anggota teamnya: farisv, visat, wearemarching, zeroload. Sengaja saya link tidak ke linkedin langsung, supaya kalau di masa depan informasi profilenya ingin dianonimkan akan lebih mudah. Ada yang baru tingkat 3, dan sisanya belum lama lulus (tidak seperti saya yang sudah lebih 20 tahun lulus S1).

Ranking akhir pemenang bisa dilihat di: https://ctftime.org/event/918 . Di posting ini saya ingin bercerita mengenai teknis CTF ini, dari format lombanya sampai teknis beberapa soalnya.

Format lomba adalah attack defense murni, tidak ada soal jeopardy. Semua tim diberikan berbagai service yang sama, dan kita perlu menyerang service team lain sambil mempertahankan tim kita. Supaya lebih jelasnya, saya akan memberikan contoh sederhana (bukan soal sesungguhnya).

Misalnya kita diberi layanan image gallery. Ternyata di programnya ada bugnya: bisa mengupload selain image, jadi kita bisa menjalankan kode kita sendiri atau mungkin ada bug lain: bisa melihat image orang lain. Nah panitia akan menaruh flag (berupa string kode) ke dalam image, dan akan mengupload ke semua peserta (flagnya beda untuk tiap service dan tim tiap peserta).

Tugas kita adalah mencuri flag dari peserta lain, dan memastikan orang tidak bisa mengambil flag kita. Bagian sulitnya adalah: fungsionalitas harus tetap jalan, jadi kita tidak bisa membela diri dengan mematikan servicenya atau memblok semua iamge, atau memblok peserta. Jadi ada program dari panitia yang akan menguji bahwa fungsionalitas masih jalan. Di contoh ini galery harus bisa tetap menerima image dan tetap bisa didownload imagenya. Jadi patchnya harus cukup eksak, kalau membuat layanannya tidak berjalan, poin kita akan dikurangi.

Panitia sudah membuat repositori semua soal dengan writeup dari panitia (dengan solusi yang diharapkan panitia). Ini bisa diakses umum di:

https://github.com/HackerDom/proctf-2019

Terlihat bahwa team PDKT berhasil pertama menyelesaikan salah satu soal drone_racing (first blood untuk soal itu).

Kita bisa menjalankan tcpdump untuk memonitor layanan kita agar bisa mempelajari eksploit yang dikirimkan team lain. Tapi tcpdump ini tidak selalu ampuh karena beberapa hal:

  • Team lain mengirimkan eksploit yang obfuscated
  • Kadang data yang dikirimkan sangat besar (misalnya image), padahal disk space virtual machine yang diberikan sangat terbatas
  • Kadang layanan memakai SSL (encrypted), jadi harus diintercept dengan cara khusus (tidak bisa sekedar tcpdump)
  • Kadang layanan memakai enkripsi custom

Jika ada beberapa team yang mendapatkan skor terlalu banyak dari satu soal, soal itu akan dipensiunkan dan diganti dengan soal yang lain. Soal-soal hari pertama baik yang bisa maupun yang tidak bisa diselesaikan juga dipensiunkan di hari ketiga.

Menurut saya beberapa soal dirancang tidak bisa diselesaikan dalam waktu sehari, dan memang diharapkan peserta meneruskan pengerjaan soal di hotel. Jadi jika ada lomba semacam ini, sebaiknya persiapkan stamina dengan baik.

Ada beberapa soal yang saya benar-benar tidak kepikiran karena tidak tahu bahwa suatu hal itu mungkin. Misalnya saya tidak memperhatikan di soal rubik bahwa bisa saja terjadi use after free karena menggunakan alokasi stack manual di F#. Saya tidak tahu bahwa ini bisa dilakukan di F# dan bahwa tidak ada pengecekan yang dilakukan oleh runtime .NET.

Satu soal yang membuat menyesal adalah SepToN. Saya tahu persis harus bagaimana: melakukan attack terhadap Substitution–permutation network. Dulu saya sempat mempelajari ini khusus AES untuk melakukan fault injection attack di hardware, tapi saya tidak pernah benar-benar mempraktikkan variasi SPN yang tidak wajar (di kasus ini round-nya hanya 4).

Saya merasa soal-soal enkripsi blok ini cukup mengada-ada. Saya tidak pernah menemukan di dunia nyata orang yang membuat block cipher custom sendiri. Sedangkan untuk berbagai kasus kelemahan kriptografi yang lain, memang saya temukan. Saya merasa stuck karena saya pikir attack hanya bisa dilakukan terhadap BMP header (4 byte) saja. Setelah membaca writeupnya, ternyata komponen Alpha bisa digunakan.

Ada satu team yang berhasil menyelesaikan soal SepToN ini, dan dari satu soal ini saja, mereka mendapatkan nilai yang sangat banyak. Tidak ada defense khusus yang bisa dilakukan untuk menangkal ini, jadi semua tim lain juga pasrah.

Soal yang diberikan sangat bervariasi, dan bahkan ada soal IOT juga. Saya sendiri awalnya diundang karena akan ada materi khusus IOT, tapi ternyata bagian ini dibatalkan. Ternyata dalam lomba ini tetap ada satu soal IOT. Saya agak menyesal tidak memperhatikan bahwa diberikan kabel mini USB untuk ST-LINK, dan baru di hari kedua saya sadari kabel ini ada dan bisa dipakai mengekstrak firmwarenya. Sayangnya waktunya tidak cukup, dan soal tidak diteruskan untuk hari ketiga. Saya jarang melakukan reversing kode ARM thumb (terakhir adalah ketika melakukan RE Pokemon Go Plus), dan prosesnya agak lama.

Ada juga satu soal berhubungan dengan AI (adversarial attack). Saya merasa sedikit kesal dengan diri sendiri karena tidak pernah benar-benar mencoba attack terhadap AI meskipun tahu teorinya. Saya tahu dengan tepat bagaimana neural networknya bekerja, dan saya mencoba-coba mengimplementasikan neural network sederhana dengan layer deconvolutional tapi akurasinya masih terlalu rendah.

Kesulitan utama dalam mengerjakan CTF seperti ini adalah: memilih soal untuk dikerjakan. Ada beberapa soal yang dari awal sepertinya sudah terlihat sangat sulit, tapi ternyata mudah (misalnya soal ca), dan karena sudah merasa akan ribet, kami jadinya tidak menyelesaikannya. Beberapa soal lain terlihat sulit dan memang sangat sulit (misalnya convolutional) dan saya merasa ini hampir mustahil selesai sehari (dan memang semua tim gagal menyelesaikan ini).

Di sisi lain: kadang soal sulit bisa memiliki solusi sederhana yang tidak diharapkan pembuat soal. Team PDKT berhasil menyelesaikan soal Drone Racing yang mestinya sangat rumit (overflow file .class) dengan hanya menggunakan trik database.

Saya kagum dengan dedikasi team PDKT yang selagi lomba juga sambil mengurus final Cyber Jawara, jadi waktunya agak tersita karena sambil lomba juga mengurusi lomba di Indonesia. Semoga berikutnya akan ada lebih banya lagi yang kemampuannya setara, supaya minimal bisa membantu penyelenggaraan lomba di Indonesia.

Penutup

CTF offline seperti ini memang cocok untuk anak muda, sedangkan saya merasa agak lelah karena masalah perjalanan dan perbedaan time zone dan stamina tidak seperti waktu saya masih muda. Selain itu sudah lama juga saya tidak ikut CTF yang umum seperti ini, dua tahun terakhir saya hanya ikutan CTF Flare On saja. Mungkin kalau pekerjaan utama saya sehari-hari berhubungan dengan security, akan lebih mudah untuk update ilmu security/CTF setiap hari.

CTF seperti ini butuh tetap mengerjakan soal di hotel. Ini juga alasan saya tidak membawa Risna dan anak-anak, karena tidak akan bisa bersenang-senang di hari lomba. Sepertinya sekarang ini saya lebih cocok dengan CTF jangka panjang seperti Flare On supaya santai.

Pemain CTF juga harus belajar banyak hal baru, termasuk juga topik sulit seperti AI. Topik dasar enkripsi secara menyeluruh juga perlu dikuasai Saya sendiri jadi terinspirasi untuk akan lebih banyak menuangkan hal-hal seperti ini dalam bentuk tulisan (sudah lama tidak menulis teknis dasar).

Semoga di tahun-tahun berikutnya team Indonesia bisa lebih baik lagi.

Flare-On 2019 dan pembahasan soal no 6

Flare On ke-6 sudah selesai dan solusi dari panitia juga sudah diberikan. Ini tahun ke-5 saya menyelesaikan seluruh soal Flare On.Tidak seperti tahun-tahun sebelumnya di mana saya ingin buru-buru selesai, tahun ini saya sangat santai dan selesai di peringkat 148. Tahun ini ada 308 orang yang selesai semua dari total 5790 yang mendaftar. Kalau tidak sibuk, tahun depan saya rencana tetap ikut dalam mode santai seperti ini.

Menurut saya Flare On ini sangat berguna untuk mengasah ilmu reverse engineering dan mengenal berbagai teknik baru yang tidak/belum saya ketahui. Soal tahun ini sejak nomor satu sudah lebih sulit dari tahun-tahun sebelumnya, tapi ada 3228 yang berhasil menyelesaikan soal pertama. Menurut saya soal-soal nomor tinggi justru lebih mudah dari tahun-tahun sebelumnya tapi butuh banyak kesabaran. Sama seperti tahun-tahun sebelumnya, di akhir kita akan ditanya apakah ingin mengirimkan CV ke Fire Eye.

Tahun ini ada dua orang yang saya kenal dari Indonesia yang berhasil menyelesaikan Flare On: 0xf4c0 dan Visat (dari team PDKT), seperti biasa karena alamat pengiriman hadiah di Thailand saya dihitung dari Thailand.

Dulu saya cukup rajin untuk menuliskan solusi semuanya, sekarang karena solusi dari panitia sudah datang cepat, saya malas menuliskannya, kecuali jika ada pendekatan saya yang berbeda. Tahun lalu saya hanya menuliskan dasar ilmu apa yang dibutuhkan untuk menyelesaikan tiap soal.

BMPHIDE

Hari ini ada yang bertanya apakah saya bisa menuliskan cara saya menyelesaikan soal No 6 (BMPHIDE), karena saya punya waktu, jadi saya tuliskan saja sekarang (kebetulan juga sekarang Flare On ke-6, jadi saya bahas soal No 6 saja). Di soal ini kita diberi sebuah program dan file bitmap (BMP). Soalnya bernama bmphide, dari namanya saja sudah terpikir bahwa ini adalah soal steganografi, tapi tentunya bukan soal steganografi biasa.

Sebelum membaca solusi saya, sebaiknya baca dulu solusi resmi dari Flare On (PDF), lalu kembali ke sini. Ada beberapa hal yang tidak akan saya bahas detail, misalnya: ada anti debug sehingga program tidak bisa didebug. Dari pengalaman di Flare On tahun-tahun sebelumnya: jika ada anti debug, maka saya akan berusaha tidak memakai debugger karena biasanya anti debugnya sangat kompleks dan memakan waktu lama. Bahkan di beberapa soal di tahun sebelumnya: jika dijalankan di debugger malah tidak bisa ketemu flagnya.

Tidak ada instruksi untuk menjalankan program yang diberikan, tapi karena programnya ditulis dalam .NET kita bisa membongkarnya dengan dnspy untuk melihat kodenya. Bagian main-nya seperti ini:

Dari membaca kodenya, Program BMPHIDE.EXE dipakai untuk menyembunyikan data di dalam file bitmap. Jika dibaca sekilas bagian enkripsi (Program.h()) dan menyembunyikan data dalam bitmap (Program.i()) cukup jelas. Ini steganografi standar dengan menggunakan LSB.

Pendekatan saya tidak memakai debugger adalah dengan membuat ulang programnya di project Visual Studio. Ternyata jika kode hasil dekompilasi ini kita copy paste ke project baru di Visual Studio, hasilnya tidak seperti yang diharapkan. Jadi pasti ada sesuatu yang ajaib yang dilakukan oleh program.

Jadi akhirnya saya mulai membaca lagi lebih teliti programnya. Ada method aneh bernama VerifySignature. Dari melihat sekilas saja, sepertinya ini akan membuat agar pointer method1 jadi pointer method2. Setelah membaca-baca beberapa artikel (contohnya ini), memang itu yang dilakukan.

Mungkin ada yang heran: dari mana tahu bahwa ini kode penting? Saya tahu dasar .NET, jadi terbayang kira-kira apa yang bisa dan tidak bisa dilakukan di .NET, jadi dari dasar ilmu itu bisa mencari di Internet mengenai MethodHandle di .NET dan apa yang bisa dilakukan.

Sekarang hal pertama sudah diketahui: ada method yang ditukar implementasinya, jadi andaikan kita memanggil method X, yang dipanggil sebenarnya Y. Tapi method mana yang ditukar? tidak dengan mudahnya mereka menuliskan tukar method bernama X dengan Y, tapi mereka membuat kode seperti ini:

Intinya seluruh method dibuat checksum kodenya, lalu method yang checksumnya sekian akan ditukar dengan yang checksumnya sekian. Di project visual studio saya, saya perlu meload bmphide.exe ini agar bisa dilihat semua methodnya dan dibuat checksumnya. Ini bisa dilakukan dengan kode semacam ini (kuncinya di sini adalah Assembly.LoadFrom):

Dari sini saya bisa mengetahui method mana yang ditukar. Tapi ternyata tidak cukup di sini triknya. Ada method yang bernama IncrementMaxStack (namanya menyesatkan, tidak ada hubunganya sama sekali dengan stack), yang berisi kode untuk mem-patch alamat memori dengan isi tertentu (lihat “writeByte” dan “writeInt32”). Dari nama fieldnya (ILCode) sudah jelas bahwa yang dipatch adalah IL (Intermediate Language) code, tapi kode yang mana yang dipatch?

Kali ini method tidak dicari berdasarkan isi checksumnya tapi berdasarkan metadata tokennya. Jadi sekali lagi saya meloop semua method dan mencetak MetadataToken-nya untuk mendapatkan dua method yang dipatch. Saya bahas saja salah satu method yang dipatch yaitu program.g, hasil dekompilasi asli seperti ini:

Tapi kode ini dipatch di offset 6 dengan angka baru dan offset 18 (atau 12 hexa) dengan angka baru.

Jika kita lihat IL code-nya, akan terlihat apa artinya offset 6 dan 12 hexa ini (lihat kolom kedua, dengan header “offset”). Di sini tidak ada offset 6, tapi ada offset 5. Di offset 5 ada instruksi ldc (load constant), yang meload bilangan -0x12477CE0. Bilangan ini yang dipatch menjadi 309030853. Hal yang sama juga dilakukan untuk offset 12 heksa.

Jadi setelah diperbaiki, fungsi g menjadi seperti ini:

Setelah mendapatkan versi benar dari semua methodnya, saya bisa mengcompile bmphide saya sendiri, dan bisa mendebugnya dan memahami algoritmanya dengan mudah. Sisanya hanya membuat dekriptor dan ekstraktornya.

Pendekatan saya sebenarnya antara pendekatan 1 dan 2: saya membrute force per byte dengan memanggil fungsi enkrip. Loopnya seperti ini:

Tidak seperti solusi di flare-on di mana hasil brute force (solusi 1) tidak jelas, hasil brute force ini akan jadi image yang bersih.

Penutup

Soal ini sebenarnya hanya “pemanasan” dalam hal enkripsi, tepatnya bagaimana sebuah enkripsi yang relatif sederhana bisa disembunyikan dengan trik sehingga sulit dibaca meskipun menggunakan decompiler. Soal berikutnya yang lebih serius ada di no 10. Di soal 10 kita diberi “ransomware” (bernama mugatu) yang memiliki kelemahan di bagian enkripsinya.

Bagi yang ingin merasakan betapa lamanya memahami enkripsi dan membuat dekriptor sebuah ransomware, silakan mencoba menyelesaikan soal no 6 dan 10. Ini soalnya masih sangat sederhana dan malware yang sebenarnya akan butuh waktu yang lebih lama lagi.

Cerita hacking dari masa lalu

Sebagian teman angkatan di Informatika ITB tahu kalau saya dan Deny dulu hampir di-DO karena “ngehack” kampus, tapi cerita detailnya belum pernah saya tuliskan. Nah kali ini dengan persetujuan dan encouragement dari Deny, Tintin, dan Okta saya akan tuliskan ceritanya. Karena ini cerita lama (lebih dari 20 tahun yang lalu), saya akan banyak memberikan latar belakang cerita.

Cerita ini sudah sangat lama, sebagian detail sangat saya ingat, tapi sebagian lagi benar-benar lupa. Ketika bertanya ke Tintin dan Deny mereka juga banyak lupa detailnya, jadi saya ceritakan saja di sini sekarang sebelum tambah lupa lagi.

Kenalan dengan Hacker

Saya awali dulu dengan cerita ketemu Deny. Sekedar background: kok bisa ketemu dengan orang lain yang suka ngehack?

Saya ketemu Deny kali pertama waktu kuliah di Informatika ITB, tahun 1998. Di ITB tingkat 1 adalah Tahap Persiapan Bersama, di tahun pertama semua jurusan pelajarannya sama yaitu ilmu-ilmu dasar dengan tujuan agar ilmunya seragam di tingkat berikutnya. Pelajaran yang diberikan misalnya: Fisika, Kimia, Matematika (Kalkulus), Bahasa Inggris, dan bahkan ada juga pelajaran Olah Raga.

ITB

Nah saya jadi ngobrol dengan Deny karena waktu itu saya membawa buku komputer. Kalau tidak salah ingat judul bukunya: Meningkatkan Dayaguna Komputer dengan Turbo Pascal karangan Busono. Buku ini mengajarkan cara mengakses hardware komputer secara low level (serial port, parallel port, dsb) dengan Turbo Pascal.

Perlu dicatat bahwa saat itu (nggak tau sekarang) banyak yang masuk Informatika ITB tapi pengetahuannya mengenai komputer sangat dasar sekali. Informatika ITB dipilih banyak orang karena passing grade-nya waktu itu adalah yang tertinggi. Jadi saya senang ketemu dengan seseorang yang bisa ngobrol programming selagi programming belum diajarkan di kelas.

Meski belum diajarkan programming, HMIF (Himpunan Mahasiswa Informatika) ITB memberikan pelatihan dasar Linux pada seluruh mahasiswa baru setelah selesai masa OSPEK. Pelajarannya sangat dasar: bagaimana mengakses Linux, mengakses email, membuat file, mengedit dengan vi, dsb.

Di pelatihan itu (Agustus 1998) kali pertama saya dan Deny belajar mengenai Linux. Sebelumnya kami cuma memakai DOS dan Windows. Setelah masa pelatihan selesai, mahasiswa (tingkat manapun, termasuk tingkat 1) boleh bebas mengakses lab ketika tidak ada praktikum. Bahkan kadang diperbolehkan juga pada jam praktikum kalau kenal dengan asistennya, selama masih ada komputer kosong di belakang dan tidak mengganggu sesi praktikum.

Lab

Di semua waktu luang tingkat 1, saya dan Deny menghabiskan sebagian besar waktu ngoprek di Lab. Waktu itu belum ada Google (tepatnya lagi baru September 1998 Google didirikan, itupun tidak langsung populer), jadi sumber utama ilmu kami adalah:

  • Majalah Phrack
  • Halaman manual (man page), bahkan saya pernah memprint banyak sekali manual page “perl” untuk dibaca di kost
  • Mailing list (misalnya bugtraq)
  • Beberapa website dan e-Zine

Entah kenapa saya dan Deny tidak tertarik sama sekali untuk join dengan berbagai “group hacker” seperti hackerlink, kecoak elektronik, dsb. Tapi saya dapat cerita dari teman kami Tintin (sekelas/seangkatan juga), bahwa group yang ada itu ya cuma bisa compile exploit dari Packet Storm, dan bahkan kadang mereka bingung kalau ketemu error waktu compile.

Waktu tahun kami masuk, kondisi mesin di lab sedang cukup parah. Baru dua tahun setelah itu ada dana baru sehingga mesinnya diupgrade secara signifikan. Dulu sudah jaman Pentium tapi mesin di lab masih 486 DX dan keyboardnya banyak yang mulai error. Mesinnya bisa dual boot: network boot ke Linux (diskless, memakai NFS) dan ke Novell Netware. Dari Netware kita bisa telnet ke salah satu server yang bisa diakses mahasiswa (Puntang/x86 dan kerinci/Sparc).

Sebagai catatan: di berbagai jurusan lain (misalnya Teknik Elektro) waktu itu yang banyak dipakai adalah BSD (biasanya FreeBSD), tapi di jurusan Informatika yang banyak dipakai adalah Linux dari awal. Dari setup yang dilakukan, bisa dilihat bahwa adminnya (mas Budi Aprianto mahasiswa yang dipandu oleh dosen, Pak Riza Satria Perdana ) sangat capable dan sudah mensetup sistemnya dengan baik:

  • Network boot dengan PXE waktu itu belum umum, harus burn EPROM di Network Card
  • Diskless boot juga tidak terlalu umum. Server NFS-nya memakai Solaris di server dengan CPU SPARC

Awalnya rasanya aneh memakai Linux, beberapa ilmu DOS seperti TSR, mengakses layar secara langsung atau memakai Library “<conio.h>” untuk mewarnai layar tidak berlaku di Linux. Tapi saya dan Deny cukup rajin belajar mengimplementasikan banyak hal, dari network programming (bikin port scanner dengan full TCP connect), sampai termasuk juga yang berhubungan dengan security.

Di tahun 1998 sebenarnya mekanisme shadow password sudah disupport di Linux, tapi entah kenapa belum diimplementasikan di distribusi yang kami pakai. Salah satu “hack” pertama yang kami lakukan adalah membuat program untuk membrute force password seseorang. Waktu itu password requirement belum diterapkan, jadi passwordnya masih relatif gampang ditebak.

Seperti yang saya jelaskan: kondisi lab waktu itu cukup parah, banyak keyboard yang error, kadang menekan 1 huruf tapi hurufnya tertekan 2 kali atau malah tidak tertekan. Ini biasanya jadi masalah ketika mengganti password (ada kelebihan/kekurangan huruf). Daripada selalu merepotkan admin, waktu itu kami membantu teman yang lupa password dengan mencoba-coba otomatis menambah dan mengurangi karakter dari password terakhir yang diingat.

Perpustakaan

Lab di Informatika ITB tutup di sore hari (lupa jam 4 atau 5), tapi ada rental Internet di perpustakaan ITB yang tutup sampai jam 7 malam. Jika saya belum ingin pulang (toh di kost nggak banyak yang bisa dikerjakan) saya akan menghabiskan uang untuk nongkrong di rental internet perpustakaan (memakai Windows 97).

Perpustakaan ITB

Akses internet di perpustakaan ITB adalah per 30 menit: bayar dulu, komputer tertentu akan diaktifkan, dan jika waktu habis koneksi akan dimatikan otomatis. Tapi lama-lama kan mahal, jadi saya mempelajari bagaimana prosesnya sejak memberi uang, dapat akses internet, sampai aksesnya dimatikan lagi.

Ternyata operator akan melakukan telnet ke sebuah server dan dari situ ada skrip untuk membuka akses internet. Saya perhatikan juga bahwa ada admin yang suka memakai salah satu komputer di dalam ruangan rental.

Saya menulis sendiri keylogger yang memakai API windows. Tepatnya sebenarnya bukan keylogger karena tidak mencatat semua tombol, tapi hanya akan mencari semua single line textbox dan password textbox dan melog teks serta passwordnya ke file. Di Windows lama (95 sampai ME) ini sangat mudah, kita cukup mengenumerasi handle Window dan mengirimkan WM_GETTEXT (waktu itu tidak ada sistem permission di Windows). Dengan teknik tersebut, segala macam password yang sudah tersimpan juga bisa didapatkan passwordnya (tidak hanya yang diketik manual).

Saya hanya memasang logger di komputer yang saya tahu dipakai admin. Dengan logger itu saya bisa mendapatkan akses internet unlimited di perpustakaan. Supaya tidak mencurigakan biasanya saya akan membayar 30 menit pertama dan hanya meneruskan kalau sepi. Di semester baru, saya baru tahu dari Deny kalau dia bawa logger saya dan dia pakai di warnet di Medan.

Tempat Lain

Lab IF dan Perpustakaan sebenarnya bukan satu-satunya tempat nongkrong. Banyak tempat lain di ITB yang punya lab komputer dan jadi tempat belajar untuk banyak orang, misalnya ada PAU (Pusat Antar Universitas), unit ARC (Amateur Radio Club), berbagai lab di berbagai jurusan.

Masing-masing orang punya kisahnya di tempat mereka, dari mulai kisah teknis seperti kami, sampai ada yang ketemu pasangan di tempat-tempat tersebut. Saya sendiri dulu sempat juga main ke ARC sebentar, tapi karena merasa kurang cocok, jadi lebih sering di lab IF (sementara Deny cukup sering ke ARC).

Root

Saya tidak ingat kapan kami mulai berani mengakses root. Tapi ini terjadi kira-kira akhir tahun (sekitar 3-4 bulan sejak kami belajar Linux). Akses root pertama kami dapatkan dari backdoor di port yang kami temukan dengan port scan. Selain cara itu, waktu itu ada banyak sekali eksploit yang bisa dipakai asalkan kita mencari di Internet (atau melihat mailing list bugtraq).

Sebagai catatan: dari adanya backdoor berarti sudah ada yang lebih dulu dari kami mendapatkan root. Salah satu teman kami, Okta juga dapet root dengan eksploit sendmail.

Salah satu alasan kami mendapatkan root adalah: untuk mengakses internet dari lab IF ITB. Di semester pertama kami cuma dapat akses email. Kami berusaha mencari host yang memiliki akses internet dan/atau username/password proxy yang bisa dipakai.

Berikutnya setelah jadi root di satu host, mau ngapain? Bagian pertama adalah: jadi root di host lain. Kami bisa telnet ke mesin x86 dan Sparc. Di mesin x86 kami sudah punya root, tapi di Sparc kami nggak punya exploit apa-apa. Kami bisa mengakses home dir yang sama (via NFS). Jadi pertama adalah pivoting: mengcopy shell di Sparc ke home directory, lalu di-chmod setuid root dari server x86. Sekarang kami punya akses di kedua server utama. Dari mana dulu tahu ilmu ini? sebenarnya semuanya cuma logika dasar aja. Setelah tahu konsepnya, mengembangkan hal-hal dasar seperti itu tidak sulit.

Keisengan berikutnya muncul: Deny mendownload source code program “login”, lalu menambahkan kode logging agar password disimpan ke file. Executable baru itu dipakai untuk menggantikan program login asli di kedua server. Hasilnya: kami dapat password semua orang.

Sebagai catatan: programming itu sangat perlu untuk seorang hacker. Sekarang ini banyak yang mengaku “hacker”, tapi kalau saya berikan source code saja dan saya minta untuk menambahkan logging kebanyakan tidak bisa.

Meskipun mendapatkan akses ke semua account, kami tidak tertarik membaca email atau file-file orang lain. Segala macam yang kami lakukan waktu itu cuma karena penasaran aja. Kami juga nggak mau mencoba teknik-teknik yang kami anggap nggak butuh skill teknis, contoh yang tidak kami lakukan:

  • Denial Of Service
  • Email bombing
  • Social engineering

Bagian social engineering ini: kami nggak pengen seseorang jadi merasa bersalah jadi korban Social engineering. Tujuan hacking waktu itu adalah: belajar teknis.

Tertangkap

Saya tidak tahu tepatnya apa yang membuat kami tertangkap. Seingat saya kami sudah sangat teliti: tidak memakai home directory sendiri, tapi memakai home directory dua mahasiswa ITB yang diterima tapi pindah keluar negeri. Kalau tidak salah ingat: ada keanehan di sistem dan itu menyebabkan penelusuran yang mendalam di sistem dan malah mengarah ke kami berdua.

Saya ingat waktu itu ada kuliah di salah satu gedung di tengah ITB (lupa tepatnya, antara Oktagon atau TVST), dosennya adalab Bu Putri. Kami sadar ada yang salah, karena di akhir kuliah tiba-tiba beliau memanggil: yang namanya Yohanes Nugroho mana ya? (saya berdiri), terus “kalau Deny Saputra?” (Deny berdiri). Terus udah: “silakan duduk, cuma pengen tahu yang mana sih orangnya”. Urutan memanggilnya begitu, karena NIM saya lebih rendah dari Deny.

Selesai kuliah itu saya dan Deny sudah tahu bahwa kami tertangkap. Saya diwawancara oleh Pak Riza Satria Perdana, lalu Deny juga (wawancaranya terpisah). Setelah semuanya selesai, kami diberi tahu bahwa sebenarnya yang kami lakukan itu bisa membuat kami di DO. Tapi Pak Riza mau memberi kesempatan, bahkan akhirnya saya menjadi administrator jaringan Informatika ITB.

Saya sebutkan di atas bahwa Okta juga mendapatkan root, tapi lolos dari interogasi. Kenapa? karena waktu interogasi, saya ditanya itu setuid shell punya siapa? saya bilang “nggak tau, mungkin Deny yang taruh situ”, dan ketika Deny ditanya: “nggak tau, mungkin Yohanes yang taruh di situ”.

Supaya jelas: meskipun kami sering ngehack bareng , bukan berarti tiap hari duduk berdua dan ngobrol berdampingan. Kami hacking terpisah, dan banyak diskusi. Kadang saya dan Deny duduk di lab terpisah dan berbicara dengan software “talk“. Jadi kami nggak tahu 100% apa yang dilakukan yang lain.

Penutup

Sejak kami tertangkap, kami jadinya pelan-pelan meninggalkan dunia security dan lebih fokus ke programming. Memasuki tahun kedua, sudah ada banyak tantangan dari berbagai tugas kuliah yang diberikan, jadi sudah tidak bosan lagi. Tapi masih ada juga sedikit jejak yang saya lakukan di bidang security setelah itu (misalnya ini).

Setelah itu saya banyak terlibat berbagai kegiatan lain, misalnya mengurus TOKI, ikut jadi programmer pengolah data di ITB, ikut proyek dosen, jadi asisten di universitas swasta, memberi les, dsb). Sedangkan Deny mengambil jalan hidup lain (silakan tanya sama Deny buat yang ketemu, nggak akan diceritakan di sini). Okta sekarang jadi expat di Timur Tengah.

Baru tahun 2014 saya mulai terlibat lagi di dunia security. Kerjanya hanya part time pentesting (sampai sekarang masih part time). Part time di sini artinya: dari Senin sampai Jumat saya kerja di perusahaan di Thailand sini menjadi programmer yang tidak ada hubungannya dengan produk security dan cuma di malam hari/weekend saya melakukan pentesting.

Tahun 2016 ikutan ngajak Deny untuk ikutan Flare On dan Pentesting. Ternyata ilmu Deny di bidang RE dan pentesting masih tajam walau tidak pernah khusus pentesting. Contohnya kelakuan hardcorenya ketika mengerjakan RHME (Hardware CTF): reversing statik assembly AVR (bukan kode C hasil decompiler), pake listing HTML dari IDA, di handphone, di kereta pulang sambil berdiri (dan flagnya ketemu).

Kami minta maaf buat yang dulu merasa kesal dengan kelakuan kami. Kami juga mengucapkan terima kasih untuk Pak Riza dan para dosen lain yang masih memberi kesempatan pada kami untuk bertobat dari kenakalan kami dan bisa meneruskan di ITB.

Setelah lama lulus, dapet cerita dari Tintin, ternyata kelakuan kami dulu sangat menginspirasi dia untuk belajar security. Bahkan Tintin sekarang sudah mengambil S2 security dari Carnegie Mellon University. Syukurlah, ternyata yang kami lakukan nggak sepenuhnya berefek negatif untuk orang lain :).

Kalau dari ingatan Tintin, ada banyak hal iseng lain yang kami lakukan, tapi karena saya nggak ingat, saya tidak ceritakan di sini. Walau mungkin dulu sengaja saya lupakan karena terlalu iseng. Seingat saya sih saya nggak pernah berniat jahat.

Tapi saya harap yang kami lakukan di atas tidak ditiru mentah-mentah. Jangan menghack kampus, sudah ada banyak cara lain yang legal untuk belajar security:

  • Ada bug bounty
  • Ada berbagai CTF
  • Ada berbagai sertifikasi yang bisa diambil

Hal yang patut ditiru adalah:

  • Semangat membaca artikel teknis
  • Semangat mencoba berbagai hal teknis secara umum
  • Semangat belajar programming

Kalau bisa ketemu orang atau kelompok yang membantu bertumbuh akan lebih baik lagi.

Happy Hacking