30 Ekim 2010 Cumartesi

1.1: Oturum Yönetimi (Session Management)

HTTP Protokolünde Oturum Yönetimi

Bir istek yaparsınız sunucuya, size cevap döner, ikinci bir istek yaptığınızda sizi tanımaz. İsterseniz aynı IP'den girmiş olun. Halbuki örneğin bir bankacılık uygulamasında bir kez login olduğunuzda defalarca istek yaparsınız ve sunucu sizi tanır. Tanıması oturum yönetimiyle olur. Genelde cookie'ler aracılığıyla oturum yönetilir.
session.start(); => Bu andan itibaren artık bir cookie var.
Cookie'yi çaldırmak çok kötü. Çalan, artık sizmişsinizi gibi o sitede oturuma devam edebilir.

Same Origin Policy (SOP)

Aynı kaynak politikası. Web scripting dillerinin (javascript mesela) güvenlik sınırlarını belirleyen en önemli kural.
Kaynak şunlardan oluşur:

Protokol (http, ftp, mailto vs)
Domain name (alan adı) (www.google.com gibi)
Port

İki kaynağın aynı olduğu kararı için bu 3 bilginin aynı olması gerek ve yeter şart.
NOT: www.google.com ile google.com domainleri FARKLI olarak değerlendirilir (www.google.com subdomaindir).

Cross Site Tracing (XST)

XST konusunda VasiliTR tarafından hacturkiye.com sitesinde yayınlanan yazıdır:
XSS ile akraba fakat işlevleri farklı.
Cross Site Tracing sözlük anlamı olarak Çapraz Site Gözleme. XST’i bulan kişi, açık hakkında “İlk bulduğumda gerçekten kötü olduğunu düşünmüştüm.” demiş.

XST, bir attacker’ın get, post vs. gibi bir yöntem ile girdiği veriyi web sunucusunun kabul etmesine dayanır. Fakat TRACE temel olarak http verilerini taklit eder. TRACE Genel olarak hata ayıklama için kullanılır.Bu sayede yüklendikten sonra verilerine göre etkin kılınır.

Sunucuya etkin kılma isteği gelene kadar, site yazı alanlarında risk söz konusudur. Buralardan http cookies çalınabilir.

Buradaki asıl hedef; kullanıcıların çerezlerini biriktirmek.

Buradaki attack şekli işe şu; kullanıcı bir uygulamaya yanlış yönlendirilebilir, bu da attackerlar tarafından avantaj kabul edilir.

XST’i Çalıştırmak için 3 farklı yöntem vardır.
Java sockets, Microsoft. XMLHTTP activeX object, ve flash. Java prizlerindeki problem, kendi bağlantılarını yaptıklarında çerezlerini ve oturumlarını gözden geçiren kişiden ayrı tutar bundan dolayı gözden geçiren kişiye iletmez.

Cross Site Scripting’den farkı şudur: XST, size sadece http’deki cookieleri çalıp verebilir.

Sadece Java yazılımlarıyla http çerezleri elde edilemez. XST, XSS'den daha savunmasızdır.

Server savunmasız ise XST’yi nasıl test edip engelleriz?
Sunucu savunmasız ise Burp Suite ti kullanacağız. burp u aç ve tekrarlayıcıyı seç. Buna benzer bir şeylerin daveti varsa değiştir. :

TRACE / HTTP/1.0
Header1: <script>alert(document.cookie);</script>

Trace secilebiliyorsa buna benzer bir seyler vardır:
HTTP/1.1 200 OK
Date: Sun, 23 Sep 2007 02:48:05 GMT
Server: Apache/1.3.34 (Ubuntu) mod_perl/1.29
Connection: close
Content-Type: message/http

TRACE / HTTP/1.0
Header1: <script>alert(document.cookie);</script>

28 Ekim 2010 Perşembe

DotDotPwn 1.0

Dizin gezinimi denetimi için Perl'de hazırlanmış bir uygulama: DotDotPwn (ddpwn.pl)

HTTP::Lite ve Net::FTP desteği olan Perl gerekiyor çalışması için.
1.0 versiyonunda ilk kurulumda 871 saldırı payload'u var. Online update için: #perl ddpwn.pl -update
HTTP Tarama: #perl ddpwn.pl -http 192.168.1.53
FTP tarama da aynı şekilde, -ftp parametresiyle.

Perl üzerinde gerekli ayarların olduğunu düşünüp doğrudan çalıştırdım uygulamayı; "Can't locate HTTP/Lite.pm in @INC" ile başlayan bir hata mesajı ile karşılaştım. bunun ortadan kaldırılması için 2 yol var:

#perl -MCPAN -e'install HTTP::Lite'
Ya da apt-get yada yum gibi distro'nun kullandığı kurulum araçları.

Bundan sonra http dizin gezinimi taraması hata vermiyor.

ANCAK, bir türlü tarama yapmayı beceremedim, her seferinde "Remote address 193.168.1.45 seems not to be up..." mesajı ile karşılaşıyorum. Başarıya ulaşabilirsem sorun ve çözüm yolu ile bu post'u update edeceğim.

19 Ekim 2010 Salı

HE:WA-C6 Popular Characters to Test Input Validation

Popular Characters to Test Input Validation

Karakter	URL Encode	Yorum
'	%27	SQL injection için gerekli. Bilgisel hatalar üretir.
;	%3b	Komut ayracı; scriptler için sayfa sonlandırıcı
[null]		Dosya erişimi için string sonlandırıcı, komut ayracı
[return]	%0a	Komut ayracı
+	%2b	URL'de boşluğu ifade eder. SQL injection için de iyidir.
<	%3c	HTML tag açar
>	%3e	HTML tag kapatır
%	%25	Çifte decode için faydalıdır, arama alanlarında kullanılır, JSP tag
?	%3f	PHP tag'e delalet eder
=	%3d	URL parametresinde birden fazla eşit işareti yerleştirme
(	%28	SQL injection
)	%29	SQL injection
[space]	%20	Uzun scriptler için gereklidir
.	%2e	Dizin gezinimi, dosya erişimi
/	%2f	Dizin gezinimi

HE:WA-C6 Common Countermeasures

Common Countermeasures

Zaten konuları irdelerken bazı önlemler sıralandı. Üstünden geçelim:

İstemci tarafında girdi denetimini performans için yap, güvenlik için değil! Kötü niyetli bir kullanıcı her zaman istemci tarafı kontrollerini bypass edebilir, bu kontrolleri sunucu tarafında tamamlamak gerekir.
Girdi değerlerini normalize et. Saldırılar karakter kümelerini ve hexadecimal gösterimi temel alan düzinelerce değişik encoding pattern dener.
Sunucu-taraflı girdi denetimi uygula.
Veri türlerini sınırla. Nümerikse nümerik, strginse string.
Karakter encoding ve "çıktı denetimi".
Beyaz liste/siyah liste. İzin verilen/verilmeyen içeriği belirlemede "regular expression" kullan.
Hataları güvenlice ele al.
Kimlik doğrulamayı gerekli kıl. Dizin seviyesinde, dizin içndeki tüm dosyalar için.

