Merhabalar, bu yazı serimde birkaç tane hacking senaryolarından bahsedeceğim.
Bütün anlatım
eğitim amaçlıdır ve
kurgudur bilginiz olsun. Sinema izlerken nasıl keyif alıyorsanz buradan da aynı yaklaşımı benimseyin daha fazla kafanızda bir hacker nasıl çalışır anlayın diye.
Bu döküman serisi güvenlik meraklıları veya araştırmacıları için hazırlanmıştır. Yapacağınız yasadışı aktiviteler tamamen sizi bağlar.
Başlayalım o zaman.
Hacking dünyasında oldukça sıklıkla kullanılan bir yöntem vardır: Password reuse veya daha genel adıyla credential stuffing.
Bu teknik temel olarak bir kişinin bir oluşumdaki authentication bilgisinin başka bir oluşumdaki auth servisinde de geçerli olmasına denir.
Bir kurum var ve bu kurumu hacklemek isteyen bir kötü aktörümüz var, bu aktörün temel amacı kuruma zarar vermek ve finansal bir getiri elde etmek.
Bu hacker kurumu incelediğinde kurumun internete açık çok kısıtlı bir çıktı noktası olduğunu farkediyor, bütün kurum içi işlemler kurumun kendi VPN ağında gerçekleştiğini düşünüyor ve buna göre saldırı planını hazırlıyor.
Server arama motorlarını kullanarak ilk önce kurumun ismini aratıyor ve çıkan sonuçları analiz ettiğinde 2 tane web servisi(HTTP-80, HTTPS-443) olan 1 sunucu ve ek olarak email servisleri olan 1 sunucu keşfediyor. Kurumun websitesinin kullandığı domain adresini server arama motorunda arattığında ise bir önceki bulgudaki o web sunucusu tek çıkmakta. Kurumun websitesi için kullandığı domain adresindeki TLD kısmını çıkarıp direkt domain aratması yaptığında elde ettiği 3 sunucudan sadece 1 tanesinde RDP servisi açık olduğunu keşfediyor, ve çıktıdaki diğer sunucuların bu kurumla çok net bir bağlantısı olmadığını düşünüp oraları detaylıca incelemiyor.
Tüm devam sürecinde bir geçerli giriş bilgisi bulup bu RDP servisine giriş yapmayı amaçlıyor. Bu hackerımız baya uğraşıyor ancak kurum oldukça secure bir halde olduğunu düşünüp artık kurum içi çalışanları hedeflemeyi amaçlıyor. Phishing akla gelen en iyi yöntem olsa da bu kurumun için bu yöntemi uygulayamıyor. Kurum içi çalışanları bulmak için OSINT çalışmaları yürütüyor ve bir iş bulma sitesinden şirketteki C-level çalışanları görebilmekte. Hmm bu C-level çalışanlar hakkında daha fazla bilgi edinmek ve strateji üretmek için onların internetekki izlerini araştırmaya koyuluyor ve sosyal medya hesaplarını analiz ettiğinde bu C-levellerden birinin golf sporuyla ilgilendiğini ve kendisinin golf oynarken bunu sosyal medya hesabından paylaştığını görüyor. Hackerın aklında hemen password reuse tekniği geliyor ve bu golf sahasının hangi şirkete ait olduğunu fotoğraftaki bir detaydan bulabiliyor. Sonrasında bu golf şirketini araştırınca oyuncuları için bir websitesi ile bir mobil appi olduğunu farkediyor ve bu applerin girişinde telefon ile parola istemekte . Hacker artık şu stratejiyi üretiyor eğer bu golf şirketini hacklersem oradan hedeflediğim kişi hakkında elde ettiğim auth bilgilerini gidip bu kişinin çalıştığı kurumdaki RDP servisine login olabilir miyim? Bunu düşündükten sonra denemeye karar veriyor ve bu golf şirketinin websitesindeki subdomainlerin birinde test adlı bir subdomain keşfediyor ve incelemeye başlıyor temel olarak ana siteyle birebir aynı gibi frontend tarafta ancak backend öyle mi bilemiyor. Bu golf şirketinin websitesindeki subdomaindeki appin login kısmı tamamen farklı bir veritabanına bağlı bunu anlıyor çünkü en genel parolaları denediğinde en genel kullanıcı adları ile bu test subdomaininde OTP onay sayfasına gelebilmekte. Buradaki giriş bilgisi test:123123 olsun yani login'de telefon kontrolü test subdomaini içerisinde olmuyor hem frontend için hem backend için, backendi şöyle anlamakta uygulama .NET framework ile geliştirildiğinden HTTP requestindeki JSON objesi içerisindeki gönderilen veri numerik dışında bir karakter kapsıyorsa .NET uygulaması convert hata çıktısı göstermemekte. Bu test subdomainindeki OTP kodunu atlatamamakta çünkü test kullanıcısının telefon numarası bilinmiyor ve bilinse bile OTP ulaşılması zor bir süreç ancak OTP sayfası açıldıktan sonra client browserı 2. bir HTTP İsteği gönderiyor yani ikinci bir request atılıyor ve bu request bir API endpointine gidip userid parametresindeki değerini alıyor ve bunu veritabanında sorgulayıp o user ile ilgili tüm çıktıyı gösteriyor yani şifresini de gösteriyor. Bu hacker arkadaşımız bundan sonra bu istekteki session tokena ellemeden aynı istekteki requestteki userid değerini başlıyor 1den arttırmaya çünkü test kullanıcısı 7 id'sine sahip olduğunu biliyor. 1 yaptığında admin adlı kullanıcın hashlenmiş parolasını alıyor ve buradaki Authorization based bir IDOR zafiyeti olduğuna kanaat getiriyor. O adminin şifresini online servislerde bir miktar ücret karşılığında kırdırtıp o test subdomainindeki admin için oluşturulan administrator pathindeki diğer webappe erişebiliyor ve giriş yapıyor. Yönetici sistem arayüzünü incelerken bir dosya yükleme zafiyeti buluyor ancak firewall engelliyor bu arkadaşta bir şekilde firewall engelini atlatıp IIS servisten sunucuda komut çalıştıracağı bir kodlardan oluşan dosyayı yüklüyor. Artık o golf şirketinde erişimi var biraz incelemeyle golf şirketinin ana login appinin olduğu configuration bilgilerini barındıran dosyayı okuyabiliyor, artık iç ağdaki asıl olan MsSQL sunucuya erişebilir bundan sonra tünelleme yazılımları ile iç ağdaki sisteme kendi saldırgan makinesiyle erişebilmekte. İç ağdan gerekli yazılımlarla golf şirketinin MsSQL sunucusuna asıl appin erişebildiği kullanıcı ile bağlanıyor sonra veritabanını inceliyor kullanıcıların bulunduğu tabloyu açıyor ve hedeflediği c-level kişinin soyismini arattığında bir email adresi(şirket email adresi değil) ve bir parola buluyor (hashlenmemiş? demek düşünüyor bu sistem her parolayı hashleyip kaydetmiyor ki oldukça ilginç bir yaklaşım). Elde edilen bir parola var ancak RDP servisine giriş yapabilmekte mi? RDP servisine kendı saldırgan makinesinden denerse arkadaki alarmlar davul zurna olacak bunu düşünüyor ve bir çare buluyor?(çare halen bilinmemekte). RDP için administrator local kullanıcısyla sisteme giriş yapmayı denese de giremiyor sonra şirketin email adreslerini incelemeye başlıyor bunun için iş arama sitesindeki diğer çalışanların email adreslerini buluyor ve şunu farkediyor
[email protected] paterninin kullanmakta yani
[email protected] yani ilk ismin ilk harfi ve soyadının tümü arada bir nokta olacak şekilde çalışanlar şirket email adreslerine sahip. Buradan o c-level çalışana uygun bir email adresi buluyor ve test için bir email atmak istese de riski alamıyor ve o emaildeki kullanıcı adının RDP servisinde kullanıcı adı olarak kullanıyor sonra hacklemiş olduğu golf şirketindeki parolanın ilk harfini büyük yapıp denediğinde hedeflemiş olduğu kurumdaki sisteme giriş yapabiliyor. Böylelikle kurumda erişim hakkı kazanmış oluyor bir active directory kullanıcısı olarak.
Teşekkürler okuduğunuz için.
