Merhaba TurkHackTeam ailesi bugün sizlere SSRF yani Sunucu Taraflı İstek Sahteciliği hakkında detaylı bir konu sunacağım.
Konuyu baştan sonra okumanızı şiddetle tavsiye ediyorum.
SSRF Nedir?
SSRF bir web uygulamasının kullanıcıdan aldığı bir girdiyi sunucu tarafında kontrol etmeden kullanarak yerel veya harici kaynağa yetkisiz istekler göndermeye olanak sağlayan bir web application güvenlik açığıdır. SSRF, saldırganın iç sistemlerle etkileşim kurmasına izin vererek Veri sızıntılarına (Data Leak), Hizmet reddi saldırılarına (DoS),Yetki yükseltmeye (Privilege Escalation) ve Uzaktan kod yürütülmesine (RCE) yol açabilir.
Kısaca SSRF, uygulamanın dışarıdan gelen bir isteği, sunucunun kendisinden geliyormuş gibi göstererek işlemesi sonucunda güvenlik duvarları, iç ağ kısıtlamaları ve erişim kontrollerini aşmasına olanak sağlayan bir güvenlik açığıdır.
SSRF Güvenlik açığı ile neler yapılabilir?
Veri Sızıntısı
Daha önce de bahsettiğim gibi, saldırganlar savunmasız web uygulamasının isteklerine müdahale ederek iç ağda barındırılan hassas verilere yetkisiz erişim sağlayabilirler.
Keşif
Saldırganlar, savunmasız sunucularda kötü amaçlı komut dosyaları çalıştırarak veya harici bir sunucuda barındırılan komut dosyalarına yönlendirme yaparak iç ağlarda port taraması gerçekleştirebilir.
Hizmet Reddi
Genellikle iç ağlar veya sunucular çok fazla istek beklemez bu yüzden düşük bant genişliğini kaldıracak şekilde yapılandırılırlar. Saldırganlar sunucuları çok fazla sayıda istekle bombardımana tutarak, sunucuların gerçek istekleri işleyemez hale gelmesine neden olabilirler.
Yetki Yükseltme
Saldırganın normalde erişemeyeceği iç servislerle etkileşim kurmasına imkan tanır. Bu iç servisler çoğu zaman kimlik doğrulama, yönetim paneli veya arka plan servisleri gibi yüksek yetkili bileşenlerdir. Örnek olarak Sadece iç ağdan erişilebilen admin panellerine, Yetkilendirme kontrolü zayıf internal API’lere, Cloud ortamlarında metadata servislerine istekler göndererek düşük yetkili bir kullanıcıdan, sistem veya servis düzeyinde yüksek yetkilere geçiş yapabilir.
Uzaktan Komut yürütme
SSRF doğrudan RCE açığı değildir. Fakat iç ağda bulunan ve komut çalıştırabilen servislerle birleştirildiğinde, saldırganlar sisteme zararlı payload’lar göndererek uzaktan kod çalıştırabilir. Bu yüzden SSRF, çoğu zaman RCE’ye giden saldırı zincirinin ilk adımı olarak görülür.
SSRF Nerede Bulunur?
SSRF genellikle web uygulamalarında sunucunun dış bir kaynağa istek attığı her noktada ortaya çıkabilir. Kullanıcıdan alınan bir veri, sunucu tarafından başka bir sisteme gönderiliyorsa, orada SSRF riski vardır. Bu yüzden SSRF, çoğu zaman fark edilmesi zor ama etkisi büyük bir güvenlik açığıdır.
URL Alan Parametreleri
Dosya ve Medya İşleme Servisleri
Redirect ve Callback Mekanizmaları
Cloud ve Mikroservis Ortamları
API Uç Noktaları
SSRF İçin Şüpheli Parametreler
Google Dork kullanılarak aşağıdaki gibi parametreler içeren sayfalar tespit edilebilir.
Fakat bu SSRF'in olduğu anlamına gelmez manuel deneme ile doğrulanabilir.
url= link= redirect= callback= return= next= dest= image= file= path= load=
SSRF Türleri
Not: Konunun devamında Klasik ve Blind SSRF'i uygulamalı olarak göstereceğim.
Klasik SSRF
Klasik SSRF, en anlaşılır ve en tehlikeli türlerden biridir. Saldırganlar, sunucuya gönderdiği isteğin yanıtını doğrudan görebilir.
Blind SSRF
Blind SSRF’de saldırganlar, gönderdiği isteğin yanıtını göremez. Ancak bu, açığın olmadığı anlamına gelmez.
Reflected SSRF
Reflected SSRF, SSRF payload’ının uygulama tarafından işlenip yanıt içerisinde yansıtıldığı durumlardır. Bu tür genellikle hata mesajlarında, debug çıktılarında, log tabanlı cevaplarda karşımıza çıkar.
Protocol-Based SSRF
Protocol-Based SSRF, sadece HTTP/HTTPS ile sınırlı değildir. Uygulama farklı protokolleri destekliyorsa saldırganlar
file:// ftp:// gopher:// dict://
gibi protokoller üzerinden iç sistemlerle iletişim kurabilir. Özellikle gopher protokolü, iç servisleri manipüle etmek için sıkça kullanılır.
Senaryo 1: Yerel Sunucuya Karşı SSRF Saldırısı
Örneğin İnsan Kaynakları yönetim sistemi uygulamasında, bir URL parametresine bağlı olarak ek sayfalar yükleyen bir özellik bulunmaktadır.
http:// hrms.com?url=localhost/copyright adresine gidildiğinde uygulamanın telif hakkı sayfası yüklenir. Bu özellik dahili kullanım içindir ve yerel sunucudan sayfalar istemek ve görüntülemek üzere tasarlanmıştır (bu nedenle localhost sorguda kullanılır).
Sayfayı ziyaret ettiğimizde fark ediyoruz ki web sayfası, web sitesinin telif hakkı durumunu göstereren bir dosya'ya yönlendiriyor.
Bu, geliştiricinin telif hakkı durumunu gösteren bir dosyayı işlerken muhtemelen bazı hatalar yaptığı anlamına gelir. İşte sorgu parametresini alan sayfanın kodu.
PHP:
$uri = rtrim($_GET['url'], "/");
...
$path = ROOTPATH . $file;
...
if (file_exists($path)) {
echo "<pre>";
echo htmlspecialchars(file_get_contents($path));
echo "</pre>";
} else { ?>
<p class="text-xl"><?= ltrim($file, "/") ?> is not found</p>
<?php
...Peki bunu test olarak değiştirirsek ne olur.
Görüldüğü üzere test.php adlı dosyayı bulmadığını söylüyor bize.
Peki şimdi geçerli bir dosya adı sağlarsak config gibi.
Evet bize config.php dosyasının içeriğini döktü ve burdaki klasik SSRF hassas veri sızıntısına yol açtı.
Senaryo 2: Dahili Bir Sunucuya Erişim
Dahili bir sunucu veritabanı yönetimi veya idari kontroller sağlıyorsa, saldırganlar, savunmasız web uygulaması tarafından işlendiğinde bu dahili sistemlerde istenmeyen bir eylemi başlatan bir URL oluşturabilir. Teknik olarak bu, özel IP adresleri ( IPv4 için 192.168.x.x ve 10.x.x.x gibi) veya alan adları (örneğin, internal-database.hrms.com) gibi manipüle edilmiş girdiler aracılığıyla gerçekleştirilir.
Düzgün bir şekilde temizlenmediğinde, bu girdiler web uygulamasında HTTP istekleri veya dosya eklemeleri gibi işlevlerde kullanılabilir. Sunucu, bu istekleri meşru olarak yorumlayarak, istemeden diğer dahili hizmetlerden eylemler gerçekleştirir veya veri alır.
Bu dahili sunucular dışa açık sunucularla aynı düzeyde güvenlik izlemesinden yoksun olabileceğinden, bu tür saldırılar genellikle fark edilmeden kalabilir. Ayrıca bu yöntemi, dahili ağ içinde keşif yapmak ve hedef alınacak diğer savunmasız sistemleri veya hizmetleri belirlemek için de kullanabilir.
HRMS web uygulamasına giriş yaptıktan sonra, çalışanları ve departmanlarını listeleyen bir kontrol paneli göreceğiz. Çalışanların verilerini ve maaşlarını gösteren bir açılır menü de bulunmaktadır.
Burada geliştiricinin yaptığı hata kullanıcıdan gelen url parametresini hiçbir doğrulama, kısıtlama veya whitelist olmadan sunucuya HTTP isteği attırmak
SSRF ile ilgili bilgilendirici içeriğim bu kadardı. Umarım keyifli ve öğretici bir yazı olmuştur. Okuduğunuz için teşekkür ederim..
Senaryo 2: Dahili Bir Sunucuya Erişim
Dahili bir sunucu veritabanı yönetimi veya idari kontroller sağlıyorsa, saldırganlar, savunmasız web uygulaması tarafından işlendiğinde bu dahili sistemlerde istenmeyen bir eylemi başlatan bir URL oluşturabilir. Teknik olarak bu, özel IP adresleri ( IPv4 için 192.168.x.x ve 10.x.x.x gibi) veya alan adları (örneğin, internal-database.hrms.com) gibi manipüle edilmiş girdiler aracılığıyla gerçekleştirilir.
Düzgün bir şekilde temizlenmediğinde, bu girdiler web uygulamasında HTTP istekleri veya dosya eklemeleri gibi işlevlerde kullanılabilir. Sunucu, bu istekleri meşru olarak yorumlayarak, istemeden diğer dahili hizmetlerden eylemler gerçekleştirir veya veri alır.
Bu dahili sunucular dışa açık sunucularla aynı düzeyde güvenlik izlemesinden yoksun olabileceğinden, bu tür saldırılar genellikle fark edilmeden kalabilir. Ayrıca bu yöntemi, dahili ağ içinde keşif yapmak ve hedef alınacak diğer savunmasız sistemleri veya hizmetleri belirlemek için de kullanabilir.
HRMS web uygulamasına giriş yaptıktan sonra, çalışanları ve departmanlarını listeleyen bir kontrol paneli göreceğiz. Çalışanların verilerini ve maaşlarını gösteren bir açılır menü de bulunmaktadır.
Sayfanın kaynak koduna baktığımızda web sitesinin dahili bir kaynaktan veri aldığı görülüyor.
Peki direk bu dahili ağdaki admin paneline erişmeyi denersek ne olur.
Görüldüğü üzere dahili bir ağdaki sayfaya ulaşamıyoruz
O zaman SSRF güvenlik açığını kullanarak sunucunun bu isteği yapmasını sağlayabiliriz.
O zaman SSRF güvenlik açığını kullanarak sunucunun bu isteği yapmasını sağlayabiliriz.
Evet SSRF güvenlik açığını kullanarak sunucunun bu dahili ağdaki admin paneline erişmemize olanak sağladığını görüyoruz.
Senaryo 3: Bant dışı Kör SSRF (Blind SSRF)
Saldırganların hedef sunucudan doğrudan yanıt almak yerine, bilgi almak veya istismar edilen sunucuyu kontrol etmek için ayrı, bant dışı bir iletişim kanalını kullandığı bir tekniktir. Bu yaklaşım, sunucunun yanıtlarına saldırganın doğrudan erişemediği durumlarda pratiktir.
Örneğin, saldırganlar savunmasız sunucuyu manipüle ederek kendi sahip olduğu bir alan adına DNS isteği gönderebilir veya belirli veriler içeren harici bir sunucuya bağlantı başlatabilir. Bu harici etkileşim, saldırgana SSRF güvenlik açığının var olduğuna dair kanıt sağlar ve potansiyel olarak iç IP adresleri
veya iç ağ yapısı gibi ek bilgiler toplamasına olanak tanır.
profile.php adlı sayfayı açtığımızda , muhtemelen analiz veya kayıtlar için kullanılan getInfo.php adlı harici bir sayfaya veri gönderiyor.Örneğin, saldırganlar savunmasız sunucuyu manipüle ederek kendi sahip olduğu bir alan adına DNS isteği gönderebilir veya belirli veriler içeren harici bir sunucuya bağlantı başlatabilir. Bu harici etkileşim, saldırgana SSRF güvenlik açığının var olduğuna dair kanıt sağlar ve potansiyel olarak iç IP adresleri
veya iç ağ yapısı gibi ek bilgiler toplamasına olanak tanır.
Burada geliştiricinin yaptığı hata kullanıcıdan gelen url parametresini hiçbir doğrulama, kısıtlama veya whitelist olmadan sunucuya HTTP isteği attırmak
PHP:
<?php
...
$targetUrl = $_GET['url'];
ob_start();
ob_start();
phpinfo();
$phpInfoData = ob_get_clean();
$ch = curl_init($targetUrl);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,$phpInfoData);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
...
?>Burada, isteği kendi sunucumuza yönlendirebilir ve böylece istismar veya veri hırsızlığı için ek bilgiler elde edebiliriz.
Aşşağıdaki verdiğim python kodu ile gelen POST isteklerini data.html dosyasına kaydedebiliriz.
Aşşağıdaki verdiğim python kodu ile gelen POST isteklerini data.html dosyasına kaydedebiliriz.
Python:
from http.server import SimpleHTTPRequestHandler, HTTPServer
from urllib.parse import unquote
class CustomRequestHandler(SimpleHTTPRequestHandler):
def end_headers(self):
self.send_header('Access-Control-Allow-Origin', '*') # Herhangi bir istekten gelen kaynakları kabul eder
self.send_header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS')
self.send_header('Access-Control-Allow-Headers', 'Content-Type')
super().end_headers()
def do_GET(self):
self.send_response(200)
self.end_headers()
self.wfile.write(b'Hello, GET request!')
def do_POST(self):
content_length = int(self.headers['Content-Length'])
post_data = self.rfile.read(content_length).decode('utf-8')
self.send_response(200)
self.end_headers()
# Post verilerini data.html dosyasına kaydeder
with open('data.html', 'a') as file:
file.write(post_data + '\n')
response = f'HRMS, POST request! Received data: {post_data}'
self.wfile.write(response.encode('utf-8'))
if __name__ == '__main__':
server_address = ('', 8080)
httpd = HTTPServer(server_address, CustomRequestHandler)
print('Server running on http://localhost:8080/')
httpd.serve_forever()SSRF ile ilgili bilgilendirici içeriğim bu kadardı. Umarım keyifli ve öğretici bir yazı olmuştur. Okuduğunuz için teşekkür ederim..
