Feed on
Posts
Comments

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.

Berbagai berita terkait dugaan Server SiREKAP di Luar Negeri

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.

Salah satu judul temuan “ahli”

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”.

Publikasi untuk acara FGD tersebut.

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.

Salah satu PoC serangan DDoS pada SSO.kpu.go.id

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.

CNAME/Alias Sirekap-api dan sirekap-web per 13 Februari 2024 (sebelum hari H)

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

sirekap-obj-dataCNAMEjson-public-prod.oss-ap-southeast-5.aliyuncs.com
$host json-public-prod.oss-ap-southeast-5.aliyuncs.com
json-public-prod.oss-ap-southeast-5.aliyuncs.com has address 149.129.201.14

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:

CNAME/Alias sirekap-api, sirekap-web, sirekap-obj-data, sirekap-obj-formc sejak 15 Februari 2024 (Setelah H+1)

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.

Contoh Skema Anti DDoS Alibaba Cloud

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.

pemilu2024CNAMEpemilu2024.kpu.go.id.w.cdngslb.com

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.

SiRekap Pemilu 2024 – APK

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).

Mengandung host *.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.

Versi Sirekap 2024 & Tanggal Publish di PlayStore

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.

BuildConfig SiRekap 2024 v.2.30 – dst
BuildConfig SiRekap v.2.4 (STG)

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).

Signer Certificate SiREKAP 2024
Keystore File & Certificate yang disertakan pada SiREKAP

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.

File tflite, object tensorflow lite, hasil training ML untuk OCR SiREKAP

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.

TPS lainnya (contoh TPS 49.pdf) menggunakan title pdf.kpu.go.id (wkhtmltopdf)
View TPS 49.pdf (Banguntapan Bantul) dan TPS lainnya
View TPS 50.pdf (beda sendiri dengan TPS yang lain)
Metadata File DPT 50.pdf (beda dengan lainnya)

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.

mobile-forensicsINFOsec.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:

Screenshot from 2017-06-05 04:01:00 Screenshot from 2017-06-05 03:57:33Screenshot from 2017-06-05 03:58:40

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.

tidak hapus chat

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]

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 : 25-28 April 2017 (4 Days) Pukul 9.00 – 15.00 WIB
Lokasi: Meeting Room Hotel or RootBrain Classroom, 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]

saksi-ahli-sebut-kasus-jessica-tidak-perlu-pembuktian-langsung-tmalj4FZt4INFOsec.ID – Hampir dua bulan sejak dimulainya sidang kasus Jessica disaksikan melalui siaran langsung pada salah satu TV Swasta Nasional hingga saat ini masih saja menarik banyak perhatian masyarakat, penegak hukum (Aparat/Jaksa), para advokat dan juga para IT Professional maupun para anggota Asosiasi Forensik Digital Indonesia. Selain dari siaran langsung, masyarakat juga dapat menonton rekamannya di media online Youtube. Sidang kasus Jessica ini memang sangat menarik, selain mendatangkan saksi saksi dan ahli yang super banyak, baik dari dalam negeri, juga berasal dari Luar Negeri. Menariknya para saksi ahli yang dihadirkan memiliki profesi yang hampir sama, dari sisi Jaksa Penuntut Umum (JPU) maupun Penasehat Hukum Terdakwa (PH). Mulai dari Professional dibidangnya hingga berasal dari para Akademisi. Celakanya, banyaknya saksi ahli yang dihadirkan dipersidangan dengan pandangan masing masing yang inti pendapatnya sangat bertolak belakang antara ahli yang dihadirkan Jaksa Penuntut Umum (JPU) dengan yang dihadirkan Penasehat Hukum Terdakwa (PH). Hal ini tentu saja membuat banyak masyarakat yang mengikuti jalannya persidangan menjadi kebingungan atau tidak memahami pendapat Ahli mana yang benar. Hal ini juga mempengaruhi banyak media akhir akhir ini mulai ikut-ikutan memberitakan hal hal yang mungkin dapat dikategorikan sebagai penggiringan opini terkait kasus Jessica. Pada persidangan kasus Jessica yang lalu turut dihadirkan beberapa ahli Digital Forensik untuk memaparkan hasil analisisnya terhadap barang bukti yang didapatkan dari penyidik. Barang bukti tersebut berupa USB Flashdisk yang menyimpan video CCTV hasil ekstraksi dari DVR sistem monitoring CCTV di Cafe Olivier (TKP). Pada perjalanan sidang ke 21, ternyata Pihak PH juga mengajukan seorang Ahli (IT) yang berasal dari Akademisi, pada persidangan tersebut, si Ahli (IT) yang didatangkan PH mengungkapkan dan menyatakan dugaan (atau “tuduhan”) bahwa video CCTV yang digunakan oleh Ahli Digital Forensic kubu JPU sudah melalui proses tampering yang bertujuan tidak baik. Dan pernyataan dan pendapat Ahli IT dari PH ini banyak digunakan pada referensi berbagai berita Online maupun Offline (surat khabar), dengan menyatakan bahwa alat bukti CCTV diduga kuat sudah dilakukan tampering yang bertujuan menyudutkan pihak terdakwa. Pendapat Ahli IT dari PH terdakwa ini juga dijadikan bahan rujukan dalam nota pembelaan dari PH. Pada nota pembelaan tersebut disebutkan bahwa bukti CCTV yang digunakan oleh JPU bukan merupakan dari alat bukti aslinya, tetapi merupakan hasil kloning dari alat bukti. Pihak PH terdakwa juga menyebutkan bahwa Video CCTV sudah melalui proses editing (menggabung-gabung/disambung-sambung) sehingga tidak layak dijadikan barang bukti dipengadilan.

