Josua M Sinambela, M.Eng

Tulisan ini merupakan lanjutan dari sini

Penulis akan mencoba mengupas terkait validitas penyataan beberapa “ahli” yang mengklaim server KPU berada di Luar Negeri (LN). Polemik terkait hasil analisa beberapa “ahli” ini ternyata menjadi perdebatan panjang di berbagai group dan forum-forum, bahkan menjadi viral dibahas dibanyak media elektronik, dan sepertinya belum ada yang mencoba meluruskan hasil analisa para ahli yang penulis kategorikan “premature” tersebut. Ini juga baiknya menjadi pembelajaran bagi banyak media untuk perlu melakukan crosscheck dengan ahli ahli lain yang lebih kredibel dan berpengalaman dibidangnya.

Diantara para “ahli” tersebut ada yang menyimpulkan jika server SiREKAP KPU berada di Luar Negeri dengan hanya melakukan resolving DNS menggunakan utility nslookup dan menemukan IP yang tercatat sebagai Provider di LN. Kemudian ada juga “ahli” yang mencoba menggunakan tools shodan untuk verifikasi lokasi IP yang ditemukan. Kemudian sang “ahli” menggunakan tools “gobuster” dan googling untuk menganalisis lokasi server KPU tersebut. Para “ahli” tersebut juga mencoba menganalisa Name Server (NS) dan Mail Exchange (MX) dengan maksud menelusuri lokasi server KPU.
Server yang menjadi objek pemeriksaan sang “ahli” dalam presentasinya ada 2 (dua) yakni
sirekap-web.kpu.go.id dan pemilu2024.kpu.go.id, kemudian sang “ahli” menyimpulkan jika Server berada di Singapore, Prancis dan bahkan China.
Si “ahli” juga belum menjelaskan sama sekali tingkat validitas temuannya tersebut. Tetapi dari pernyataan pada media sudah merasa yakin dengan hasil temuannya dan disampaikan berbagai media yang ikut memviralkan kesimpulan tersebut.

Hmm sebaiknya penulis mulai cerita darimana dulu ya agar para pembaca lebih mudah memahami maksud tulisan ini ? sebentar ….. saya coba dari topik satu ini dulu.

Prediksi Serangan pada Server KPU.

Pada H-1 sebelum pencoblosan tepatnya 13 Februari 2024 pukul 20.00 WIB, kebetulan penulis dan teman teman komunitas di DFIS (Digital Forensic & InfoSec Community) mengadakan FGD dengan Tema “Mengawal Hasil Pemilu 2024”.

Pada FGD tersebut, kami komunitas DFIS sudah mewanti-wanti berbagai potensi permasalahan dan kecurangan pada SiREKAP KPU dan bagaimana peran Komunitas TI dalam mengawal hasil pemilu 2024. Di saat diskusi ada juga peserta yang menanyakan terkait kemungkinan KPU bisa diserang secara DDoS (Distributed Denial of Services). Ternyata salah satu peserta ada yang menginformasikan secara privat kepada penulis bahwa si peserta sudah menguji serangan Stress Testing/Load Testing atau DDoS menggunakan berbagai botnet pada salah satu sistem KPU dan berhasil melumpuhkan server KPU tersebut meski sudah teridentifikasi dilindungi WAF yang disediakan Provider. Diinformasikan bahwa pengujian itu dilakukan pada H-1 dan hanya diset berlangsung sekitar 2 menit.

Penulis masih ingat jika saat itu sempat mengulas IP IP Server yang digunakan oleh SiREKAP KPU, termasuk sistem SSO yang digunakan pada waktu tersebut yang masih menggunakan salah satu IP provider Cloud di Jakarta. Permasalahan akses ke Situs KPU dan SiRekap juga sudah diprediksi sejumlah peserta FGD yang bakal terjadi kala itu. Tidak lupa kami menyerukan kepada penggiat Keamanan IT di Indonesia untuk tidak mengganggu sistem KPU/Pemilu mulai hari H hingga perhitungan selesai, tidak perlu melakukan assessment kepada situs KPU maupun jaringan KPU. Penulis sendiri sudah sempat menyatakan bahwa meskipun tidak diganggu, sudah bakal terjadi berbagai permasalahan pada sistem SiREKAP KPU berdasarkan analisis yang sudah dijabarkan pada tulisan part 1 sebelumnya.

