[Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik Acigi]

Bedirhan Urgun urgunb at hotmail.com
Thu May 24 14:25:49 EDT 2007


 
 Tabi detayli olarak gormeden bisey demek cok mantikli degil ama sanki implement ettiginiz ana obje (class), choke point (girdi bogumu) gibi geldi bana. Hicbir girdi burdan gecmeden uygulamaya girmiyor (kullanilmiyor). Bunun icin de _GET ve _POST degiskenlerine ulasimi engellemissiniz sanirim. Gelistirici direk eristigi zaman kod icinde bu durumlar acikca goruluyor ve potansiyel olarak guvensiz durumlar (tainted variables gibi yani) oluyor.
 
 Okudugum bi makalede soyle bi ana fikir vardi: pozitif girdi kontrolunu (sunucu tarafinda) kullaniciya en yakin yerde yapin ama uygulamanin icinde yeri geldiginde mantiksal girdi denetimleri de uygulayin. Mesela kredi karti numarasini uygulama girisinde kontrol edin (sadece rakamlardan olusacak), ama bu kredi karti bilgisini business object'lerde kullanacaginiz zaman, kredi karti numarasi algoritmalarini uzerinde uygulayin (mantiksal olarak bu gercekten kredi karti numarasi mi).
 
 Soylemesi kolay. Her orta capta program yazan, bunlari uygulanmanin ne kadar zor geldigini cok iyi bilir. Burda da guvenlik kutuphaneler yardima yetisebilir.
 
 


