Deteksi pelanggaran dengan forensik sistem file Linux

Analisis forensik dari citra disk Linux sering kali menjadi bagian dari respons insiden untuk menentukan apakah pelanggaran telah terjadi. Forensik Linux adalah dunia yang berbeda dan menarik dibandingkan dengan forensik Microsoft Windows. Dalam artikel ini, saya akan menganalisis disk image dari sistem Linux yang berpotensi disusupi untuk menentukan siapa, apa, kapan, di mana, mengapa, dan bagaimana insiden tersebut serta membuat timeline peristiwa dan sistem file. Terakhir, saya akan mengekstrak artefak yang menarik dari gambar disk.

Dalam tutorial ini, kita akan menggunakan beberapa alat baru dan beberapa alat lama dalam cara kreatif dan baru untuk melakukan analisis forensik citra disk.

Skenario

Lebih banyak sumber daya Linux

• Lembar contekan perintah Linux
• Lembar contekan perintah Linux tingkat lanjut
• Kursus online gratis:Ikhtisar Teknis RHEL
• Lembar contekan jaringan Linux
• Lembar contekan SELinux
• Lembar contekan perintah umum Linux
• Apa itu container Linux?
• Artikel Linux terbaru kami

Premiere Fabrication Engineering (PFE) menduga telah terjadi insiden atau kompromi yang melibatkan server utama perusahaan bernama pfe1. Mereka percaya server mungkin telah terlibat dalam sebuah insiden dan mungkin telah dikompromikan antara pertama Maret dan terakhir Maret. Mereka telah menggunakan layanan saya sebagai pemeriksa forensik untuk menyelidiki apakah server telah disusupi dan terlibat dalam suatu insiden. Penyelidikan akan menentukan siapa, apa, kapan, di mana, mengapa, dan bagaimana di balik kemungkinan kompromi tersebut. Selain itu, PFE telah meminta rekomendasi saya untuk tindakan keamanan lebih lanjut untuk server mereka.

Gambar disk

Untuk melakukan analisis forensik server, saya meminta PFE untuk mengirimi saya gambar disk forensik pfe1 pada drive USB. Mereka setuju dan berkata, "USB ada di dalam pos." Drive USB tiba, dan saya mulai memeriksa isinya. Untuk melakukan analisis forensik, saya menggunakan mesin virtual (VM) yang menjalankan distribusi SANS SIFT. SIFT Workstation adalah sekelompok respons insiden dan alat forensik sumber terbuka dan gratis yang dirancang untuk melakukan pemeriksaan forensik digital terperinci dalam berbagai pengaturan. SIFT memiliki beragam alat forensik, dan jika tidak memiliki alat yang saya inginkan, saya dapat menginstalnya tanpa banyak kesulitan karena ini adalah distribusi berbasis Ubuntu.

Setelah diperiksa, saya menemukan USB tidak berisi gambar disk, melainkan salinan file host VMware ESX, yang merupakan file VMDK dari cloud hybrid PFE. Ini bukan yang saya harapkan. Saya memiliki beberapa opsi:

1. Saya dapat menghubungi PFE dan lebih eksplisit tentang apa yang saya harapkan dari mereka. Di awal pertunangan seperti ini, itu mungkin bukan hal terbaik untuk dilakukan.
2. Saya dapat memuat file VMDK ke dalam alat virtualisasi seperti VMPlayer dan menjalankannya sebagai VM langsung menggunakan program Linux asli untuk melakukan analisis forensik. Setidaknya ada tiga alasan untuk tidak melakukan ini. Pertama, stempel waktu pada file dan konten file akan diubah saat menjalankan file VMDK sebagai sistem langsung. Kedua, karena server dianggap telah disusupi, setiap file dan program dari sistem file VMDK harus dianggap telah disusupi. Ketiga, menggunakan program asli pada sistem yang disusupi untuk melakukan analisis forensik mungkin memiliki konsekuensi yang tidak terduga.
3. Untuk menganalisis file VMDK, saya dapat menggunakan paket libvmdk-utils yang berisi alat untuk mengakses data yang disimpan dalam file VMDK.
4. Namun, pendekatan yang lebih baik adalah mengonversi format file VMDK ke format RAW. Ini akan memudahkan untuk menjalankan berbagai alat dalam distribusi SIFT pada file dalam citra disk.

Untuk mengonversi dari format VMDK ke RAW, saya menggunakan utilitas qemu-img, yang memungkinkan pembuatan, konversi, dan modifikasi gambar secara offline. Gambar berikut menunjukkan perintah untuk mengubah format VMDK menjadi format RAW.

Selanjutnya, saya perlu membuat daftar tabel partisi dari gambar disk dan mendapatkan informasi tentang di mana setiap partisi dimulai (sektor) menggunakan utilitas mmls. Utilitas ini menampilkan tata letak partisi dalam sistem volume, termasuk tabel partisi dan label disk. Kemudian saya menggunakan sektor awal dan menanyakan detail yang terkait dengan sistem file menggunakan utilitas fsstat, yang menampilkan detail yang terkait dengan sistem file. Gambar di bawah menunjukkan mmls dan fsstat perintah dalam operasi.

Saya belajar beberapa hal menarik dari mmls output:Partisi utama Linux dimulai pada sektor 2048 dan berukuran sekitar 8 gigabyte. Partisi DOS, mungkin partisi boot, berukuran kira-kira 8 megabyte. Terakhir, ada partisi swap sekitar 8 gigabyte.

Menjalankan fsstat memberi tahu saya banyak hal berguna tentang partisi:jenis sistem file, terakhir kali data ditulis ke sistem file, apakah sistem file dilepas dengan benar, dan di mana sistem file dipasang.

Saya siap memasang partisi dan memulai analisis. Untuk melakukan ini, saya perlu membaca tabel partisi pada gambar mentah yang ditentukan dan membuat peta perangkat di atas segmen partisi yang terdeteksi. Saya dapat melakukan ini secara manual dengan informasi dari mmls dan fsstat —atau saya bisa menggunakan kpartx untuk melakukannya untuk saya.

Saya menggunakan opsi untuk membuat pemetaan hanya-baca (-r ), tambahkan pemetaan partisi (-a ), dan berikan keluaran verbose (-v ). loop0p1 adalah nama file perangkat di bawah /dev/mapper Saya dapat menggunakan untuk mengakses partisi. Untuk memasangnya, saya menjalankan:

$ mount -o ro -o loop=/dev/mapper/loop0p1 pf1.raw /mnt

Perhatikan bahwa saya memasang partisi sebagai hanya-baca (-o ro ) untuk mencegah kontaminasi yang tidak disengaja.

Setelah memasang disk, saya memulai analisis dan penyelidikan forensik saya dengan membuat garis waktu. Beberapa pemeriksa forensik tidak percaya pada pembuatan garis waktu. Sebagai gantinya, begitu mereka memiliki partisi yang terpasang, mereka merayap melalui sistem file mencari artefak yang mungkin relevan dengan penyelidikan. Saya memberi label pada pemeriksa forensik ini "creepers". Meskipun ini adalah salah satu cara untuk menyelidiki secara forensik, ini jauh dari pengulangan, rentan terhadap kesalahan, dan mungkin kehilangan bukti berharga.

Saya percaya membuat garis waktu adalah langkah penting karena mencakup informasi berguna tentang file yang dimodifikasi, diakses, diubah, dan dibuat dalam format yang dapat dibaca manusia, yang dikenal sebagai bukti waktu MAC (dimodifikasi, diakses, diubah). Aktivitas ini membantu mengidentifikasi waktu tertentu dan urutan terjadinya suatu peristiwa.

Catatan tentang sistem file Linux

