İLK ERİŞİM AŞAMASI

Öncelikle linux sunucu cloud ortamında değil, o yüzden verilmiş olan ova dosyasını sanal makine yöneticime kurdum ve netdiscover ile ağı tarayarak ip adresini öğrendim:

Komut: netdiscover -i eth0 -r 192.168.1.0/24

Nmap taramasıyla sunucuda çalışan servisleri keşfettiğimde 2 adet port'un açık olduğunu görüyorum(22/tcp ssh, 8080/tcp http):

8080 portunda çalışan web sayfasını görüntülediğimde aşağıdaki mesaj bizi karşılıyor:

Hedef web sayfasına gobuster ile dizin taraması gerçekleştiriyorum : 

Görmüş olduğunuz gibi 2 adet dizin buldum, öncelikle robots.txt dosyasına neler dahil edilmiş onlara bakıyorum:

Daha sonra burpsuite ile /redirect dizinini inceliyorum:

Gördüğünüz gibi isteğin url parametresine ihtiyaç duyduğunu söylüyor, bu noktada ?url parametresiyle localhost isteği atıyorum : 

Bu sefer de Only Accessible internally hatası aldım, robots.txt dosyası sayesinde /credz diye bir dizin daha bulmuştum hatırlarsanız, bu sefer oraya erişmek istiyorum:

Fakat gördüğünüz gibi yine aynı hatayı aldım, bu noktada sunucuya çift parametre isteği yolluyorum, yani ?url=localhost&?url=/credz parametrelerini kullanıyorum:

Ve sunucuya çift parametre ile istek yaptığımızda erişim kısıtlamasını bypasslamış olduk, aklınızda şu olabilir, neden tek url ile /credz'in içeriğini görüntüleyemedik de çift url ile görüntüleyebildik?

Bu durumda  url=/credz gibi bir path direktifi gönderdiğinde, sunucu bunu geçerli bir URL olarak algılamamış olabilir (örneğin http:// eksikliği veya domain yokluğu). Diğer bir ihtimal ise şu olabilir, bazı sunucular/framework'ler, aynı isimdeki çoklu parametrelerden sonuncusunu kabul eder. Örneğin: İlk parametre (url=localhost) WAF veya internal kontrolü geçti, ikinci parametre (url=/credz) ise asıl değer olarak işlendi. 

Son olarak belki de sunucu iki parametreyi birleştirip localhost/credz gibi bir internal URL oluşturmuş olabilir.

Elde ettiğim bilgiler ile ssh kullanıcısı olarak hedef sunucuya login oluyorum:

user flag:

YETKİ YÜKSELTME AŞAMASI

sudo -l komudunu çalıştırarak elde etmiş olduğum kullanıcıya sudo izni verilip verilmediğini kontrol ediyorum:

Görüldüğü üzere "/sbin/service sshd restart" komudunu root kullanıcısının sudo yetkileriyle çalıştırabiliyoruz. Burada sshd servisine restart atabildiğimi görünce aklıma ssh_config ve sshd_config dosyalarına yazma yetkim olup olmadığını kontrol etmek geliyor çünkü eğer bu dosyalara yazma yetkim varsa, konfigürasyon ayarlarını yetki yükseltmeye müsait şekilde ayarlayarak kolayca root yetkisi elde edebilirim:

Tam da tahmin ettiğim gibi konfigürasyon dosyalarına yazma yetkim var, bu sayede sshd_config dosyasında istediğim gibi ayarlamalar yapabilirim.

İlk olarak bir metin düzenleyicisiyle(vim,nano vb...) config dosyasını açıyorum, burada dikkat edilmesi gereken değerler "PermitRootLogin,StrictModes, AuthorizedKeysFile"  satırlarıdır.

Bahsetmiş olduğum parametrelerin default değerleri aşağıdaki gibidir fakat biz bunları değiştireceğiz:

PermitRootLogin değerini yes, StrictModes değerini ise no olarak değiştireceğiz (başındaki # işaretini kaldırmayı unutmayın aktif etmek için). AuthorizedKeysFile parametresine hangi dosyayı gireceğimizi de ilerideki adımlarda anlatacağım ama ondan önce gelin neden bu değişkenleri değiştiriyoruz onları açıklayayım.

Bu iki ayar (PermitRootLogin yes ve StrictModes no), SSH sunucusunun güvenlik ve erişim kurallarını belirler.

PermitRootLogin

• Root kullanıcısının SSH ile doğrudan giriş yapmasına izin verir.

• Varsayılan değer genellikle prohibit-password veya no'dur (güvenlik için).

Eğer varsayılan değer değiştirilip yes yapılırsa root kullanıcısı brute force ataklarına karşı savunmasız olur.

StrictModes

• SSH'nin, kullanıcı dizinlerindeki (**~/.ssh, authorized_keys vb.) dosya izinlerini kontrol etmesini devre dışı bırakır.

• Varsayılan değer yes'dir (güvenlik için sıkı izin denetimi yapar).

Eğer default değer değiştirilip no yapılırsa, yanlış dosya izinleri (örn. authorized_keys'in herkes tarafından yazılabilir olması) yetki yükseltme açığına yol açar. Ve ayrıca saldırgan, başka bir kullanıcının ~/.ssh/ dizinine kendi anahtarını ekleyebilir.

Şimdilik bu iki değeri dediğim şekilde değiştirdikten sonra ele geçirmiş olduğum kullanıcının ana dizinine gidiyorum, kullanıcı için ssh klasörü oluşturuyorum ve ssh-keygen aracını kullanarak id_rsa private ve public key oluşturuyorum:

Şimdi AuthorizedKeysFile parametresine gelebiliriz işte. Bu parametreyi açıklamam gerekirse,OpenSSH sunucusunun (sshd) kullanıcıların SSH public key'lerini nerede arayacağını belirleyen kritik bir yapılandırma parametresi diyebilirim. SSH bağlantısı sırasında, sunucu kullanıcının home dizinindeki bu dosyaları tarar. Aynı zamanda birden fazla dosya yolu belirtilebiliriz. 

Yani buradaki asıl mantık şudur, SSH, bir kullanıcı giriş yapmaya çalıştığında o kullanıcının home dizinindeki "~/.ssh/authorized_keys" dosyasını kontrol eder. Ancak AuthorizedKeysFile ile bu dosyanın yolu değiştirilebilir. Saldırgan, bu yolu kendi kontrol ettiği bir dosyaya yönlendirerek (/home/ssh/.ssh/authorized_keys örneğindeki gibi), root girişlerinde bile kendi anahtarının okunmasını sağlar.

Hatırlarsanız hemen bir önceki adımda ele geçirmiş olduğum yetkisiz kullanıcıyla bir id_rsa ve id_rsa.pub dosyaları oluşturmuştum, işte şimdi AuthorizedKeysFile parametresinin default değerini, oluşturmuş olduğum dosya adı ile değiştireceğim (tam dosya yoluyla):

Dosyayı kaydedip çıkıyorum, sudo izniyle beraber sshd restart komudunu çalıştırıyorum ve sshd servisini resetliyorum, yaptığım konfigürasyon değişiklikleri artık aktif olduğu için oluşturduğum id_rsa private key ile birlikte root kullanıcısı adına bağlanıyorum ve hedef sistemde başarılı bir şekilde root erişimi elde ediyorum:

Bir yazının daha sonuna geldik, umarım keyif almışssınızdır. Sonraki yazılarımda görüşmek dileğiyle, hoşçakalın...