Mohon tunggu...
Mboi Coy
Mboi Coy Mohon Tunggu... -

:)

Selanjutnya

Tutup

Inovasi

Investigasi Sistem Linux yang Terinfeksi Trojan -2

15 Januari 2010   08:02 Diperbarui: 26 Juni 2015   18:27 551
+
Laporkan Konten
Laporkan Akun
Kompasiana adalah platform blog. Konten ini menjadi tanggung jawab bloger dan tidak mewakili pandangan redaksi Kompas.
Lihat foto
Bagikan ide kreativitasmu dalam bentuk konten di Kompasiana | Sumber gambar: Freepik

lanjutan dari bagian pertama Setelah diketahui lokasi aplikasi std terletak di folder /flood saya langsung menuju folder tersebut. Dan setelah berada didirektori tersebut, saya cukup tercengang dengan isinya. Didalamnya terdapat aplikasi-aplikasi exploit untuk bermacam jenis system dari target yang dituju dan juga metode yang berbeda-beda pula. Beberapa antaranya dari aplikasi-aplikasi tersebut; ipbomb, nuke, pinger dll. Setelah itu, kita juga ingin mengetahui siapakah atau apakah yang men-trigger aplikasi std itu untuk jalan. Kalau kita melihat kembali ke hasil dari # ps axjf tadi, terlihat parent process dari std adalah httpd. Secara spontan saya langsung mematikan service httpd itu dengan perintah #service httpd stop. [caption id="attachment_53320" align="aligncenter" width="500" caption="# ps axjf"][/caption] Sesaat kita merasa sudah mengambil kendali situasi. Dan kita salah. Ternyata aplikasi httpd yang terlihat tadi bukanlah aplikasi web server melainkan satu paket dengan aplikasi std. Dengan perintah # netstat -pln |grep httpd kita dapatkan info bahwa httpd tiruan itu berjalan di port 47065/udp, dan port tersebut berubah-ubah. Asumsi awal yang menganggap kita sebagai korban juga tidak sepenuhnya benar, bahkan sebenarnya kita dimanfaatkan sebagai bagian dari penyerang DOS (denial of service) ke server-server eropa dan amerika (dugaan dari ip-ip yang di serang adalah ip dari kedua benua tersebut) Jadi contoh perintah ./std 173.63.99.156 53 adalah perintah untuk nge-flood ip 173.63.99.156 dengan port 53. Kita sudah mengetahui cara kerja aplikasi std dan kedudukan aplikasi httpd sebagai parent prosesnya. Untuk tindakan preventifnya saya matikan proses kedua proses tersebut. Dan apabila ternyata masih ada daemon (proses) lainnya yang berfungsi menjalankan aplikasi-aplikasi tersebut, saya coba pindahkan folder itu ke tempat lainnya. Cara sederhana ini dilakukan karena pada umumnya aplikasi (secara default) akan memanggilkan file pendukung lainnya dengan tiga cara, yakni:

  • melihat dari variable path environment
  • parsing direktorinya itu sendiri
  • membaca file konfigurasi (aplikasi hacking jarang se-fleksibel ini)

Maka dengan ketiga point diatas, saya berasumsi kalau kita memindahkan direktori flood tersebut maka daemon atau proses akan kehilangan path aplikasi-aplikasinya. Dan ini diperkuat dengan fakta bahwa aplikasi std dipanggil dengan perintah ./std (point ke-2 diatas), yang berarti letaknya satu direktori dengan httpd tiruan. Ditambah lagi, apabila kita melihat scheduled task dengan perintah # crontab -l ternyata ada perintah yang ditaruh disana  /flood/update >/dev/null 2>&1, jadi langkah untuk memindahkan folder tersebut adalah hal yg logis. Ternyata keluar error dengan menggunakan perintah # mv /flood /home [caption id="attachment_53650" align="aligncenter" width="500" caption="# mv /flood /home"][/caption] Bahkan root saja tidak bisa memindahkan folder tersebut. Hal yang paling mungkin dari ini adalah folder tersebut telah diset attribute spesialnya. Ini bisa dicek dengan perintah # lsattr dan contoh outputnya seperti ini [caption id="attachment_53651" align="aligncenter" width="184" caption="lsattr"][/caption] Dari outputnya terlihat attribute i telah terset di direktori flood. Ini berarti folder ter-immutable dan tak dapat dilakukan perintah-perintah seperti mv, rm ataupun operasi-operasi write lainnya, tetapi file masih bisa read. Untuk menghilangkan attribute ini bisa diberikan perintah # chattr -i -R /flood. Baru file tersebut dapat dipindahkan. Service httpd (palsu) telah dimatikan, aplikasi std telah di-kill, folder aplikasi telah dipindahkan dan scheduled task di crontab dinontaktifkan.  Tidak terlihat kembali lonjakan-lonjakan di aktifitas network. Kondisi server aman dan sudah bisa ditinggal pulang. Keesokan harinya saya sedang iseng-iseng lihat aktifitas server dan ternyata ada perintah # send-mail -i zmeuhacker@***.com. Sepertinya server sudah sangat terinfeksi oleh trojan ini. Dan pertanyaan yang paling penting adalah, siapa dan bagaimanakah trojan itu bisa sampai diserver ini. Investigasi masih perlu dilakukan lebih lanjut.

Mohon tunggu...

Lihat Inovasi Selengkapnya
Beri Komentar
Berkomentarlah secara bijaksana dan bertanggung jawab. Komentar sepenuhnya menjadi tanggung jawab komentator seperti diatur dalam UU ITE

Belum ada komentar. Jadilah yang pertama untuk memberikan komentar!
LAPORKAN KONTEN
Alasan
Laporkan Konten
Laporkan Akun