Pada hari H, hal yang tidak diinginkanpun terjadi, meski masih sesuai prediksi komunitas saat FGD sebelumnya, bahwa akan terjadi berbagai permasalahan pada sistem SiREKAP dan server KPU. Pada waktu pencoblosan (07.00-13.00 WIB tanggal 14 Februari 2024), terjadi serangan pada Server KPU (situs www.kpu.go.id), sehingga tidak bisa diakses dari internet dan dari beberapa provider merasakan sangat lambat. Pada waktu penghitungan suara serentak (sekitar pukul 13.00 – malam hari), Server SiREKAP (diantaranya SSO.kpu.go.id maupun sirekap-web.kpu.go.id tidak bisa diakses, diprediksi akibat load server yang terlalu banyak mengakses secara bersamaan oleh para pengguna SiREKAP atau kemungkinan terjadi serangan DoS/DDoS pada server/jaringan SiREKAP. Berdasarkan data informasi internal KPU, pengguna dari satu kota saja, bisa mencapai belasan ribu akun/pengguna KPPS yang harus mengakses SiREKAP secara bersamaan. Bisa dibayangkan jika seluruh KPPS daerah/kota secara nasional melakukan akses bersamaan terhadap server SiREKAP, jadi sudah diprediksi akses aplikasi ini akan penuh masalah dan “drama”. Sejak dikembangkan tahun 2020, diberbagai kegiatan uji coba secara massal dari penelusuran beberapa berita, siREKAP sudah sering mengalami berbagai kendala khususnya terjadi trouble saat digunakan bersama sama seperti disebut di berita disini. Dan kejadian yang sama ini terulang hingga tahun ini (tahun 2024).

Pada malam hari setelah pencoblosan hingga menjelang pagi hari (H+1), SiREKAP mulai dapat diakses meski dengan berbagai kendala disisi user. Pada H+1 beberapa host server SiREKAP terdeteksi sudah menggunakan alamat IP dan host yang berbeda dengan sebelumnya.

IP kedua CNAME (sirekap-api dan sirekap-web KPU) per 13 Februari 2024 (sebelum hari H) tersebut diatas masih menggunakan IP Address Alibaba Cloud Indonesia (ALICLOUD-ID). Alamat IP address public untuk CNAME ini juga selalu tetap/sama/satu yakni 149.129.208.159 meskipun diakses dari berbagai provider dibelahan dunia dan teridentifikasi berlokasi di Indonesia dari hasil traceroute. Sehingga dapat disimpulkan IP ini masih bersifat Unicast (Unicast IP) dan berlokasi di satu tempat saja (di Alicloud-ID Jakarta).

$ host er2cfqghcwrbttxualrqgeghb87yybgy.aliyunwaf1.com
er2cfqghcwrbttxualrqgeghb87yybgy.aliyunwaf1.com has address 149.129.208.159
$ host tsqclwvmghlwojwazlc3fyn14itwktci.aliyunwaf2.com
tsqclwvmghlwojwazlc3fyn14itwktci.aliyunwaf2.com has address 149.129.208.159

Server dengan IP Unicast sangat rentan terhadap DDoS dan kurang reliable karena tidak ada fitur redundancy/load balancing server di lokasi berbeda, sehingga semua paket serangan (flooding) yang berasal dari berbagai botnet akan menumpuk di satu titik lokasi. Meskipun sebenarnya sudah diproteksi atau perlindungan berupa aplikasi WAF/Reverse Proxy/Filtering, tetap tidak akan tertangani jika paket yang tergenerate melebihi kapasitas kemampuan titik lokasi tersebut. Inilah salah satu penyebab Server SiREKAP KPU pada saat pencoblosan (Hari H) tanggal 14 Februari 2024 mengalami gangguan akibat load akses yang sedemikian besar (akses bersamaan operator dan admin SiRekap seluruh indonesia) ditambah adanya serangan DoS/DDoS.

Pada saat pengecekan tgl 13 Feruari (H-1) beberapa host server lain seperti sirekap-obj-data.kpu.go.id dan beberapa API lainnya juga kondisinya sama masih menggunakan Unicast IP yang berlokasi di AliCloud Jakarta

Dihari berikutnya, belajar dari pengalaman bahwa server KPU mengalami kegagalan berfungsi melayani di hari H, Tim IT KPU dibantu berbagai konsultan dari lembaga lain tampaknya memutuskan untuk melanggan layanan proteksi DDoS dan CDN yang bersifat Anycast (Anycast IP) melalui Provider Cloud Alibaba, sehingga pemetaan subdomain KPU yang menjadi backend SiREKAP berubah alamat CNAME menjadi seperti berikut:

Domain alyunddos0010.com merupakan ciri penggunaan layanan keamanan proteksi DDoS di Alibaba Cloud. Sedangkan cdngslb.com merupakan salah satu ciri penggunaan layanan CDN Server Load Balancer (SLB). Kedua layanan ini sudah mendukung Anycast IP. Untuk layanan CDN/SLB alamat IP Alias/CNAME setiap host server ini bisa berbeda ketika diakses dari berbagai negara, seolah olah akan dihandle oleh banyak server yang memiliki nama/host yang sama, baik dengan IP yang sama maupun berbeda IP. Setiap request dari setiap pengguna akan diarahkan melalui proses routing ke host server terdekat. Jika menghadapi serangan DDoS, paket serangan yang umumnya merupakan flooding request menggunakan banyak hingga ribuan bahkan ratusan ribu botnet dari selurh penjuru internet ( berasal berbagai negara), maka request tersebut menjadi terdistribusi ke banyak lokasi/server, sehingga relatif lebih mudah atau dapat diatasi. Sangat berbeda halnya ketika masih menggunakan server dengan Unicast IP yang ditangani di satu server dan satu Lokasi saja yang biasanya akan menimbulkan bootleneck/overload trafik ataupun resource server yang exhausted.

Dari skema diatas, dapat dilihat bahwa IP yang mungkin dideteksi dengan tools sejenis nslookup, whois, shodan, dan berbagai tools DNS lainnya hanyalah IP Anti-DDoS atau Traffic Manager yang disetting pada DNS dan Network Scrubbing Center. Sedangkan Origin Server (Server Backend Aslinya) akan tetap tersembunyi atau tidak terpublikasi. Dengan teknik teknik forensic analisis tertentu seperti OSINT, History DNS dst sebenarnya IP Backend ini dapat dideteksi. Penulis sudah menemukan beberapa backend server SiRekap KPU yang saat ini digunakan aktif sebagai backend aplikasinya (sirekap-api, sirekap-web dst). Tetapi untuk sementara ini tidak untuk dipublikasikan karena sangat rentan jika informasi tersebut disalahgunakan atau menjadi target serangan seperti DDoS dst. Penulis bisa memastikan jika hampir semua Backend Server (Origin Server) yang digunakan mensupport SiRekap KPU berada di Datacenter/Cloud Provider Indonesia.

Kondisi pemanfaatan layanan CDN GSLB juga diberlakukan pada publikasi tabulasi SiRekap KPU melalui laman https://pemilu2024.kpu.go.id. Server pemilu2024.kpu.go.id sudah menggunakan layanan CDN GSLB dari Alibaba Cloud yang sudah mendukung Anycast IP.

Jika diakses dari berbagai negara untuk host pemilu2024.kpu.go.id maka akan mendapatkan masing masing IP Alias/CNAME pemilu2024.kpu.go.id.w.cdngslb.com yang berbeda seperti ditunjukkan gambar dibawah

Alasan KPU menggunakan layanan Scrubbing/AntiDDOS dan CDN dari Alibaba Cloud sebenarnya mudah dipahami, tim developer mereka sudah menggunakan layanan Cloud Provider tersebut sejak awal pengembangan aplikasi SiREKAP (sejak tahap Development hingga Staging). Dari skema dan dokumentasi Layanan Proteksi DDoS dan CDN GSLB dari Alibaba Cloud, dapat disimpulkan bahwa jika Origin Server (Backend Server asli) berada di Alibaba Cloud (AliCloud-ID), maka akan memiliki performance yang lebih baik terkait Interconnection Jaringan yang memanfaatkan Private Connection.

Jika KPU menggunakan layanan Scrubbing/AntiDDOS dan CDN dari cloud provider lain, seperti CloudFlare, Imperva atau lainnya, maka dimungkinkan terjadi bootleneck di Jaringan Internet diantara Origin Server/Backend Server dengan Cloud penyedia Scrubbing/AntiDDoS dan CDN..

Di Indonesia sendiri, sepengetahuan penulis belum ada provider “lokal” yang bisa menyediakan layanan Scrubbing/AntiDDoS dan CDN yang infrastrukturnya tersedia banyak lokasi di belahan dunia.

Semoga bermanfaat.

Salam.

Semoga tulisan ini dapat membantu mencerahkan kepada masyarakat terkait berita dan postingan di media sosial yang mempermasalahan pada sistem SiREKAP KPU bahkan ada yang ingin menuntut diadakannya “Audit TI dan Digital Forensik SiREKAP”.

Jauh hari sebelum pemilu (sekitar Desember 2023 – awal Januari 2024), penulis dan beberapa teman di Group DFIS (Digital Forensic & InfoSec Community) sudah membahas adanya permasalahan di sistem aplikasi SiREKAP KPU. Pada saat itu, KPU sedang gencar gencarnya mencoba melakukan sosialisasi dan uji coba aplikasi SiREKAP di berbagai daerah. Mereka menggunakan SiREKAP versi Staging 2.4-STG. Lucunya saat itu sebenarnya KPPS yang menjadi bagian pengguna/operator resmi dari SiREKAP belum dilantik secara resmi. Secara umum KPPS yang akan bertugas baru akan dilantik pada akhir Januari 2024, jadi sosialisasi aplikasi SiREKAP sebelum itu tentu dipertanyakan efektivitasnya untuk KPPS.

Secara teknis, penulis kebetulan menyempatkan melakukan static/dynamic analysis berupa reverse engineering hingga simulasi aplikasi hingga analisis trafik terhadap aplikasi SiREKAP yang kala itu masih versi Staging 2.4-STG (versi ini hanya di distribusikan di internal KPU). Sebelumnya juga ada versi Aplikasi SiREKAP 2020 (1.9.5) yang digunakan saat pilkada tahun 2020 (bisa diambil dari playstore) yang bisnis prosesnya kurang lebih sama, hanya terdapat penambahan beberapa fitur/activity. Dari proses static analysis terhadap kedua versi aplikasi SiREKAP tersebut, dengan mudah diketahui bahwa pengembang aplikasi (tim developer) ternyata berasal dari teman teman Informatika ITB, ini terlihat jelas dari berbagai domain dan nama host server yang digunakan sebagai backend dan API aplikasi tersebut (mengandung domain informatika.site).

Pada akhir Januari 2024, KPU akhirnya mempublikasikan versi SiREKAP 2024 Mobile di Google Playstore. Versi Awal terpublish merupakan SiREKAP 2024 versi 2.30, disusul update/pembaharuan versi 2.32 dikarenakan banyak trouble saat mulai dipasang diberbagai jenis HP oleh anggota KPPS yang baru dilantik, terakhir menjelang pemilu versi 2.41 (Versi ini yang digunakan pada hari H pemilu, versi ini di publish 9 Februari 2024). Aplikasi SiREKAP 2024 versi 2.41 yang paling banyak digunakan oleh KPPS untuk menginput data ke Server KPU. Di aplikasi versi ini jugalah banyak kesalahan dalam konversi angka/jumlah suara dari foto yang diinputkan oleh petugas KPPS.

Pada versi SiRekap 2024 mulai versi 2.30 terdapat fitur tanda tangan digital yang rancang enkripsinya menggunakan kunci & CA (Certificate Authority) BSSN. Di versi SiREKAP 2024 staging (2.4-STG) sebelumnya, tidak ditemukan ada fitur tandatangan digital dengan kunci/CA dari BSSN, sehingga dipastikan fitur ini masih baru dikembangkan menjelang hari H. Dari timeline tersebut sebenarnya sudah bisa diprediksi bahwa aplikasi ini tidak melalui proses pengujian yang ideal untuk sebuah aplikasi mengawal event sebesar Pemilu.

Sekilas keamanan SiREKAP Mobile
Jika ingin membahas keamananannya, menurut hemat penulis masih sangat jauh dari cukup. Dari hasil static analysis yang penulis lakukan, ditemukan jika keystore password yang digunakan masih default menggunakan kunci signer public dan kunci private (P12) bawaan Android development tools. Seharusnya pengembang aplikasi SiREKAP KPU menggunakan kunci keystore signer khusus developer, untuk dapat membedakan hasil pengembangan versi official lembaga KPU tersebut atau orang lain. Resikonya, dimungkinkan ada pihak lain yang membuat package aplikasi yang mirip dan disalahgunakan. Misalnya untuk mengelabui pada operator di level KPPS/PPK (se-sederhana kasus kasus undangan/tagihan apk).

Selain itu proteksi keamanan internal aplikasi SiREKAP Mobile ini masih relatif mudah dibypass, karena selain proses otentikasi hanya memanfaatkan user password saja dan masih dengan mudah emulasikan pada emulator. Meski di versi versi sebelumnya ada fitur aktivasi 2FA dengan Authenticator Eksternal, ternyata fitur itu tidak digunakan sama sekali di versi terakhir saat pemilu.
Contoh lainnya pada keamanan di level aplikasi, SiREKAP KPU mewajibkan proteksi keamanan seperti wajib aktivasi screen lock dan fingerprint, tetapi rupanya dengan membypass urutan activity aplikasinya, penulis dengan mudah menjalankannya tanpa harus aktivasi security (pola/pin) dan fingerprint.

Kenapa aplikasi SiREKAP banyak melakukan kesalahan mengkonversi angka/jumlah suara tertera di pleno C1?

SiREKAP menggunakan builtin modul fungsi OCR (Optical Character Recognition) pada aplikasinya menggunakan library opencv dan pengenalan karakter tulisan dengan MNIST Dataset, SiRekap tidak menggunakan API OCR luar yang biasanya cloud based. Sebenarnya ada tersedia banyak pilihan API untuk fungsi OCR yang berbasis cloud yang sangat baik hasilnya, tetapi relatif cukup mahal jika akan digunakan utk kegiatan sejenis pemilu yg jumlah dokumen/gambarnya sangat banyak, disamping itu akan membutuhkan koneksi internet yg stabil. Mungkin saja itu juga pertimbangan tim developer SiREKAP KPU sehingga menggunakan module OCR sendiri.

Dari analisis penulis, kemampuan teknologi OCR yg mengenali angka angka difoto pleno C1 yg digunakan pada siRekap sebenarnya sudah cukup baik jika cara penulisan oleh panitia kpps di form tersebut sesuai dengan aturan yg dikeluarkan KPU yang tercantum pada Panduan Sirekap Mobile. Dari pengamatan penulis bahwa mayoritas kesalahan konversi karakter angka tersebut diakibatkan cara/teknik penulisan di lembar Pleno C1 yang tidak sesuai aturan. Kemungkinan petugas KPPS yang menuliskan kelupaan atau kurang teliti jika harus mengikuti aturan penulisan agar aplikasi siRekap dapat mengkonversi tulisan angka tersebut ke dalam bentuk angka digital. Tetapi bisa juga karena sudah kelelahan atau bahkan hampir putus asa akibat aplikasi siRekap tidak bisa login saat servernya sempat down hampir seharian sejak pagi hari di saat pencoblosan.

Berikut contoh kesalahan penulisan petugas KPPS pada lembar pleno C1

Permasalahan ini juga diperparah saat IT KPU mengubah cara penulisan di form Pleno di detik detik terakhir menjelang pemilihan. Jadi saat sosialisasi sebelumnya sebelumnya penulisan form pleno mengunakan kotak kotak meniru angka digital, tetapi menjelang pemilu kebijakan aturan tersebut dirubah IT KPU menjadi penulisan biasa (menyesuaikan dataset mereka dari sebelumnya bukan MNIST). Penulis sudah melakukan pengecekan cek di versi SiRekap 2.4 (STG) yakni yang digunakan saat sosialisasi sejak Desember hingga Januari 2024, versi ini belum menggunakan dataset MNIST (tulisan tangan biasa). Sejak versi 2.30-sekarang baru menggunakan MNIST. Itu sebabnya banyak anggota KPPS yang keliru cara penulisan di lembar form pleno, karena sosialisasinya berbeda dengan implementasi saat digunakan secara saat perhitungan suara.

Selain menggunakan teknologi OCR (Optical Character Recognition), aplikasi sirekap juga dilengkapi fitur OMR (Optical Mark Recognition), yang seharusnya bisa dijadikan alternatif pembacaan jumlah suara dalam bentuk tanda lingkaran pada kolom nomor nomor yg disediakan. Hanya saja di aplikasi SiREKAP sepertinya belum mamfaatkan informasi tersebut, dan hanya menggunakan OCR sebagai dasar pendeteksi jumlah suara.

SiREKAP Offline Mode dan Online Mode
SiREKAP dapat dijalankan secara Offline Mode, asal sudah terotentikasi terlebih dahulu secara online, maka saat menjalankan aplikasi berikutnya bisa tanpa harus terhubung internet. Saat menjalankan offline Mode, SiREKAP bisa melakukan aktivitas mengisi data yang diperlukan dan dokumentasi/ambil gambar pleno C1 dst. Saat Online atau terhubung internet (Triggernya saat aplikasi berhasil ping google.com dan ), kemudian SiREKAP akan langsung otomatis melakukan sinkronisasi (Upload Data) ke Server KPU.
Hanya saja proses Offline Mode dan Online Mode itu sering mengakibatkan permasalahan pada sesi aplikasi, sehingga user dihadapkan aplikasi restart dan diminta otentikasi ulang kembali.

Dalam implementasi sistem informasi yang baik, idealnya para pengembang sistem harus mampu memperkirakan dan mengantisipasi input dari setiap penggunanya, baik yang sesuai aturan maupun belum sesuai aturan. Seperti penulisan angka jumlah yangg memenuhi kriteria, maupun yang diluar dari kriteria yang seharusnya. Sehingga hasilnya tetap dapat diprediksi atau paling tidak dibatasi jika terdapat kesalahan. Misalnya dengan adanya prosedur verifikasi bertahap sebelum langsung terpublish dalam tabulasi. Pada aplikasi SiREKAP KPU, sebenarnya ada tahapan flagging jika proses konversi OCR dari foto pleno C1 atau pembacaan jumlah suara terjadi kesalahan. Operator KPPS yang menginputkan data dan photo pleno C1 diberi opsi untuk memberi flag (tanda X) dan otomatis menjadi berwarna merah jika hasil konversi jumlah suara oleh aplikasi berbeda dengan jumlah suara di foto pleno C1. Operator KPPS ini memang tidak diberi pilihan untuk langsung mengedit jumlah yang keliru tersebut. Jadi hasil yang masuk ke aplikasi murni terjemahan teknologi OCR yg digunakan, dan jika ada keliru maka hanya dapat diberi penanda (flag) artinya perlu dikoreksi. Sedang yang akan mengoreksi nanti adalah petugas/admin KPU yang ditugaskan dilevel yang lebih tinggi (biasanya di level Kota/Kabupaten) melalui aplikasi sirekap-web (Aplikasi SiREKAP berbasis Web). Nah disinilah salah satu bootleneck atau terjadi antrian proses koreksi. Koreksi sirekap-web tidak bisa secepat yang diinginkan para KPPS atau masyarakat yang ikut memonitor, mungkin karena jumlah yang harus dikoreksi juga sangat banyak, mengakibatkan seolah olah data tersebut “disengaja” oleh KPU yang berujung menjadi polemik di media.

Harusnya jika developer atau pengembang dapat mengantisipasi dengan adanya tahapan verifikasi sebelum di publish ke tabulasi dan berbagai filter kemungkinan kesalahan input atau konversi angka (misal menetapkan jumlah total maximum suara tiap TPS yang sudah terprediksi sebesar 300 plus tambahan), maka tidak akan menimbulkan polemik berkepanjangan berkaitan kesalahan perhitungan dan bahkan tuduhan tuduhan kecurangan memanfaatkan SiREKAP. Berdasarkan analisis penulis, publikasi SiREKAP melalui laman situs pemilu2024.kpu.go.id dipastikan tidak melalui tahapan tahapan verifikasi dan filtering kesalahan lebih dahulu, terlihat dari banyaknya input atau jumlah suara paslon yang tidak logis. Dan kesalahan ini sudah diakui oleh KPU beberapa waktu yang lalu.

Kembali ke laptop. Jadi untuk menjawab pertanyaan mungkinkah dilakukan Audit TI dan Forensik Digital terhadap SiREKAP KPU? Audit TI dan Forensik Digital pada dasarnya adalah dua hal yang sangat berbeda.
Menurut penulis perlu diperjelas secara spesifik tujuan dari Audit TI maupun Forensik Digital yang dimaksud. Audit TI mungkin bisa dilakukan utk mendeteksi persiapan sistem IT pendukung kegiatan Pemilu, apakah sudah disiapkan secara professional atau malah asal asalan bahkan SKS (Sistem Kebut Semalam ala Mahasiswa). Target Audit TI bisa dimulai dari tata kelola IT (IT Governance) hingga pengembangan berbagai aplikasi pendukung pemilu (silon, siakba, sirekap dst). IT Governance termasuk pemilihan partner pengembangan sistem, SDM TI hingga penyedia infrastruktur teknologi informasi. Khusus pengembangan aplikasi, idealnya sudah melalui proses pengujian pengujian seperti software testing, load testing hingga penetration testing. Apakah pada aplikasi tersebut sudah dilakukan, dan bagaimana metodologi pengujian beserta hasilnya. Tujuan pengujian pengujian tersebut agar diketahui dan diprediksi atau diantisipasi segala kendala maupun kelemahan kelemahan saat implementasi dilapangan.

Terkait rencana pemeriksaan digital forensik pada sistem SiREKAP, penulis pribadi tergelitik ingin mengetahui apakah objective atau tujuan pemeriksaannya. Pada setiap pemeriksaan digital forensik harus sudah sudah jelas tujuan spesifik pemeriksaannya. Untuk aplikasi khusus seperti SiREKAP tentu belum diketahui framework pemeriksaan forensiknya karena teknologi ataupun sourcenya tidak bersifat terbuka. Sehingga yang mungkin digunakan adalah metode metode best practice teknologi aplikasi sejenis. Keberhasilan pemeriksaan digital forensik terhadap sebuah sistem juga dipengaruhi oleh kesiapan sistem aplikasi dan lembaga yang mengelola aplikasi tersebut untuk dilakukan pemeriksaan forensik. Istilah umumnya adalah digital forensic readiness. Banyak lembaga khususnya pemerintahan atau lembaga negara yang belum mencapai level “digital forensic readiness” yang mumpuni, sehingga data yang dibutuhkan tidak optimal ketika menghadapi pemeriksaan digital forensik. Hal ini yang biasanya membuat banyak kasus kasus siber seperti kebocoran data atau insiden keamanan siber lainnya tidak mungkin terungkap.

Contohnya pada SiREKAP KPU, secara teknis idealnya photo yang dihasilkan sudah berisikan metadata yang memadai, seperti lokasi (sekitar TPS), waktu Foto, Jenis Kamera/HP, dst yang bisa menunjukkan sumber dari foto tersebut. Tetapi ternyata pada aplikasi SiREKAP informasi ini tidak disertakan pada setiap foto pleno yang dikirimkan. Padahal informasi metadata tersebut bisa digunakan sebagai petunjuk atau bahkan validasi data yang di upload oleh operator atau pihak lain

Contoh lainnya, Log Akses pada setiap Environment Server seperti Log Web Server, Log DB Server, Log Api yang digunakan, belum tentu siap atau tersedia untuk dilakukan analisis, Log ini idealnya selalu tercatat pada media penyimpanan sejenis backup secara periodik dengan dilengkapi dengan catatan nilai hash/cek integritas. Sehingga ketika terjadi incident atau diperlukan investigasi kasus siber dapat langsung digunakan untuk menjelaskan insiden tersebut. Hal hal seperti inilah yang menjadi kendala paling sering terjadi saat penanganan insiden siber dan pembuktian secara forensik digital.

Jadi tujuan seperti apa yang mungkin dilakukan pemeriksaan secara digital forensik pada SiREKAP?
Berdasarkan analisis penulis, sistem sejenis SiREKAP ini bisa saja dengan mudah bisa mendeteksi siapa saja yang melakukan editing (level user KPU ataupun KPPS) atau pihak yang mengupload photo/data yang sengaja keliru/salah. Atau sekedar siapa saja akun akun yang mengupload data tanpa dengan sop/prosedur yang baku. Misalnya akun KPPS yang tidak memberi tanda/flag suatu data perlu dikoreksi meskipun hasil konversinya sebenarnya masih salah dst.

Tetapi jika penulis ditanya, apakah dengan pemeriksaan digital forensik pada SiREKAP dapat ditemukan bukti adanya kecurangan? Sepertinya akan akan sulit terjawab, selain harus dijabarkan bentuk kecurangan yang dimaksud yang akan menjadi tujuan pemeriksaan, juga faktor kesiapan lembaga KPU dan para Stakeholder (pengembang aplikasi/vendor/penyedia provider) yang belum pada level digital forensic readiness yang memadai untuk dilakukan pemeriksaan forensik digital, ditambah faktor kecurangan yang masih sangat terbuka dapat dilakukan tanpa keterlibatan KPU dan para stakeholder pengembang aplikasi, mengingat beberapa kelemahan dan permasalahan SiREKAP yang sudah diungkap diatas.

(update 22 Februari 2024 )

– Penambahan gambar/script yang menunjukkan pengenalan karakter tulisan OCR dengan Dataset MNIST, penambahan deskripsi perubahan metode pengenalan karakter dari sebelumnya tulisan bentuk digital (kotak kotak) menjadi tulisan biasa pada lembar pleno.

(bersambung ke part 2)

Tergelitik ingin membahas terkait beredarnya Data Penduduk Indonesia khususnya data penduduk se-Provinsi DIY yang berasal dari DPT Pemilu 2014 di forum underground. Menanggapi kicauan (media social) dan pernyataan Komisioner KPU Viryan Azis di berbagai media seperti di kompas (1) dan (2), di detik (1) dan di blog pribadinya saya akan mencoba membeberkan temuan saya sebagai salah satu pengguna internet yang sempat mendownload keseluruhan dokumen yang diupload oleh pelaku di forum tersebut, dan kebetulan saya memang cukup memahami bagaimana melakukan forensik digital atau analisis terhadap dokumen-dokumen tersebut.

Informasi beredarnya Data Penduduk Indonesia diketahui awalnya dari akun Twitter underthebreach pada 21 Mei 2020 seperti berikut :

Twitter Akun underthebreach juga memposting gambar sumber data yang diperolehnya yakni dari sebuah postingan di forum Underground per tanggal 20 Mei 2020, forum ini beberapa waktu lalu juga sudah pernah mempublikasikan data pengguna Tokopedia dan Bukalapak seperti berikut:

Kemudian dalam waktu tidak lama media mencoba meliput dan mulai mempertanyakan kebenaran data tersebut kepada KPU. Dan KPU sepertinya tanpa melakukan verifikasi secara komprehensif langsung membantah jika data pemilu tersebut tidaklah bocor, tetapi data tersebut bersifat publik. Seperti pernyataan Komisioner KPU Viryan Azis di berbagai media seperti di kompas (1) dan (2), di detik (1) dan di blog pribadinya.

Saya akan membahas lebih detil satu persatu bagian dengan mengutip pernyataan Komisioner KPU di blog pribadinya, karena tampaknya pernyataannya diblog tersebut lebih lengkap daripada yang ada di media kompas/detik atau social media lainnya. Sebenarnya saya juga sudah membahas di status FB saya pada hari informasi di twitter tersebut beredar. Bisa dibaca di sini:

Judul postingan di Blog Pribadi Komisioner KPU Viryan Azis diposting per 23 Mei 2020 seperti berikut:

Sang Komisioner tersebut berkesimpulan sesuai judul bahwa DPT Pemilu 2014 tidak bocor, alasannya akan saya bahas dibawahnya :

Mau benaran hanya 187jt atau 200jt bagi saya yang data pribadinya ada disana tidak ada bedanya Pak Komisioner KPU !!!. Hacker atau Leaker sering sengaja melebih-lebihkan informasinya agar mencari perhatian, tidak perlu dikomentari bagian yang belum dileaked, tetapi jika memang data ternyata itu ada (entah 187/200jt), harusnya sang komisioner harus lebih berhati hati, bukan malah langsung membantah jika data itu pasti tidak benar tanpa melakukan investigasi menyeluruh secara professional. Yang menggelikan, sang komisioner belum tahu seperti apa data yang di leaked tetapi sudah mengklaim bahwa data itu adalah data terbuka untuk publik. Sejak kapan data pribadi berupa plain NIK/KK/Tgl Lahir/alamat/status data penduduk 2.3 juta se-provinsi DIY merupakan data terbuka ? Dasar hukumnya apa? UU Adminduk (2006) menyatakan itu data pribadi yang harus dijaga kerahasiaannya.

Detilnya saya saya kutipkan berikut ini :

Adapun mengenai data pribadi, pengertiannya dapat ditemukan dalam Undang-Undang Nomor 23 Tahun 2006 tentang Administrasi Kependudukan (“UU Adminduk”) sebagaimana yang telah diubah dengan Undang-Undang Nomor 24 Tahun 2013 tentang Perubahan Atas Undang-Undang Nomor 23 Tahun 2006 tentang Administrasi Kependudukan (“UU 24/2013”). Pasal 1 angka 22 UU 24/2013 berbunyi:   Data Pribadi adalah data perseorangan tertentu yang disimpan, dirawat, dan dijaga kebenaran serta dilindungi kerahasiaannya.Perlindungan atas Privasi dan Data Pribadi Masyarakat Secara konstitusional, Negara melindungan privasi dan data penduduk masyarakat. Pasal 28G ayat (1) Undang-Undang Dasar Negara Republik Indonesia Tahun 1945(“UUD 1945”) berbunyi:

Setiap orang berhak atas perlindungan diri pribadi, keluarga, kehormatan, martabat, dan harta benda yang di bawah kekuasaannya, serta berhak atas rasa aman dan perlindungan dari ancaman ketakutan untuk berbuat atau tidak berbuat sesuatu yang merupakan hak asasi. Senada dengan Pasal 28G ayat (1) UUD 1945, Pasal 2 UU Adminduk mengatur bahwa:   Setiap Penduduk mempunyai hak untuk memperoleh:

1. Dokumen Kependudukan;
2. pelayanan yang sama dalam Pendaftaran Penduduk dan Pencatatan Sipil;
3. perlindungan atas Data Pribadi;
4. kepastian hukum atas kepemilikan dokumen;
5. informasi mengenai data hasil Pendaftaran Penduduk dan Pencatatan Sipil atas dirinya dan/atau keluarganya; dan
6. ganti rugi dan pemulihan nama baik sebagai akibat kesalahan dalam Pendaftaran Penduduk dan Pencatatan Sipil serta penyalahgunaan Data Pribadi oleh Instansi Pelaksana.

Data yang leaked memang rata rata formatnya PDF, tetapi dari analisa forensik digital yang saya lakukan terhadap metadata sebagian besar dokumen yang leaked, umumnya data tersebut berasal atau didownload dari aplikasi web KPU yakni pdf.kpu.go.id. Silahkan perhatikan data data berikut yang saya cuplik dan tunjukkan metadatanya

Bahkan beberapa filename data berformat pdf masih menggunakan title yang berasal dari page HTML yang menunjukkan berasal dari situs pdf.kpu.go.id seperti ditunjukkan dibawah ini. File file pdf ini di produce atau dihasilkan dari web pdf.kpu.go.id menggunakan tools/plugin wkhtmltopdf diwebsitenya.

Jika ingin ditelusuri, apakah website pdf.kpu.go.id benar ada pada saat dokumen tersebut di download? Jawabnya Ya, bisa kita lihat dari screenshoot archive.org berikut ini :

Meskipun saat ini Web pdf.kpu.go.id sudah tidak aktif, tetapi berdasarkan halaman archive tersebut terdeteksi bahwa situs pdf.kpu.go.id memang pernah aktif pada periode 2012, 2013, 2017. Ada history rekaman archive pada bulan November 2013 pada saat dokumen dokumen tersebut di download.

Saya juga membandingkan dengan dokumen DPT/DPS lain yang diproduksi oleh aplikasi tersebut yang beredar diinternet. Seperti hasil pencarian dibawah ini contoh salah satu DPT dari kota kelahiran saya.

Silahkan menilai sendiri benar tidaknya kesimpulan kedua dari sang Komisioner KPU tersebut.

Alasan ketiga diatas sebenarnya sudah terjawab dari analisa metadata sebelumnya. Tetapi saya coba ulas data lainnya, selain dari web pdf.kpu.go.id, data tersebut juga tampaknya berasal dari data export/import aplikasi SIDALIH (milik KPU!!). Berikut beberapa metadata dokumen lainnya :

Adakah Petunjuk Lainnya ?

Berikut informasi petunjuk lain yang mungkin perlu diketahui oleh pihak pihak yang membutuhkan keperluan Investigasi asal usul dokumen tersebut.

Saya kebetulan menyempatkan untuk melakukan pemeriksaan secara forensik digital keseluruhan dokumen yang saya peroleh dengan tools yang saya miliki, Ada beberapa hal menarik yang perlu nanti dikonfirmasi atau diklarifikasi oleh pihak yang muncul di artikel ini. Saya tidak bermaksud menuduh atau mengkaitkan, tetapi ini adalah hasil temuan saya yang berasal dari hasil download dokumen yang leaked tersebut.

Ada dokumen yang tidak lumrah atau mencurigakan tersisipkan pada sebuah folder DPT disalah satu kecamatan di Bantul. Selain ukuran dan metadata (modified timenya) berbeda (jika lainnya pada tanggal 8 November 2013, file satu ini modified datenya berbeda sendiri yakni pada tanggal 14 November 2013), ternyata setelah ditulusuri headernya juga berbeda dengan lainnya.

Jika header file TPS lainnya di folder tersebut merupakan hasil download dari web pdf.kpu.go.id, tetapi file TPS 50.pdf ini beda sendiri, seperti ditunjukkan gambar berikut.

Dari metadata tersebut diperoleh informasi jika Dokumen hasil Producer dari Microsoft Office Excel 2007, dengan Author DWI RIYANTO Y, SE. http://www.facebook.com/khrisna.dewa; KPU NGANJUK, JATIM

Dari hasil penelusuran di internet nama Author tersebut, diperoleh profil yang benar terkait nama tersebut yakni merupakan STAFF Bagian Program dan Data KPU Nganjuk.

Yang perlu ditelururi dan diklarifikasi adalah, kenapa metadata aplikasi Microsoft Office dari KPU Nganjuk bisa muncul pada data DPT Provinsi DIY Kabupaten Bantul / Kecamatan Banguntapan? Apakah memang setiap Anggota KPU didaerah lain dapat mengakses DPT daerah lain ? Apakah tidak ada Access Control yang dilakukan oleh KPU di level aplikasinya?

Saya juga menelusuri dokumen dokumen yang beredar di internet yang menggunakan metadata yang sama. Ternyata memang Metadata tersebut juga ada pada banyak dokumen DPT dari daerah lain (Bukan hanya Provinsi DIY, tetapi beberapa daerah di jawa timur (Bukan Nganjuk)) juga terdeteksi menggunakan Metadata tersebut. Contohnya dari URL berikut https://ziladoc.com/downloadFile/aplikasi-daftar-pemilih-by-khrisna-dewa_pdf

Sebenarnya masih banyak lagi hal yang menarik atau keganjilan pada dokumen yang dileaked oleh pelaku upload data Penduduk DIY tersebut. Semoga nanti ada waktu untuk mengulasnya. Semoga bermanfaat.

INFOsec.ID – Beberapa minggu terakhir di timeline facebook saya muncul berbagai status maupun artikel yang terkait dengan kasus yang sedang hangat yakni berkaitan dengan kelanjutan peristiwa munculnya audio rekaman suara FH dan video berisi chat HRS dan FH pada akhir januari lalu. Audio dan Video Chat tersebut diupload oleh seseorang (anonim) yang tidak ingin diketahui identitasnya. Beberapa hari lalu ternyata kepolisian telah menetapkan HRS dan FH sebagai tersangka pada kasus tersebut. Secara umum dari status-status yang sempat terbaca, banyak yang tidak setuju dengan penetapan status tersebut, dan kepolisian menjadi sasaran bulan-bulanan para pembuat status, komentar, diskusi di TV maupun melalui artikel.

Diantara artikel yang muncul, ada yang ditulis oleh seseorang yang mengaku berijazah S2 Forensik dan sudah bersertifikat internasional (Artikelnya dapat dibaca di sini atau di sini . Selain di share di FB, tulisan tersebut juga sudah di share dan diposting diberbagai media website yang lebih condong membela HRS. Kemudian banyak pihak yang mengutip seolah-olah menjadi rujukan yang sahih, pada artikelnya si penulis juga tidak mengungkapkan nama aslinya meskipun mungkin dapat ditebak dari inisial dan jurusannya. Pada awal artikelnya, si penulis juga menginformasikan jika sudah pernah membantu kepolisian mengungkap kasus ITE.

Tanpa bermaksud menggurui dengan apa yang sudah disebutkan pada tulisan-tulisan tersebut, saya hanya ingin berupaya meluruskan dan juga mungkin menambahkan beberapa informasi sehingga tidak ada yang salah paham terhadap maksud isi artikel tersebut dikemudian hari. Hingga saat ini, saya juga tidak bermaksud memihak siapapun, tetapi hanya ingin meluruskan beberapa miss-informasi yang mungkin telah terjadi di lapisan masyarakat melalui pemahaman Digital Forensik dan IT Security yang saya ketahui.

Saya langsung saja membahas bagian artikel yang saya kutip berikut, pertama

Aturan tentang penggunaan bukti digital:

– Syarat agar suatu alat dapat dijadikan alat bukti digital adalah alat-alat bukti digital harus memenuhi unsur keterpercayaan, yaitu pada setiap file tidak boleh ada satupun yang “modified date” nya diatas tanggal ketika alat tersebut ditahan oleh petugas.

– Misal Hp FH ditahan pada 2 Des 2016 jam 16.00, maka jika ada satu saja file pada HP nya yang “Modified date” nya diatas tanggal 2 des 2016 pukul 16.00, maka HP tersebut tidak bisa dijadikan alat bukti karena sudah terkena “data tampering”/pemodifikasian.

Mungkin maksud dari point pertama dan kedua dengan unsur keterpercayaan adalah memiliki keutuhan/integritas sebagai alat bukti. Pada Mobile Forensic ada beberapa standard melakukan akusisi dan ekstraksi, bergantung pada kebutuhan kasusnya yakni akusisi logikal dan akusisi fisik. Akusisi Logikal biasanya digunakan untuk mengakses informasi informasi (konten-konten) yang masih dapat diakses pada memory/penyimpan menggunakan aplikasi standard/tersedia (Misalnya file file atau konten yang masih ada di media penyimpan/storage atau belum terhapus), sedangkan akusisi fisik biasanya dapat digunakan untuk mengakses informasi yang lebih lengkap dan detail, dengan cara melakukan dumping raw data (mengcopy isi keseluruhan media penyimpan/storage biasanya berupa Flash/eMMC/MMC card secara bit-stream copy, bit per bit). Dengan akusisi fisik, kita mendapatkan semua isi media penyimpan/storage dan partisi partisinya, dan dimungkinkan juga kita mengembalikan data/file yang sudah terhapus (data/file recovery). Bit-stream-copy juga biasanya dilakukan pada storage HDD Komputer/Laptop atau USB Flashdisk yang dijadikan alat bukti.

Di artikel juga disebut bahwa tidak boleh ada satupun file “modified date”nya diatas tanggal ketika perangkat tersebut ditahan oleh petugas. Kalimat ini yang bisa kurang tepat jika diimplementasikan pada Mobile/Smartphone Forensic. Pada proses akusisi dan extraksi data dari perangkat mobile, banyak ahli digital forensic biasanya melakukan secara bertahap dengan memprioritaskan menggunakan Akusisi secara Logikal dan bergantung pada jenis perangkat yang akan di akusisi dan dukungan software Forensic yang dimiliki. Secara umum laboratorium forensic yang dimiliki kepolisian terutama di daerah masih sangat bergantung pada Tools dan Software Forensic, tidak jarang juga banyak perangkat yang tidak compatible dengan perangkat yang akan diperiksa. Saya sendiri sering menerima permintaan digital forensic dari rekan rekan kepolisian setelah labfor tidak mampu mengakusisi atau data ekstraksi perangkat perangkat yang menjadi alat bukti tersebut (tidak compatible) dengan tools/software yang mereka miliki, biasanya untuk perangkat perangkat yang masih berbasis Java/HP China (Non-Android). Kebetulan saya ada alatnya, yang juga mensupport hampir semua jenis HP China/Java/Non-Android.

Akusisi secara logikal pada perangkat mobile, dipastikan harus dengan tahapan menyalakan perangkat mobile tersebut, kemudian dihubungkan dengan kabel tertentu ke tools/komputer yang digunakan untuk mengakusisi data yang ada di perangkat mobile. Hal ini juga tidak serta merta dengan mudah dilakukan. Untuk banyak jenis perangkat yang statusnya ter-lock/terkunci, atau USB Debugging (ADB) tidak aktif (Android), maka perlu dilakukan tahapan tahapan untuk membypass/unlock atau mengaktifkan USB Debugging (ADB)nya terlebih dahulu. Nah, pada proses akusisi secara logikal, saat menyalakan perangkat, sudah dipastikan beberapa file yang akan ter-modified, terutama partisi boot dan Log pada aplikasi aplikasi khususnya yang autorun pada perangkat/smartphone tersebut. Meskipun semua koneksi sudah dinonaktifkan atau dimasukkan ke Faraday bag, modifikasi ini pasti dilakukan setiap OS Mobile (Android/Windows/IOS). Akusisi Logical secara Forensic tetap masih diakui sebagai salah satu standard Forensic pada perangkat Mobile. Tidak berarti jika ada file yang berubah diperangkat (seperti Log aplikasi/System Boot) akibat proses akusisi secara logikal, maka menjadi tidak memenuhi unsur integritas atau keutuhan alat bukti. Tetapi tetap dapat digunakan sebagai alat bukti yang sah, sejauh perubahan tersebut tidak mengubah atau tampering data yang berkaitan dengan kasus.

Sedangkan Akusisi secara fisikal juga terdiri dari beragam cara, dan sangat bergantung pada jenis perangkat dan software yang digunakan. Pada beberapa kasus, untuk melakukan akusisi secara fisikal misalnya berbasis Android, secara umum membutuhkan syarat USB Debugging (ADB) aktif dan Rooted. Nah pada proses memenuhi syarat ini biasanya Ahli Digital forensic juga harus menyalakan perangkat yang tetap mengakibatkan adanya perubahan pada file Log Boot System dan aplikasi yang autorun aktif. Sehingga dipastikan file file log tersebut ter-“modified” pada saat dinyalakan. Pada banyak kasus juga, jika untuk perangkat perangkat tertentu yang kita sudah kenali sistem Boot dan Chipset/Firmware yang digunakan, dengan perangkat Box Flasher/Physical Analyzer UFED/Tarantula dst dapat mengganti sistem boot dan membypass proteksi sehingga dapat mendownload isi Flash/eMMC secara raw data.

Sekilas Contoh hasil Akusisi Fisikal yang pernah saya lakukan saat menemukan alat bukti beberapa kasus:

Jika ada pertanyaan, apakah ada cara melakukan akusisi fisikal tanpa harus melakukan perubahan yang berarti pada perangkat mobile atau tanpa memodifikasi? Jawabnya ada beberapa cara, yakni akusisi fisikal dengan teknik Chip Off, JTAG Forensic dan In-System Programming (ISP)
– Chip Off : mengangkat fisik memory Chip dari perangkat, dan dibaca menggunakan chip reader lain, teknik ini dapat merusak perangkat.
– JTAG Forensic: menggunakan perangkat PCB khusus/JIG dan JTAG Box untuk menginstruksikan processor untuk mendapatkan raw data dari chip berupa full image dari perangkat, teknik ini relatif lebih aman terhadap perangkat/tidak merusak, meski tetap beresiko data rusak jika pin JTAG tidak tepat.
– In-System Programming (ISP): menggunakan perangkat identik dengan dan menggunakan semacam Konektor khusus untuk menghubungkan ke perangkat target, dan mengemulasikan softare di perangkat lain. Teknik ini biasanya mengorbankan sebuah perangkat yang identik tersebut (merusak perangkat identik)
AFAIK, ketiga cara akusisi fisikal diatas (Chip Off, JTAG forensic dan ISP) masih jarang digunakan oleh ahli digital forensik di indonesia, meskipun sudah ada yang mampu melakukannya.

Bagian kedua, yang ingin saya komentari dari artikel tersebut:

Fakta-fakta tentang dunia IT:

1. Sangat mudah bagi kami orang-orang IT utk membuat chat WA palsu, semudah mahasiswa kami mengerjakan perkalian 4 digit.
2. Agak sulit untuk membuat audio palsu dengan suara identik meskipun bisa tetapi diperlukan waktu.
3. Relatif mudah bagi kami untuk mengecek apakah suatu foto asli/modifikasi.
4. Chat WA antar seseorang, adalah ranah privat tidak bsa dikenakan hukum kecuali ada aduan, sama seperti kita ngobrol, jika ada yang merekam maka baru bisa masuk pasal penyadapan, jika disebarkan masuk UU ITE (bagi yg menyebarkan).

Saya bahas masing masing point sebagai berikut:

Point pertama, benar sekali bahwa membuat chat WA Palsu cukup mudah, dan dipastikan mudah juga bagi awam untuk mengenali chat palsu yang dibuat tersebut. Tetapi akan sulit membuat chat palsu yang jalan ceritanya mirip/sesuai kenyataan atau kebenarannya bisa diperdebatkan serta berkaitan dengan foto foto real/asli dari dokumen pribadi tersebut.
Sebagai pemanasan, saya coba request bagi para pembaca yang sangat percaya bahwa chat itu palsu, silahkan buat chat palsu yang persis seperti kasus diatas, silahkan gunakan semua jenis aplikasi chat palsu yang ada di Internet/Playstore. Jika ada yang bisa membuat sama persis, mulai font chat, periode chat, jam/tanggal chat, content dst. Bisa mengirimkan capturannya ke saya, tambahkan juga informasi aplikasi yang anda gunakan. Untuk membedakan dengan chat di Video, tambahkan sebuah karakter unik juga pada setiap content chat untuk membedakan dengan yang ada di video chat yang tersebar tersebut.

Point kedua, dahulu mungkin sangat benar bahwa membuat audio palsu dengan suara yang identik itu memang sulit, tetapi jika kita mengikuti perkembangan teknologi, Adobe sudah memiliki teknologi “Voice Photosop” seperti video berikut . Dengan teknologi itu, kita hanya butuh sampling suara target, dan bisa membuat/mengenerate percakapan sesuka hati menggunakan suaranya dan identik. Meskipun diberitanya disebut bahwa photoshop akan membuatkan watermarking disetiap voice yang di generate aplikasinya, sehingga dapat dikenali bahwa voice tersebut di-generate dengan software (bukan suara asli), tetap saja dimungkinkan kedepan para pelaku kejahatan menghilangkan atau mengaburkan watermarking tersebut.
Point ketiga, untuk mengecek keaslian suatu foto saat ini relatif sulit jika hanya menggunakan teknologi saja. Karena hampir setiap aplikasi yang melakukan proses pengiriman foto seperti WA/FB/Instagram/Blog dll saat ini secara default sudah menghilangkan/merubah metadata dari sebuah file foto/gambar yang dikirimkan. Misalnya bagaimana mengidentifikasi foto yang diedit, kemudian dicapture dari screen menggunakan screen capture, lalu disebarkan. Atau foto yang screen capture atau difoto ulang (dengan kamera manual) dari layar monitor setelah di edit, kemudian disebarkan melalui media social. Relatif cukup sulit, karena selain kehilangan meta-data, beberapa algoritma yang biasa digunakan untuk deteksi keaslian foto juga akan kesulitan mendeteksi, sebut saja ELA (error level analisys), clone detection, histogram dst).

Point keempat, bahwa komunikasi antar dua orang pribadi memang ranah privat, dan dilindungi undang undang (UU ITE) sebagai salah satu hak pribadi/Privacy. Pada penjelasan Pasal 26 Ayat 1 point B disebut Hak pribadi merupakan hak untuk dapat berkomunikasi dengan Orang lain tanpa tindakan memata-matai. Tetapi meskipun demikian, jika salah seorang dari kedua pribadi tersebut melakukan aduan atas konten yang dikirimkan lawan komunikasinya, tetap dapat dikenakan pasal lainnya (spt mentransmisikan hal hal yang berbau pornografi) pada UU ITE. Jika dikaitkan dengan kasus WA tersebut, dari berita yang beredar bahwa Kepolisian dari Polda Metro Jaya sepertinya tidak menggunakan pasal pasal di UU ITE dalam menjerat kedua tersangka, tetapi menggunakan UU Pornografi, dimana disebut ada kata kunci tindakan “menyuruh” dan “melakukan” sebagai model pornografi.

Bagian ketiga dari artikel yang ingin saya komentari:

ANALISA-ANALISA:

1. Pada Kasus ARL dan LM-CT digunakan UU ITE, yang menjadi tersangka dan dihukum adalah pembuat/penyebar yaitu ARL dan RD sedangkan LM-CT bebas karena secara logika ARL dan RD ada andil pada terbitnya barang tersebut sedangkan LM-CT tidak.
2. Pada Kasus FH, posisi FH mirip posisi LM/CT, yaitu sebagai korban/bukan penyebar, maka kemungkinan FH juga tidak akan dihukum meskipun sudah tersangka persis sperti LM/CT.
3. Untuk FH, CT, LM lebih pas jika menggunakan perdata/delik aduan, baru bisa diproses/dihukum setelah ada yang mengadu.
4. Pada kasus FH ini, yang mungkin bisa dihukum adalah penyebar/pembuat yaitu: pembuat website/chat.
5. Foto-foto pribadi di HP adalah private tidak ada hukumnya, sama seperti anda tidak dihukum karena tidak memakai baju ketika mandi. Karena ini masuk ranah pribadi. Baru ada hukum ketika disebarkan.

Komentar saya:

Bahwa analisa yang ditulis diatas sepertinya masih hanya difokuskan pada kasus Chat saja, padahal sebenarnya ada kaitannya dengan chat/rekaman Audio (suara komunikasi seperti monolog) yang juga dipublikasikan oleh pelaku penyebar anonim sebelumnya. Jika dicermati pada rekaman video yang berisi Audio (yang diduga suara Firza Husein) bahwa ada ungkapan/ucapan dari FH yang menyatakan bahwa “Firza Bohong, Firza tidak hapus Chat, Oh Tidak saya hapus Bib“, siapapun bisa menduga, pasti ada informasi Chat yang memang sengaja tidak dihapus oleh FH, dan akibatnya orang yang dibicarakan oleh melalui curhat audio tersebut merasa dibohongi karena FH tidak menghapus Chatnya.

Salah satu konten Video Audio yang di upload si Hacker/Anonim

“Kak Emma” sendiri sudah mengkonfirmasi melalui keterangannya kepada kepolisian jika chat tersebut memang komunikasi dia dengan FH. Beritanya bisa dilihat di sini:
https://www.youtube.com/watch?v=f5Y8PSeAV7o

Bagian terakhir yang saya komentari adalah bagian kesimpulan dari artikel tersebut antara lain :

1. Kasus chat FH ini kemungkinan adalah gabungan antara foto pribadi yang sifatnya private (foto2 pribadi yg sulit utk ditemukan hukumnya), digabungkan dengan chat yang bisa dibilang meragukan keasliannya.

Komentar saya:
Foto pribadi yang mengandung pornografi (dan mau menjadi model), jika ditransmisikan karena permintaan atau suruhan pihak lain, bisa saja dikenakan pasal UU pornografi, ada aktifitas “menyuruh” dan “kesediaan menjadi model”. Memang akan tidak masalah jika misalnya foto-foto tersebut dibuat untuk dikonsumsi/disimpan sendiri oleh si model. Dan inilah yang harusnya dibuktikan secara Digital Forensic dan dijelaskan di pengadilan. Jika foto tersebut terdapat/ditemukan pada perangkat lain (misal perangkat orang yang menyuruh) atau selain perangkat milik si model, maka dipastikan juga sudah ditransmisikan atau disebarkan. Demikian juga dengan chat asusila tersebut, meskipun bagi sebagian orang masih meragukan keasliannya, tetap harus diperiksa keasliannya dengan digital/mobile forensik pada kedua perangkat yang digunakan.

2. Melihat timeline kejadian, website muncul satu bulan setelah FH dan HP tersangka ditahan, maka jika diberitakan anonymouse lah yang membuat web/menyebarkan chat adalah impossible, karena posisi BARANG BUKTI masih dipegang petugas.

Komentar saya:
Kira kira dari mana penulis artikel diatas mengetahui bahwa barang bukti yang digunakan untuk chat masih dipegang petugas? Jangan-jangan dari khabar hoax? Seperti orang Indonesia umumnya, memiliki HP lebih dari satu adalah hal yang biasa. Dari beberapa informasi seperti yang disampaikan Adik Firza pada berita ini ada 3 HP milik Firza. Ada HP Baru dan HP Lama, dan kepolisian akan (dan mungkin sudah memeriksanya). Baca disini

3. Ketika HP tersangka berada pada petugas, maka HP tidak boleh dinyalakan jaringannya karena jika dinyalakan akan merusak keaslian barang bukti/berubah “modified date” nya/tidak layak dijadikan barang bukti lagi.

Jadi urutannya: HP disita dengan prosedur khusus – ditaruh di tempat khusus penghilang jaringan – dilakukan bitstream copy / memorinya dikopi / – selanjutnya yang diutak atik petugas adalah kopian sedangkan HP asli disterilkan sampai proses persidangan membutuhkannya.

Komentar saya:

Lihat komentar sebelumnya pada aturan tentang penggunaan bukti digital diatas.

4. Berdasakan pada nomer 3, maka tidak mungkin anonymouse melakukan hacking ke HP yang dalam kondisi mati/dibawa petugas.

Komentar saya:

Jika bukan si penulis sendiri yang menangani secara digital forensik, sebaiknya tidak perlu menarik kesimpulan dari asumsi-asumsi (seperti asumsi klo HP yang digunakan chat masih dibawa petugas dst), bisa saja HP baru atau HP lama/Lainnya yang belum dikuasai polisi, salah satu buktinya bisa digunakan untuk berkomunikasi dengan “Kak Emma”. Yang jelas dari hasil pemahaman saya dari rekaman suara percakapan/komunikasi yang disebut mirip FH tersebut, bisa terjadi setelah peristiwa penangkapan atau penahanan desember. Si pelaku peng-upload Audio/Video Chat tersebut bisa jadi melakukan hackingnya sebelum penangkapan atau sesudah penangkapan. AFAIK, saya belum ada petunjuk yang terpublish tentang ini, kecuali mungkin pihak Kepolisian yang sudah memeriksa beberapa perangkat terkait kasus tersebut.

5. Kemungkinan HRS dalam hal ini adalah PIHAK YANG TIDAK ADA HUBUNGAN SAMA SEKALI dengan kasus FH karena chatnya kemungkinan menurut saya palsu.

6. Membandingkan dengan kasus ARL, CT, LM maka pada kasus FH, FH menurut tebakan saya mungkin tidak akan dihukum, HRS mungkin menurut tebakan saya juga tidak akan dihukum.

7. Satu-satunya pihak yang kmungkinan mnurut saya akan dihukum adalah penyebar dengan pasal UU ITE pasal 27 (1) yaitu si pembuat website dan penyebar foto/chat sekaligus pasal fitnah/perbuatan tidak menyenangkan dan pelanggaran HAM menyebarkan alat bukti diluar persidangan.

8. Asli tidaknya foto FH tidak ada hubungan sama sekali dengan chat.

9. Akan sangat berbahaya bagi petugas untuk melanjutkan kasus ini, karena ujung-ujungnya bisa bumerang, masih ingat kan rentang waktu antara website/chat muncul dan penahanan tersangka? pada waktu website muncul posisi barang bukti masih ada pada petugas.”

Komentar saya untuk No 5-9:
Nama HRS jelas-jelas disebut pada Audio dan tertera namanya pada Video Chat. Bagaimana mungkin tidak berhubungan dengan HRS? Bukankah bisa dianalogikan mirip kasus yang baru saja kita ketahui bahwa dipengadilan alkes ada informasi terkait KKN (menerima suap/kolusi/korupsi) yang dilakukan oleh seorang professor doktor, apakah tidak pantas si professor diperiksa secara intens?. Soal palsu atau tidak, bersalah atau tidak, jelas harus dibuktikan di jalur hukum. Tetapi tentu saja tidak cukup dengan asumsi atau kemungkinan-kemungkinan seperti yang dituliskan di artikel tersebut. Kita sebagai awam lebih baik tunggu saja bukti-buktinya di pengadilan, karena bukti bukti pasti akan dibuka dipengadilan. Saya pribadi sebenarnya sejak lama tidak ingin membahas kasus ini, hanya saja saya kuatir banyak pihak yang terjebak dengan asumsi asumsi dan pendapat yang dilatari hoax/berita bohong, sehingga ujung ujungnya banyak masyarakat yang tidak percaya dengan lembaga lembaga yang berwenang seperti Pemerintah dan Kepolisian.

Sebagai ahli digital forensik, idealnya posisinya adalah netral, baik sebelum melakukan pemeriksaan maupun setelah melakukan pemeriksaan. Kita hanya mengungkapkan fakta fakta sebenarnya melalui proses Digital Forensik yang sudah kita ketahui bersama, khususnya bagi yang sudah belajar. Jika sebagai ahli forensik si penulis sudah menarik kesimpulan tanpa melakukan pemeriksaan, apakah pantas disebut ahli Digital Forensik dan menggambarkan seorang lulusan S2 jurusan Forensik Digital? Membela seseorang memang tidak ada salahnya, tetapi jika langsung menyimpulkan sesuatu berdasarkan informasi hanya sekedar “katanya katanya” atau bahkan hoax justru lebih berbahaya. IMHO, justru petugas kepolisian harus melanjutkan kasus ini sehingga terang benderang dengan bukti bukti nanti dipengadilan, dan dipengadilan nanti semua pihak memiliki kesempatan yang sama dalam membela diri. Jika memang tidak bersalah, kenapa takut membuktikannya?

Demikian akhir komentar saya terhadap salah satu artikel yang terkait kasus yang sedang hangat tersebut, sebenarnya ada beberapa artikel lain yang ingin saya bahas, tetapi saya sepertinya kehilangan URLnya, berhubung artikel tersebut sudah lama melintas di timeline saya.

Saya akan lanjutkan membahas beberapa diskusi di TV/Youtube dan status atau komentar di Facebook yang masih berhubungan dengan kasus tersebut.

Saat menonton beberapa diskusi di TV (rekamannya di Youtube) antara Ahli IT vs Penasehat Hukum HRS dan status/diskusi FB, banyak pihak yang mengesampingkan kemungkinan bahwa peretas atau si anonymous melakukan remote akses terhadap perangkat yang terlibat komunikasi. Umumnya mereka, termasuk si Ahli IT terlalu yakin bahwa si pelaku/peng-upload video/audio chat (anonim) tersebut memiliki akses langsung (memegang) perangkatnya, kemudian melakukan print screen/screenshoot dari perangkat langsung, seolah olah itu jalan satu satunya mendapatkan sreenshoot seperti pada video chat. Hal ini juga yang dikait-kaitkan dengan status Barang Bukti perangkat yang diasumsikan masih ditahan di pihak kepolisian, sehingga banyak yang “menuduh” bahwa hanya dari pihak kepolisianlah yang mungkin menyebarkan screenshoot Chat atau video tersebut.

Banyak juga status di FB yang membela HRS dengan membahas keamanan Whatsapp yang telah memanfaatkan end to end encryption sehingga tidak mungkin dilakukan intercept/penyadapan, bahkan pihak kepolisian, dan semuanya terlalu yakin dengan keamanan Whatsapp tersebut. Mereka hanya memahami jika lapisan keamanan hanya pada teknologi enkripsi, penyimpanan data dan saat transmisi/komunikasi saja, dan melupakan keamanan untuk melindungi lapisan lainnya seperti SDM/People Awareness, Physical/Lapisan Fisik dan Policy/Procedure.

Sama halnya dengan kejadian yang baru terjadi beberapa waktu lalu, saat ransomware Wannacry membuat banyak pihak kelabakan, sampai sampai kemkominfo tanpa sadar telah melakukan “teror” terhadap banyak pihak/instansi karena menimbulkan kekuatiran berlebih dengan pengumuman/pemberitaan yang overdosis dilakukan banyak media terkait ransomware tersebut. Prosedur teknis Update/Pencegahan yang sudah dipublikasikan oleh Kemkominfo tetap akan kurang efektif jika security awarenes pengguna komputer tidak ditingkatkan, seperti untuk tidak mengklik attachment yang tidak dikenal atau menginstall software crack-crack-an/bajakan. Karena semua prosedur yang sudah diumumkan tidak mungkin dapat mencegah masuknya ransomware jika kesalahan pada tindakan para pengguna tersebut.

Demikian pula dengan aplikasi Whatsapp, meskipun saat ini whatsapp sudah memanfaatkan end-to-end enkripsi (yang hanya bisa baca pesan hanya perangkat pengirim dan perangkat penerima saja), tetapi jika perangkat sudah disusupi oleh malware/trojan/backdoor, maka tidak akan berguna melindungi informasi tersebut. Karena si hacker bisa melakukan remote akses ke perangkat tanpa disadari pemiliknya.

Si Hacker mungkin saja sudah menargetkan orang-orang tersebut, dengan memanfaatkan teknik teknik “social engineering” sebelumnya, agar pemilik perangkat mau membuka atau menginstall trojan/malware berupa backdoor tersebut. Pada aplikasi mobile/Smarphone, tidak sulit bagi hacker membuatkan trojan/backdoor, misalnya aplikasi.APK di Android dst. Setelah trojan terpasang di perangkat, maka hacker sangat dimungkinkan akan mampu akses ke perangkat melalui backdoor/trojan secara remote tanpa disadari pemilik perangkat. Kemudian dapat memasang/menginstall atau mengaktifkan aplikasi sejenis remote desktop, Contoh di Android biasanya menggunakan VNC Server (Droid VNC Server). Dengan membuat semacam tunnel, sangat mudah bagi hacker untuk mengakses layar target secara remote dari Perangkat PC/Laptop/Mobile si hacker, dan mengoperasikannya seperti mengoperasikan secara langsung. membuka Whatsapp dst. Dengan teknik ini juga si hacker dimungkinkan mampu merekam microphone perangkat, sehingga di video yang ada suara terdengar seperti monolog. Bisa jadi karena hacker memang saat itu hanya mampu merecord Microphone dari perangkat, sehingga yang terekam adalah suara pemilik perangkat.

Metode lain yang mungkin dilakukan hacker selain mengakses aplikasi WA secara remote adalah dengan mendownload hasil backup database Whatsapp yang ada di direktory Whatsapp/Databases dan file kunci (key)-nya. Kemudian mencopy database menginstall WA di perangkat yang sudah disediakan, dan merestore (secara otomatis ) database tersebut saat instalasi.

Metode lainnya, bisa juga dengan dari hasil take over account email yang digunakan setelah berhasil menyisipkan malware/trojan pada perangkat mobile yang mungkin kebetulan digunakan juga untuk backup google drive yang menyimpan backup Whatsapp pemilik perangkat, dan kemudian melakukan penyadapan pada SMS/GSM atau melakukan cloning Nomor GSM untuk didaftarkan pada perangkat lain yang disiapkan si hacker/Anonymous. Setelah terpasang, maka database WA diperangkat dapat langsung tersyncronize dari hasil backup google drive.

Dan mungkin masih ada metode lainnya, silahkan cari sendiri.. pembaca budiman :). Beberapa orang mungkin berfikir seperti “katak dalam tempurung”, dan merasa sudah menguasai setiap teknologi yang biasa digunakan, sehingga kadang langsung membatasi diri dengan asumsi asumsi yang dangkal. Ada baiknya kita selalu berfikir “How” ~ bagaimana caranya. Sehingga diharapkan tetap terus belajar dan tidak membatasi diri dengan pengetahuan yang minim. Saya yakin masih ada metode lain yang mungkin dilakukan oleh si Anonim.

Jika ada pertanyaan terkait tampilan WA di Video, kenapa gambar gambar yang dikirimkan pada video chat tersebut tidak muncul di layar chat, tetapi hanya muncul di luar kolom chat (melalui video editing). Ada beberapa kemungkinan, jika dicermati dari beberapa bagian chat WA yang ada di video chat tersebut terlihat jika waktu melakukan capture chat WAnya berdurasi rentang waktu yang sangat lama, dan terdiri dari banyak pesan, baik yang berasal dari si penerima maupun si pengirim pesan. Hal ini terlihat juga dari perbandingan posisi kursor dengan jumlah pesan chatnya. Sehingga dimungkinkan pesan pesan ini bisa saja sudah hasil recovery backup sebelumnya, seperti dari google drive atau database lokal, yang mana dapat terjadi ketika WA terinstall ulang/aplikasi pernah rusak/corrupt, atau berpindah/pergantian perangkat dst. Saat WA terinstall ulang dan memasukkan nomor yang sama, maka proses recovery bisa saja tidak menyertakan video/gambar gambar yang lama (karena tidak dipilih/diincludekan saat melakukan backup). Jadi gambar gambar ini bisa saja memang tidak muncul (tidak terecovery) di perangkat aslinya, atau hanya tidak muncul di perangkat pelaku yang melakukan recovery dengan method yang dijelaskan diatas, tetapi diperangkat aslinya bisa saja gambar tersebut benar masih ada/muncul. Hal inilah yang juga perlu dikonfirmasikan dengan hasil digital forensik nantinya. Apakah gambar gambar tersebut memang masih ada atau sudah terhapus. Jikapun terhapus, untuk file gambar relatif lebih mudah recoverynya, dibandingkan dengan chat WA yang sudah terhapus (tanpa ada backup). Mengapa? Karena untuk gambar/image, biasanya aplikasi pembuka spt gallery pasti akan membuatkan thumbnail dan melalui process caching yang disimpan di storage, dan bahkan sering berulang kali, sehingga saat recovery file (deleted) dengan Akusisi dan Extraksi secara Fisikal, sering ditemukan hingga beberapa file aslinya. Berbeda dengan pesan WA (khususnya yang tanpa Backup/database terenkripsi), ketika pesan di hapus, maka di database WA (DB lokal berupa SQLite) juga akan terhapus/teredit, dan rentan sekali untuk ter-overwite oleh pesan pesan yang baru masuk, karena masih menggunakan nama file dan lokasi inode/cluster yang sama pada storage (WA.db/Chat.db).

