[TR] Hack The Box — DevOops Write-Up
Herkese merhaba. Bu yazımda, Hack The Box platformunda bulunan DevOops isimli makinenin çözümünü sizlerle paylaşıyor olacağım.
Öncelikle nmap taraması ile başlayalım:
Nmap taraması sonucunda hedef makine üzerinde 22 ve 5000 portlarının açık olduğunu görüyoruz. SSH portuna yönelik herhangi bir işlem gerçekleştirmeden önce, öncelikle üzerinde Gunicorn web servisi çalışan 5000 numaralı portu ziyaret edelim:
Web servisini ziyaret ettiğimizde, yukarıdaki gibi bir sayfayla karşılaşmaktayız. Burada sayfanın hala yapım aşamasında olduğuna dair ve şuanda bulunmakta olduğumuz sayfa içerisinde aşağıdaki resimde görünen feed akışının isminin de feed.py olduğu belirtiliyor. Burdan sonra öncelikle bu dosyanın sunucuda bulunup bulunmadığını kontrol edebiliriz ancak dosya sunucuda bulunmamakta. Ayrıca resim dosyasını indirip içeriğine göz atabiliriz ancak burada da bir şey bulunmamakta:
Buradan sonra yapabileceğimiz ilk şey, bu web servisi üzerinde bulunan gizli dizinleri test etmek olmalıdır, bunun için gobuster isimli araçtan faydalanacağız:
Gobuster taraması sonucunda “/feed” ve “/upload” şeklinde iki adet dizin görmekteyiz.
“/upload” isimli dizine gittiğimizde, sayfanın yukarısında bu sayfanın bir test API’ı olduğu, final API içerisinde bu fonksiyonun (upload) bulunmayacağı belirtiliyor. Aşağı kısmı incelediğimizde ise, Author, Subject ve Content bilgilerine sahip XML dosyalarının sisteme yüklenebileceği gösteriliyor. Burada aklımıza gelecek ilk şey, XML External Entity Injection (XXE Injection) olmalıdır. Bu saldırı metodu, XML dosyasını çalıştıran sunucu tarafında bu dosyanın çalıştırılmasını manipüle ederek gerçekleştirilmektedir. Bu saldırının sonucunda, hedef sunucudan çeşitli dosyalar okunabilir (arbitrary file read) veya SSRF saldırıları gerçekleştirilebilir. XXE saldırısına direkt olarak geçmeden önce, öncelikle hedef sunucuya gerçekten bir XML dosyası gönderip gönderemediğimizi kontrol edelim:
Buradan görülebileceği gibi, upload kısmında verilen ve yukarıda da ayrıca belirtmiş olduğumuz gibi göndermekte olduğumuz test.xml dosyasını Author, Subject, Content formatında gönderdiğimizde, bu dosyayı sisteme başarılı olarak yükleyebiliyoruz. “File path” kısmında da dikkat edilebileceği gibi, dosyanın yüklendiği path olarak “/home/roosa/..” olarak gösteriliyor. Buradan, dosyanın “roosa” isimli bir kullanıcının dizinine yüklendiğini görebiliriz. Şimdi öncelikle bu dosyaya bir DOCTYPE elementi vererek bu element ile göndermekte olduğumuz Author, Subject veya Content içerisinde gönderilen verileri manipüle edip edemediğimizi kontrol edelim:
Burada görebileceğimiz gibi, öncelikle “test” isimli bir DOCTYPE Entity tanımladık ve sonrasında replace ..“SUCCESS!” komutu ile “test” ifadesini placeholder olarak tutan yerlerde (Author) bu ifadenin “SUCCESS!” mesajı ile değiştirilmesini sağladık. Yani buradan anlayacağımız üzere, çalıştırılmakta olan XML dosyasına sunucu tarafındaki execution flow aşamasında manipülasyon gerçekleştirerek XXE Injection saldırısını gerçekleştirebilmekteyiz. Bir önceki figürde dikkat edilebileceği ve bizim de bahsetmiş olduğumuz üzere, yüklemiş olduğumuz dosya “home/roosa/..” dizini altında “roosa” isimli kullanıcıya ait dizine yüklenmekte. Hedef sunucu üzerindeki diğer kullanıcıları da tespit edebilmek adına, öncelikle “/etc” dizini altında bulunan “passwd” dosyasını okumaya çalışalım:
Buradan görebileceğimiz üzere, az önce kullanmış olduğumuz “replace” yerine bu sefer gireceğimiz komutun sistem üzerinde çalıştırılabilmesini test etmek için “SYSTEM” keyword’ünü kullandık. Sunucudan dönen cevapta ise, “root”, “git” ve “roosa” olmak üzere 3 adet kullanıcı olduğunu görebiliriz. Buradan sonra, sisteme SSH portundan erişim sağlayabilmek için, “roosa” isimli kullanıcının SSH Private Key’i olan “id_rsa” dosyasını okumayı deneyebiliriz:
Burada SSH Private Key olan “id_rsa” dosyasını okumamızın sebebi, SSH servisine bağlanmak için kullanılan Encryption Key’in Asymmetric Encryption’a sahip olmasından ve kaynaklanmaktadır. Symmetric Encryption’ın aksine, Asymmetric Encryption içerisinde tek bir Public Key yerine Public Key’in yanında bir de Private Key kullanılmaktadır. Biz şuanda “roosa” kullanıcısı için SSH servisine bağlantı gerçekleştireceğimiz esnada girmemiz gereken parolayı bilmediğimiz için, Password Authentication yerine Public Key Authentication kullanarak direkt olarak Private Key değerine sahip “id_rsa” dosyası ile bağlantı sağlamaya çalışacağız. Böylelikle, sahip olduğumuz Private Key değerini sunucuda tutulmakta olan Public Key değeri ile eşleyerek erişimimizi sağlamış olacağız. Symmetric & Asymmetric Encryption hakkında ve kriptoloji hakkında daha fazla bilgi edinmek için burada bulunan yazıma göz atabilirsiniz. Şimdi elde ettiğimiz Private Key değerini local sistemimizde yeni bir “id_rsa” (ismi istediğiniz şekilde değiştirebilirsiniz, bir farklılık oluşturmayacaktır) dosyası oluşturalım ve gerekli dosya izinlerini (chmod 600) ayarlayarak bağlantı sağlamaya çalışalım:
Şimdi bağlantı sağlamaya çalışalım:
“roosa” kullanıcısı üzerinden sisteme bağlantı sağladık. Vakit kaybetmeden bulunmakta olduğumuz “/home/roosa” dizinine göz atarak user.txt dosyasını bulmaya çalışalım:
User flag’i elde ettik. Şimdi yetkilerimizi yükseltmeye çalışalım. Bunun için ister manuel olarak enumeration işlemine devam edebilir, isterseniz süreci hızlandırmak adına linPEAS gibi araçları kullanarak işleminizi otomatize hale getirebilirsiniz. Öncelikle manuel olarak neler bulabildiğimize göz atalım:
“/work/blogfeed/resources/integration” dizinine gittiğimizde, başka bir Private Key değeri daha elde ettiğimizi görüyoruz. Bunu da local sistemimize alıp diğer kullanıcılar olan “root” veya “git” isimli kullanıcılar için bağlantı sağlamayı deneyebiliriz:
Öncelikle “root” kullanıcısı için bağlantı sağlamaya çalıştık ancak bir bağlantı elde edemedik. İkinci kullanıcı olan “git” kullanıcısı için aynı işlemi deneyelim:
Bu kullanıcı için de bağlantı sağlayamadık. Burada bağlantı sağlayamamış olmamızın iki sebebi olabilir; ilki, sunucu tarafında bu kullanıcılar için Public Key Authentication devre dışı bırakılmış olabilir, yani sadece parola kullanarak bağlantı sağlayabiliyor olabiliriz. İkinci sebep ise kullanmakta olduğumuz Private Key dosyası bu kullanıcılardan birine ait bir Private Key dosyası değil. Manuel olarak enumeration işlemine devam edelim:
“.git” isimli dizin içerisinde bulunan dosyaları inceledik ancak işe yarar bir şey elde edemedik. “/home/roosa” dizini altında “.bash_history” dosyasını incelediğimizde, Git üzerinde birkaç işlemin gerçekleştirilmiş olduğunu görebiliriz:
Dosyayı biraz daha incelediğimizde:
“ssh-keygen” aracı ile SSH keylerin oluşturulmuş olduğunu, ve gönderilmiş olan commit içerisinde de yorum olarak da commit ile gönderilmiş doğru “key” değerinin revert edildiğini, yani geri alındığı söylenmekte. Buradan hareketle, “.git” dizini bir Git dizini olduğu için, bu dizin kullanılarak Git servisine gönderilmiş olan commitleri listelemeye çalışabilir ve revert edilmiş key değerine ulaşabiliriz:
“git log” komutu ile gönderilmiş commitleri listeledikten sonra, aramakta olduğumuz commitin hash değerini elde ediyoruz. Burdan sonra, “git show <hash_value>” komutu ile bu hash değeri ile kaydedilmiş commitin kendisini görebiliriz:
Burada görebileceğimiz gibi, kırmızı olarak görünen ve her satırının başında “-” bulunan değerler dosya içerisinden çıkartılan, başında “+” ile gösterilen değerler ise dosyaya yeni eklenen değerleri temsil etmektedir. Bizim burada “reverted” satırları elde etmek için dosya içerisinden çıkartılan satırları dikkate almalıyız. Bu Private Key değerini bir local sistemimiz üzerinde bir dosyaya kaydedip tekrar “root” ve “git” kullanıcıları ile sisteme bağlantı sağlamaya çalışalım:
Öncelikle “git” kullanıcısı ile bağlantı sağlamaya çalıştık ancak bağlantı talebi başarısız oldu. Sonrasında ise “root” kullanıcısı ile bağlantı sağlamaya çalıştığımızda, başarılı bir şekilde bağlantı sağladık.
Bu makine ile ilgili sizlere aktarmak istediklerim bu kadardı. Yazımı okuduğunuz için teşekkür ederim.
Bir sonraki yazımda görüşmek üzere.
Kaynaklar:
