Copy Link
Add to Bookmark
Report
Echo Magazine Issue 20 Phile 0x012
o.OOoOoo o OoooOOoO
O O o o
o o O
ooOO O o
O .oOo OoOo. .oOo. O O 'OoOo. .oOo.
o O o o O o o o o O OooO'
O o o O o O O O O o O
ooOooOoO `OoO' O o `OoO' OOooOooO o' o O `OoO'
Echo Magazine Volume VII, Issue XX, Phile 0x0c.txt
]=========[[Anti-forensic; Seek and Destroy]]=========o
Brought To You By : jck.mrshl
http://id-mayhem.blogspot.com
======= Pendahuluan ---|
Computer forensics adalah suatu metode untuk mengidentifikasi, mengekstrak dan
menemukan informasi dari media digital seperti komputer dan "hard drives".
Computer forensics dalam artian sempit, hanya diaplikasikan kepada proses
evaluasi komputer, "data storage' dan "processing devices"[1]. Computer
forensic biasanya dimanfaatkan terkait dengan hukum dan persidangan.
Lalu, apa yang dimaksud dengan "Computer Anti Forensics" adalah suatu metode
untuk membuat para "computer forensics investigator" kesulitan dalam
melaksanakan tugasnya.
======= Forensic: Know your enemy:lol: ---|
Sebelum memulai Pembahasan tentang Anti-forensic, ada baiknya terlebih dahulu
saya mengajak kita semua untuk menjadi Ahli Computer Forensic. Ya, kita akan
menjadi ahli komputer forensic, untuk dapat mengetahui cara kerjanya dan
bagaimana meng-"counter"-nya untuk keperluan anti-forensic nantinya. Dalam hal
ini, saya sengaja mengambil contoh untuk merecover sebuah file yang telah
dihapus oleh attacker (kita? :lol:)
Sebagai contoh file yang dihapus adalah log files (syslog, httpd log,
firewall log) yang merupakan sumber vital bagi ahli computer forensic,
adapun alasan kedua lebih kepada artikel ini, yaitu kemungkinan kita dapat/harus
melakukan recovery saat mesin masih menyala/ proses belum di "kill".
Catatan: Pada artikel kali ini saya menggunakan user root, baik dalam proses
computer forensic atau Anti-forensic, jangan tanyakan saya bagaimana mendapatkan
root atau kenapa harus menggunakan user root, karena jika pertanyaan itu
terbersit pada benak anda, maka dengan berat hati saya meminta anda untuk tidak
melanjutkan membaca artikel ini, karena akan melukai hati dan merusak otak anda!
Go away, kiddo.. ini Anti-forensics !
========= Recover file yang terhapus ---|
Sekarang, kita akan coba menghapus file syslog lalu me-recover-nya kembali,
sebelum itu, untuk memastikan file ini masih di akses/buka oleh system,
maka ada baiknya kita lihat isinya, sekaligus sebagai metode verifikasi
setelah proses recovery nanti.
-------------------- untuk keperluan recovery & verifikasi --------------------
root@hell:~# tail -f syslog
Feb 10 14:20:47 hell NetworkManager: <debug> [1235028047.728549] nm_hal_device\
Feb 10 14:20:47 hell NetworkManager: <debug> [1235028047.959516] nm_hal_device\
Feb 10 14:20:47 hell NetworkManager: <debug> [1235028047.982317] nm_hal_device\
Feb 10 14:21:23 hell sendmail[5406]: unable to qualify my own domain name (hell)
Feb 10 14:21:24 hell dhclient: bound to 192.168.16.14 -- renewal in 984139
Feb 10 14:21:24 hell sendmail[6860]: My unqualified host name (hell) unknown;
Feb 10 14:21:27 hell ntpdate[6782]: step time server 91.189.94.4 offset -207.\
Feb 10 14:22:24 hell sendmail[6860]: unable to qualify my own domain name (hell)
Feb 10 14:25:46 hell anacron[6522]: Job `cron.daily' started
Feb 10 14:25:46 hell anacron[7003]: Updated timestamp for job `cron.daily' to\
**** Isi dari syslog saya mutilasi dengan "\", dan setelahnya dihapus, untuk
mengurangi "junk" dan mengikuti ketentuan length < 80. :lol: ****
Sebelum memulai proses penghapusan, ada baiknya kita mencatat nomer inode dari
file syslog, untuk mempermudah kita dalam melakukan sorting menggunakan "lsof"
nantinya
root@hell:~# stat /var/log/syslog
File: `/var/log/syslog'
Size: 91967 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 99810 Links: 1
Access: (0640/-rw-r-----) Uid: ( 102/ syslog) Gid: ( 4/ adm)
Access: 2009-02-10 25:51:19.000000000 +0700
Modify: 2009-02-10 25:51:01.000000000 +0700
Change: 2009-02-10 25:51:01.000000000 +0700
root@hell:~#
/var/log/syslog memiliki inode "99810",
-------------------- untuk keperluan recovery & verifikasi --------------------
Kita akan menggunakan perintah remove "rm" dengan opsi "rf" terhadap file syslog
root@hell:~# rm -rf /var/log/syslog
Silahkan di cek,
root@hell:~# ls -la /var/log/syslog.
ls: cannot access /var/log/syslog.: No such file or directory
root@hell:~# ls -la /var/log/syslog
ls: cannot access /var/log/syslog: No such file or directory
root@hell:~# stat syslog
stat: cannot stat `syslog': No such file or directory
Sampai disini proses penghapusan sukses dilaksanakan.
========= Lsof; proses recovery file ---|
Sekarang, Kita akan mencoba untuk mengembalikan file log yang telah kita hapus,
dalam hal ini kita akan menggunakan lsof untuk mendapatkan info file dan
merecovernya, mengikuti "kultur" sistem operasi dan filesystem yang digunakan.
Lsof adalah suatu utilitas yang berfungsi untuk menampilkan semua informasi
secara komprehensif dari suatu file/direktori, file spesial, network file
(internet socket, NFS, unix domain socket), dsb. Informasi yang kita perlukan
adalah PID (process id), serta file descriptor. Seluruh proses akan memiliki
suatu direktori khusus dalam direktori "/proc" dengan nomer PID sebagai namanya,
dan sebelum proses induk tersebut di "kill", maka meskipun data telah dihapus
dengan "rm", kopian dari data tersebut akan berada di sini. (got the point?)
Adapun pemetaan path lengkapnya akan seperti berikut,
/proc/process id/fd/file descriptor
=========== Forensic recovery di mulai ---|
Sekarang, kita perlu untuk mendapatkan informasi file syslog, dengan menggunakan
lsof dan melakukan "sorting" memanfaatkan nomer inode-nya,
root@hell:~# lsof | grep 99785
syslogd 5484 syslog 2w REG 8,1 91967 99785 /var/log/syslog (deleted)
Sehingga, didapatkan PID=5484 dan file descriptor=2 (dari 2w), dan apabila kita
sesuaikan dengan pemetaan path untuk pseudo-filesystem adalah,
root@hell:~# ls -l /proc/5484/fd/2
l-wx------ 1 root root 64 [X] 14:27 /proc/5484/fd/2 ->/var/log/syslog (deleted)
root@hell:~#
**** X= berisi tanggal, 2009-02-10 ****
Maka akan tampil satu blok berwarna merah, yang menandakan link
/proc/5484/fd/2 sudah dihapus.
root@hell:~# file /proc/5484/fd/2
/proc/5484/fd/2: broken symbolic link to `/var/log/syslog (deleted)'
Karena sesungguhnya "rm" hanya menghapus link ke inode, dan atribut, informasi
dan blok data dari file tersebut tidak tersentuh, maka cara termudah untuk
me-recovery-nya adalah dengan mengkopikan file tersebut kembali. Sebagai contoh
digunakan nama "syslog" kembali,
root@hell:~# cp /proc/5484/fd/2 syslog
lalu, periksalah hasilnya untuk melihat isinya,
root@hell:~# tail -f syslog
Feb 10 14:20:47 hell NetworkManager: <debug> [1235028047.728549] nm_hal_device\
Feb 10 14:20:47 hell NetworkManager: <debug> [1235028047.959516] nm_hal_device\
Feb 10 14:20:47 hell NetworkManager: <debug> [1235028047.982317] nm_hal_device\
Feb 10 14:21:23 hell sendmail[5406]: unable to qualify my own domain name (hell)
Feb 10 14:21:24 hell dhclient: bound to 192.168.16.14 -- renewal in 984139
Feb 10 14:21:24 hell sendmail[6860]: My unqualified host name (hell) unknown;
Feb 10 14:21:27 hell ntpdate[6782]: step time server 91.189.94.4 offset -207.\
Feb 10 14:22:24 hell sendmail[6860]: unable to qualify my own domain name (hell)
Feb 10 14:25:46 hell anacron[6522]: Job `cron.daily' started
Feb 10 14:25:46 hell anacron[7003]: Updated timestamp for job `cron.daily' to\
dan kita yang seolah ahli komputer forensik akan dapat kembali membaca file log
yang (dianggap) terhapus oleh attacker. **we are doomed**
======= Anti forensic ---|
Setelah diatas kita membuktikan bahwa penggunaan 'rm' hanyalah menghapus link ke
inode atau lebih dikenal dengan index node, yang menyimpan atribut dari suatu
file, dan inode di identifikasi dengan nomer yang unik untuk tiap inode. Atribut
dari suatu file itu adalah semisal: tipe file, "permission", info pemilik dan
grup, ukuran file, jumlah link (soft/hard), alamatnya di blok data, dsb.
Saya tidak berusaha mengulas dan bercerita lebih jauh tentang file di unix/
linux, jadi kita akan "skip" hal ini. (sorry , no candy for you all kiddo)
Penggunaan "rm" dalam melakukan penghapusan file dari mesin target tidaklah
efissien, karena para ahli komputer forensik dapat dengan mudah untuk kembali
me-recover data-data, baik log, dsb, hal tersebut sudah saya buktikan diatas.
Penggunaan "lsof" hanyalah salah satu cara, banyak sekali aplikasi/utility/tools
yang dapat digunakan untuk me-recover file, bahkan keseluruhan data di media,
baik saat komputer menyala atau setelah restart,"single mode" atau "network mode".
========= Secure Data Deletion ---|
Secure Data Deletion adalah salah satu teknik tertua/tradisional dari anti-
forensics, suatu metode yang sangat mudah, efisien dan "simple" untuk dilakukan,
dibanding dengan berbagai teknik lain seperti enkripsi, "steganography",
modifikasi data, penyembunyian data, dsb. Meskipun resiko untuk diketahui akan
relatif lebih mudah, tetapi untuk kegiatan computer rforensic, apabila data yang
dibutuhkan tidak didapatkan maka akan mempersulit/memperlambat kegiatannya.
Beberapa aplikasi yang bisa anda manfaatkan adalah: srm, wipe, shred, dsb,
tetapi dalam demo ini saya mengunakan shred di sistem operasi GNU/Linux dengan
filesystem ext3.
Sejak 2008 Shred masuk kedalam paket penting dari GNU (GNU coreutils) dan akan
membuat secara default terinstall, sehingga anda tidak perlu melakukan instalasi
aplikasi Secure Data Deletion lainnya.
=========== Shred ---|
Apa yang dilakukan Shred adalah dengan menulis ulang file/s secara berulang kali
dengan tujuan mempersulit kemungkinan untuk merecover data yang sudah dihapus.
Shred, bagaikan pisau bermata dua. Tetapi shred juga memiliki berbagai
keterbatasan pada jenis file system tertentu, terkompresi dan yag memiliki
dukungan snapshot, dan untuk detilnya silahkan baca manual shred.
Untuk lebih jelasnya kita akan menggunakan shred dan mencoba me-recovery data
tersebut kembali seperti yang sudah kita lakukan di atas.
=========== Shred Beraksi ---|
Sekarang, kita akan kembali menghapus file syslog, sebelum itu, untuk memastikan
file ini masih di akses/buka oleh system, maka ada baiknya kita lihat, sekaligus
sebagai metode verifikasi setelah proses recovery (seperti diatas).
root@hell:~# tail -f /var/log/syslog
Feb 10 15:01:01 hell sm-msp-queue[8122]: n1J7f194007446: to=postmaster, delay=\
Feb 10 15:17:01 hell /USR/SBIN/CRON[8262]: (root) CMD ( cd / && run-parts --\
Feb 10 15:20:01 hell sm-msp-queue[8304]: My unqualified host name (hell) \
Feb 10 15:21:01 hell sm-msp-queue[8304]: unable to qualify my own domain name \
Feb 10 15:21:01 hell sm-msp-queue[8304]: n1J7f194007446: to=postmaster, delay=\
Feb 10 15:40:01 hell /USR/SBIN/CRON[8468]: (smmsp) CMD (test -x /etc/init.d/\
Feb 10 15:40:01 hell sm-msp-queue[8483]: My unqualified host name (hell) \
Feb 10 15:41:01 hell sm-msp-queue[8483]: unable to qualify my own domain name \
Feb 10 15:41:01 hell sm-msp-queue[8483]: n1J7f194007446: to=postmaster, delay=\
Catat inode dari file syslog, akan bermanfaat saat proses melakukan recovery.
"Inode /var/log/syslog" adalah "99810"
root@hell:~# stat /var/log/syslog
File: `/var/log/syslog'
Size: 2400 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 99810 Links: 1
Access: (0640/-rw-r-----) Uid: ( 102/ syslog) Gid: ( 4/ adm)
Access: 2009-02-10 15:41:19.000000000 +0700
Modify: 2009-02-10 15:41:01.000000000 +0700
Change: 2009-02-10 15:41:01.000000000 +0700
root@hell:~#
Selanjutnya kita akan menghapus file tersebut dengan menggunakan shred,
untuk mengerti penggunaan opsi yang diberikan, silahkan cek manual dari shred
root@hell:~# shred --random-source=/dev/urandom -u /var/log/syslog
Shred terbukti telah berhasil menghapus file /var/log/syslog,
root@hell:~# ls -la /var/log/syslog
ls: cannot access /var/log/syslog: No such file or directory
root@hell:~# stat syslog
stat: cannot stat `syslog': No such file or directory
Selanjutnya adalah me-"list" file/s yang masih terbuka, dan seperti sebelumnya,
karena syslog akan secara kontinyu di tulisi oleh sistem, maka otomatis file
tersebut akan dianggap masih ada,
root@hell:~# lsof | grep 99810
syslogd 5484 syslog 3w REG 8,1 0 99810 /var/log/0 (deleted)
Lihat dan samakan inode number dari file syslog, dan kita temukan bahwa saat ini
yang tercatat adalah file "0", berbeda dengan saat kita menghapus menggunakan
"rm".
Selanjutnya, seperti saat kita me-"recovery" file syslog sebelumnya adalah
dengan hanya mengkopikannya kembali dari direktori tempat pseudo-filesystem.
root@hell:~# cp /proc/5484/fd/3 syslog
root@hell:~# tail -f syslog
root@hell:~# file syslog
syslog: empty
Dan kemudian setelah kita periksa ternyata file tersebut tidak mengandung
data apapun a.k.a empty.
Yup, "we are done now homey", Bisa tidur nyenyak, karena proses recovery menjadi
hal yang relatif sulit bagi para ahli-forensik.
======= Referensi ---|
[1] http://www.forensicswiki.org/
[2] lsof manual
[3] shred manual
======= Greetz ---|
- gentoo, echostaff, underground people
Echo Magazine Volume VII, Issue XX, Phile 0x0c.txt