Demikian artikel ini saya posting sebagai pengetahuan bersama khususnya berkaitan dengan digital forensik. Sebenarnya masih ada bagian yang belum sempat dibahas. Semoga masih ada kesempatan lain untuk menuliskannya. Silahkan berdiskusi melalui kolom komentar dibawah.

Semoga bermanfaat

Sumber: http://infosec.id/2017/06/mobile-forensic-kasus-audio-dan-chat-wa-asusila/

Pelatihan ini sangat diperlukan dalam mengamankan Infrastruktur Teknologi Informasi perusahaan, instansi/lembaga dari berbagai ancaman dan serangan Cyber saat ini.
Pada pelatihan ini akan dibahas secara rinci langkah-langkah yang digunakan para hacker maupun cracker dalam melakukan serangan terhadap infrastruktur Teknologi Informasi, cara menyerang dan melindungi aset Teknologi Informasi mulai dari PC, Server-Server, LAN, teknologi SSL, Jaringan Nirkabel dan Aplikasi Web atau situs-situs organisasi/instansi. Dalam pelatihan Peserta akan mempraktekkan langsung setiap teknik-teknik yang digunakan para cracker atau hacker. Dan dibahas juga bagaimana cara menanggulangi serangn serangan sejenis.

JADWAL DAN LOKASI
Training “Ethical Hacking & Perimeter Defense” diadakan pada:
Waktu : 22-24 Mei 2017 (3 Days) Pukul 9.00 – 16.00 WIB
Lokasi: Meeting Room Gaia Cosmo Hotel Yogyakarta