Pada artikel kali ini, penulis yang juga sering diminta bantuan sebagai ahli pada berbagai kasus baik saat penyidikan di kepolisian maupun saksi ahli di persidangan akan mencoba meluruskan beberapa informasi atau pengetahuan terkait Digital Forensik yang saat ini menjadi rancu atau kurang tepat dipublikasikan di berbagai media massa berkaitan persidangan kasus Jessica tersebut. Beberapa berita dan pendapat Ahli yang kurang tepat menurut saya seperti pendapat pada berita ini . Pada berita tersebut disebutkan bahwa CCTV hasil kloning tidak dapat dijadikan bukti menjerat Jessica. Ahli Mudzakir juga menyebutkan bahwa bentuk rekaman CCTV yang dihadirkan JPU harus aslinya dalam format DVR.

Pada berita di tribun disebutkan “Tayangan CCTV tak autentik dan diragukan. Rekaman CCTV merupakan kloningan bukan barang bukti asli untuk diputar,” ujar Yudi saat membacakan nota pembelaan di sidang kasus pembunuhan Mirna di Pengadilan Negeri (PN) Jakarta Pusat, Kamis (13/10).

Sebelum memberi komentar dan meluruskan informasi dari pemberitaan pemberitaan diatas, penulis akan mencoba memaparkan apa yang dimaksud dengan digital forensik, apa itu Video/CCTV Forensik dan apa bedanya dengan Computer Forensik, bagaimana standard prosedur untuk penanganan CCTV sebagai alat bukti, Apakah boleh ahli digital forensik melakukan tampering seperti menyambung/menggabung-gabung video, melakukan enhancement (memperbesar/zooming, meningkatkan kualitas gambar/contrash/sharpen atau dengan algoritma tertentu) dst? Sejauh apa tampering yang dapat dilakukan Ahli Digital Forensik? Siapa saja sebenarnya yang layak dapat disebut sebagai Ahli Digital Forensik dan siapa yang hanya layak sebagai Ahli IT (Multimedia), Bagaimana melakukan verifikasi ulang (untuk membantah/menganulir) terhadap hasil analisis Ahli Digital Forensik.

Apa yang dimaksud dengan Digital Forensik ?

Digital Forensik adalah satu cabang ilmu forensik yang berkaitan dengan bukti legal yang ditemukan pada sistem komputer dan media penyimpanan digital. Digital forensik merupakan penggunaan teknik analisis dan investigasi untuk mengidentifikasi/ menemukan, mengumpulkan, memeriksa dan menyimpan bukti/informasi pada sistem komputer atau media penyimpanan digital dengan sebuah standard dan dokumentasi tertentu untuk dapat diajukan sebagai bukti hukum yang sah. Pengertian dan contoh selengkapnya bisa dibaca pada presentasi penulis berikut.
Penulis sengaja menggarisbawahi atau memberi huruf tebal pada kata Standard dan Dokumentasi dimaksudkan agar pembaca lebih memahami bahwa setiap aktifitas dalam kegiatan forensik ada Standard yang berupa SOP/Guidelines yang harus diikuti setiap Examiner atau Digital Forensik Investigator dalam melakukan setiap tahapan tugas digital forensik (Examiner atau investigator merupakan sebutan bagi yang melakukan kegiatan digital forensic). Kemudian ada Dokumentasi yang artinya setiap tahapan aktifitas digital forensik, examiner/investigator harus mendokumentasikan setiap kegiatan dan temuan temuannya. Sejak mulai menerima Barang bukti, Akusisi, Analisa hingga Pelaporan. Dokumentasi ini biasanya berisi informasi-informasi teknis yang dilakukan oleh examiner/investigator Digital Forensik, sehingga jika suatu saat harus disampaikan di pengadilan dapat dijelaskan secara runtut/gamblang bagaimana proses hingga menemukan petunjuk/informasi digital yang dapat menjadi bukti bukti untuk menjelaskan kejadian/kasus tersebut. Dokumentasi ini juga akan diperlukan jika suatu saat di sidang/pengadilan harus dilakukan pemeriksaan kembali oleh ahli digital forensic / examiner lain (cross-examination), sehingga dari mempelajari dokumentasi digital forensic sebelumnya si Ahli Digital Forensic / Examiner lain dapat mengetahui bagaimana petunjuk/bukti digital pada barang bukti tersebut sebelumnya dianalisis dan ditemukan, dengan mengikuti tahapan dan petunjuk pada dokumentasi, ahli digital forensic lainnya mendapatkan hasil yang sama, ini juga yang membuktikan bahwa digital forensik adalah ilmu exact/ilmu pasti. Jadi pada prinsipnya, dokumentasi memungkinkan semua kegiatan forensic menjadi repeatable, artinya semua proses yang dilakukan oleh examiner/investigator harus dapat diulang dan menghasilkan petunjuk/hasil dan kesimpulan yang sama.

Apa yang dimaksud dengan video CCTV forensik? Dan apa bedanya dengan Computer Forensic?

Video (CCTV) Forensik dan Computer Forensic merupakan sub bidang dari Digital Forensik. Selain Video (CCTV) Forensik dan Computer Forensik, ada beberapa sub bidang Digital Forensik lainnya seperti Mobile Forensic, Hacking/Cyber Forensic, Audio Forensic, Image Forensic, Malware Forensic dan Memory Forensic.
Video (CCTV) Forensik merupakan teknik analisis dan investigasi untuk mengidentifikasi/ menemukan, mengumpulkan, memeriksa petuntuk dan bukti digital yang berupa Video atau rekaman CCTV. CCTV sendiri ada dua jenis, yakni Digital CCTV dan Analog CCTV. Secara umum Teknologi CCTV terbaru sudah menggunakan Digital Closed Circuit Television (DCCTV) merekam ke media digital (Storage/HDD) dengan memanfaatkan sistem DVR (Digital Video Recording System), sedangkan teknologi analog adalah teknologi lama yang merekam CCTV hanya dengan Kaset VHS.
Pada Video (CCTV) Forensik, secara umum operator/pemilik CCTV (DVR) biasanya tidak terlibat dalam kasus atau bukan merupakan pelaku kejahatan/tersangka pada kasus yang ditangani, sehingga tidak ada keharusan penyidik ataupun investigator untuk mendapatkan semua sistem dan konten Video yang terekam pada CCTV/DVR, hanya video rekaman dengan parameter tertentu dan berhubungan dengan kasus (orang orang yang terlibat spt korban/saksi-saksi atau terduga pelaku) atau pada durasi waktu kejadian yang akan dilakukan pengambilan data/akusisi oleh pihak penyidik/investigator. Investigator tidak perlu melakukan akusisi semua sistem aplikasi dan data DVR yang dapat berakibat tidak berjalannya sistem monitoring CCTV saat akusisi. Pada prosedur pengambilan rekaman (retrieve video) atau ekstraksi DVR direkomendasikan agar proses recording system (merekam) tetap berjalan seperti biasa. Detail prosedur dapat dibaca pada bagian pertanyaan berikutnya. Berbeda halnya dengan Computer Forensik, dimana kegiatan komputer forensik biasanya melibatkan perangkat milik terduga seorang pelaku kejahatan/tersangka sehingga harus menggunakan metodologi Computer Forensik, yang biasanya terdapat prosedur imaging/bit-stream copy (Istilah awam menyebutnya kloning ) memory sistem dan seluruh storage dan aplikasi yang terinstall, sehingga investigator/examiner dapat merekonstruksi semua sistem dan aplikasi yang digunakan si pelaku kejahatan/tersangka dengan menganalisis data-data yang sudah di imaging/bit-stream copy (kloning) tersebut. Dari hasil imaging/bit-stream copy (kloning), investigator/examiner dapat mencari data/informasi baik yang sudah terhapus (melalui proses recovery) maupun yang masih tersedia di sistem komputer yang menjadi barang bukti tersebut.

Bagaimana standard prosedur untuk penanganan rekaman CCTV sebagai alat bukti yang sah?

Ketika suatu kejadian kasus terjadi di sebuah lokasi (misalnya Cafe/Ruang publik/jalan raya dst) yang terdapat Camera CCTV merekam kejadian, maka pihak penyidik dapat langsung menggali/mencari informasi terkait sistem CCTV kepada pemilik CCTV/management dan penyidik juga dapat meminta kepada operator/pemilik sistem CCTV untuk menunjukkan rekaman yang terkait kasus tersebut berdasarkan parameter waktu, lokasi kejadian dan penampakan orang orang yang mungkin terlibat pada kasus tersebut. Jika memang rekaman CCTV menunjukkan adanya petunjuk terkait kasus tersebut, maka penyidik dapat secara resmi meminta rekaman yang relevan tersebut dengan membuatkan berita acara pengambilan barang bukti. Jika sistem CCTV menggunakan sistem DVR (Digital Video Recording) dan penyidik memahami atau mampu mengoperasikan sistem DVR tersebut, maka penyidik dapat langsung melakukan ekstraksi (retrieve video) DVR ke media penyimpanan yang tersedia (mulai CD/DVD/USB HDD External/USB Flashdisk) pada sistem DVR didampingi pemilik/operator. Jika penyidik tidak familiar dengan sistem DVR, maka dapat meminta Ahli/Engineer (yang mengetahui cara kerja sistem DVR tersebut) atau jika tidak ada, maka penyidik dapat meminta Operator atau Pemilik CCTV yang sudah familiar untuk melakukan ekstraksi (retrieve) Video ke media penyimpanan yang tersedia.

Berikut prosedur Ekstraksi (Retrieve) rekaman Video dari DVR saya ambil dari ACPO CCTV/Video Working Group.

SOP-CCTV-Retrieve

Setelah ekstraksi Video CCTV dari DVR sudah didapatkan dan berhasil disimpan di suatu media penyimpanan (seperti DVD atau USB Flashdisk/HDD External), maka langkah ideal selanjutnya adalah melakukan checksum integritas data pada media penyimpanan melalui proses hashing file file video tersebut. Kemudian mencatatkan/ menambahkan/ melampirkan pada berita acara pengambilan barang bukti, sehingga pihak penyidik dan pemilik CCTV/DVR sama sama mengetahui/menyetujui bahwa video rekaman tersebut memang diambil dari CCTV/DVR mereka.
Media penyimpanan digital, seperti DVD atau USB Flashdisk/HDD yang digunakan untuk menyimpan file file video hasil ekstraksi DVR/CCTV tersebut dapat disebut sebagai barang bukti asli (Master).
Langkah selanjutnya, biasanya penyidik akan meminta bantuan Ahli Digital Forensic (Video Examiner/Investigator) untuk melakukan analisis terhadap rekaman video pada media yang menjadi barang bukti tersebut. Setelah membuatkan prosedur serah terima barang bukti dan berita acara pemeriksaan bukti, Ahli Digital Forensic pertama kali akan melakukan tahapan awal Forensik Digital yakni imaging/bit-stream copy terhadap barang bukti, yaitu proses duplikasi barang bukti ke dalam bentuk salinan (copy) yang identik. Sebelum melakukan imaging/bit-stream copy, diwajibkan examiner memastikan sudah memasang write blocker atau safe-block yakni proteksi untuk memastikan tidak ada perubahan pada Master saat dilakukannya imaging/bit-stream copy dari media Master ke Media lainnya. Proses Imaging/Bit-stream copy salinan ini dapat ke media yang jenisnya sama (copy dan master sama sama berupa flashdisk/DVD/HDD ) atau dapat juga menjadi sebuah file image yang disimpan pada media storage yang lebih besar (biasanya berupa HDD). Bit-Stream Copy dan Master dari barang bukti ini identik, dan harus memiliki nilai hash/check integritas yang sama, dan secara saintifik kedua konten hasil imaging dan Master ini bisa dipastikan sama persis. Beberapa pihak atau masyarakat awam sering menyebut hasil imaging/bit-stream copy ini sebagai hasil kloning dari barang bukti. Hasil Imaging/Bit-Stream Copy inilah yang akan dianalisa oleh pihak Ahli Digital Forensic (Video Examiner/Investigator). Sedangkan barang bukti asli (Master) disimpan dengan aman sebagaimana barang bukti lainnya. Secara prosedur Ahli Digital Forensik hanya perlu menganalisa hasil imaging atau bit-stream copy atau sering yang masyarakat sebut sebagai hasil kloning, karena sudah dipastikan sama hasilnya dengan barang bukti asli (Master). Master hanya dapat diakses kembali jika dan hanya jika perlu dilakukan cross-examination oleh pihak lain (misalnya oleh ahli yang didatangkan PH Terdakwa). Akses tersebut juga hanya bertujuan untuk melakukan imaging atau bit stream-copy kembali, dalam rangka verifikasi hasil imaging/copy-bit stream adalah sama dengan yang dianalisis secara digital forensik oleh Ahli. Ahli Forensic digital pihak manapun tidak diperkenankan melakukan analisis langsung dari barang bukti master untuk mencegah kerusakan pada barang bukti. Setiap ahli digital forensik (examiner/investigator) hanya dapat melakukan analisis dari hasil imaging/copy bit-stream yang telah dilakukan, dan secara prosedur para examiner/investigator sudah sama sama memahami hal tersebut.