Sistem file Linux seperti ext2 dan ext3 tidak memiliki stempel waktu untuk pembuatan/waktu lahir file. Stempel waktu pembuatan diperkenalkan di ext4. Buku Penemuan Forensik (edisi pertama) oleh Dan Farmer dan Wietse Venema menguraikan stempel waktu yang berbeda.

• Waktu modifikasi terakhir: Untuk direktori, ini adalah terakhir kali entri ditambahkan, diganti namanya, atau dihapus. Untuk jenis file lain, ini terakhir kali file tersebut ditulis.
• Waktu akses terakhir (baca): Untuk direktori, ini terakhir kali dicari. Untuk jenis file lain, ini terakhir kali file dibaca.
• Perubahan status terakhir: Contoh perubahan status adalah perubahan pemilik, perubahan izin akses, perubahan jumlah tautan keras, atau perubahan eksplisit waktu MAC mana pun.
• Waktu penghapusan: ext2 dan ext3 merekam waktu file dihapus dalam dtime stempel waktu, tetapi tidak semua alat mendukungnya.
• Waktu pembuatan: ext4fs mencatat waktu file dibuat di crtime stempel waktu, tetapi tidak semua alat mendukungnya.

Stempel waktu yang berbeda disimpan dalam metadata yang terkandung dalam inode. Inode mirip dengan nomor entri MFT di dunia Windows. Salah satu cara untuk membaca metadata file pada sistem Linux adalah dengan terlebih dahulu mendapatkan nomor inode menggunakan perintah ls -i file lalu gunakan istat terhadap perangkat partisi dan tentukan nomor inode. Ini akan menunjukkan kepada Anda atribut metadata yang berbeda, termasuk stempel waktu, ukuran file, grup pemilik dan id pengguna, izin, dan blok yang berisi data aktual.

Membuat garis waktu super

Langkah saya selanjutnya adalah membuat timeline super menggunakan log2timeline/plaso. Plaso adalah penulisan ulang berbasis Python dari alat log2timeline berbasis Perl yang awalnya dibuat oleh Kristinn Gudjonsson dan disempurnakan oleh orang lain. Sangat mudah untuk membuat timeline super dengan log2timeline, tetapi interpretasinya sulit. Versi terbaru mesin plaso dapat mengurai ext4 serta berbagai jenis artefak, seperti pesan syslog, audit, utmp, dan lainnya.

Untuk membuat timeline super, saya meluncurkan log2timeline terhadap folder disk yang terpasang dan menggunakan parser Linux. Proses ini membutuhkan waktu; setelah selesai saya memiliki timeline dengan artefak yang berbeda dalam format database plaso, maka saya dapat menggunakan psort.py untuk mengubah basis data plaso menjadi sejumlah format keluaran yang berbeda. Untuk melihat format keluaran yang psort.py mendukung, masukkan psort -o list . Saya menggunakan psort.py untuk membuat garis waktu super berformat Excel. Gambar di bawah menguraikan langkah-langkah untuk melakukan operasi ini.

(Catatan:garis asing dihapus dari gambar)

Saya mengimpor garis waktu super ke dalam program spreadsheet untuk mempermudah melihat, menyortir, dan mencari. Meskipun Anda dapat melihat timeline super dalam program spreadsheet, lebih mudah untuk bekerja dengannya di database nyata seperti MySQL atau Elasticsearch. Saya membuat timeline super kedua dan mengirimkannya langsung ke instance Elasticsearch dari psort.py . Setelah timeline super diindeks oleh Elasticsearch, saya dapat memvisualisasikan dan menganalisis data dengan Kibana.

Menyelidiki dengan Elasticsearch/Kibana