OVERVIEW:
Program Training ini sangat sesuai untuk orang-orang yang sudah profesional dan berpengalaman di bidang IT maupun orang-orang yang telah memperoleh sertifikasi lainnya di bidang TI.
Pada training ini peserta akan dihadapkan pada pembelajaran secara interaktif dimana mereka akan ditunjukkan dan berhasil melakukan proses scanning, penetration test, hacking serta mempertahankan dan mengamankan sistem mereka. Lingkungan laboratorium yang intensif akan memberikan pengetahuan yang mendalam serta pengalaman praktek langsung dengan konsep dan prinsip sistem keamanan bagi setiap peserta. Peserta juga akan mulai memahami bagaimana perimeter defense bekerja dan kemudian akan mampu mensimulasikan proses scanning dan serangan terhadap jaringan mereka. Pada training ini, peserta akan belajar bagaimana penyusup mampu meningkatkan privileges (escalate privilege) dan langkah langkah yang dilakukan untuk mengamankan sebuah system. Selain itu peserta juga akan belajar mengenai Intrusion Detection, Policy Creation, Social Engineering, DDoS Attacks, Buffer Overflows dan pembuatan Virus.

TARGET PESERTA
Professional TI bidang Keamanan Sistem Komputer
Dosen atau staff pengajar bidang keamanan jaringan & sistem Informasi
System Administrator & Network Administrator
Pengelola Bidang Infrastruktur Jaringan atau TIK Organisasi
Konsultan dan Auditor TI bidang Keamanan Sistem Informasi
Mahasiswa yang sudah memiliki pengalaman bidang Keamanan Sistem Informasi atau pernah mengambil kuliah Keamanan Jaringan dan Sistem Komputer.
Individu yang akan mengikuti Ujian Sertifikasi EC-Council CEH & SCNS (SCP)