Apakah diperkenankan seorang ahli digital forensik melakukan tampering seperti menyambung-nyambung/menggabung-gabung video, melakukan enhancement (memperbesar/zooming, meningkatkan kualitas gambar/contrash/sharpen atau dengan algoritma tertentu) dst? Sejauh apa tampering yang dapat dilakukan Ahli Digital Forensik?

Untuk tujuan mempermudah menganalisis beberapa video yang umumnya berjumlah cukup banyak dan diambil dari beberapa camera pada saat yang bersamaan, maka ahli digital forensic (examiner/investigator) sah sah saja melakukan compositing video (menggabung atau menyambung video). Termasuk juga untuk mempermudah memahami kejadian dengan cara melakukan enhancement (meningkatkan kualitas gambar/video), sehingga setiap event/gerakan atau penampakan pada video lebih mudah dikenali atau dipahami dalam rangka mendapatkan petunjuk dan bukti-bukti pada saat kejadian berlangsung. Perlu diingat kembali bahwa semua proses tampering (menggabung/menyambung atau meningkatkan kualitas gambar/enhancement) pada rekaman video harus didokumentasikan secara lengkap, dan semua proses tampering ini dilakukan oleh Ahli Digital Forensic (examiner/investigator) hanya terhadap data/file video yang ada pada media hasil imaging/bitstream-copy atau hasil kloning, dan tidak boleh dilakukan pada barang bukti asli (Master). Tampering pada rekaman video-video CCTV hanya untuk bertujuan memudahkan proses analisis serta peningkatan kualitas (enhancement) atau mempertegas suatu kejadian yang tampak pada video, dan tentu saja tidak diperkenankan digunakan untuk mengubah informasi atau kejadian yang sesungguhnya (contoh tampering yang tidak diizinkan seperti mengedit beberapa frame sehingga menampilkan sesuatu yang berbeda dengan kejadian aslinya, mengurangi atau menambah frame lain). Jika terjadi tampering yang tujuannya tidak baik (mengubah informasi dan kejadian yang sesungguhnya), pasti akan dengan mudah ketahuan atau dideteksi, karena setiap aktifitas digital forensik harus sesuai prosedur, kode etik ahli forensik yang mewajibkan objektif dan bersifat netral, serta didokumentasikan dengan lengkap sehingga proses analisa dengan teknik/tahapan yang sama mengasilkan hasil yang sama pula atau disebut repeatable yang artinya bila pengujian dilakukan oleh ahli digital forensik (examiner/investigator) lainnya, misalnya saat terjadi cross-examination maka harus ditemukan hasil yang sama, dengan catatan menggunakan prosedur dan teknik teknik analisis yang sama seperti pada dokumentasi.

Siapa yang sebenarnya layak dapat disebut sebagai Ahli Digital Forensik ? dan siapa yang hanya layak sebagai Ahli IT (Multimedia) ?

