“POP3 Protocol berfungsi untuk mendapatkan email dari server melalui TCP/IP”
Komunikasi melalui email merupakan fondasi penting kehidupan manusia saat ini. Pertukaran data dan informasi hingga pengambilan keputusan hampir mustahil terjadi tanpa melalui email. Begitu tergantungnya manusia saat ini terhadap email. Salah satu teknologi yang saat ini digunakan untuk melakukan fungsi tersebut adalah POP3 Protocol. Ia digunakan untuk mengakses email kita pada Mail Server. Melalui protocol ini kita dapat mengambil maupun mengirimkan email dari mail server menggunakan koneksi TCP/IP. S
Sayangnya implementasi POP3 tidak luput dari kerentanan Buffer Over Flow yang dapat berakibat fatal bagi keamanan komunikasi melalui email. Threat actor dapat memanipulasi kerentanan BOF ini untuk menguasai secara penuh sistem operasi terhadap sebuah mail server. Tentunya hal ini sangat berbahaya dan merupakan ancaman bagi privacy komunikasi kita semua.
Pada serial studi kasus kerentanan Buffer Over Flow kali ini, kita akan menerapkan beberapa konsep dasar dari artikel 0x0 Ghost from the past untuk melakukan identifikasi kerentanan hingga membuat working exploit untuk mengambil alih (pwnd) sistem operasi sebuah mail server. Pada artikel ini kita akan bereksperimen dengan SLMail versi 5.5, sebuah aplikasi POP3 yang telah diidentifikasi memiliki kerentanan BOF pada tahun 2004 oleh para peneliti keamanan informasi. Dalam artikel ini, aplikasi tersebut akan berjalan diatas Windows 7 32 bit dan mesin attacker akan menggunakan Kali Linux 2.0 Rolling.
Untuk melakukan identifikasi kerentanan hingga membuat exploit yang dapat memanipulasi dan mengeksploitasi kerentanan Buffer Over FLow tersebut, kita akan menggunakan pembahasan yang melalui tiga tahapan yaitu; Tahap Discovery, Tahap Develop dan Tahap Exploit.
Discovery
SLmail adalah perangkat lunak untuk berkomunikasi melalui email yang dikembangkan oleh Seattle Lab Software. Perangkat lunak ini dirancang untuk menyediakan layanan SMTP dan layanan POP3. SMTP protocol digunakan untuk berkomunikasi antar Mail Server melalui internet dan POP3 protocol digunakan oleh pengguna untuk meng-unduh dan mengirimkan email melalui Mail Server. SLmail version 5.5 memiliki sejumlah keunggulan yaitu: dapat mendukung jumlah pengguna email yang tak terbatas, dapat berintegrasi dengan third party melalui API yang disediakan serta memiliki administrasi mail berbasis web sehingga memudahkan administrator untuk mengelola Mail Server. Menurut Server Watch, ia dirancang untuk segmen entry to mid level Mail Server.
“Gambar 1. SLmail Server 5.5”
“Gambar 2. Administrasi pengguna pada SLmail Version 5.5”
“Gambar 3. Administrasi pengguna Slmail 5.5 melalui Web”
Untuk mencari kerentanan Buffer Over Flow pada SLmail 5.5, maka berinteraksi dan eksplorasi dengan protokol POP3 merupakan langkah awal. Kita dapat menggunakan netcat untuk mengetahui bagaimana SLmail berinteraksi dengan menggunakan beberapa command yang biasanya diterima oleh POP3 protocol, yaitu: USER, PASS dan QUIT (gambar 4).
“Gambar 4. Berinteraksi dengan SLmail 5.5 dengan netcat”
Berdasarkan penelitian yang dilakukan oleh Muts (peneliti keamanan informasi) ditemukan adanya kelemahan pada command PASS. Selanjutnya kita melakukan investigasi lebih lanjut dengan melakukan fuzzing menggunakan bantuan python script sebagaimana terlihat pada gambar 5 berikut ini.
“Gambar 5. Python script untuk melakukan fuzzing pada PASS command di SLmail versi 5.5”
Selanjutnya kita lakukan eksekusi script tersebut pada POP3 server yang berjalan pada mesin dengan sistem operasi Windows 7 32 bit. Dengan hasil, aplikasi tersebut crashed ketika menerima data yang berjumlah 2900 byte, hal tersebut dapat dilihat pada gambar 6 dan gambar 7 sebagaimana berikut.
“Gambar 6. Python script berhenti pada saat mencapai 2900 byte”
“Gambar 7. Aplikasi SLmail 5.5 crashed ketika menerima”
Berdasarkan hasil fuzzing pada command PASS, terlihat bahwa teridentifikasi dan terverifikasi adanya kerentanan Buffer Over Flow pada SLmail versi 5.5. Pada gambar 7 terlihat bahwa karakter 41 atau karakter “A” melakukan overwrite stack dari stack paling atas yang ditunjuk oleh register ESP (pada alamat 00E5A128) dan serta menyebabkan register EIP corrupt karena berisi nilai “A”, akibatnya aplikasi tersebut crashed. Kondisi Buffer Over Flow tersebut terjadi ketika kita memberikan data sebesar 2900 bytes. Temuan ini akan menjadi pijakan pada fase berikutnya ketika membuat exploit untuk memanipulasi kerentanan ini.
Develop
Setelah mengidentifikasi dan melakukan verifikasi adanya kerentanan Buffer Over Flow pada command PASS, langkah selanjutnya adalah membangun hipotesa tentang berbagai faktor agar exploit yang kelak dibuat dapat berjalan dengan baik. Untuk itu langkah awal adalah menemukan lokasi alamat yang ditunjuk oleh ESP pada stack disaat terjadinya Buffer Over Flow. Hal ini tidak akan teridentifikasi dengan mengirimkan 2900 karakter yang semuanya sama. Untuk itu dibutuhkan 2900 karakter dengan pola tertentu. Kita akan menggunakan script bernama pattern_create.rb yang tersedia pada Kali Linux untuk menghasilkan karakter dengan pola spesifik tersebut serta melakukan update pada script kita (gambar 8 dan gambar 9).
“Gambar 8. Membuat rangkaian karakter dengan pola spesifik untuk mencari lokasi alamat ESP pada saat terjadinya Buffer Over Flow “
“Gambar 9. Melakukan update terhadap script python dengan menggunakan pattern yang telah dibuat”
Setelah meng-update script python, langkah selanjutnya kita kembali mengaktifkan POP3 services pada mail server dan meng-eksekusi script tersebut. Hasilnya, kita mendapatkan nilai EIP pada saat terjadi Buffer Over Flow adalah 44396944 (lihat gambar 10). Berdasarkan informasi ini, kita dapat melakukan estimasi jumlah karakter yang harus kita gunakan untuk mengendalikan EIP. Kita dapat menggunakan tools bernama pattern_offset.rb yang tersedia pada Kali Linux untuk menghitung jumlah karakter tersebut, dimana hasilnya adalah 2607 (lihat gambar 11 berikut ini).
“Gambar 10. Menjalankan script untuk mendapatkan alamat yang ditunjukkan oleh register EIP pada saat kondisi BOF terjadi”
“Gambar 11. Menghitung jumlah karakter yang dibutuhkan untuk menghasilkan nilai yang ditunjukkan oleh register EIP pada saat kondisi Buffer Over Flow terjadi”
Berdasarkan perhitungan tersebut, maka kita dapat mengembangkan hipotesa untuk script exploit yang akan kita gunakan untuk memanipulasi kerentanan tersebut. Script tersebut memiliki tiga komponen utama, yaitu komponen untuk membuat kondisi Buffer Over Flow sehingga dapat meng-overwrite EIP dan mengendalikannya yang dilakukan dengan karakter “A” sebanyak 2607 bytes. Komponen berikutnya adalah return address sebanyak 4 bytes yang diwakili karakter “B” sebanyak 4 bytes, dan akhirnya komponen shellcode itu sendiri yang untuk sementara ini sebanyak 100 bytes yang diwakili oleh karakter “C”. Hipotesa script tersebut dapat dilihat pada gambar 12 sebagaimana berikut ini.
“Gambar 12. Membangun hipotesis untuk mengendalikan register EIP pada saat kondisi Buffer Over Flow terjadi”
Setelah hipotesa untuk exploit dituangkan ke dalam script seperti terlihat pada gambar 13, maka langkah selanjutnya adalah melakukan pengujian dan verifikasi terhadap hipotesa tersebut. Kriteria keberhasilan pengujian hipotesa tersebut adalah dapat menciptakan kondisi Buffer Over Flow (melalui karakter “A”) dan meng-overwrite EIP dengan return address melalui karakter “B”. Pada gambar 10 berikut ini, menunjukkan bahwa hipotesa telah terbukti benar. Stack dapat di-overwrite dengan karakter “A”, register EIP menunjukkan lokasi return address dan register ESP menunjukkan alamat awal dari shellcode kita pada 020FA128. Shellcode diwakilkan dengan karakter “C”.
“Gambar 13. Hasil pengujian hipotesis yang menunjukkan dapat mengendalikan register EIP saat kondisi Buffer Over Flow terjadi”
Akhirnya tibalah kita pada pertanyaan penting berikutnya, yaitu: apakah ruang bagi shellcode sudah mencukupi (lihat gambar 14)? Mengingat kita akan membuat shellcode dengan menggunakan bantuan tools msfvenom yang biasanya menghasilkan shellcode cukup besar, yaitu antara 350 hingga 400 bytes. Untuk itu kita memperbaiki script dengan melakukan modifikasi terhadap jumlah karakter “C” dari sebelumnya berjumlah 100 bytes menjadi 380 bytes.
“Gambar 14. Apakah hipotesis sudah mengalokasikan ruang yang memadai bagi shellcode di memory ?”
“Gambar 15. Menyempurnakan hipotesis dengan mengalokasikan ruang yang memadai bagi shellcode”
Untuk itu kita harus mempertimbangkan jumlah karakter ketika kita melakukan fuzzing diawal yaitu 2900 bytes sebagai batas optimal. Dengan demikian kita mengalokasikan ruang bagi shellcode kurang lebih 389 bytes saja pada script exploit yang kita kembangkan (lihat gambar 15). Hal ini kita lakukan agar tidak melampaui batas optimal ketika Buffer Over Flow terjadi. Pada prinsipnya, semakin kecil ukuran shellcode semakin baik, karena “hemat tempat”. Apabila kita membuat shellcode secara manual ukurannya dapat lebih kecil dibandingkan jika menggunakan tools seperti msfvenom.
Exploit
Setelah hipotesa terbukti dapat menciptakan Buffer Over Flow, mengendalikan register EIP serta mengarahkan register ESP untuk menunjukkan pada lokasi shellcode yang kelak akan kita letakkan pada memory. Maka langkah selanjutnya adalah memastikan agar shellcode yang kita buat dapat berjalan dengan baik dengan menghilangkan dan menyingkirkan bad character. Bad character adalah karakter yang difilter oleh SLmail verison 5.5 yang berakibat shellcode yang kita miliki terpotong dan tidak utuh berada di memory . Hal ini berakibat shellcode tidak bisa dieksekusi oleh CPU.
Untuk mencari dan mengidentifikasi bad character, maka kita akan memberikan rangkaian karakter dari 0x00 hingga 0xFF pada aplikasi SLmail version 5.5. Dengan bantuan python script berikut ini kita dapat membuat rangkaian test character tersebut (lihat gambar 16) serta hasil dari script tersebut dapat dilihat pada gambar 17 sebagai berikut.
“Gambar 16. Python script untuk membuat test character dari 0x00 hingga 0xFF”
“Gambar 17. Test character dari 0x00 hingga 0xFF”
Sesuai dengan hasil pada gambar 17, maka kita akan meng-update script hasil hipotesa yang telah diuji dengan test character tersebut. Adapun hasil script setelah memasukkan rangkaian test character dapat dilihat pada gambar sebagaimana terlihat pada gambar 18 berikut ini.
“Gambar 18. Python script untuk mencari dan mengidentifikasi Bad Character”
Setelah script untuk mengidentifikasi dan mencari bad character selesai dibuat, maka langkah selanjutnya kita melakukan “perburuan” terhadap bad character pada SLmail version 5.5. Adapun hasil dari perburuan tersebut dapat disimpulkan ada tiga character yang harus dibersihkan dari shellcode yaitu: “\x00\x0A\x0D”. Adapun rangkaian pencarian dan identifikasi bad character dengan menggunakan script tersebut dapat dilihat secara berturut-turut pada gambar 19, gambar 20 hingga gambar 21 berikut ini.
“Gambar 19. Character \x00 adalah Bad Character”
“Gambar 20. Character \x0A adalah Bad Character”
“Gambar 21. Character \x0D adalah Bad Character”
Setelah Bad Character teridentifikasi, selanjutnya adalah menentukan return address. Hal ini telah dibahas pada artikel sebelumnya (“Ghost from The Past“) tentang sangat pentingnya peran Return Address dalam pembuatan exploit. Apabila mengacu pada nilai ESP yang senantiasa berubah-ubah serta teridentifikasi memiliki bad character, seperti terlihat pada awal alamat di gambar 13 yaitu “020FA128“. Tentu kita tidak dapat menggunakan alamat tersebut sebagai return address bagi script shellcode yang sedang kita kembangkan.
Untuk mengatasi permasalahan ini, kita harus mencari alternatif alamat return address yang dapat digunakan. Persyaratannya adalah return address tersebut adalah tidak mengandung bad character dan module yang menggunakan address tersebut tidak terproteksi oleh beberapa mekanisme proteksi memory dari Microsoft seperti DEP dan ASLR. Kita dapat menggunakan bantuan tools pendukung dari Immunity Debugger bernama mona.py. Tools tersebut dapat diunduh di sini, setelah diunduh tools tersebut diletakkan pada lokasi C:\Program Files\Immunity Inc\Immunity Debugger\PyCommands pada mesin Windows 7 tempat SLmail berjalan.
Dengan menggunakan perintah “!mona modules” pada Immunity Debugger, kita dapat mencari dan memilih module yang tidak terproteksi oleh mekanisme proteksi DEP dan ASLR dari Microsoft. Berdasarkan hasil analsis mona.py, dapat disimpulkan bahwa module SLMFC.DLL tidak menggunakan proteksi DEP dan ASLR (lihat gambar 22).
“Gambar 22. Module SLMFC.DLL tidak menggunakan proteksi DEP dan ASLR”
Setelah module yang akan digunakan telah teridentifikasi, yaitu: SLMFC.DLL. Selanjutnya kita harus mencari alamat dimana module ini menggunakan perintah JMP ESP, sebuah perintah yang akan digunakan oleh register ESP pada saat kondisi Buffer Over Flow yang kita ciptakan terjadi. Untuk memudahkan pencarian tersebut, kita dapat mengkonversi opcode yang ekuivalen dengan perintah JMP ESP dengan menggunakan tools bernama nasm_shell.rb yang tersedia pada Kali Linux. Dengan menggunakan tools tersebut kita mendapatkan informasi bahwa opcode yang ekuivalen adalah: “FFE4“, sebagaimana terlihat pada gambar 23 sebagai berikut.
“Gambar 23. Module SLMFC.DLL tidak menggunakan proteksi DEP dan ASLR”
Dengan bantuan mona.py, kita dapat melanjutkan pencarian alamat yang digunakan oleh module SLMFC.DLL untuk menjalankan instruksi JMP ESP. Perintah yang kita gunakan pada Immunity Debugger adalah: “!mona find -s “\xff\xe4″ -m slmfc.dll”. Hasilnya adalah beberapa alamat alternatif untuk return address, namun kita akan mencoba memverifikasi alamat “5F4A358F” pada script exploit yang kita miliki. Hasil verifikasinya ternyata alamat ini menunjuk pada alamat “779D1463” yang berisi instruksi “FFE4” atau “JMP ESP” (lihat gambar 24). Meskipun ada perbedaan alamat, namun dapat digunakan. Jangan lupa untuk memperhatikan bahwa IA-32 menggunakan peraturan Little Endian sehingga alamat “779D1463” diubah menjadi “\x63\x14\xD1\x77” ketika meng-update script exploit yang kita kembangkan.
“Gambar 24. Module SLMFC.DLL menggunakan alamat 779D1463 untuk mengeksekusi perintah JMP ESP”
“Gambar 25. Membuat shellcode berdasarkan informasi dan hipotesis yang dibangun”
Setelah semua informasi untuk melengkapi hipotesa yang sudah dibangun lengkap. Tibalah kita pada tahap akhir, yaitu membuat shellcode dengan menggunakan perangkat msfvenom pada Kali Linux. Adapun payload yang kita gunakan adalah windows/shell_reverse_tcp dengan variable LHOST adalah IP Address dari kita selaku threat actor yaitu LHOST 172.16.123.134 dan LPORT adalah 443. Format file yang kita inginkan adalah dalam bahasa C, encoder yang kita pilih adalah shikata_ga_nai, arsitektur dari mail server adalah x86 dan akhirnya bad character yang tidak boleh ada dalam shellcode adalah “\x00\x0a\xd”. Hasil dari shellcode dapat dilihat pada gambar 25.
Setelah itu, kita melakukan update terhadap script exploit dengan memasukkan hasil shellcode dan return address yang telah kita peroleh. Adapun working exploit tersebut dapat dilihat pada gambar 26.a dan gambar 26.b berikut ini:
“Gambar 26.a. Working exploit script yang digunakan untuk mengeksploitasi Mail Server SLmail version 5.5”
“Gambar 26.b. Working exploit script yang digunakan untuk mengeksploitasi Mail Server SLmail version 5.5”
Akhirnya kita melakukan eksekusi terhadap Mail Server yang menggunakan exploit script tersebut, serta menjalankan netcat dengan listening port 443. Hasilnya, kita dapat melakukan eksploitasi terhadap kerentanan Buffer Over Flow dan dapat menguasai mesin tersebut dengan mendapatkan privilege Administrator dari Sistem Operasi Windows 7 32 bit (Gambar 27).
“Gambar 27. Mengeksploitasi kerentanan Buffer Over Flow dan menguasai Sistem Operasi Windows 7 32 bit dari Mail Server SLmail version 5.5”
Kesimpulan
Berdasarkan rangkaian analisis, eksperimen dan eksplorasi terhadap kerentanan Buffer Over Flow pada SLmail version 5.5, dapat disimpulkan beberapa hal. Kerentanan Buffer Over Flow pada aplikasi Mail Server sangat berbahaya, karena dapat di-eksploitasi oleh threat actor untuk menguasai Sistem Operasi pada mesin tersebut. Hal ini dapat berdampak pada akses yang lebih luas terhadap seluruh aspek pada mesin tersebut, dimana mailbox pengguna adalah salah satunya.
Untuk mencegah terjadinya resiko ini, maka sangat penting untuk senantiasa melakukan monitor terhadap berita dan perkembangan aplikasi Mail Server yang kita miliki. Security update dari vendor pembuat penting untuk senantiasa dikaji dan diuji sebelum diterapkan pada Mail Server yang tengah operasional. Namun, apabila produk Mail Server tersebut sudah tidak berlanjut (discontinued) sebaiknya mengganti dengan produk yang memiliki dukungan vendor yang lebih baik. Pada kasus SLmail version 5.5, nampaknya Seatlle Lab Software sudah tidak melanjutkan produknya.
Py-Sec[dot]org 