Esenlikler,
Bugün sizlerle TryHackMe üzerinden ulaşabileceğiniz Silver Platter challenge’ını çözmeye çalışacağım.
Silver Platter Hakkında
Bu challenge’da verilen ön bilgilere kısaca göz atacak olursak; hedef sistemin bir web sunucusu olduğu ve parola protokolü kullandığı belirtiliyor. Ancak bu protokol yalnızca, rockyou.txt dosyasındaki parolaların kullanılmasını engelliyor.
Yani kısaca rockyou.txt wordlist’i kullanmayacağız.
Amaç kısaca, hedef sistemde bir adet user flag ve bir adet root flag olduğunu belirtmektedir. Bizden ise bu flagleri bulmamız istenmektedir.
Keşif
Öncelikle, TryHackMe bizlere gerekli makineleri sağlıyor ve IP atamasıyla beraber bu makinelerin IP adreslerini veriyor. Bu yüzden hedef sistemin IP adresini öğrenmek için ICMP taraması yapmayacağım.
İlk olarak, hedef sistemde hangi servislerin çalıştığını öğrenmek amacıyla bir NMAP taraması gerçekleştireceğim.
sudo nmap 10.10.254.139 -sT -p- -A -O
Bu noktada, hedef sistemde 22 numaralı SSH, 80 numaralı HTTP (Nginx 1.18.0) ve 8080 numaralı HTTPS portlarının aktif olduğunu görüyorum.
Hedef web sitesinin ne yaptığını kontrol etmek için öncelikle siteyi ziyaret ediyorum. Anasayfada sayfa ve hedefle ilgili çeşitli bilgiler bulunuyor, ancak genel olarak kaynak kodlarında işime yarayacak bir şey bulamıyorum.
Ancak sayfa içerisinde çeşitli alanlarda hedef sistemle ilgili işime yarayabilecek bilgilerle karşılaşıyorum.
Örneğin, intro alanında "1337est" anahtar kelimesi dikkatimi çekiyor.
Work alanında ise "1337 h4x0r" ifadesi bulunuyor.
About kısmında "Tyler Ramsbey" ismi yer alıyor.
Contact bölümünde ise "scr1ptkiddy" ifadesi mevcut.
Bu ifadeler dikkatimi çekiyor ve ileride kullanmam gerekebilir diye notlarıma alıyorum.
Bu ifadelerin notunu aldıktan sonra, hedef sistemle ilgili ilk olarak görünmeyen alt sayfalar (subpage) olup olmadığını kontrol etmek için dirb aracını kullanarak bir tarama yapacağım.
Bu taramadan şimdilik herhangi bir sonuç alamadım. Bu noktada, gobuster ile daha ayrıntılı bir tarama yapmayı deneyebilirim; ancak bunun çok işe yarayacağını düşünmüyorum. Bu yüzden, 80 numaralı portta çalışan site yerine, 8080 portunda ne olduğunu kontrol etmeye karar verdim.
Burada, gördüğüm “404 - Not Found” mesajının doğrudan Nginx sunucusundan değil, sayfa içeriğinde yer aldığını fark ettim. Bu yüzden 8080 portunda da bir subpage taraması yapmaya karar verdim.
Bu noktada, 8080 portunda çalışan serviste çeşitli subpageler olduğunu görüyorum. Bunları kontrol ettiğimde, advandare ve secci sayfalarında 404 hatası alırken, console sayfasında bir yönlendirme olduğunu fark ediyorum. Console sayfası beni nonredirect.html sayfasına yönlendiriyor.
Burp Suite ile gerçekleştirdiğim işlemlerde şu ana kadar dikkatimi çeken kayda değer bir bulguya rastlamadım. Bu nedenle, subdomain taramasını daha da derinleştirmeye karar verdim. Daha kapsamlı bir wordlist kullanarak yeniden şansımı deneyeceğim.
Küçük Ayrıntının Önemi
Daha büyük bir wordlist ile gerçekleştirdiğim subdomain taraması da başarısız oldu. Şimdiye kadar yaptıklarımı değerlendirirken, contact sayfasında yer alan şu mesaj aklıma geliyor:
"If you'd like to get in touch with us, please reach out to our project manager on Silverpeas. His username is 'scr1ptkiddy'."
Bu ifadeden yola çıkarak sistemde “silverpeas” adında bir uygulama olabileceğini düşündüm. Bu uygulamaya erişimin web üzerinden sağlanabileceğini varsayarak, hem 80 hem de 8080 portları üzerinden silverpeas subdomain’ine erişmeyi deniyorum.
Ve tahmin ettiğim gibi, gerçekten de silverpeas adında bir web uygulamasıyla karşılaşıyorum.
Nedir bu silverpeas?
İnternetten bu uygulamanın ne olduğunu araştırmaya başlıyorum. Resmî web sitesine ve GitHub reposuna göz attığımda şu açıklamayla karşılaşıyorum:
"Silverpeas, kullanıcılar arasında iş birliğini ve paylaşımı kolaylaştırmak amacıyla geliştirilen, işbirlikçi ve sosyal bir web portalı oluşturmak ve çalıştırmak için tasarlanmış açık kaynaklı bir projedir. Bu proje, tüm Silverpeas modüllerinin özelliklerini, bağımlılıklarını ve ortak bileşenlerini tanımlar."
Bu açıklamaya bakarak, Silverpeas’in muhtemelen ekipler için proje ve iş takibi yapmaya yönelik bir platform olduğunu tahmin ediyorum.
İlk olarak internetten varsayılan kullanıcı adı ve parolasını araştırıyorum. Bu bilgilerin doğrudan “SilverAdmin / SilverAdmin” olarak belirlendiğini görüyorum.
Ancak giriş yapamıyorum.
Silverpeas hakkında araştırma yapmaya devam ederken, bu sistemde kimlik doğrulama atlatma (authentication bypass) açığı olduğunu fark ediyorum. Bu açıklık CVE-2024-36042 olarak kayıtlı. Açığın detaylarına baktığımda, kullanıcı adı belirtildiği halde parola belirtilmeden sistemin girişe izin verdiğini görüyorum. Bu güvenlik açığını test etmek için aşağıdaki şekilde bir HTTP isteği göndereceğim:
POST /silverpeas/AuthenticationServlet HTTP/2
Host: 10.10.71.248
Content-Length: 28
Origin: https://10.10.71.248
Content-Type: application/x-www-form-urlencoded
Login=SilverAdmin&Password=SilverAdmin&DomainId=0Bu şekilde, yani hem kullanıcı adı hem de parola alanı doldurularak sisteme giriş yapmaya çalıştığımızda başarısız oluyoruz.
Ancak aşağıdaki gibi yalnızca kullanıcı adı (Login) ve domain bilgisi (DomainId) gönderdiğimizde:
POST /silverpeas/AuthenticationServlet HTTP/2
Host: 10.10.71.248
Content-Length: 28
Origin: https://10.10.71.248
Content-Type: application/x-www-form-urlencoded
Login=SilverAdmin&DomainId=0Bu sefer sistem bizi başarılı bir şekilde oturum açmış olarak kabul ediyor. En azından, CVE bize bunu söylüyor. Peki bunun nedeni ne?
CVE-2024-36042'nin nedeni?
Silverpeas sistemindeki bu açığın nedenini özellikle merak ediyorum çünkü yaptığım sızma testlerinde asıl amacım öğrenmek ve anlamaktır. Dolayısıyla, açığın nasıl oluştuğunu bilmek benim için en önemli noktalardan biri.
İlgili açığın nasıl kapatıldığını görmek için CVE-2024-36042 bağlantısındaki GitHub commit’ine göz atalım.
Sorun 1:
Yukarıda görülen isPasswordSet fonksiyonu, eğer parola değeri null ise yani kullanıcı herhangi bir parola girmemişse, parolayı null olarak işaretliyor. Sonrasında yapılacak kontrollerde, parola yoksa kullanıcıya bir uyarı gösteriliyor.
Peki ya kullanıcı parolayı null yerine "" (boş string) ya da " " (boşluk karakteri) olarak girerse ne olur?
Ne yazık ki, bu duruma yönelik herhangi bir önlem alınmamış.
Bu durum, aşağıdaki kontrolde aslında false dönmesi gereken ifadenin true dönmesine sebep oluyor. Böylece kullanıcı, parolasız giriş yapmasına rağmen sistem tarafından başarılı bir şekilde oturum açmış kabul ediliyor:
CVE-2024-36042'nin kullanımı
Bu mantıkla hedef sisteme giriş yapmak için Burp Suite aracını kullanacağız. Kısaca, hedef sistemde parola bilgisini göndermeden CVE açığını kullanmış olacağız.
İlk olarak, login işlemi sırasında gerçekleşen POST isteğini yakalıyorum.
Hatırlarsanız, contact bölümünde bahsedilen kullanıcı adı "scr1ptkiddy" idi. Bu nedenle bu hesapla giriş yapmayı deneyeceğim.
Ardından, bu istekteki parola bilgisini siliyorum ve isteği gönderiyorum.
Bu şekilde scr1ptkiddy hesabı ile başarılı bir şekilde giriş yapmış oluyoruz.
Admin hesabına erişmek
scr1ptkiddy hesabı ile gezindiğimde personal workspace kısmında write to administratos kısmından Administrateur kullanıcı adına sahip bir hesabın olduğunu ve bu hesabın admine ait olduğunu görüyorum. bu hesaba giriş yapmak için yine aynı açıktan faydalanmak istiyorum
Ancak teknik bir sorun yaşıyoruz
Bu sebeple tekrar scr1ptkiddy hesabına geçiş yapıyorum.
CVE-2023-47323
Araştırmamı, Silverpeas platformunun başka hangi zafiyetleri içerdiğine bakarak derinleştirmeye çalışıyorum; çünkü ana sayfa üzerinde gerçekleştirdiğim incelemelerde kayda değer bir bulguya ulaşamadım.
Bu araştırmalarım sırasında, Silverpeas’in mesajlaşma uygulamasını etkileyen bir Broken access control olan CVE-2023-323’e rastlıyorum. Bu nedenle, sistemdeki mesajları inceleyerek bir ipucu elde edebileceğimi düşünüyorum.
Bu zafiyeti kullanabilmek için http://10.10.96.235:8080/silverpeas/RSILVERMAIL/jsp/ReadMessage.jsp?ID=[MESSAGE_ID] şeklinde bu path'e gitmem gerekiyor. Bu sayede yetkinin kimde olduğu önemsiz bir şekilde tüm mesajları sırası ile gezebiliyorum.
Peki nedir bu broken access control?
Bu durumu bir örnekle açıklamak istiyorum. Bir web uygulamasında, her kullanıcıya sadece kendi yetkileri doğrultusunda belirli verilere erişim hakkı tanınır. Yani kullanıcı yalnızca kendisine ait ya da erişim izni verilen verileri görüntüleyebilmelidir.
Ancak Silverpeas uygulamasında karşılaştığımız durumda, bu güvenlik prensibi ihlal ediliyor. Uygulama, kullanıcıların yetkileri dışında başka kullanıcılara ait verilere erişmesini engelleyecek bir kontrol mekanizmasına sahip değil. Bu da ciddi bir yetki doğrulama (authorization) açığına işaret ediyor.
Bu sebeple, şu an bulunduğumuz scr1ptkiddy kullanıcısı ile yalnızca yukarıda belirttiğim URL yolu üzerinden ve belirttiğimiz ID parametresi aracılığıyla mesajlara erişim sağlanabiliyor. ID değerlerini sırasıyla 1, 2, 3 şeklinde denediğimde, sonunda 6 numaralı mesajda tim adlı kullanıcıya ait SSH kullanıcı adı ve parolasını içeren bir bilgiye ulaşıyorum.
SSH ile tim kullanıcısı olarak sisteme giriş yaptığımızda, bu challenge’ın ilk aşaması olan user flag’i başarıyla elde etmiş oluyoruz.
Privilege Escalation
Artık sistemde tim kullanıcısı olarak oturum açtığımıza göre, sıradaki hedefimiz root flag’ini elde etmek olacak. Bir sisteme erişim sağladığımda genel olarak şu adımları takip etmeyi alışkanlık haline getirdim:
- Sistemde hangi yetkilere sahibim?
- Sistemde root yetkisi ile çalıştırabileceğim bir komut var mı?
- Sistemde başka hangi kullanıcılar mevcut?
- crontab içerisinde tanımlı görevler var mı?
- Yedekleme klasörlerinde (backups) işime yarayacak bir şey var mı?
Bu noktada, öncelikle sahip olduğum yetkileri kontrol ettiğimde ADM grubuna ait olduğumu görüyorum. Yaptığım araştırmalara göre, ADM (admin log reader) grubu, sistem üzerindeki log dosyalarını okuma yetkisi sağlayan bir kullanıcı grubudur.
Ayrıca sistem içerisinde tyler adında bir başka kullanıcının daha bulunduğunu fark ediyorum.
Backuplarda ve crontab'da işe yarar bir bilgiye rastlayamıyorum. Bu nedenle, ilk aşamada doğrudan sistem loglarına bakarak yeni bir ipucu elde etmeyi deneyeceğim.
Sistem logları içerisinde, özellikle tüm auth loglarını tek tek incelediğimde dikkatimi çeken bir durumla karşılaştım: Tyler kullanıcısı tarafından oluşturulan bir PostgreSQL veritabanı parolası, sistemde şifresiz (düz metin olarak) belirtilmiş.
Bu parolanın doğrudan Tyler kullanıcısına ait olup olmadığını merak ederek bir deneme yaptım. Elde ettiğim parola ile Tyler kullanıcısı olarak sisteme doğrudan giriş yapabildiğimi gördüm.
Root Olmak
Yukarıda belirttiğim gibi yeni bir kullanıcı olan tyler ile sisteme giriş yaptıktan sonra, bu kullanıcı üzerinde de bazı kontroller gerçekleştirdim. Özellikle dikkatimi çeken nokta, tyler kullanıcısının ALL yetkilerine sahip olmasıydı.
Bu da demek oluyor ki, tyler kullanıcısı üzerinden sudo su komutu ile kullanıcı değiştirerek doğrudan root olarak sisteme giriş yapabiliyorum.
Bu sayede, son flag olan root flag’ini de başarılı bir şekilde elde ediyor ve böylece bu makineyi de başarıyla tamamlamış oluyoruz.
Teşekkürler
Bu yazımı da buraya kadar okuduysan sana gönülden teşekkür ederim. Bir sonraki yazımda görüşmek üzere, kendine iyi bak. Esenlikler.