Menurut penulis, ahli Digital Forensik adalah profesi yang sangat unik, karena tidak hanya membutuhkan skill ataupun akademik yang baik pada bidang TI, tetapi juga pengalaman yang mumpuni dalam menangani kasus-kasus real (hukum) yang melibatkan komputer dan media digital. Secara umum ahli digital forensik adalah orang orang yang berpengalaman dan sudah sering terlibat dalam penanganan kasus hukum yang melibatkan media digital atau komputer dengan menggunakan prosedur (SOP-SOP) tahapan forensik digital, terlatih dan terbiasa menggunakan berbagai tools forensik, juga familiar membuat dokumentasi laporan forensik serta memahami dan patuh terhadap kode etik digital forensic examiner/investigator yang objective dan bersifat netral dalam berpendapat. Bidang keahlian dan llmu pengetahuan lain yang berhubungan erat dan terkait dengan Digital Forensik juga sangat diperlukan sebagai ahli Digital forensik sesuai dengan sub bidang masing masing, misalnya skill Network/Security dan Internet (Cyber Forensic), Programming/Reverse Engineering (Malware Forensic), Multimedia (Audio/Video/Image Forensic). Tetapi tidak berarti orang orang yang memiliki keahlian dan pengetahuan bidang bidang tersebut otomatis dapat disebut sebagai ahli digital forensic. Misalnya, apakah seseorang yang ahli bidang network/security atau berprofesi sebagai network/security engineer lantas dapat disebut sebagai ahli cyber forensic? Atau Apakah seseorang yang lulusan S3 (Doktor) bidang Multimedia lantas dapat disebut sebagai Ahli Video Forensic ? Atau apakah seseorang yang pernah berpengalaman ikut pelatihan atau workshop Digital (Video) Forensic otomatis langsung dapat disebut sebagai Ahli Digital Forensik? Atau bahkan pada pertanyaan, apakah orang yang certified salah satu/dua bahkan tiga Sertifikasi Digital Forensic (nasional/internasional) lantas dapat disebut sebagai Ahli Digital Forensik? Jika pertanyaan ditujukan kepada penulis dan mungkin ke beberapa rekan penulis, maka jawabannya adalah TIDAK!. Selama seorang ahli tersebut belum pernah berpengalaman ikut menangani kasus hukum yang melibatkan media digital/komputer dan mengimplementasikan/mengikuti SOP forensik digital, menggunakan tools forensik yang terstandarisasi (tools yang juga digunakan berbagai organisasi/lembaga law enforcement), dan belum pernah membuat laporan forensic atau tidak memahami kode etik (examiner/investigator) atau expert witness saat di-pengadilan seperti menduga adanya tampering tanpa melakukan investigasi/examination dengan prosedur yang benar, maka tentu saja tidak layak disebut sebagai Ahli Digital Forensik. Jika ada media atau di pengadilan menyebut mereka sebagai Ahli IT (Multimedia) atau Ahli Network/Security, Ahli Malware dst, penulis tidak akan mempermasalahkan karena memang sesuai dengan kompentensi bidang yang mereka geluti. Tetapi jika mereka yang sebenarnya tidak layak disebut sebagai Ahli Digital Forensik malah dijadikan sebagai referensi yang seolah-olah sudah melakukan prosedur digital forensik, maka mungkin akan terjadi “bencana” dan penyimpangan ilmu pengetahuan forensik khususnya Digital Forensik seperti yang terjadi pada persidangan kasus Jessica yang melibatkan CCTV yang lalu. Celakanya, banyak media yang menganggap pernyataan ahli ini adalah pendapat yang benar sebagai ahli digital forensik sehingga banyak yang mengutipnya sebagai judul-judul berita, seperti judul berikut:
berita-tribun-kloning-cctv
Bagaimana cara melakukan verifikasi ulang (untuk membantah/menganulir) terhadap hasil analisis seorang Ahli Digital Forensik (Cross-Examination).

Pada prinsipnya semua Ahli Digital Forensik harus siap dan bersedia jika analisanya harus dilakukan cross-examination oleh examiner/investigator atau Ahli Digital Forensik lain. Karena pada dasarnya atau secara kode etik Ahli Digital Examiner itu dari awal sudah objective dan netral, maka tidak mungkin ada kekuatiran jika Barang Bukti akan dilakukan analisis oleh pihak lain. Hanya perlu diperhatikan kompetensi dan kesiapan ahli lain yang akan melakukan examination/investigation, apakah memang sudah layak disebut sebagai Ahli Digital Forensik yang memang berpengalaman menangani alat bukti kasus real ? Atau hanya mampu ber-acting atau sekedar mengetahui apa tugas ahli Digital Forensik tanpa memiliki pengalaman dan kompetensi yang layak? Karena dampak/akibatnya bisa fatal jika seseorang hanya menganggap dirinya layak sebagai Ahli Digital Forensik (Examiner/Investigator), tetapi tidak paham prosedur prosedur penanganan alat bukti yang baik. Misalnya contoh yang sederhana, jika seseorang Ahli Digital Forensik ketika ditanya dan tidak tahu apa yang dimaksud dengan Write Blocker dan kegunaannya maka sudah dipastikan ahli forensik tersebut adalah abal-abal atau tidak pantas disebut ahli digital forensic.
Idealnya yang menyatakan seorang Examiner/Investigator atau Ahli Digital Forensik sudah layak untuk melakukan cross-examination adalah para Hakim yang memimpin persidangan kasus tersebut dengan melakukan verifikasi atau menanyakan latar-belakang ahli, credential dan pengalaman pengalaman menangani kasus dan barang bukti dengan Digital Forensik. Jika dari hasil verifikasi ahli belum berpengalaman atau tidak pernah menangani alat bukti dengan Digital Forensik baiknnya permintaan cross-examination idealnya ditolak oleh Hakim.
Tetapi jika ternyata seseorang Examiner/Investigator lain tersebut sudah layak disebut sebagai Ahli Digital Forensik (dari skill/berpengalaman), maka dipastikan akan menggunakan tahapan dan prosedur yang sama. Dan pengujian atau verifikasi ulang hanya perlu mengikuti SOP dan tahapan pada dokumentasi yang dilakukan Ahli Digital Forensic sebelumnya. Pengujian tidak harus menggunakan tools yang sama persis, tetapi dapat menggunakan tools yang fungsinya sama. Dengan demikian examiner/investigator tersebut akan mendapatkan hasil yang kurang lebih sama. Jika ternyata ada perbedaan, maka dapat di cross check kembali bersama-sama Ahli Digital Forensik lainnya sampai menentukan kekurangan atau kesalahan yang dilakukan examiner yang lain, atau dapat diungkapkan atau dinyatakan di pengadilan dengan menjelaskan perbedaan yang ditemukan dan hakim yang bisa menilai sendiri. Sama halnya dengan kasus Jessica, jika ada Ahli IT atau ahli Digital Forensik yang menyatakan bahwa pada video ditemukan atau diduga adanya tampering yang tujuannya tidak baik, tetapi si Ahli IT dengan jelas-jelas tidak menggunakan SOP Digital Forensik yang benar, seperti menggunakan Sumber Video yang bukan dari berasal barang Bukti Asli ataupun hasil imaging/copy bitstream/hasil kloning nya, melainkan hanya dari rekaman TV persidangan yang pada dasarnya hanya menampilkan cuplikan-cuplikan Video CCTV atau bahkan dari Media Youtube, maka sewajarnya tidak layak disebut sebagai Ahli Digital Forensik, karena sudah tidak sesuai prosedur Digital Forensik dan Cross-Examination yang benar. Sehingga harusnya setiap pendapat si Ahli tersebut menjadi tidak layak dijadikan referensi untuk keputusan pengadilan.