En az hak erişim hakkı kullan. Kullanıcıya ihtiyacı olan en az yetkiyi ver.

HE:WA-C6 Other Input Validation Attacks

Boundary Checks

Sınırların dışında değerler girip uygulamanın üreteceği sonuçlara bakalım. Byte için üst sınır 255, iki-byte için 65.535 mesela.

· Boolean: T/F, true/false, 1/0. İki değeri de dene, sonra bambaşka birşey dene. Karakter isteyen parametreye numara, numara isteyene karakter gir.

· Numerik: 0 yada negatif değer (-1) gir. Üstten taşmayı dene: 256, 65536, 4294967296 vs.

· String: Uzunluk sınırını taşmayı dene. Noktalama işaretleri kabul eden girdi alanlarını tesbit et.

Manipulate Application Behavior

Bazı uygulamalar developer'ın test için kullandığı özel komutlara sahip olabilir. En yaygını "debug=1". Bu parametreyi GET veya POST talebine eklemek sistem yada değişkenler yada veritabanı vs hakkında detaylı bilgi döndürebilir. Debug yerine dbg, 1 yerine T yada true vs dene.

SQL Injection And Datastore Attacks

En basitinden adreste parametre olarak "or+1=1" denenir. Detaylı olarak ileride incelenecek. Biraz daha bilgi için: http://webuygulamalariguvenligi.blogspot.com/search/label/SQL%20Injection

Command Execution

Çoğu saldırı ile genelde sadece bilgi elde edilir, komut işletimi ise süper bir goldür.

Detay için: http://webuygulamalariguvenligi.blogspot.com/2010/05/web-app-pentest-egitimi-19-os.html

HE:WA-C6 HTML Injection

HTML Injection

En basit script atağı form alanına <script> tag'ini girmek. Bu atağın gerçek hedefleri, kötü niyetli içeriği görecek olan diğer uygulama kullanıcıları olacaktır ki, sosyal mühendislik saldırısına kurban olacaklar.

Bu saldırının 2 ön şartı var:

Uygulama kullanıcıdan girdi kabul etmek zorunda. Dikkat: bu girdi form alanından yapılamk zorunda değil; URL sorgu parametresi, HTTP header ve cookiler de olabilir.
Uygulama, girdiyi tekrar göstermeli. Saldırı, uygulama veriyi render ettiğinde oluşacaktır; girdi HTML tag olacak ve borwser tarafından yorumlanacak.

XSS (Cross-Site Scripting)

XSS saldırılarında kötü niyetli kod, genellike JavaScript, başka kullanıcıların göreceği lokasyonlara yerleştirilir. Genelde kullanıcının cookie'sini çalmak için kullanılır.

<script>document.write(document.cookie)</script>

<script>alert('Salut!')</script>

Bir uygulamanın arama motoru, XSS saldırıları için birincil hedeftir:

http://website/search/search.pl?qu=<script>alert('foo')</alert>

Hata sayfaları çoğu zaman XSS saldırılarına konu olur:

http://website/inc/errors.asp?Error=Invalid%20password
http://website/inc/errors.asp?Error=<script%20src=...

Embedded Scripts

XSS saldırısı uygulamanın başka kullanıcılarını hedef alırken, gömülü script saldırısı uygulamanın kendisini hedef alır.

Bu olayda <script> tag çiftleri değil, formatlama tag'leri kullanıyoruz: SSI direktifleri, ASP parantezleri, PHP parantezleri, SQL sorgu yapıları ve hatta HTML tag'leri. Birkaç kategori:

ASP sayfaları için date() fonksiyonunun sonuç dönüp dönmediği test edilir:

<%= date() %>

Sunucu-tarafı "include"ları :

<!--#include virtual="global.asa" -->

<!--#include file="/etc/passwd" -->

<!--#exec cmd="/sbin/ifconfig –a" -->

Gömülü Java ve JSP de ASP kadar tehlikeli:

<% java.util.Date today = new java.util.Date(); out.println(today); %>

PHP'yi unutmayalım:

<? print(Date("1 F d, Y")); ?>

<? Include '/etc/passwd' ?>

<? passthru("id");?>

Cookies and Predefined Headers

Küçük ve büyük işaretlerini HTML-encode değerlerine çevirelim: < küçüktür için ve > büyüktür için.
Bazı uygulamalar kullanıcının bold, italik, altı çizgili vs değerler girmesine izin vermesi gerekebilir. Bu durumda sadece zararlı olduğunu düşündüğü tag'leri engelleme yoluna gidilmiş olabilir. Bu gibi durumlar için aşağıdakine benzer girdi değerleri deneyebiliriz:

<scr%69pt>

<<script>

<b+<script>

<scrscriptipt> (uygulama gördüğü "script"leri null ile değiştiriyor ise)

HE:WA-C6 Common Input Validation Attacks

Common Input Validation Attacks

Bu başlık altında sadece açıklığın varlığını araştırma ile yetinilecek. Örneğin SQL injection da bir girdi denetimi açığı, fakat detayları burada incelenmeyecek.

Buffer Overflow

Yorumlanan yada üst düzey dillerde karışlaşılması daha zordur.

Sunucuya normal bir talep gönder, sunucunun dönüşünü (response) kaydet-not et.
İlk bufer taşması testini uygulamaya gönder, sunucunun dönüşünü kaydet.
Bir sonraki buffer'ı gönder, sunucunun dönüşünü kaydet.
Üçüncü adımı gerektiği kadar tekrar et.

Ne zaman sunucunun dönüşü normal talebe göre değişiyorsa ne değiştiğini incele.

Not: Çoğu zaman bu saldırı "blind"dır. Bir debugger attach etmeden veya logları / sistem bilgilerini görmeden açıklığı exploit etmek pek mümkün değildir.

Örnek: Strig bir alana 500 tane "a" karakteri gönderip sonucunu izleyelim. Unix'teki "perl" komutu bu işte bize kolaylık sağlayacaktır: perl –e 'print "a" x 500'. Mesela bu komutu "curl" ile birleştirip kullanabiliriz:

$ curl https://website/login.php?user=`perl –e 'print "a" x 500'`

Canonicalization (Dot-Dot-Slash)