Seperti yang dikatakan Sersan Utama Farrell, "Melalui kesiapan dan disiplin, kita adalah penguasa nasib kita." Selama analisis, Anda harus bersabar dan teliti dan menghindari menjadi orang yang menjalar. Satu hal yang membantu analisis garis waktu super adalah memiliki gagasan tentang kapan insiden itu mungkin terjadi. Dalam kasus ini (pun intended), klien mengatakan insiden itu mungkin terjadi pada bulan Maret. Saya masih mempertimbangkan kemungkinan klien salah tentang jangka waktu. Berbekal informasi ini, saya mulai mengurangi jangka waktu super timeline dan mempersempitnya. Saya mencari artefak yang menarik yang memiliki "kedekatan sementara" dengan perkiraan tanggal kejadian. Tujuannya adalah untuk menciptakan kembali apa yang terjadi berdasarkan artefak yang berbeda.

Untuk mempersempit cakupan timeline super, saya menggunakan instance Elasticsearch/Kibana yang saya atur. Dengan Kibana, saya dapat mengatur sejumlah dasbor rumit untuk menampilkan dan menghubungkan peristiwa forensik yang menarik, tetapi saya ingin menghindari tingkat kerumitan ini. Sebagai gantinya, saya memilih indeks minat untuk ditampilkan dan membuat grafik batang aktivitas berdasarkan tanggal:

Langkah selanjutnya adalah memperluas bilah besar di akhir grafik:

Ada bar besar pada 05-Mar. Saya memperluas bilah itu untuk melihat aktivitas pada tanggal tertentu:

Melihat aktivitas file log dari timeline super, saya melihat aktivitas ini berasal dari pemasangan/peningkatan perangkat lunak. Sangat sedikit yang dapat ditemukan di area aktivitas ini.

Saya kembali ke Kibana untuk melihat rangkaian aktivitas terakhir pada sistem dan menemukan ini di log:

Salah satu aktivitas terakhir pada sistem adalah pengguna john menginstal program dari direktori bernama xingyiquan. Xing Yi Quan adalah gaya seni bela diri Cina yang mirip dengan Kung Fu dan Tai Chi Quan. Tampaknya aneh bahwa pengguna john akan menginstal program seni bela diri di server perusahaan dari akun penggunanya sendiri. Saya menggunakan kemampuan pencarian Kibana untuk menemukan contoh xingyiquan lainnya di file log. Saya menemukan tiga periode aktivitas di sekitar string xingyiquan pada 05-Mar, 09-Mar, dan 12-Mar.

Selanjutnya, saya melihat entri log untuk hari ini. Saya mulai dengan 05-Mar dan menemukan bukti pencarian internet menggunakan browser Firefox dan mesin pencari Google untuk rootkit bernama xingyiquan. Pencarian Google menemukan keberadaan rootkit seperti itu di packetstormsecurity.com. Kemudian, browser pergi ke packetstormsecurity.com dan mengunduh file bernama xingyiquan.tar.gz dari situs itu ke direktori unduhan pengguna john.

Meskipun tampaknya pengguna john pergi ke google.com untuk mencari rootkit dan kemudian ke packetstormsecurity.com untuk mengunduh rootkit, entri log ini tidak menunjukkan pengguna di balik pencarian dan unduhan. Saya perlu memeriksa lebih jauh.

Peramban Firefox menyimpan informasi riwayatnya dalam database SQLite di bawah .mozilla direktori di direktori home pengguna (yaitu, pengguna john) dalam file bernama places.sqlite . Untuk melihat informasi dalam database, saya menggunakan program bernama sqlitebrowser. Ini adalah aplikasi GUI yang memungkinkan pengguna menelusuri database SQLite dan melihat catatan yang disimpan di sana. Saya meluncurkan sqlitebrowser dan mengimpor places.sqlite dari .mozilla direktori di bawah direktori home john pengguna. Hasilnya ditunjukkan di bawah ini.