Ok. Kembali ke Laptop.

Dari penjelasan penulis diatas, harusnya kekeliruan yang terjadi di beberapa judul dan isi media ataupun didalam persidangan mudah mudahan bisa langsung terjawab.
Misalnya untuk pernyataan “Ahli Mudzakir juga menyebutkan bahwa bentuk rekaman CCTV yang dihadirkan JPU harus aslinya dalam format DVR.” pada berita di metrotvnews
Komentar penulis :
Format DVR itu bagaimana maksudnya? Mungkin yang dimaksud format DVR bahwa alat buktinya yang disita/ambil adalah sistem DVRnya. Dalam prosedur investigasi CCTV pada bagian Prosedur Ekstraksi Video atau Retrieve video, sudah dijelaskan bahwa ada sistem prioritas pada metode retrieve/ekstraksi rekaman video khususnya pada sistem DCCTV (Digital CCTV). Perlu diingat juga seperti yang penulis jelaskan sebelumnya, bahwa Video (CCTV) Forensic berbeda dengan Computer Forensic. Pada Video CCTV, yang diperlukan hanya video dengan parameter waktu/lokasi yang sudah jelas, sehingga menjadi tidak efektif jika harus memproses semua File Video yang terdapat pada DVR atau HDD DVR. Lagi pula dengan menyita/mengambil DVR sebagai alat bukti, akan menyebabkan rekaman CCTV akan berhenti merekam. Padahal sesuai Prosedur yang disepakati asosiasi ACPO bahwa saat retrieving video CCTV, sebaiknya CCTV tetap melakukan proses rekaman, kecuali memang tidak ada metode lain selain mematikan sistem DVR tersebut dan menggantinya dengan yang lain. Artinya metode menjadikan perangkat DVR ataupun HDDnya sebagai alat bukti adalah jalan terakhir jika tidak ada metode ekstraksi/retrieve video dari DVR. Pada dasarnya semua CCTV/DVR sistem memiliki standard format file yang biasanya propriatery, sehingga tidak semua aplikasi media/video player dapat langsung memutar video tersebut. DCCTV dan sistem DVR biasanya menyediakan fitur aplikasi untuk melakukan retrieving/ekstraksi file video dengan parameter waktu/time stamp ataupun lokasi (nomor kamera). File video hasil extraksi biasanya sudah dalam bentuk kompresi dan ber ekstensi .AVI atau .MP4 yang umumnya sudah dapat langsung diputar di berbagai aplikasi video player, meskipun dapat juga diekstract sesuai format aslinya (propriatary) vendor cctv tersebut.

Terkait berita di Tribun, yang menyatakan Jessica di jerat dengan CCTV hasil kloning seperti pada url berita tribunnews . Maka bisa ditarik kesimpulan, bahwa banyak media yang tidak memahami bagaimana sebenarnya examiner/ahli digital forensic bekerja. Tidak memahami apa sebenarnya hasil kloning tersebut dan bagaimana hasil analisis Digital Forensik seharusnya. Jika yang dimaksud hasil kloning adalah hasil imaging/bitstream copy dari Barang Bukti asli, maka analisa oleh Ahli Digital Forensik tersebut sudah benar dan memang demikian prosedurnya, bahwa Examiner/Investigator hanya melakukan analisis terhadap hasil imaging/kloning yang secara saintifik telah dibuktikan kesamaan dan integritasnya dengan barang bukti asli (MASTER).

Diberbagai forum/group atau milis ada juga yang masih meragukan apakah dimungkinkan terdakwa tetap dijatuhi hukuman meskipun tidak ditemukannya direct-evidence (Bukti langsung seperti rekaman memasukkan sianida ke dalam gelas atau Bukti terdakwa membawa Sianida dst).
Saya lebih sepakat dengan pernyataan Pak Edward Omar Sharif Hiariej bahwa pembuktian hukum pidana tidak memerlukan bukti langsung, pernyataannya bisa dibaca pada url berikut.