Bu saldırı, template kullanan sayfaları hedef alır, bunun dışında web sunucu üzerindeki altefnatif dosyaları referans alır.
Web uygulama sunucuları genellikle "../../../../../../../../../../../boot.ini" tarzındaki saldırıları engelleyecek kadar akıllıdır.
Bu teknik, talep edilen dosyanın lokasyonunu ve/veya içeriğini kontrol etmeyen sunucular üzerinde başarılı olabilir.
Bazı teknikler:
- (null karakter URL encode) karakterini kullanmayı sakın unutma. Uygulama path'in sonuna statik olarak ".html" vs ekliyor olabilir; null karakteri talebi orada keser.
- Null karakteri soyulup çıkarılıyor olabilir, bir de %0a dene (new line URL encode)
- ../ yerine bunların URL encode'ları %2e%2e%2f dene. Bu da engelleniyor olabilir, farklı kombinasyonlar dene (..%2f, %2e%2e/ gibi)

Dosyaların dökümünü/sayımını çıkarma:

Hata kodlarını sına.

Sent:    /includes/printable.asp?Link=../../../../inetpub/blablabla

Return:  Micosoft VBScript runtime error '800a0046'


Path not found

         /includes/printable.asp, line 10

Sent: /includes/printable.asp?Link=../../../../Program%20Files/

Return: Micosoft VBScript runtime error '800a0046'

Permission denied

/includes/printable.asp, line 10

"blablabla" için "Permission Denied" alınsaydı bu bir bulgu olmayacaktı...

Kökü bul. Sürücü harfini yada root'u bulana kadar dizin gezinimi karakterleri ekle.
Web doküman köküne in. Buradaki dosyaların dökümünü almak kolay, zaten uygulama profili (crawling) esnasında yolun çoğunu aldık.
Yaygın dizinleri bul. Geçici dizinleri (/temp, /tmp, /var), program dizinlerini (/Program Files, /winnt, /bin, /usr/bin) ve popüler dizinleri (/home, /etc, /downloads vs) sına.
Dizin isimlerine erişmeye çalış.

Countermeasures

GET ve POST taleplerinden bütün noktaları temizle. Ayrıca parsing motoru noktanın Unicode ve hexadecimal değerlerini de yakalasın.
Uygulamanın bütün okumaları özel bir dizin içinden olsun.
Dosya erişimi sistem izinlerini güvenli hale getirmek bu saldırıyı zorlaştıracaktır.

*.inc gibi hassas dosyalar web dokümanı kök dizininin dışına taşı.

HE:WA-C6 Input Validation Attacks

Expect the Unexpected

Girdi denetimi saldırılarının cepheleri:

Veri saklama ünitesi: SQL Injection saldırılarında kullanılan karakterleri içerir.
Diğer kullanıcılar: XSS ve "phishing" saldırılarını içerir. Kullanıcı, HTML'i tekrar düzenleyen bilgi submit edebilir.
Web sunucusu host'u: Saldırı, işletim sistemine has olabilir, örneğin UNIX'te bir ";" koyarak yeni bir sistem komutu gönderebilir kullanıcı.
Uygulama içeriği: Saldırgan, uygulamanın yazıldığı dil ile ilgili detaylı bilgileri içerecek hata mesajları üretebilir.
Sunucuda tampon bölge taşması (Buffer overflow): Saldırgan girdi alanına mümkün olduğu kadar büyük değer girer, sonuçta uygulama crach olabilir yada farklı sonuçlar dönebilir. Daha çok C ve C++ gibi derlenen (compiled) için düşünülmeli, Perl ve Phyton gibi yorumlanan (interpreted) diller için değil. Java ve .NET için de buffer overflow çok zordur, çünkü bu diller programcıya doğrudan hafıza yönetimine izin vermiyor.
Keyfi veri erişimi: Bir müşterinin başka bir müşterinin verilerini sorgulaması gibi. Erişimi engellenmiş dosyalara yada admin alanlarına erişim de aynı şekilde.

Where to find Attack Vectors

Bütün GET ve POST talepleri, girdi denetimi saldırıları için bir yemdir. Argumanları değiştirmek, FORM verileri ile oluşturulmuş yada uygulama tarafından oluşturulmuş olsun, çok kolaydır. Girdi alanları saldırıların en kolay noktalarıdır.
Sakın girdi denetimi saldırıları sadece kullanıcı tarafından girilen alanlarda yapılır gibi bir yanlış anlamaya düşülmesin. GET ve POST taleplerindeki tüm değişkenlere saldırılabilir.
Cookie değerleri başka bir hedeftir. Cookie basitçe bir HTTP header olgusudur. Tüm HTTP header'ları da birer girdi denetimi vektörüdür.

HTTP talebi parçalama: Bir örnek:
http://website/redirect.cgi?page=http://website/welcome.cgi

"Page" parametresi ile oynayarak talebi şu hale getirebilir miyiz:

http://website/redirect.cgi?page=0d%0aContent-Type:%20text/ html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/ html%0d%0a%0d%0a%3chtml%3eHello, world!%3c/html%3e

Böylece talebi şu hale getirmiş oluruz:

Content-Type: text/html

HTTP/1.1 200 OK

Content-Type: text/html

<html>Hello, world!</html>

Bypass Client-Side Validation Routines
İstemci tarafı kontroller her zaman bypass edilebilir:
Kişisel proxy, kişisel güvenlik duvarları, cookie-yönetcileri vb yazılımları
aracılığıyla. Bunu yaparken JavaScriptleri tamamen kapamak, uygulamayı çalışmaz
hale getirebilir. Bunun yerine, Paros gibi kişisel proxy'ler ile GET ve POST
talepleri sunucuya göndermeden önce "pause" edilebilir; bu sayede
JavaScript kontrolünden geçtikten sonra talebi istedğimiz gibi modifiye
edebiliriz.

HE:WA-C5 Authorization Best Practices

Authorization Best Practices

Web ACL Best Practices

Apache Authorization

Özel bir URL'e kullanıcı erişimini kontrol etmek için 2 direktif var:

"Directory" direktifi: Kullanıcı erişimi kontrolü dosya yollarına dayalı ise kullanılır.
"Location" direktifi: Kullanıcı erişimi kontrolü URL'e dayalı ise kullanılır.

IIS Authorization

Web sayfaları ve dizinlerinin erişim kontrolünü yönetmek için IIS administration tool (iisadmin.msc).

Web Authorization/Session Token Security

SSL kullan
"Set-Cookie" response header'ının "Secure" parametresini kullanan cookieleri işaretle (her RFC 2109 için)
Kişisel olarak hassas veriyi token içinde tutma.
Yetkinin değiştiği durumlarda oturum ID'sini tekrar oluştur.
Replay saldırılarına kapıyı kapatmak için oturumlara zaman sınırı koy.
Eş zamanlı login olabilmeye sınır koy. Birden fazla authenticated oturum açmasına izin verme kullanıcının.

Security Logs

Default olarak web sunucular ve işletim sistemleri log tutarlar fakar var olan haliyle bu loglama yetersizdir.