Nomor di kolom paling kanan adalah stempel waktu untuk aktivitas di sebelah kiri. Sebagai uji kesesuaian, saya mengonversi stempel waktu 1425614413880000 untuk waktu manusia dan mendapat 5 Maret 2015, 8:00:13,880 PM. Ini sangat cocok dengan waktu 5 Maret 2015, 20:00:00.000 dari Kibana. Kita dapat mengatakan dengan kepastian yang masuk akal bahwa pengguna john mencari rootkit bernama xingyiquan dan mengunduh file dari packetstormsecurity.com bernama xingyiquan.tar.gz ke direktori unduhan pengguna john.

Menyelidiki dengan MySQL

Pada titik ini, saya memutuskan untuk mengimpor timeline super ke database MySQL untuk mendapatkan fleksibilitas yang lebih besar dalam mencari dan memanipulasi data daripada yang diizinkan oleh Elasticsearch/Kibana saja.

Membangun rootkit xingyiquan

Saya memuat timeline super yang saya buat dari database plaso ke database MySQL. Dari bekerja dengan Elasticsearch/Kibana, saya tahu bahwa pengguna john mengunduh rootkit xingyiquan.tar.gz dari packetstormsecurity.com ke direktori unduhan. Berikut adalah bukti aktivitas pengunduhan dari database timeline MySQL:

Sesaat setelah rootkit diunduh, sumber dari tar.gz arsip telah diekstraksi.

Tidak ada yang dilakukan dengan rootkit sampai 09-Mar, ketika aktor jahat membaca file README untuk rootkit dengan program More, kemudian mengkompilasi dan menginstal rootkit.

Riwayat perintah

Saya memuat riwayat semua pengguna di pfe1 yang memiliki bash histori perintah ke dalam tabel di database MySQL. Setelah histori dimuat, saya dapat dengan mudah menampilkannya menggunakan kueri seperti:

select * from histories order by recno;

Untuk mendapatkan riwayat untuk pengguna tertentu, saya menggunakan kueri seperti:

select historyCommand from histories where historyFilename like '%<username>%' order by recno;

Saya menemukan beberapa perintah menarik dari bash pengguna john sejarah. Yaitu, pengguna john membuat akun johnn, menghapusnya, membuatnya lagi, menyalin /bin/true ke /bin/false , berikan kata sandi ke akun whoopsie dan lightdm, salin /bin/bash ke /bin/false , mengedit kata sandi dan file grup, memindahkan direktori home johnn pengguna dari johnn ke .johnn , (menjadikannya direktori tersembunyi), mengubah file kata sandi menggunakan sed setelah mencari cara menggunakan sed , dan akhirnya menginstal rootkit xingyiquan.

Selanjutnya, saya melihat bash riwayat perintah untuk pengguna johnn. Itu tidak menunjukkan aktivitas yang tidak biasa.

Memperhatikan bahwa pengguna john menyalin /bin/bash ke /bin/false , saya menguji apakah ini benar dengan memeriksa ukuran file-file ini dan mendapatkan hash MD5 dari file tersebut. Seperti yang ditunjukkan di bawah ini, ukuran file dan hash MD5 adalah sama. Jadi, filenya sama.

Menyelidiki login yang berhasil dan gagal

Untuk menjawab sebagian dari pertanyaan "kapan", saya memuat file log yang berisi data login, logout, startup sistem, dan shutdown ke dalam tabel di database MySQL. Menggunakan kueri sederhana seperti: 

select * from logins order by start

Saya menemukan aktivitas berikut:

Dari gambar ini, saya melihat bahwa pengguna john login ke pfe1 dari alamat IP 192.168.56.1 . Lima menit kemudian, pengguna johnn masuk ke pfe1 dari alamat IP yang sama. Dua login oleh pengguna lightdm diikuti empat menit kemudian dan satu menit kemudian, kemudian pengguna johnn login kurang dari satu menit kemudian. Kemudian pfe1 di-boot ulang.

Melihat login yang gagal, saya menemukan aktivitas ini:

Sekali lagi, lightdm pengguna mencoba masuk ke pfe1 dari alamat IP 192.168.56.1 . Mengingat akun palsu masuk ke pfe1, salah satu rekomendasi saya untuk PFE adalah memeriksa sistem dengan alamat IP 192.168.56.1 untuk bukti kompromi.

Menyelidiki file log

Analisis login yang berhasil dan gagal ini memberikan informasi berharga tentang kapan peristiwa terjadi. Saya mengalihkan perhatian saya untuk menyelidiki file log di pfe1, khususnya aktivitas otentikasi dan otorisasi di /var/log/auth* . Saya memuat semua file log di pfe1 ke dalam tabel database MySQL dan menggunakan kueri seperti:

select logentry from logs where logfilename like '%auth%' order by recno;

dan simpan itu ke file. Saya membuka file itu dengan editor favorit saya dan mencari 192.168.56.1 . Berikut adalah bagian dari kegiatan:

Bagian ini menunjukkan bahwa pengguna john masuk dari alamat IP 192.168.56.1 dan membuat akun johnn, menghapus akun johnn, dan membuatnya lagi. Kemudian, pengguna johnn login ke pfe1 dari alamat IP 192.168.56.1 . Selanjutnya, pengguna johnn mencoba menjadi pengguna whoopsie dengan su perintah, yang gagal. Kemudian, kata sandi untuk pengguna whoopsie diubah. Pengguna johnn selanjutnya mencoba menjadi pengguna lightdm dengan su perintah, yang juga gagal. Ini berkorelasi dengan aktivitas yang ditunjukkan pada Gambar 21 dan 22.

Kesimpulan dari penyelidikan saya

• User john mencari, mendownload, mengkompilasi, dan menginstal rootkit bernama xingyiquan ke server pfe1. Rootkit xingyiquan menyembunyikan proses, file, direktori, proses, dan koneksi jaringan; menambahkan pintu belakang; dan banyak lagi.
• Pengguna john membuat, menghapus, dan membuat ulang akun lain di pfe1 bernama john. User john menjadikan direktori home user john sebagai file tersembunyi untuk mengaburkan keberadaan akun pengguna ini.
• User john menyalin file /bin/true lebih dari /bin/false lalu /bin/bash lebih dari /bin/false untuk memfasilitasi login akun sistem yang biasanya tidak digunakan untuk login interaktif.
• User john membuat kata sandi untuk akun sistem whoopsie dan lightdm. Akun ini biasanya tidak memiliki sandi.
• Akun pengguna johnn berhasil masuk dan pengguna johnn gagal mencoba menjadi pengguna whoopsie dan lightdm.
• Server pfe1 telah disusupi secara serius.

Rekomendasi saya untuk PFE

• Buat ulang server pfe1 dari distribusi asli dan terapkan semua patch yang relevan ke sistem sebelum mengembalikannya ke layanan.
• Siapkan server syslog terpusat dan semua sistem di PFE hybrid cloud log ke server syslog terpusat dan ke log lokal untuk mengkonsolidasikan data log dan mencegah gangguan dengan log sistem. Gunakan produk informasi keamanan dan pemantauan peristiwa (SIEM) untuk memfasilitasi tinjauan dan korelasi peristiwa keamanan.
• Terapkan bash stempel waktu perintah di semua server perusahaan.
• Aktifkan log audit akun root di semua server PFE dan arahkan log audit ke server syslog terpusat di mana log tersebut dapat dikorelasikan dengan informasi log lainnya.
• Selidiki sistem dengan alamat IP 192.168.56.1 untuk pelanggaran dan kompromi, karena digunakan sebagai titik pivot dalam kompromi pfe1.

Jika Anda telah menggunakan forensik untuk menganalisis sistem file Linux Anda untuk kompromi, silakan bagikan tip dan rekomendasi Anda di komentar.

Gary Smith akan berbicara di LinuxFest Northwest tahun ini. Lihat highlight program atau daftar untuk hadir.