Kejahatan pembunuhan khususnya pembunuhan berencana tentu saja sudah dipersiapkan oleh pelaku kejahatan, dipastikan pelaku juga sudah mempersiapkan sebaik mungkin usaha menghilangkan atau mengaburkan bukti-bukti kejahatannya. Tepat seminggu lalu (11 Oktober 2016), penulis juga menjadi saksi ahli di sebuah persidangan kasus pembunuhan berencana di Pengadilan Negeri salah satu kabupaten di Yogyakarta. Posisi penulis sebagai Ahli IT sekaligus Ahli Digital Forensik yang juga telah melakukan examiner terhadap perangkat mobile phone milik Ibu Korban dan milik terdakwa , dan melakukan Analisis dan cross-check juga terhadap Hasil CDR (Call Detail Record) yang diperoleh dari beberapa Provider Telekomunikasi, dengan tegas menyatakan terdakwa tersebutlah sebagai pelaku teror dan pelaku pembunuhnya sesuai pesan pesan yang dikirimkan secara elektronik (SMS) meskipun telah menggunakan berbagai nomor telp yang berbeda pada setiap terrornya. Jika diikuti dipersidangan sebelum-sebelumnya dan kesaksian para saksi, bahwa memang tidak ada bukti direct-evidence yang ditemukan di TKP, kecuali Jejak Kaki yang sangat mirip dengan terdakwa dan jejak kendaraan yang mirip dengan ban roda kendaraan terdakwa. Hal ini karena semua bukti bukti lainnya sudah dihilangkan, mulai bukti sidikjari di sekitar lokasi TKP, membakar pakaian yang berlumuran darah yang digunakan saat membunuh, membersihkan kendaraan yang berlumuran darah, menjual HP yang digunakan untuk meneror korban dan Ibu Korban. Tetapi ketika secara komprehensif dilakukan pemeriksaan dan runtut mulai proses terror ancaman melalui SMS serta dibandingkan dengan keterangan saksi saksi mulai dari Istri dan anak Terdakwa, saksi saksi yang melihat terdakwa dengan korban pada hari kejadian, dan kesaksian kesaksian banyak pihak disekitar terdakwa, sangat meyakinkan bahwa terdakwalah pelaku kejadian tersebut.

Sedangkan kasus yang mirip dengan kasus persidangan Jessica yang melibatkan video rekaman CCTV disebuah Cafe saat ini sedang ditangani oleh penulis bersama penyidik kepolisian disalah satu kota di Jawa Tengah. Kasus ini bermula dari akan dilakukannya transaksi penjualan cincin antara dua teman di Cafe tersebut. Cincin yang diperjualbelikan ternyata cincin yang harganya sama seperti harga Rumah tipe 60an di Jogja. Dari rekaman CCTV dapat dianalisis pelaku pencurian cincin yang diletakkan diatas Meja tersebut, meskipun sebenarnya posisi meja lumayan jauh dari camera CCTV, dengan berbagai teknik enhancement dan super-resolution akan mampu memperjelas setiap gerakan gerakan yang menjadi bukti pada kasus pencurian tersebut. Tentu saja sebelumnya penulis telah melakukan imaging/bitstream copy terhadap barang bukti yang didapatkan dari Penyidik tersebut.

Demikian artikel ini dipublikasikan atas dasar keinginan meluruskan informasi-informasi yang kurang tepat terkait dengan persidangan kasus terdakwa Jessica yang melibatkan Video CCTV dan Ahli Digital Forensik.
Semoga ilmu pengetahuan forensik digital di indonesia semakin baik dikemudian hari dan semakin banyak Ahli Digital Forensik yang mumpuni di NKRI tercinta ini.

Salam.

Josua M Sinambela
(Infosec Consultant & Digital Forensic Analyst @RootBrain.Com
Sejak tahun 2006 ikut membantu lembaga kepolisian menangani kasus-kasus berhubungan IT dan Digital Forensic)

Sumber: http://infosec.id/2016/10/digital-forensik-dan-barang-bukti-rekaman-cctv-kasus-jessica/

Tags: , , , , ,

LPSE [In]security

 LPSEINFOsec.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)

data-center-1-862x646

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)

People Security

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)

system-security

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)

Write Your Own Stinking Procedures

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

Detil Framework SPSE
Detil Framework SPSE

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/

ransomINFOsec.ID – Sedia payung sebelum hujan, merupakan peribahasa yang paling tepat untuk menanggapi banyaknya kejadian cybercrime  yang memanfaatkan malware ransomware  yang marak belakangan ini.

Ransomware merupakan istilah untuk jenis malware yang melakukan enkripsi file/dokumen pada perangkat Server/Komputer/Mobile kemudian meminta tebusan kepada pemilik dokumen jika masih menginginkan file/dokumen tersebut kembali (terdekripsi). Pelaku yang memanfaatkan ransomware biasanya menggunakan algoritma enkripsi yang cukup kuat sehingga hanya bisa direcovery jika memiliki kunci yang tepat.

Hari rabu lalu (kemarin), tanggal 30 Maret 2016, salah seorang dari perusahaan client saya di Kalimantan tiba-tiba menghubungi  via telepon, Beliau menanyakan tentang malware/virus yang menginfeksi beberapa Server dan PC berbasis Windows mereka sejak tanggal 27 Maret lalu. Beliau menginformasikan jika semua file pada Server mereka tidak dapat dibuka dan berubah nama menjadi berekstensi *.xtbl . Mendengar informasi tersebut, feeling saya langsung menyatakan pasti ransomware. Setelah saya gali informasi lagi, apakah ada informasi dan pesan-pesan yang muncul pada komputer server tersebut seperti file terenkripsi dan permintaan komunikasi atau pembayaran. Ternyata betul, disebut bahwa ada informasi pesan pada Wallpaper desktop mesin terinfeksi tersebut, terdapat juga file Readme.txt dan How to decrypt your files.txt.

cyber_baba2-ransomware
Tampilan Desktop – wallpaper mesin terinfeksi ransomware *.xtbl
cyber_baba2-ransomware2
Daftar File dan Dokumen terinfeksi ransomware *.xtbl

Saat itu juga, saya langsung menginformasikan bahwa itu merupakan salah satu jenis malware ransomware, yang bertujuan men-sandera seluruh file file/dokumen dengan enkripsi  dan akan meminta bayaran sebagai tebusan agar file file dapat terdekripsi kembali.  Saran saya untuk tidak mengikuti keinginan pelaku dan tidak perlu menghubungi mereka.  Saya konfirmasi juga apakah mereka memiliki backup data dan system mesin tersebut, untungnya mereka menjawab ya. Meskipun backup tersebut mungkin bukan versi yang relatif baru. Saya juga teringat 2 tahun lalu pernah memasang server NAS yang memang ditujukan  untuk memirror/backup seluruh server server di perusahaan tersebut. Semoga NAS backup tersebut sering difungsikan dan bisa digunakan untuk merestore system pada server tersebut.