Kullanıcı profili değişiklikleri loglanmalı.
Şifre değişiklikleri loglanmalı, hatta bu değişiklik kullanıcının bilinen en geçerli mail adresine bildirilmeli.
Kullanıcının başka bir kullanıcı profilini değiştirmesi loglanmalı.

Kullanıcı ekleme/silme loglanmalı.

HE:WA-C5 Authorization Attack Case Studies-2

Differential Analysis

Kitabın yazarları bir testte kullandıkları yönetmi anlatıyor:

Uygulamayı önce sıradan bir kullanıcıyla login olarak, sonra da admin kullanıcı ile login olarak crawl ediyorlar. Sonuçta sayfa sayısı vs artarken, cookie sayısının aynı olduğunu görüyorlar, buradan oturum/yetki ilişkisinin cookielerde tutulabileceği sonucunu çıkarıyorlar. Sonra admin ve normal kullanıcılar için oluşan cookieleri karşılaştırıyorlar:

Kullanıcı Türü	Cookie Değeri
Standard	jonafid= 833219244.213a72e5767c1c7a6860e199e2f2bfaa.0092.783823921
Admin	jonafid= 833208193.dd5d520617fb26aeb18b8570324c0fcc.0092.836100218

Üzerinde birkaç dakika harcayarak şu sonuçları çıkarıyorlar:

Cookie değeri segmentlere ayrılmış.
İlk, üçüncü ve dördüncü segmentler aynı uzunlukta ve nümerik.
İkinci segment MD5 hash olabilir (32 byte uzunlukta, rakam ve f'ye kadar harfler...)
Her kullanıcı için her segment aynı uzunlukta.
İlk segmentin ilk 3 karakteri her kullanıcı için aynı (833)

Sonra sistematik olarak segmentleri manipüle etmeye başlıyorlar. Son segmentten başlıyorlar ve son segment için şu sonuçlara ulaşıyorlar:

Değiştirilen değer	Sonuç
1 karakter ekle (9)	Uygulama hatası: "Not logged in"
Son karakteri 1'den 9'a değiştir	Login durumunda gözle görülür değişiklik yok
Sondan bir önceki karakteri değiştir	Önceki durumla aynı
Segmentteki 9 katakteri de değiştir	Önceki durumla aynı

Bu sonuçlarla son segmentin yetkilendirme için pek bir anlam ifade etmediğine hükmediyorlar.

Bu şekilde tüm segmentleri manipüle ediyorlar ve görüyorlar ki yetkilendirmede sadece cookiedeki ilk 5 karakter yetkilendirmede söz sahibi. Sonra standart ve admin kullanıcı cookielerini karşılaştırdıkları bir önceki tabloya dönüyorlar, bakıyorlar ki ilk 5 karakterde sadece 5. Karakter farklı! Sonuç: Cookie'nin 5. Karakteri adminler için 0, sıradan kullanıcılar için 1...

HE:WA-C5 Authorization Attack Case Studies-1

Authorization Attack Case Studies

Horizontal Privilege Escalation

Request içinden header'ları çıkararak gerekli olup olmadıkları anlaşılır.

Nümerik alanlara dikkat. Bunlar birer sıra numarası olabilir, manipüle edilerek başkalarının hesap bilgilerine ulaşılabilir. Misal, bir alışveriş sitesinde account bilgileri görüntüleme / değiştirme için yapılacak talepte cookie içindeki shopperID parametresini 1 azaltarak talebi gönderelim, işte bir başkasının account bilgileri, üzerinde değişiklik yapabilecek şekilde karşımızda.

Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000;

ShopperID=193096346;

Tek yaptığımız shopperID'yi 1 azaltmak. Ve sonuçta başka bir kullanıcının hesap bilgileri!

Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000;

ShopperID=193096345;

Vertical Privilege Escalation

Dikey hak yükseltmeyle sonuçlanabilecek 4 senaryo var:

User-modifiable Roles

Örnek1:

Cookie: Auth=

897ec5aef2914fd153091011a4f0f1ca8e64f98c33a303eddfbb7ea29d217b34; -

563131=Roles=End User; K=HomePageHits=True;ASP.NET_SessionId=

dbii2555qecqfimijxzfaf55

Buradaki "Roles=End User" parametresi iç gıcıklayıcı, manipüle edelim: "Roles=admin", "Roles=administrator"...

Örnek2:

Cookie: ASPSESSIONIDAACAACDA=AJBIGAJCKHPMDFLLMKNFLFME; rC=X=

C910805903&Y=1133214680303; role=ee11cbb19052e40b07aac0ca060c23ee

Açıkça görülüyor ki "role=ee..." parametresi üzerine eğileceğiz burada da. Ama anlamlı bir şey gibi gözükmüyor. Farklı bir kullanıcı ile talebi tekrar oluşturalım:

Cookie: ASPSESSIONIDAACAACDA=KPCIGAJCGBODNLNMBIPBOAHI; rC=C=0&T=

1133214613838&V=1133214702185; role=ee11cbb19052e40b07aac0ca060c23ee

Görünen o ki "role" parametresinin değeri değişken değil, statik!

İpucu: Stringin 32 karakter olması, rakamlar ve f'ye kadar harflerden oluşması, bizi bunun standart bir 128-bit MD5 hash kodunun hexadecimal gösterimi olduğu düşüncesine sevketti. Sonra "admin", "administrator", "root"... denemeye başlıyoruz.

İyisi mi bu işi otomatize edelim, payload oluşturup aracımıza yaptıralım bu denemeleri (Burp Suite'in intruder aracını hatırla!).

Using Hijacked Accounts

Yatay hak yükseltme saldırısını hatırlayalım. Artarak giden bir ID belirleniyorsa en düşük ID numarasının sıradan kullanıcılardan daha çok yetkiye sahip bir admin yada developer hesabı olması olmayacak şey değil! "AuthID=3289" parametresi yerine "AuthID=1" gönderelim, bakalım ne sonuç verecek...

Using Other Security Flaws

SQL injection yada buffer overflow gibi açıklıklar, istediğimiz yetkilere sahip olmak için yeterli olacaktır.

HE:WA-C5 Attacking Tokens-3

Capture / Replay

Başka bir kullanıcının token'ını olduğu gibi "replay" edelim. Sonuç olumlu ise artık o kullanıcıyız. Bu saldırıyı yapabilmek için token'ı elde etmek gerek, bunun için de birkaç klasik yol var: "eavesdropping", MitM (Main in the Middle), sosyal mühendislik hileleri.

Session Fixation

Saldırgan, kurbanın sessionID'sini elde etmeye çalışmak yerine kurban için bir sessionID belirler.

Saldırgan, açıklık barındıran siteye login olarak geçerli bir sessionID alır; bunu kurbanı tuzağa düşürmede kullanacaktır.
Sonra kurbanı bu sessionID ile uygulamaya girmek için "ikna" eder (en basit yolu, sorgu stringi içinde sessionID'yi de içeren bir linki kurbana mail yoluyla göndermek olabilir)
Kurban bir kere siteye login olduktan sonra saldırgan aynı sessionID'yi replay ederek kurbanın oturumuyla sitededir artık.

Zorlukları:

Saldırgan, kurbanı hazırladığı link ile sisteme giriş yapma konusunda ikna etmeli. Zaten bunu başarırsa kurbana daha kötü şeyler de yapabilir.
Saldırgan, kullanıcı ile eş zamanlı olarak, kullanıcı sistemden çıkmadan yada oturumu expire olmadan sisteme girmek durumunda.

Önlemi basit:

Her başarılı login için sistem yeni bir sessionID üretir.
Ve uygulamanın login yeteneği, kullanıcının ürettiği / istemciden gelen sessionID'lerin kullanımına izin vermez ( Bu demektir ki test ederken login sonrası yeni bir ID üretilip üretilmediği ve ürettiğimiz ID'ler ile sisteme girip giremediğimiz kontrol edilir).

Ve mutlaka time-out mekanizmasının sunucu tarafında olması ve kesin bir değer içermeli.

HE:WA-C5 Attacking Tokens-2

Automated Prediction

Bu bölüm, tahmin edilebilir session ID'ler ve kriptolanmış veriler üzerinde otomatize analizler yapma teknikleri içerir.

Collecting Samples

Session ID'lerin gerçekten ne kadar rastgele olduğunu anlamak için yeteri miktar örnek sessionID toplamak gerekir. Aşağıdaki scriptler, sonsuz döngülüdür, yeterince bilgi toplandığı düşünüldüğünde kesilmelidir.

Gather.sh: netcat kullanarak HTTP sunucudan ASPSESSIONID bilgilerini toplar:

#!/bin/sh

# gather.sh

while [ 1 ]

do

echo -e "GET / HTTP/1.0\n\n" | \

nc -vv $1 80 | \

grep ASPSESSIONID

done

Gather_ssl.sh: openssl kullanarak HTTPS sunucudan JSESSIONID bilgilerini toplar:

#!/bin/sh

# gather_ssl.sh

while [ 1 ]

do

echo -e "GET / HTTP/1.0\n\n" | \

openssl s_client -quiet -no_tls1 -connect $1:443 2>/dev/null | \

grep JSESSIONID

done

Gather_nudge.sh: Bir üsttekine ilaveten sunucu cookie'yi set etmeden önce belirli bir login talebi POST eder (nudge dosyasına dikkat):

#!/bin/sh

# gather_nudge.sh

while [ 1 ]

do

cat nudge \

openssl s_client -quiet -no_tls1 -connect $1:443 2>/dev/null | \

grep JSESSIONID

done

Bu scriptte referans edilen "nudge" dosyasının içeriği:

POST /secure/client.asp?id=9898 HTTP/1.1

Accept: */*

Content-Type: text/xml

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Host: www.victim.com

Content-Length: 102

Connection: Keep-Alive

Cache-Control: no-cache

<LoginRequest><User><SignInName>latour</SignInName><Password>Eiffel

</Password></User></LoginRequest>

Scriptlerin kullanılış örnekleri:

$ ./gather.sh www.victim.com | tee cookies.txt

$ ./gather_ssl.sh www.victim.com | tee cookies.txt

$ ./gather_nudge.sh www.victim.com | tee cookies.txt

Non-linear Analysis

Brute-force/Directory Attacks

Bit Flipping

HE:WA-C5 Attacking Tokens

Attacking Tokens

Erişim/oturum token'larına 3 temel saldırı söz konusu:

Tahmin (manuel yada otomatik)
Yakalama/yeniden kullanma (Capture/Replay)
Sabitleme (Fixation)

Manual Prediction

Query String

http://www.mail.com/mail.aspx?mailbox=joe&company=acme

"joe" yerine "jack" yazarak bir başkasının maillerine erişilebiliyor olmasın? En azından sorgu stringlerinin URI içinde görünmemesi için GET yerine POST ile talebimizi yapmalıyız ki çoğu web uygulama geliştirici de böyle yapıyor zaten.

POST Data

POST talebinde parametreler URI için değil HTTP talebi (request) içinde taşınır. Tabi ki POST data da çok kolay manipule edilebilir (personal proxy kullanımı mesela).

> POST / HTTP/1.1

User-Agent: curl/7.9.5 (i686-pc-cygwin) libcurl 7.9.5 (OpenSSL 0.9.6c)

Host: www.victim.com

Pragma: no-cache

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Content-Length: 38

Content-Type: application/x-www-form-urlencoded

authmask=8195&uid=213987755&a=viewacct

Son satıra dikkat: authmask etiketindeki "auth" ibaresi ilginç, "uid" user id olmasın? "viewacct" da sanki hesap bilgilerini görme yetkisi gibi duruyor.

HTTP Headers

HTTP Header'lar hakkında detaylı bilgi için: http://webuygulamalariguvenligi.blogspot.com/2010/05/http-headers.html

Genel olarak, kolaylıkla manipüle edilebildiği için HTTP header'lara güvenerek hareket etmek çok güvensiz. Bir örnek:

Referer: Talep edilen URI'nin nereden talep edildiğini söyler. siteA'dan siteB'nin linkinin tıklandığını düşünelim, oluşacak requestte:

Referer: http://www.siteA.com/index.html

satırı yer alacaktır.

Kural şu: eğer bir bilgi sunucu tarafından değil de istemci tarafından set ediliyorsa, kolaylıkla menipüle edilebilir.

Cookies

Web uygulamalarında yetki / oturum yönetiminin en yaygın yöntemi.
RFC 2109 içinde tanımlanmıştır.
Cookilere özel inceleme aracı olarak bir Internet Explorer plug-in'i olan CookiSpy örnek verilebilir. Bir sitenin tüm cookie'lerini gösterir, manipüle edilmesine ve replay edilmesine izin verir.
Cookie geçerlilik süresi, header içindeki expires tarihini değiştirerek mümkün olabilir. Aşağıdaki örnekte expire tarihi 2010 iken 2011 olarak değiştirilmiş, 20 dakika olan expire süresi 1 yıl 20 dakika olmuştur:

Set-Cookie: HasPwd=45lfhj28fmnw; expires=Tue, 17-Apr-2011

12:20:00 GMT; path=/; domain=victim.com

HE:WA-C5 Attacking ACLs

Attacking ACLs

ACL üzerine saldırmak çoğu zaman en basit iştir, yetki/oturum token'larına saldırma çok daha fazla iş gerektirir.

Directory Traversal (Dizin Gezinimi)

Detay için: http://webuygulamalariguvenligi.blogspot.com/2010/05/web-app-pentest-egitimi-15-path.html

"Hidden" Resources

İyi bir profilleme çalışması, gizli kaynakları açığa çıkarmada yardımcı olabilir. Misal, bir sitede /user/menu dizini varsa, /admin/menu dizini de olabilir. Bu gibi, dizin-adı-tahmini ile sitelerin gizlenmiş sayfalarına erişilebilir. Bunun gibi abc.com/report12345.txt gibi bir sayfa linki, bizi abc.com/report12346.txt denemesine teşvik eder, başkalarının raporlarına erişebiliriz belki de.

Uygulamadaki isimlendirme yaklaşımı (convention) de gizli dizin isimleri konusunda bize ipuçları verir. Misal, uygulamada "secret" kısaltması olarak kullanılan secPass gibi değişkenler yada secMenu.html gibi sayfalar varsa, /admin dizini aramak yerine /secAdmin dizini aramakta fayda var.

HE:WA-C5 Attacking Web Authorization

Tipik bir web uygulaması yetkilendirme modeli

Sunucu-tarafı ACL'leri
Ve yetki/oturum token'leri (COTS yada custom-developed) temel alır.

Yetkilendirme (Authorization), klasik olarak login olmuş kullanıcının session bilgisi içindeki access token ile sağlanır. Uygulama, token ile ACL (access control list) arasında karşılaştırma yaparak kullanıcının işlem üzerinde yetkisi olup olmadığına karar verir. Logout olunduğunda yada session zaman aşımına uğradığında token da expire olur.

Çoğu zaman session ID ile access token aynı şeydir.

Yetkilendirmeye saldırı 2 ana alanda olur:

Yetki/oturum token'ı hırsızlığı
Sunucu tarafındaki ACL'i bypass etme.

Fingerprinting Authorization

ACL'lerini crawl etme
Erişim/Oturum token'larını tanıma
- Yaygın COTS session ID etiketleri için: http://webuygulamalariguvenligi.blogspot.com/2010/05/identifying-server-side-technologies.html
Oturum token'larını analiz etme

Yaygın session token içerikleri:

Oturum Bileşeni	Özellikleri Tanımlama	Olası Saldırılar
Timestamp – Datestamp	Encoded olsalar bile sabitçe değişirler. Basit bir string, yada periyodik formatlı 10 basamak sayı.	Bu değeri değitirmek oturum login periyodunu uzatabilir. Replay atakları bu bilgiye dayandırılabilir.
Artan sayı	Her talepte mololitik artar.	Bu değer, değiştirmek oturum hırsızlığına yol açabilir.
Kullanıcı profili	Ad-soyad, adres gibi bilinen değerlerin encoded hali.	Oturum hırsızlığı
Sunucu IP adresi	4 byte; örn. 192.168.0.1 0xC0A80001 (big-endian) yada 0X0100A8C0 (little endian) olabilir.	Değeri değiştirmek oturumu bozabilir, fakat server çiftliği haritasını çıkarmaya yardımcı olur.
İstemci IP adresi	Sunucu IP adresi ile aynı	Replay saldırısı ile oturum hırsızlığına yardı olasılığı

Base64'ü tanıma: Büyük ve küçük latin harfleri (A-Z, a-z), numaralar (0-9), + ve / işaretleri içeriyorsa ve = ile bitiyorsa büyük ihtimal base64 encoded bir anahtardır.
Fark analizi. Web sitesi 2 farklı kullanıcı ile crawl edilir ve farklar not edilir, cookie verilerindeki fark gibi.

Role Matrix

HE:WA-C4 Bypassing Authentication

Bypassing Authentication

Token Replay

Session hijacking.

Session ID: Tahmin ve brute-force, 2 temel saldırı yöntemi. Sitenin tahmin edilmesi kolay session ID kullanıp kullanmadığı (belki sıralı) incelenir. ID üretme algoritmasının tebiti mümkün mü?
Cookies: Ne olursa olsun hassas bilgi içermemeli cookie. En popüler cookie çalma yönetmleri XSS ve araya girip dinleme (eavesdropping). Ayrıca reverse engineering ile cookie üzerinde çalışmak da etkili bir yönetm olabilir; farklı zamanlarda ve farklı kullanıcılarla cookie'ler alınır, zamana, kullanıcı adına, kullanıcı yetkilerine vs göre cookie'nin nasıl değiştiği izlenir.

Identity Management

Kullanıcı kayıt (registration), hesap yönetimi (şifre değişimi gibi) vs.

User Registration Attacks

Bu saldırı türünün üstesinden gelmede CAPTCHA kullanımı yaygın.

Credential Management Attacks

Birçok sitede şifresini unutanlar için gizli sorular vardır; bunlar kimi zaman cevaplarının tahmin edilmesi kolay sorular olabilir, en sevdiğin renk gibi. Bir de unutulan şifrenin (ya da bir yenisinin) mail adresine gönderilmesi var ki, aşağıdaki gibi bir durum yaşanabilir (2003 MS Passport'ta yaşanmış):

https://register.passport.net/emailpwdreset.srf?em=victim@hotmail.com&prefem=attacker@attacker.com&rst=1

Client-Side Piggybacking

Buraya kadar kullanıcı credential bilgilerini çalma yada tahmin etme yollarını konuştuk. Ya saldırgan istediklerini kimlik doğrulama işleminden geçmiş kullanıcıya yaptırırsa?

HE:WA-C4 Web Authentication Attacking

Web Authentication Threats

Username/Password è En yaygın kullanılan.

Strong(er) Authentication è user/pwd yöntemin zayıflıklarını önlemek amacıyla ortaya çıkmış, token bazlı, sertifika bazlı vs.

Authentication Services è Sitenin kimlik doğrulama işini outsource yapması (MS Passport gibi). ID management ve authentication protocol içerir.

Username/Password Threats

Username Enumeration

SALDIRI: Şifre tahmin saldırılarının etkinliğini artırmak için kullanılır. Mesela "nuri" diye bir kullanıcı yoksa "nuri" kullanıcısı için şifreler denemenin de alemi yok. Kullanıcı adı belirleme için kullanılabilecek yöntemler:

Profilleme sonuçları. Kaynak kod açıklama satırları, config dosyaları vs çoğu zaman bu konuda bilgi sağlayıcı olabiliyor.
Login sırasındaki hata mesajları. "Kullanıcı adı yanlış" gibi bir mesaj alınca artık o kullanıcı için şifre denemeye gerek kalmaz; "Şifre yanlış" mesajı alınınca da kayıtlı bir kullanıcı adı bulduk demektir. "Kullanıcı ve/veya parola yanlış" denebilir mesela.
Mesaj bilgi vermiyor olsa da mesaj için açılan sayfa bilgi verebilir: Hatalı kullanıcı adı girildiğinde "nouser.html" sayfası açılıyor, şifre hatalı olduğunda "failedlogin.html" sayfası açılıyor örneği mevcut gerçek hayattan.
Registration. Siteye üye olmaya çalışırken "Bu isimde kullanıcı zaten var, başka isim dene" gibi mesajlar sayesinde kullanıcı adı atoplanabilir. İnsanlar genelde isimlerini kullanıcı adı olarak verme eğilimindedir: Ahmet Selim için Ahmet, AhmetS vs; bebeklerinin adını yada telefon numaralarını... Bir liste oluşturulabilir, zaten oluşturulmuş listeler bulunabilir google ile.
Şifre değiştirme sırasındaki hata mesajı. Çoğu zaman şifre değiştirme için farklı bir sayfaya yönlendirme olsa da kullanıcı adı tekrar sorulmaz, bir hidden tag ile POST methodunda kullanıcı adı o sayfaya taşınır. Bu saldırı için proxy gerekir; ancak bazen şifre değiştirmedeki hata mesajları değerlendirerek isim tespit edilebilir.
Hesap kilitleme. Belirli bir sayıda deneme sonrası hesabın kilitlenmesi, doğru kullanıcı üzerinde çalıştığımız anlamına da gelir. Olmayan bir hesap nasıl kilitlensin, değil mi?

Password Guessing

Tarama teknikleri, kitapta anlatıldığından daha detaylı. 4 teknikten daha önce bu blogda söz edilmişti (http://webuygulamalariguvenligi.blogspot.com/2010/05/web-app-pentest-egitimi-11.html): Dikey, yatay, diyagonal ve 3 boyutlu tarama teknikleri mevcut.
DİKKAT: Bu saldırı uygulamanın hizmet dışı kalmasına neden olabilir.
Bir şifre belirleme politikası varsa, deneme uzayı daraltılabilir. Mesela 8 harften kısa şifreyi kabul etmediğini daha önce tespit etmişsek, kısa şifre denemelerini atlayabiliriz.
Şifre tahmininde kullanılabilecek bazı araçlar:
- Hydra. Basic authentication kullanılan durumlarda kullanılabilir. Web uygulamalarına saldırmada http-head, http-get, https-head, https-get ve http-proxy metodlarını destekler.
  D:\Toolbox>hydra -C list.txt victim.com http-get /secure
- WebCracker. Windows tabanlı, eski, grafik arayüzlü araç. Amatörler yada script bilmeyenler için önerilebilir.
- Brutus. HTTP Basic ve Form-based kimlik doğrulamada, SMTP ve POP3 protokolleri ile kullanılabilir. Hem sözlük, hem kaba kuvvet saldırıları yapılabilir.
- NTLM Authorization Proxy Server. Entegre Windows kimlik doğrulama yönetiminin kullanıldığı durumlarda kullanılabilir. Çoğu araç bu yöntemi desteklemez.

Countermeasures of Password Guessing

Güçlü bir şifre politikası ve güçlü bir kilitleme mekanizması kombinasyonu.
CAPTCHA kullanımı.
Bir saldırı altında olmanın neye benzediğinin bilinmesi. Trafiğin ve logların değerlendirilmesi gibi.

Eavesdropping and Replay Attacks

Basic Authentication:

İstemcinin korunan bir kaynağa herhangi credential bilgisi olmadan erişim talep etmesiyle başlar (Talep ve yanıtlar [requests and responses] sadeleştirilmiştir):
GET /test/secure HTTP/1.0
Sunucu erişim engellendi mesajı döner (401 Unauthorized):
HTTP/1.1 401 Unauthorized

WWW-Authenticate: Basic realm="luxor"
Bu cevap istemcinin browser'ında bir credential ekranı açar. User/pwd bilgileri ile OK tuşouna basıldığında talep gönderilir:
GET /test/secure HTTP/1.0

Authorization: Basic dGVzdDp0ZXN0

Burada dGVzdDp0ZXN0 parçası, Base64 ile encode edilmiştir, kolayce decode edilebilir. Buradaki örnekte değeri decode ettiğimizde test:test olduğunu görürüz. Bu yüzden bu metod en azından HTTPS ile kullanılmalıdır.

Digest Authentication:

HTTP protokolü üzerinde çalışıyor; basic authentication'a göre daha güvenli, fakat güçlü protokoller varken de (Public-key yada Kerberos gibi) tercih edilmemeli.
HTTP'den daha çok IMAP, LDAP, POP3, SMTP protokollerinde kullanılır.
Temelde basic authentication gibi çalışıyor:
- Kullanıcı, credential bilgileri olmaksızın talep yapar,
- Sunucu WWW_Authenticate header'ı ile credential gerekli mesajı gönderir.
- Sunucu, istemciye Base64 kodlu kullanıcı adı istemek yerine, NONCE adı verilen rasgele bir değer ile kimlik sorar.
- Browser "message digest" oluşturmak için tek yönlü kriptografik bir fonksiyon kullanır (hashing algoritm) è MD5!
Dezavantajları:
- Replay / MitM ataklarına açıktır. MitM saldırgan, istemciye basic authentication kullanacağını söyleyerek credential bilgilerini alabilir.
- Güvenlik kriterlerinin çoğu opsiyoneldir; iyi tanımlanmadığında güvenlik açığı oluşur.
MD5 hash'lerini kırmak için tool: MDcrack by Gregory Duchemin.

Eavesdropping Countermeasures

128-bit SSL encryption.

Forms-based Authentication Attacks

Çok esnektir. En yaygın kullanılan kimlik doğrulama çeşididir. En temelde şöyle bir trafik yaşanır:

İstemci sayfayı talep eder:

GET /default.aspx HTTP/1.0

Sunucu talebi login sayfasına yönlendirir:

HTTP/1.1 302 Found

Location: /login.aspx?ReturnUrl=%2fdefault.aspx

Kullanıcı açılan pencereden kullanıcı adı ve parolayı girer:

POST /login.aspx?ReturnUrl=%2fDefault.aspx HTTP/1.0

STATE=gibberish&txtUser=test&txtPassword=test

Burada GET değil POST kullanılıyor. Bir konu da, eğer SSL kullanılmıyorsa kullanıcı adı ve parolanın açık text olarak iletilmesi.

Eğer credential'lar doğruysa sunucu Set-Cookie header'ı içeren bir "302 found" döner:

HTTP/1.1 302 Found

Location: /Default.aspx

Set-Cookie: AuthCookie=45F68E1F33159A9158etc.; path=/

htmlheadtitleObject moved/title/headbody

Cookie'nin encyrpted olduğuna dikkat.

Son olarak istemci ilk talebini yeniler, bu kez cookie ile birlikte:

GET /Default.aspx HTTP/1.0

Cookie: AuthCookie=45F68E1F33159A9158etc.

Sunucu çerezin geçerli olduğuna kanaat ederse "200 OK" döner.

Yapı bu şekliyle parola-tahmin saldırılarına açıktır. Bu saldırı için Brutus aracı kullanılabilir. Bu aracın bir avantajı, geçerli bir credential girildiğinde sunucunun nasıl bir dönüş yapmasını beklediğimizi Brutus'a söyleyebilmemiz. Zira sıkça görülür ki siteler başarılı yada başarısız kimlik doğrulama girişimlerinde 200 OK yerine kendi unique cevaplarını (response) dönerler.

Strong(er) Web Authentication

Dijital sertifikalar
PassMark/SiteKey
One-time Passwords (OTPs)

Web Authentication Services

Yaygın olarak kullanılan tek web kimlik doğrulama servisi Microsoft Passport. Her ne kadar Microsoft third-party şirketleri Passport kullanımına teşvik etmek istediyse de uygulamada Passport, Microsoft'un servisleriyle sınırlı denebilir (MSN, Hotmail vs).

Temelde mekanizma şu şekilde çalışır: Örneğin abc.com Passport partneri olmaya karar verdi. Passport SDK'yı indirir ve Microsoft ile anlaşma imzalar. abc.com express mail aracılığıyla kriptolu bir anahtar alır, bunu SDK'daki Passport Manager aracı yardımıyla kendi web sunucularına kurar. Passport'un login sunucuları bu anahtarın bir kopyasını barındırır.

HE:WA-C3 Hacking Web Platforms

Web platformu açıklıkları 2 kategoride değerlendirilecek: Web sitesi admini yada developer tarafından doğrudan düzeltilebilecek şeyler; bir de yazılım üreticilerinin versiyon update'leri ve yamalar çıkararak çözmek durumunda olduğu şeyler. Bu başlık altında konfigürasyon bozuklukları nedeniyle oluşabilecek açıklıklardan söz edilmeyecek.

Saldırganların sızma girişimleri için ilk bakacakları yer web platformları olacaktır. Web platform, sunucu işletim sistemi üzerine yerleşen ve uygulamanın altında yer alan COTS (Common –ticari olmak zorunda olmayan- Off-The-Shelf) yazılımlardan oluşur.

Point-And-Click Exploitation Using Metasploit

Metasploit, açık kaynak bir exploitation aracı.
Saldırılacak adresi de, saldırılacak açıklığı da bildiğimiz öngörülüyor.
Exploit aracı, yani iş tamamlandığında karşıya trojan yerleştirme, konsol açma vs gibi bir sonuca ulaşılıyor.
GUI ve web arayüzleri de var, ancak en etkili kullanımı konsolu aracılığıyla bu yazılımı kullanmak.
CORE IMPACT (Core Security Technologies) ve CANVAS (Immunity) de bu tarzda bir araç.
Hızlı bir referans olarak: http://www.webguvenligi.org/docs/metasploit&wmap.pdf

Örnek bir iki komut:

# msfconsole

msf> svn update è online güncellemeler

msf> use exploit/windows/... è tab tuşu ile komut tamamlama mevcut

msf (......)>show options è parametreler; hepsi değil

msf (......)>set [TAB] è tab tüm parametreleri listeler; gereklileri set et

msf (......)>set PAYLOAD windows/meterpreter/... è saldırı

msf (......)>show options

...

msf (......)>exploit è yada "run"

Web Platform Security Best Practices

Common Best Practices:

Her iki yöne de agresif bir network erişim kontrolü uygula.
Güvenlik yamalarını mutlaka uygula.
Uygulama kaynak koduna gizli data koyma!
Düzenli olarak networkte açıklık barındıran sunucu olup olmadığını tara.
Bir saldırı altında olmanın nasıl birşey olduğunu bil. Networkü izlerken olası anormallikleri değerlenirebiliyor musun?

IIS Hardening

Saldırganlara çok fazla bilgi veren detaylı hata mesajlarını kapat.
Web klasörlerini, sistemin kurulu olduğu sürücüden başka bir sürücüye kur (sistem c:'de ise web klasörleri d:'de olsun mesela).
Kullanılmayan uzantı eşleştirmelerini (.txt ó notepad.exe gibi) kaldır.
IISLockdown ve ve URLScan kullan
- IISLockdown: IIS'e güvenlik konfigürasyonları uygulayan otomatik, template tabanlı bir araç.
- URLScan: IIS'e yapılan talepleri keserek kriterlere uymayanları reddeden template tabanlı bir araç. IIS için bir firewall gibi düşünülebilir.
Web sunucu sürücüleri mutlaka NTFS olsun (FAT32 değil!) ve ACL (Access Control List) konusunda son derece tutucu ol.
Sistem üzerindeki güçlü yetkileri (cmd.exe gibi) sil, kısıtla, taşı yada adını değiştir.
Sunucu üzerindeki yazma ve execute ACL'lerinden "everyone" ve "guests" gruplarını kaldır.

Apache Hardening

İhtiyaç duyulmayan modülleri disable et.
ModSecurity (Ivan Ristic tarafından yazılan ve web uygulama firewall'u gibi çalışan bir modül) uygula.
Chrooting. Güvenlikte ilk kurallardan biri derinlemesine defanstır. Bir saldırgan içeri sızdığında ilk bakacağı şey, /etc/passwd vb dosyalara erişmek ve sistem üzerinde kendi yetkilerini yükselltmek olacaktır. Bu tür atakları engellemenin bir yolu Apache sunucusunu karantina altında tutmaktır, buna chrooting deniyor. Apache, kendi kapalı dosya sistemi üzerinde kısıtlı haklarla çalışır; içeri sızmayı başaran saldırgan, bu "hücre" içinde sıkışıp kalacak ve gerçek dosya sistemine erişemeyecektir.
SuExec uygula.
CIS (CISecurity – Center of Internet Security)'deki Apache benchmarklarını kullan.

PHP Best Practices

Dosya adı yada path'inin kullanıcıdan gelen bir input olmasını engelle.
Eval() fonksiyonunu kullanıcıdan gelen input almadan ve ayrı olarak kullan.
Register_globals'i kapat.
Tüm kullanıcı girişleri için doğrulama yap.
Php.ini dosyası içinde aşağıdaki konfigürasyonu yap:
- open_basedir è Belirlenen klasördeki dosyaların erişimlerini kısıtlar. "../../../../etc/passwd" artık bir yere gidemez.
- disable_functions èDerinlemesine defans için büyük yol. Kullanılmayan ve güvenlik açısından riskli fonksiyonları (eval(), passthru(), system() gibi) kapat.
- expose_php è Bu konfigürasyonu kapatmak, HTTP response headerlarında gösterilen PHP banner'i kaldırır.
- display_errors è Bir exception durumunda detaylı bilgi vermeyi engellemek için.
- safe_mode è Açılırsa çok kısıtlı dosya erişim izni.
- allow_url_fopen è Uzak dosyalar üzerindeki operasyon kabiliyetini disable etmek için.