Date: Thu, 24 May 2007 14:29:09 +0100From: ferruh at mavituna.comTo: urgunb at hotmail.comSubject: Re: [Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik Acigi]CC: huzeyfe at lifeoverip.net; owasp-turkey at lists.owasp.orgBence giris noktasi kontrolleri cok verimli degil. 1-2 sene kadar 10 kisilik falan bir ekibin calistigi bir web uygulamasinda (PHP) guvenli kutuphaneler gelistirdik. Bu gelistirmede su sekilde bir yontem uyguladik ve bayagi da verim aldik. Herseyden ote direk GET ve POST vs. her turlu erisimleri gelistiriciye kapadik. Dolayisiyla kod yazarlarken isteseler de bu verilere direk ulasamiyorlardi. Ikinci olarakta bu verilere erisimi ana obje altinda tek bir class tan yaptik, eger sayfa HTML e cikti gidecekse HTMLSafe gibi bir isimli property den koyuyorlar, eger SQL e gidecekse bunu da SQLsafe gibi bir property den. Ek olarak girdinin ozune de de bazen erismek gerekiyor onu da ek olarak koyduk erisime ama bu erisim cok basit sekilde yazilimda gozlenebiliyordu, dolayisiyla potansiyel olarak guvensiz olan yerler anlasiliyor. Maalasef PHP de strong type olmamasindan dolayi bazi limitleri implemente etmedik. Mesela aynisi .NET te cok daha verimli sekilde yapilabilir.Aslinda dumur noktasi su, bu adamlar niye parameterized SQL ler kullanmiyorlar ? Ikincisi basit bir sekilde kontrollerin son noktada yapilmasi katman karmasasindan dogan buradaki gibi sorunlari da cozuyor. Katmandan kastim kodun geldigi yeri bilmemek. Genelde web uygulamalarinda olan bir sey. WP deki Bir onceki SQL Injeciton acigi da bu sekilde cache sistemindeydi ( http://www.notsosecure.com/folder2/2007/04/03/wordpress-212-xmlrpc-security-issues/).Eger acigi kaynak koddan takip ederseniz yaklasik 4 ten fazla fonksiyondan geciyor ve neredeyse pasif olarak cacheleme ile ilgili bir yerde SQL Injection olusuyor. Muhtemel bir skaynak kod analizinde bile gozden kacabilecek bir sey. 

On 24/05/07, Bedirhan Urgun <urgunb at hotmail.com> wrote: 

 Girdi denetimini stratejilerinde denetimi sunucuda nerde yapmak gerekir diye bi konu var. trust boundary, choke point meseleleri.  Acigin kaynak koduna baktim tam egitimlik (hatta tartismalik)... ******************function check_ajax_referer() {$cookie = explode('; ', urldecode(empty($_POST['cookie']) ?  <<------$_GET['cookie'] : $_POST['cookie'])); // AJAX scripts must passcookie=document.cookieforeach ( $cookie as $tasty ) { if ( false !== strpos($tasty, USER_COOKIE) )$user = substr(strstr($tasty, '='), 1);if ( false !== strpos($tasty, PASS_COOKIE) )$pass = substr(strstr($tasty, '='), 1);}if ( !wp_login( $user, $pass, true ) ) die('-1');******************* simdi genel bir strateji olarak girdi denetimini soyle yapilabilir; Girdi uygulamaya ulastigi en yakin noktada (choke point), daha ileri gitmeden. Ama yukaridaki durum boyle bir denetimi by-pass edebilir. Mesela double url encoded stringler (sunucu tarafindan uygulamaya gelmeden bir kere decode edilmislerdi) pozitif denetim fonksiyonlarimizi atlatabilirler (tam yukaridaki durum, yani regular expressionimizda % karakterine izin veriliyorsa varsa tamam).   Cok gelistiricili bir projede choke point falan yetmeyebiliyor demek ki. Daha kademeli bir anlayis lazim. Gelistiriciye "(giris noktasinda) girdi denetimi yap" dedikten sonra uygulamasinda boyle bi hata bulmak umutsuzluga dusurebilir.  bedirhan 


Date: Thu, 24 May 2007 09:49:57 +0100From: ferruh at mavituna.comTo: huzeyfe at lifeoverip.netCC: owasp-turkey at lists.owasp.orgSubject: Re: [Owasp-turkey] [Fwd: [netsec] WordPress Kritik Guvenlik Acigi] 
Biz de iki gun once test ettik, acik ilk yayinlandiginda. Gayet guzel bir sekilde calistigini onayliyabilirim.Ek olarak her daim WP kulanicilarinin admin kisimlarina en azindan ekstra bir Basic Auth eklemesini oneriyorum. Ek olarak  patch i  uygulayana kadar bu sekilde hizli ilk onlemi de almis olabilirsiniz. 
On 24/05/07, Huzeyfe ONAL <huzeyfe at lifeoverip.net> wrote: 
---------------------------- Original Message ----------------------------Subject: [netsec] WordPress Kritik Guvenlik AcigiFrom: "Huzeyfe ONAL" < huzeyfe at lifeoverip.net>Date: Thu, May 24, 2007 10:29 amTo: netsec at huzeyfe.net-------------------------------------------------------------------------- WordPress 2.1.3 kullanicilarinindikkatine...Bir iki gundur bloguma gelen web isteklerindekianormallikleri incelerken iki gun oncesine ait bir WP acigininkullanildigini kesfettim.wp-admin/admin-ajax.php ve buna bagli olanscriptlerdeki eksik kontroller yuzunden blogunuzun /wp-admin kisminaerisebilen kotu niyetli birisi sistemdeki wp kullanicilarina aitplain md5 ciktilarini alabilir(kendi sistemimde test ettim) ve otesinde bunu kullanarak sisteme admin yetkileri ilebaglanilabiliyor(mus)-test etmedim.Cesitli undergorundsitelerde konu ile ilgili exploitler yayinlanmis durumda. Aciktan korunma icin WP tarafindan cikarilan guncellemeler ( 2.2)gecilebilir Detayli Bilgi :http://secunia.com/advisories/25345/--Huzeyfe ONALhuzeyfe at lifeoverIP.nethttp://www.lifeoverip.netAg guvenligi listesine uye oldunuzmu?http://netsec.huzeyfe.net_______________________________________________ Owasp-turkey mailing listOwasp-turkey at lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-turkey-- Ferruh Mavitunahttp://ferruh.mavituna.com 

Create the ultimate e-mail address book. Import your contacts to Windows Live Hotmail. Try it!-- Ferruh Mavitunahttp://ferruh.mavituna.com 
_________________________________________________________________
Change is good. See what’s different about Windows Live Hotmail. 
http://www.windowslive-hotmail.com/learnmore/default.html?locale=en-us&ocid=RMT_TAGLM_HMWL_reten_changegood_0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-turkey/attachments/20070524/df8fdb41/attachment.html 


More information about the Owasp-turkey mailing list