Mungkin ada pertanyaan, kenapa tidak menyarankan untuk mengikuti instruksi dengan membayar untuk mendapatkan kunci atau  berinteraksi dengan pelaku/pemilik ransomware? Bukankah lebih mudah mendapatkan file dan dokumen kembali dengan utuh? Ya, memang dengan mengikuti permintaan pelaku, ada kemungkinan mendapatkan file/dokumen kita kembali, tetapi tidak ada jaminan mereka memberikan kunci yang tepat, atau kunci yang diberikan dapat mengembalikan semua file/dokumen terenkripsi. Sama halnya saat kita berkomunikasi dengan penyandera yang tidak kita ketahui atau kenal sama sekali pelakunya dan tidak tahu apa yang mungkin dilakukannya. Instruksi pembayaran-pun dilakukan secara anonim melalui Bitcoin yang relatif sangat sulit untuk penelusurannya.  Atau meskipun ternyata semua file/dokumen dapat direcover dengan mengikuti instruksi mereka (membayar kunci), maka tidak tertutup kemungkinan mereka akan mencatat atau menandai perusahaan dan akan beraksi mengulangi kembali dengan teknik sedikit berbeda setelah mengetahui si perusahaan  bersedia membayar kunci tersebut, atau menjadikan perusahaan sebagai target kembali dikemudian hari.

Bagaimana mencegah kemungkinan terinfeksi malware ransomware?

Setiap organisasi atau perusahaan yang memanfaatkan Teknologi Informasi rentan terhadap malware ransomware , selain dengan teknologi proteksi yang baik seperti Anti Virus/Anti Malware disisi Jaringan/Server/PC/Mobile, kesadaran terhadap keamanan (security awareness) setiap person pengguna dan pengelola TI sangat berperan penting untuk mencegah terinfeksi ransomware. 

Ransomware umumnya menyebar melalui internet (email/mailing list/attachment/website/url), pelaku biasanya mengirimkan email massal (sehingga sering dianggap spam beberapa mail server) disertai attachment (berupa file dokumen maupun archive .xlsx .docx .zip .rar dst) biasanya menyisipkan trojan/malware pada dokumen ataupun url menuju file dokumen yang berisi trojan/malware. Jika mail server atau filtering jaringan tidak dilengkapi teknologi proteksi malware/virus yang mumpuni, maka tidak tertutup kemungkinan dokumen dokumen tersebut akan masuk ke INBOX atau Komputer/PC pengguna.  Tetapi jika pengguna sudah terlatih dan aware terkait email spam ber-attachment dan malware yang masuk ke INBOX/SPAM Box, seharusnya tidak perlu kuatir, karena pengguna yang sudah paham resiko malware tidak akan mencoba-coba untuk membukanya.  Masalahnya masih belum banyak orang yang sadar (aware) resiko keamanan dari serangan malware tersebut.  Selain melalui email, banyak juga malware ransomware yang menyebar dibantu melalui media social, yang sengaja menggunakan judul page URL yang menarik banyak perhatian pembaca, dan sering tidak disadari juga oleh orang yang mem-posting atau yang men-share URL tersebut.

Hari ini (31 Maret 2016), tersebar berita adanya ransomware bernama kimcilware yang menginfeksi beberapa website berbasis Magento, framework khusus e-commerce. Penulis menduga jika malware kimcilware merupakan hasil pekerjaan orang indonesia, dilihat dari alamat emailnya menggunakan [email protected] .  

ransom-note
Pesan Kimcilware

 

encrypted-files-in-folder
Daftar File terenkripsi Kimcilware

Menurut analisis penulis, malware yang disebut ransomware kimcilware diatas berbeda dengan ransomware contoh sebelumnya (*.locky, *.xtbl dll), yang mampu otomatis menyebar dan menginfeksi targetnya. Kimcilware kemungkinan besar dieksekusi secara manual oleh sipelaku setelah berhasil mengupload webshell (phpshell) dengan memanfaatkan kelemahan framework Magneto dan menggunakan php script untuk enkripsi. Hal ini dapat diamati dari beberapa situs yang diretas dengan script yang sama oleh Kimcilware, umumnya website-website tersebut hosting di mesin server Linux yang memiliki proteksi keamanan di level file ownership dan permission untuk setiap akun hosting. Pada ransomware yang umum seperti *.locky, *.xtbl, malware dapat menginfeksi seluruh system dengan priviledge administrator system, sehingga bahkan mampu mendisable/locked fasilitas restore point MS Windows. Pada kasus kimcilware, si pelaku hanya mampu mengenkripsi folder salah satu akun hosting yang sebelumnya berhasil di take over. Dari informasi pada forum magento , di peroleh informasi jika ada beberapa domain yang menggunakan CMS/framework yang sama  pada server tersebut, tetapi tidak ikut terinfeksi.

Jika memang benar ini adalah hasil pekerjaan “iseng” dari anak Indonesia, sangat disayangkan jika menggunakan kemampuannya dalam membobol situs disalahgunakan untuk mencari keuntungan dengan men-sandera dokumen dan file milik orang lain. Motif pekerjaan seperti ini sudah tergolong sangat merugikan dan memang bertujuan jahat yang sifatnya pemerasan, berbeda dengan para hacker atau defacer umumnya hanya menambahkan informasi pesan jika sistem memiliki kelemahan sembari menampilkan nickname pelaku (defacing).

Sumber :  http://infosec.id/2016/03/restore-backup-sebagai-satu-satunya-solusi-penanganan-ransomware/

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.

Older Posts »