KEUNTUNGAN DAN FASILITAS:
Trainer very Qualified & Certified
75% Lab Work & Practices
Direct Internet Connection
Certificate of Attendance
Training Modules

INSTRUKTUR/TRAINER:
Konsultan dan Trainer kami tidak hanya memiliki sertifikasi
professional seperti CEH, CHFI, ECSA/LPT, ACE, MCP, RHCT, MTCNA, CCNP,
CCNA, CompTIA (Security+, Network+. Linux+) tetapi juga memiliki
pengalaman di industri lebih dari 12 tahun. Trainer kami akan
menggunakan metode terbaik, best practices dalam memanfaatkan
teknologi keamanan sesuai kebutuhan Anda. Trainer kami menggunakan
metode pelatihan dan pembelajaran aktif dan menyenangkan

OUTLINE COURSE
Information Security Essential
Ethical Hacking
Footprinting
Scanning
Enumeration
Sniffers
Denial-of-Service & DDoS
Social Engineering
Session Hijacking
Hacking Web Servers
Viruses and Worms
Physical Security
Email Security
Hacking Linux
IDS, IPS & Honeypots
Design Firewall & Router ACL
Proxy Server
System Hacking
Trojans and Backdoors
Web Application Vulnerabilities
Web-Based Password Cracking Techniques
SQL Injection
Hacking Wireless Networks
Cryptography
Penetration Testing Methodologies

INVESTASI :
Rp. 4.500.000,-/ person

PENDAFTARAN
Silahkan mengisi formulir Pendaftaran
http://rootbrain.com/training/registration/

INFORMASI

RootBrain IT Security Training & Consulting
Network & Security Specialists
Telp/WA: 0811 2507224 atau 0811 250 8780
Website: http://rootbrain.com
Email: [email protected]

 INFOsec.ID –  Lembaga Pengadaan Secara Elektronik atau disingkat LPSE, merupakan lembaga yang berfungsi untuk menyelenggarakan pengadaan barang/jasa untuk Pemerintahan, baik di tingkat pusat maupun daerah. LPSE memanfaatkan aplikasi SPSE (Sistem Pengadaan Secara Elektronik) yang dikembangkan oleh Lembaga Kebijakan Pengadaan Barang/Jasa Pemerintah (LKPP) bekerja sama dengan Lembaga Sandi Negara (LEMSANEG) dan Badan Pengawasan Keuangan dan Pembangunan (BPKP). LKPP merupakan salah satu dari 28 Lembaga Pemerintah Non-Kementerian (LPNK) yang berada di bawah dan bertanggungjawab langsung kepada Presiden Republik Indonesia.

LKPP mulai mengembangkan SPSE sejak tahun 2007, saat ini SPSE terakhir dikenal dengan SPSE versi 4.1.0. Pemanfaatan aplikasi e-procurement seperti SPSE dalam pengadaan barang/jasa untuk pemerintahan adalah langkah yang sangat baik untuk menuju Good Governance dan perlu didukung setiap elemen pemerintah, pelaku usaha dan masyarakat umum.

Bulan April 2016 lalu, kabar terkait keamanan LPSE kembali menjadi booming disebabkan marak berita tertangkapnya salah satu tersangka pelaku pembobolan aplikasi Sistem Pengadaan Secara Elektronik (SPSE) yang dikelola oleh LPSE. Beberapa berita bisa dilihat pada url satu, dua, tiga dan empat

Dari informasi pada berita berita tersebut dapat diambil beberapa kesimpulan, bahwa pelaku sudah melakukan aktifitas ilegalnya cukup lama dan berhasil mengakses dan mengontrol/mengatur sistem -sistem LPSE di beberapa lokasi/sistem yang berbeda. Dan berdasarkan analisis penulis, kelompok yang anggotanya sudah tertangkap ini bukan merupakan satu satunya yang mampu melakukan aktifitas ilegal tersebut. Sebenarnya kasus yang kurang lebih sama sudah terjadi sebelum-sebelumnya dibeberapa sistem LPSE yang tersebar di Indonesia, banyak pelaku usaha yang ingin ikut tender di berbagai LPSE tetapi karena selalu ada gangguan pada sistem maka tidak dapat mengakses sistem SPSE, akhirnya tidak berhasil mengupload dokumen sebagai administrasi peserta lelang.

Mungkin masih ada pelaku atau kelompok lainnya yang mampu dan melakukan aktifitas pembobolan sistem pada LPSE seperti kasus tersebut. Penulis akan mencoba mengurai berbagai faktor-faktor mengapa masih dimungkinkan terjadi penyalahgunaan akses dan pembobolan dengan memetakan keamanan sistem LPSE saat ini berdasarkan prinsip-prinsip keamanan dan lapisan (layer) keamanan.

Pada bukunya Computer crime: a crimefighter’s handbook, David Icove membagi keamanan komputer menjadi beberapa lapisan, yakni lapisan Keamanan Fisik (Physical Security), Manusia/SDM (People), Data/Teknik Komunikasi (System/Technology), Kebijakan/Prosedur (Policy & Procedure). Penulis akan mencoba menggambarkan kondisi SPSE berdasarkan lapisan-lapisan tersebut satu-persatu.

Keamanan Fisik (Physical Security)

Sistem SPSE yang digunakan oleh LPSE-LPSE, saat ini terpasang di ratusan (atau bahkan ribuan) mesin server yang tersebar di seluruh instansi-instansi pemerintahan baik di Pusat (Lembaga/Kementrian maupun Non Kementrian) maupun Daerah. Setiap instansi mengelola infrastruktur (datacenter) masing masing LPSE, mulai dari Jaringan Intranet/Internet hingga server-servernya. Setiap instansi dan pemerintah daerah memiliki kesiapan dan kelengkapan infrastruktur berbeda satu sama lainnya, banyak instansi pemerintah khususnya didaerah yang secara fisik, NOC atau Datacenternya belum memadai terutama dari segi keamanan. Salah satu kejadian yang merupakan pengalaman pribadi penulis beberapa tahun lalu, saat memberikan workshop keamanan pada salah satu datacenter/ruang server yang dikelola salah satu Pemerintah Daerah, tiba tiba saja ada seorang tukang semir yang masuk ke ruangan datacenter tersebut dan menawarkan jasanya, “pak sepatunya pak” sambil menunjukkan alat semir sepatu ditangannya. Ternyata pintu ruang datacenter yang berisi rak rak server dan beragam perangkat “canggih dan mahal” itu kelihatannya selalu terbuka selama jam kerja. Menariknya lagi, datacenter ini terletak di gedung satu lantai dengan ruangan kantor dengan space terbuka, meja-meja pegawai dibatasi sekat sekat pendek, ruang datacenter hanya dibatasi oleh sekat kaca transparan. Sehingga setiap pegawai dan masyarakat umum yang lalu lalang dari sekitar datacenter di kantor tersebut, bisa melihat isi datacenter dari luar ruangan. Jika tukang semir sepatu saja bisa masuk, artinya phisical security bisa dikatakan hampir tidak ada. Memang banyak juga pemerintah daerah yang datacenternya sudah mumpuni, dilengkapi berbagai perangkat keamanan fisik mulai dari kunci digital/fingerprint dan CCTV, dan juga dilengkapi dengan standar keamanan dari disaster (kebakaran/api). Tetapi pengalaman penulis yang sering berkunjung ke instansi pemerintah di daerah, masih lebih banyak datacenter yang dikelola “seadanya”. Penulis belum melihat adanya kewenangan LKPP sampai menentukan layak tidaknya suatu infrastruktur instansi pemerintah untuk mengoperasikan aplikasi SPSE. Penulis berharap kedepan ada standard keamanan fisik infrastruktur datacenter di setiap instansi pemerintah di daerah secara umum dan infrastruktur yang mengelola sistem SPSE secara khusus.

Manusia/SDM (People)

Pada lapisan Sumberdaya Manusia/SDM (people), terdapat beberapa hal yang perlu diperhatikan dalam implementasi sistem informasi (SPSE). Yang pertama adalah dari sisi personal pengembang sistem SPSE itu sendiri, mulai dari keahlian (skill), attitude, loyalitas hingga moral pengembang setiap sistem informasi sepenting SPSE sewajarnya harus mendapat perhatian khusus. SPSE dikembangkan berbasis web menggunakan bahasa pemrograman java dan database PostgreSQL, serta berjalan di atas server ber-OS Linux. Versi terakhir (4.x) dikembangkan menggunakan framework Play Framework, yakni framework pengembangan berbasis Java. Tentu saja para pengembang adalah orang orang yang ahli dibidangnya. Secara umum saat recruitment cukup mudah bagi IT Management suatu instansi melihat skill/keahlian seseorang, tetapi untuk attitude, loyalitas dan moral mungkin hanya orang-orang tertentu yang bisa menilainya (spt psikologi), atau bahkan hanya waktu yang bisa mengungkapkannya. Penulis pernah membaca dari beberapa sumber berita, bahwa banyak pengembang SPSE di LKPP yang telah berpindah pindah, artinya kemungkinan adanya “turnover itention” yang cukup tinggi, sehingga LKPP harus mencari pengganti penerus para developer tersebut. “Turnover” seorang developer dari sebuah tim pengembang sistem informasi jika tidak diantisipasi sebelumnya, bisa menjadi seperti mimpi buruk bagi tim pengembang lainnya, karena tidak mudah menemukan rekan developer yang sama pola kerjasama/skill/attitudenya. Apalagi jika seorang developer tersebut termasuk salah satu “panutan” atau “sumber inspirasi teknis” bagi rekan rekannya satu tim. “Turnover intension” seorang developer biasanya berhubungan dengan work environment dan remunerasi, tetapi tidak tertutup juga karena permasalahan lainnya. Yang paling perlu dikuatirkan adalah jika si developer yang akan keluar/pindah dengan sengaja atau tanpa sengaja meninggalkan bugs atau backdoor pada aplikasi yang dikembangkannya. Artinya security bugs dan backdoor ini suatu saat dapat ditemukan atau dimanfaatkan orang lain. Yang kedua atau berikutnya adalah dari sisi orang orang yang pengelola infrastruktur dan sistem SPSE itu saat diimplementasikan. Pada sisi ini, kita ketahui bahwa pengelola infrastruktur dan sistem SPSE merupakan tim bentukan instansi pemerintah di pusat maupun daerah yang menjalankan LPSE. Pengelola infrastruktur dan sistem yang dimaksud adalah system administrator dan network administrator yang bertugas merawat sistem dan jaringan SPSE. Hampir sama dengan pengembang sistem, faktor faktor seperti skill, attitude, loyalitas dan moral juga menjadi perhatian yang penting bagi pengelola infrastruktur dan sistem SPSE ini. Jika di LKPP Pusat mungkin dengan mudah mendapatkan/mencari atau memfilter system/network administrator yang mumpuni secara skill, tetapi pasti sangat berbeda kondisinya dengan di instansi  pada Pemerintah Daerah khususnya di luar Jawa. Biasanya di lingkungan pemerintah daerah, relatif sulit mencari system/network administrator yang memiliki skill baik. Apalagi sampai memfilter yang memiliki attitude, loyalitas dan moral? Tidak jarang di instansi pemerintahan terutama di daerah, system/network administrator SPSE di handle, ditangani atau bahkan di maintenance oleh pihak ketiga (orang orang ini biasanya yang dipercaya oleh instansi tersebut, yang tidak jarang juga merupakan kontraktor TI di daerah tersebut). Sebagai system administrator sebuah server yang memiliki akun admin atau superuser, memiliki priviledge untuk mengontrol sistem secara penuh, dapat mengakses database dan dokumen-dokumen pada sistem secara langsung tanpa tercatat pada sistem aplikasi. Berbeda dengan pengguna yang berstatus panitia, ppk dan bahkan auditor, yang mungkin hanya dapat berinteraksi melalui sistem aplikasi SPSE dan otomatis dapat terekam pada history aplikasinya. Bagian lain yang harus diperhatikan dari setiap pengelola sistem SPSE (system administrator dan network administrator), bahwa belum adanya standard kompetensi untuk keahlian (skill) yang dijadikan acuan bahwa seseorang administrator sistem/jaringan SPSE sudah layak atau belum mengelola sistem SPSE. Karena menurut penulis, administrasi pengelolaan dan monitoring sistem SPSE termasuk bagian yang sangat kritis untuk keberhasilan LPSE memenuhi tugas-tugas dan tanggungjawabnya mencegah kecurangan pada proses pengadaan. Berbeda dengan panitia pengadaan (PPK) yang sudah memiliki standard kompetensi dengan mengikuti ujian tertentu yang ditetapkan oleh LKPP. Secara umum para system dan network administrator yang ditunjuk ikut mengelola SPSE di instansi instansi dan daerah merupakan administrator datacenter yang tugasnya bukan hanya mengelola SPSE, tetapi ada banyak sistem/server dan jaringan lain yang harus dikelola, sehingga monitoring atau pengelolaan SPSE terkadang tidak dilakukan dengan baik. Biasanya system administrator dan network administrator tersebut melakukan administrasi sistem SPSE hanya saat terjadi incident atau sistem tidak dapat diakses berdasarkan laporan para pengguna. Padahal system dan network administrator merupakan ujung tombak keamanan sistem dan aplikasi SPSE, yang harusnya secara periodik harus selalu melakukan update, monitoring sistem, dan koordinasi dengan pengembang di LKPP Pusat untuk mengantisipasi adanya anomali dan berbagai ancaman serangan.

Sistem/Data/Teknik Komunikasi (System/Technology)

Jika kita semua sepakat bahwa sistem yang digunakan oleh LPSE yakni SPSE adalah sistem yang sangat penting dan berharga demi kepentingan masyarakat melalui implementasi good governance dan percepatan pembangunan, maka SPSE sudah seharusnya menjadi sistem yang memiliki kehandalan yang baik dan dan keamanan yang tinggi. Oleh sebab itu juga SPSE harusnya sudah menggunakan teknologi atau teknik teknik pengamanan data/informasi dan komunikasi terbaik. Tetapi berdasarkan pengamatan penulis yang sudah biasa melakukan audit keamanan, penetration testing dan security testing di berbagai instansi pemerintahan, universitas dan corporate, sepertinya belum demikian kondisinya. Aplikasi SPSE yang dikembangkan oleh LKPP bersama LEMSANEG dan BPKP mulai dari versi awal hingga versi yang terakhir (SPSE v.4.x ?) masih memiliki kelemahan pada keamanan (security vulnerability) dan sifatnya berbahaya (kritikal), kelemahan-kelemahan ini ditemukan penulis saat ada kegiatan audit/penetration testing terhadap beberapa instansi pemerintah berdasarkan permintaan instansi tersebut. Saat artikel ini ditulis versi SPSE yang paling banyak digunakan adalah v.3.6, meskipun masih ada beberapa yang menggunakan v3.5. Saat ini LKPP sedang menyiapkan agar LPSE-LPSE di setiap lembaga pemerintah mulai migrasi ke v.4.x.

Penulis meyakini bahwa LKPP sudah melakukan antisipasi-antisipasi adanya vulnerabilitas pada setiap sistem telah dikembangkan. LKPP dipastikan juga telah melakukan internal audit atau internal penetration testing atau vulnerability assessment, atau bahkan juga mungkin telah mengundang dari pihak eksternal. Penulis sendiri masih ingat, sekitar tahun 2007/2008 ketika LKPP akan memperkenalkan sistem SPSE versi awal yang dikembangkannya, LKPP mengirimkan surat permintaan penawaran untuk kegiatan penetration/security testing/vulnerability assessment yang ditujukan kepada lembaga-lembaga dan perusahaan bidang keamanan di Indonesia. Salah satu yang menerima surat permintaan penawaran dari LKPP pada saat itu termasuk tempat penulis bekerja saat ini. Dari kejadian tersebut, penulis sangat menyakini bahwa LKPP sudah aware terhadap kemungkinan adanya permasalahan keamanan pada sistem yang dikembangkannya. Tetapi karena setiap aplikasi merupakan hasil pekerjaan para tim developer yang juga manusia, bisa dipastikan selalu dimungkinkan ada kesalahan pengkodean yang terjadi sehingga menyebabkan munculnya kelemahan (vulnerability) pada sistem aplikasi SPSE. Bahkan meskipun SPSE tersebut sudah dilakukan antisipasi seperti penetration testing/security testing baik internal maupun eksternal, tetap saja dimungkinkan selalu adanya temuan-temuan kelemahan baru, yang mungkin tidak ditemukan saat proses assessment/pentest sebelumnya. Hal ini dapat juga disebabkan pengalaman dan skill setiap pentester/auditor juga pasti berbeda atau perkembangan teknologi yang relatif sangat cepat. Kritikalnya adalah jika terdapat salah satu kelemahan pada kode aplikasi yang bisa diexploitasi di salah satu SPSE, maka dipastikan semua SPSE yang terpasang oleh LPSE yang menggunakan versi yang sama juga memiliki kelemahan. Dapat disimpulkan juga bahwa jika seorang hacker mampu membobol salah satu LPSE/SPSE, maka dimungkinan dapat membobol ratusan SPSE lainnya.

Kedepannya diharapkan selain melakukan penetration testing secara berkala, baik oleh tim internal maupun external, LKPP dapat juga mengadopsi mekanisme bug bounty seperti yang dilakukan oleh berbagai perusahaan internet dan DoD US beberapa waktu lalu. Bug bounty pada dasarnya merupakan suatu program yang diperuntukkan bagi para praktisi keamanan untuk mencari celah-celah yang rentan dieksploitasi dari suatu produk layanan yang berbasis TI. Program ini pada umumnya dibuat oleh perusahaan-perusahaan besar atau lembaga pemerintah yang sangat bergantung pada media internet untuk mengizinkan bug hunter (istilah peserta bug bounty) mencari celah keamanan dari produk mereka. Sebut saja Microsoft, Twitter, Google, Facebook, PayPal, Uber ataupun perusahaan raksasa lainnya yang selalu menjadi langganan bagi para bug hunter untuk melaporkan celah keamanan. Selain kelemahan dari sisi pengkodean aplikasi SPSE, kemungkinan kelemahan lainnya adalah pada proses penyimpanan informasi/data pada database. Banyak developer/analis sistem yang hanya memanfaatkan teknik teknik proteksi enkripsi/hashing sederhana dalam menyimpan informasi yang sifatnya sensitif/rahasia, misalnya password, Token, Private Key. Pada banyak kasus, developer-developer masih percaya dengan kekuatan algoritma hashing (sering di sebut enkripsi searah) seperti MD5, SHA1, SHA256 atau bahkan SHA512 dalam pengamanan password di database. Padahal sudah jelas-jelas hasil hashing ini dengan mudah di pecahkan (crack) melalui dictionary/brute force attack, atau dengan hanya memanfaatkan fasilitas hash cracker online yang bertebaran di internet. Ada juga developer yang hanya menyimpan informasi sensitif/rahasia hanya mengandalkan teknik encode seperti base64, yang mana sangat mudah dibaca dan dibongkar. Pada beberapa aplikasi, para developer ada juga yang sudah lebih baik pengamanan informasi/datanya pada database, meskipun masih tetap menggunakan algoritma hashing, tetapi dengan adanya salt (salting) yakni penambahan kode tertentu pada informasi password yang akan di-hash sebelum disimpan pada database. Sehingga meskipun attacker/hacker mampu mengakses database tersebut dengan teknik teknik hacking (contoh: SQL Injection), tetapi informasi hash tersebut masih relatif lebih sulit untuk dipecahkan (di-crack) dibandingkan tanpa salt sama sekali. Penyimpanan informasi-informasi yang bersifat sensitif/rahasia jika diperoleh pihak lain seperti password, private key, token idealnya disimpan dengan algoritma enkripsi yang lebih kuat dan bukan dengan sekedar checksum/hashing. Sehingga meskipun terjadi incident atau database kebobolan, informasi tersebut masih relatif lebih sulit untuk dibaca/dipecahkan si attacker. Salah satu contoh algoritma enkripsi yang relatif lebih baik dari pada algoritma hashing spt MD5, SHA1, SHA256 adalah bcrypt/jbcrypt. Pada bahasa pemrograman PHP dan Java sudah disediakan komponen atau modulenya. Jikapun ingin tetap memanfaatkan algoritma hashing, diharapkan developer menambahkan salt yang dinamis untuk setiap akun/passwordnya.

Dari sisi komunikasi data, karena aplikasi SPSE merupakan aplikasi yang berbasis Web, maka harusnya telah memanfaatkan protokol HTTPS (SSL) secara default. Dari pengamatan penulis, hanya sekitar 20-30% dari seluruh LPSE yang ada yang telah memanfaatkan protokol HTTPS pada sistem SPSE mereka. Sedang 70-80% masih menggunakan protokol HTTP (Plain Text) saja. Hal ini dapat menjadi masalah keamanan yang serius bagi setiap LPSE yang masih memanfaatkan HTTP saja, karena setiap komunikasi data yang dilakukan setiap pengguna baik itu admin, panitia, ULP, auditor dan penyedia akan dimungkinan disadap atau dibaca oleh pihak pihak yang tidak bertanggung jawab, khususnya jika mengakses sistem SPSE dari jaringan public atau jaringan yang tidak dapat dipercaya seperti Wifi/Hotspot. Implementasi HTTPS/SSL pada server juga sebenarnya belum tentu dapat menjamin komunikasi data pengguna selalu terenkripsi saat transmisi. Menurut penulis, untuk sistem SPSE yang saat ini, meskipun LPSE yang mengelola sudah menggunakan HTTPS/SSL, masih ada teknik teknik yang dapat digunakan para hacker untuk melakukan downgrade protokol (seperti stripping SSL). Hal ini terutama disebabkan jika ternyata server aplikasi SPSE belum menerapkan HSTS Policy (HTTP Strict Transport Security). Setiap teknologi keamanan yang diciptakan memang selalu ada cara/trick bagi para hacker untuk mem-bypass-nya, oleh sebab itu keamanan sistem/aplikasi jangan dianggap sebagai sekedar fitur, melainkan merupakan proses yang harus dilakukan secara terus-menerus. Dengan menerapkan sistem keamanan yang tinggi, berarti akan mengurangi kenyamanan dalam menggunakan dan mengelolanya. Sehingga kita harus menyesuaikan dengan level keamanan yang kita inginkan, masih ingat bahwa kita menginginkan keamanan SPSE ke level tertinggi atau seaman mungkin, sehingga tujuan dibangunnya SPSE tersebut tercapai.

Kebijakan dan Prosedur (Policy & Procedure)

LKPP yang merupakan singkatan dari Lembaga Kebijakan Pengadaan Barang/Jasa Pemerintah, secara harfiah dari nama lembaga sudah jelas bahwa tugas utama berhubungan dengan pengembangan/penyusunan kebijakan-kebijakan terkait pengadaan barang dan jasa pemerintah. Jadi dapat dipastikan lembaga LKPP memiliki banyak ahli yang berpengalaman dalam membuatkan berbagai kebijakan-kebijakan dan prosedur-prosedur sesuai dengan tugasnya. LKPP sudah membuat berbagai kebijakan-kebijakan dan berbagai SOP terkait layanan pengguna, pedoman bimtek, pengamanan & pemeliharaan infrastruktur, dokumentasi, pengembangan sistem, registrasi hingga penanangan masalah SPSE. Kebijakan dan SOP ini juga sudah disosialisasikan dan didistribusikan ke setiap LPSE yang ada di instansi pusat maupun daerah. Menurut penulis, dari mempelajari dokumentasi online terkait kebijakan dan SOP-SOP yang ada, harusnya sudah tidak ada lagi permasalahan yang berlarut-larut dengan sistem SPSE, karena SOPnya sudah sedemikian lengkap dan jelas hingga setiap penanganannya. Setiap bagian/unit/komponen LPSE sudah memiliki tanggungjawab dan kewenangan masing masing. Sekarang tinggal bagaimana melakukan monitoring terhadap implementasi di lapangan, apakah semua SOP telah dilakukan secara baik, atau masih banyak aktifitas yang tidak sesuai dengan SOP tersebut, dan bagaimana proses pemberian sanksi jika ternyata terdapat pelanggaran atau tidak sesuai Kebijakan dan SOP tersebut.

Masih terkait kebijakan dan SOP, dari hasil pencarian online, penulis menemukan dokumen SOP LPSE yang cukup lengkap dan detil dipublish oleh salah satu LPSE Kementerian. SOP ini terdiri dari 400 halaman. Menurut analisis penulis, dari keseluruhan isi dokumen SOP ini, banyak informasi yang harusnya hanya diketahui kalangan terbatas, yaitu komunitas Pengelola LPSE saja, hal ini adalah untuk menjaga informasi tersebut tidak disalahgunakan oleh pihak yang tidak bertanggung jawab. Penulis mengkategorikan beberapa informasi pada dokumen SOP tersebut sebagai “Information Leakage” yang harusnya bisa diminimalkan. SOP-SOP yang terpublish secara online harusnya adalah yang memang berhubungan dengan layanan pengguna atau masyarakat luas. Informasi yang dapat disalahgunakan para cracker/hacker pada SOP yang terpublish tersebut antara lain :

– Proses Instalasi SPSE, Framework SPSE hingga detil framework SPSE
– Konfigurasi Web, Path Konfigurasi, Konfigurasi Database hingga File Log System/Aplikasi
– Daftar paket aplikasi dan aplikasi pendukung, path Aplikasi hingga versi setiap aplikasi
– Konfigurasi Keamanan Web, penggunaan Web Application Firewall dan Module keamanan lainnya
– Nama Database, User dan Password database yang digunakan untuk latihan dan production
– Instruksi-instruksi monitoring Log, pengamanan datacenternya, informasi backup & recover
– Prosedur penangan insiden keamanan, infrastruktur, dan sistem

Jika para hacker/attacker mendapatkan informasi informasi diatas dengan mudah, artinya kelemahan dari sistem SPSE tersebut otomatis menjadi relatif lebih mudah juga didapatkan. Demikian juga untuk menemukan cara-cara evasion dari setiap filter/proteksi yang dilakukan oleh sistem SPSE, sehingga kemungkinan untuk dipenetrasi/exploitasi semakin besar. Pada proses pengamanan sistem informasi, terdapat lapisan keamanan yang biasa disebut dengan istilah “Security by Obscurity”, artinya untuk keamanan sistem, kita dapat menambahkan lapisan untuk mempersulit para attacker/hacker menemukan informasi-informasi mengenai jenis teknologi, konfigurasi, teknik proteksi hingga versi aplikasi yang kita gunakan. Selain dengan tidak mempublish jenis aplikasi, versi aplikasi dan konfigurasi, kita juga bisa membuat seolah-olah jenis aplikasi atau versinya tidak sesuai dengan kenyataanya. Bukan berarti kita hanya memanfaatkan lapisan tersebut sebagai satu satunya pengaman sistem, tetapi kita hanya menjadikannya sebagai salah satu lapisan keamanan tambahan, sehingga para attacker terutama para “kiddies” relatif lebih sulit untuk menemukan informasi tersebut. Sedangkan lapisan-lapisan keamanan lainnya tetap masih harus diaktifkan atau dilakukan.

Sumber: https://infosec.id/2016/05/lpse-insecurity/

Hari ini cukup heboh berita tentang pembajakan domain IDSIRTII (idsirtii.or.id) yang dilakukan oleh attacker. Pembajakan domain IDSIRTII ini berakibat akses ke situs IDSIRTII diarahkan ke sebuah situs yang disiapkan attacker dengan pesan seperti layaknya “web defacing”. Banyak juga media yang terkecoh memberitakan bahwa situs IDSIRTII disusupi attacker tersebut.
Dari hasil internet forensic, dari artifak artifak di internet serta history perubahan DNS IDSIRTII sangat mirip dengan kasus presidensby.info yang pernah saya bahas di sini dan di sini

Berikut perubahan yang terjadi pada Administrative Domain idsirtii.or.id yang dilakukan oleh attacker.
Attacker melakukan perubahan DNS Server untuk domain idsirtii.or.id menjadi ke dua server dns yang dihosting pada Cloud Flare yakni IAN.NS.CLOUDFLARE.COM (173.245.59.118) dan SARA.NS.CLOUDFLARE.COM (173.245.58.144). Pada kedua DNS Cloud Flare tersebut, si attacker sudah menambahkan zone domain idsirtii.or.id sebelumnya dan dimapping ke IP 104.31.92.5 dan 104.31.93.5. Pada kedua IP webserver tersebut (104.31.92.5 dan 104.31.93.5) sudah disiapkan halaman layaknya “web defacing”, sehingga banyak pihak yang berfikir bahwa server idsirtii.or.id benar-benar disusupi. IP DNS Server yang seharusnya mengelola idsirtii.or.id adalah
idsirtii.or.id.        3600    IN    NS    ns1.twisted4life.com.
idsirtii.or.id.        3600    IN    NS    puck.nether.net.
idsirtii.or.id.        3600    IN    NS    ns1.rollernet.us.
idsirtii.or.id.        3600    IN    NS    ns2.rollernet.us.
idsirtii.or.id.        3600    IN    NS    nsus.idsirtii.or.id.

Dan IP Server (IN A) idsirtii.or.id harusnya adalah :

idsirtii.or.id.        3600    IN    A    203.34.118.11

Perubahan DNS tersebut dapat digambarkan sebagai berikut :

Perubahan DNS IDSIRTII

Pertanyaannya, bagaimana mungkin attacker dapat merubah setting administrative domain idsirtii.or.id. Hingga saat ini masih dilakukan investigasi pihak pihak yang berkepentingan mulai dari Registrant (IDSIRTII), Registrar (IDWebHost?) dan PANDI (pengelola Domain ID). Beberapa kemungkinan antara lain bahwa attacker melakukan akses ilegal terhadap account pengelola domain tersebut, baik ditingkat registrar maupun account pengguna (registrant). Dari informasi di media, pengelola IDSIRTII menyebutkan bahwa adanya kemungkinan serangan social engineering pada registrar , sehingga kemungkinan registrar terkecoh melakukan perubahan DNS tersebut.

Baik, kasus tersebut harusnya menjadi pelajaran bagi pemilik & pengelola domain serta pemilik situs di Indonesia. Karena pada dasarnya ancaman seperti ini sangat banyak terjadi di internet dan bisa menimpa siapa saja. Dan yang perlu saya tekankan adalah bahwa hingga saat inipun, beberapa situs berita maupun instansi utama milik indonesia juga dapat mengalami hal yang sama.
Berikut beberapa domain/situs yang kemungkinan menjadi target berikutnya dengan metode yang sama. Mengapa saya informasikan demikian? Karena beberapa zone domain pada daftar dibawah ini juga sudah disiapkan pada DNS Server yang sama dengan DNS yang digunakan attacker diatas yakni pada server IAN.NS.CLOUDFLARE.COM (173.245.59.118) atau SARA.NS.CLOUDFLARE.COM (173.245.58.144).

1. polri.go.id

#dig @SARA.NS.CLOUDFLARE.COM polri.go.id

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> @173.245.58.144 polri.go.id
;; QUESTION SECTION:
;polri.go.id.            IN    A

;; ANSWER SECTION:
polri.go.id.        300    IN    A    104.28.20.52
polri.go.id.        300    IN    A    104.28.21.52

;; Query time: 29 msec
;; SERVER: 173.245.58.144#53(173.245.58.144)

Informasi yang benar harusnya:

#dig polri.go.id

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> polri.go.id

;polri.go.id.            IN    A

;; ANSWER SECTION:
polri.go.id.        4469    IN    A    203.130.236.199

;; AUTHORITY SECTION:
polri.go.id.        2757    IN    NS    ns1.polri.go.id.

;; ADDITIONAL SECTION:
ns1.polri.go.id.    36181    IN    A    203.130.236.196

;; Query time: 0 msec
;; SERVER: 175.111.88.2#53(175.111.88.2)

2. detik.com

#dig @SARA.NS.CLOUDFLARE.COM detik.com

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> @173.245.58.144 detik.com

;; QUESTION SECTION:
;detik.com.            IN    A

;; ANSWER SECTION:
detik.com.        300    IN    A    104.31.71.138
detik.com.        300    IN    A    104.31.70.138

;; Query time: 29 msec
;; SERVER: 173.245.58.144#53(173.245.58.144)

Informasi yang benar harusnya :

#dig  detik.com

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> detik.com

;; QUESTION SECTION:
;detik.com.            IN    A

;; ANSWER SECTION:
detik.com.        62    IN    A    203.190.241.43
detik.com.        62    IN    A    203.190.242.69

;; AUTHORITY SECTION:
detik.com.        59274    IN    NS    ns.detik.net.id.
detik.com.        59274    IN    NS    ns1.detik.com.
detik.com.        59274    IN    NS    ns1.detik.net.id.
detik.com.        59274    IN    NS    ns.detik.com.

;; ADDITIONAL SECTION:
ns.detik.com.        2096    IN    A    203.190.242.2
ns.detik.net.id.    66175    IN    A    203.190.242.2
ns1.detik.com.        2096    IN    A    203.190.240.131
ns1.detik.net.id.    67936    IN    A    203.190.240.131

;; Query time: 0 msec
;; SERVER: 175.111.88.2#53(175.111.88.2)

3. kompas.com

dig @SARA.NS.CLOUDFLARE.COM kompas.com

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> @173.245.58.144 kompas.com
;; QUESTION SECTION:
;kompas.com.            IN    A

;; ANSWER SECTION:
kompas.com.        300    IN    A    104.28.9.90
kompas.com.        300    IN    A    104.28.8.90

;; Query time: 27 msec
;; SERVER: 173.245.58.144#53(173.245.58.144)
;; WHEN: Mon May 25 22:30:11 WIB 2015
;; MSG SIZE  rcvd: 71

Informasi yang harusnya :

dig  kompas.com

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> kompas.com

;; QUESTION SECTION:
;kompas.com.            IN    A

;; ANSWER SECTION:
kompas.com.        360    IN    A    202.61.113.35
kompas.com.        360    IN    A    202.146.4.100

;; AUTHORITY SECTION:
kompas.com.        69254    IN    NS    ns1.kidsklik.com.
kompas.com.        69254    IN    NS    ns2.kidsklik.com.

;; ADDITIONAL SECTION:
ns1.kidsklik.com.    3857    IN    A    202.146.4.250
ns2.kidsklik.com.    3857    IN    A    202.61.112.10

;; Query time: 13 msec
;; SERVER: 175.111.88.2#53(175.111.88.2)
;; WHEN: Mon May 25 22:30:53 WIB 2015
;; MSG SIZE  rcvd: 148

4. kaskus.co.id

#dig @SARA.NS.CLOUDFLARE.COM kaskus.co.id

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> @173.245.58.144 kaskus.co.id

;; QUESTION SECTION:
;kaskus.co.id.            IN    A

;; ANSWER SECTION:
kaskus.co.id.        300    IN    A    104.28.13.87
kaskus.co.id.        300    IN    A    104.28.12.87

;; Query time: 27 msec
;; SERVER: 173.245.58.144#53(173.245.58.144)
;; WHEN: Mon May 25 22:24:40 WIB 2015
;; MSG SIZE  rcvd: 73

Yang benar harusnya adalah:
;; QUESTION SECTION:
;kaskus.co.id.            IN    A

;; ANSWER SECTION:
kaskus.co.id.        64963    IN    A    103.6.117.2
kaskus.co.id.        64963    IN    A    103.6.117.3

;; AUTHORITY SECTION:
kaskus.co.id.        9971    IN    NS    ns1.lumanau.web.id.
kaskus.co.id.        9971    IN    NS    ns3.lumanau.web.id.
kaskus.co.id.        9971    IN    NS    ns4.lumanau.web.id.
kaskus.co.id.        9971    IN    NS    ns2.lumanau.web.id.

Selain domain/situs diatas, kemungkinan masih ada beberapa domain lainnya. Saya tidak ada waktu untuk mengecek, silahkan bagi yang mau menambahkan dengan memberi komentar pada pesan dibawah.  Mudah mudahan para pemilik domain/situs serta pengelola domain (registrar) semakin aware terhadap ancaman ancaman terkait DNS sejenis ini.

Semoga bermanfaat.