Oturumumuzu almıştık.
Şimdi ise Task 2 ye geçtik
You can complete this with manual enumeration, but do it as you wish ifadesi bizi karşılıyor. Anlamı ise, manuel numaralandırma ile tamamlayabilirsin ama sana bağlı, nasıl istersen öyle yap diyor.
Soru1-) Where was the other users pass stored(no extension, just the name)? : Diğer kullanıcıların parolaları nerede saklanıyor ?
python3 -c ‘import pty; pty.spawn(“/bin/bash”)’ komutunu kullanarak dumb olarak adlandırılan en basit shellden, upgrade shell e yükseltelim kabuğumuzu
Dizini listeledik ve backup.sh dosyasını gördük, bi okuyalım bakalım
Burada bir bash script verilmiş ve ek olarak bir kimlik bilgisi yazılmış. İlk resimde beyaz alan içerisinde belirttim
stoner : superduperp@$$no1knows
cat /etc/passwd dizinini okuyalım ve kullanıcı varsa eğer bi switch user diyerek o kullanıcıya geçelim
evet kullanıcı mevcut, ozaman kullanıcıya geçiş yapalım
Stoner kullanıcısına geçiş yaptık
Kimlik bilgilerini backup.sh dosyasında bulduğumuz için
Cevap: backup (no extension - .sh olmadan)
Soru2-) user.txt
Kullanıcının home dizini kontrol edelim ve muhtemel /etc/stoner dizinindeki bayrağı okuyalım
Bayrağımıza ulaştık
Cevap: You made it till here, well done. (Anlamı buraya kadar geldin, aferin.)
Soru3-) What did you exploit to get the privileged user? : Ayrıcalık yükseltmek için hangi neyi kullandın ?
Öncelikle bi suid bitlerini kontrol edelim.
SUID, set owner user id anlamına gelir. Yani bir dosyayı root kullanıcısı herkesin çalışması için ayarlar (veya unutur). Bunu ise normalde yetkisi olmamasına rağmen çalıştırabileceği anlamına gelir.
Kullanacağımız komut ise:
find / -type f -perm -04000 2>/dev/null
-perm aranan dosya veya dizinin dosya izinlerini içeriyor
baştaki 0 sgid yani group için ayarlanmış s bitini temsil eder
4 user için ayarlanmış s olan suid bitini temsil eder
000 ise dosyaların herhangi bir izni içerebileceği anlamına gelir
Çıktımız yukarıdaki resimdedir.
Burada gtfo bins kullanacağız ( https://gtfobins.github.io/ ). Gtfobins de yukarıdaki komutlardan birçoğu yok. Olanlardan ise su yu deneyelim.
İkilinin sudo tarafından süper kullanıcı olarak çalışmasına izin verilirse, yükseltilmiş ayrıcalıkları düşürmez ve dosya sistemine erişmek, ayrıcalıklı erişimi yükseltmek veya sürdürmek için kullanılabilir.
Şimdi sudo su komutunu çalıştıralım.
Bize diyor ki:
Üzgünüm, stoner kullanıcısının Vulnerable üzerinde root olarak '/bin/su' yürütmesine izin verilmiyor.
Ozaman bu kullanıcının root olarak neyi çalıştırabileceğini görmek için sudo -l komutunu çalıştıralım.
Buradan şu anlamı çıkarıyoruz. Senin root olarak, parola ihtiyacı olmadan kullanabileceğin tek komut:
Yani hiçbir şey.
Ozaman sudo komutunu çalıştıramıyorsak suid bitlerinden en muhtemel komut olan find komutuna bakalım.
SUID
İkili dosyanın SUID biti ayarlanmışsa, yükseltilmiş ayrıcalıkları düşürmez ve dosya sistemine erişmek, bir SUID arka kapısı olarak ayrıcalıklı erişimi yükseltmek veya sürdürmek için kötüye kullanılabilir. sh -p'yi çalıştırmak için kullanılıyorsa, varsayılan sh kabuğunun SUID ayrıcalıklarıyla çalışmasına izin veren Debian (<= Stretch) gibi sistemlerde -p bağımsız değişkenini atlayın.
Bu örnek, ikili dosyanın yerel bir SUID kopyasını oluşturur ve yükseltilmiş ayrıcalıkları korumak için onu çalıştırır. Mevcut bir SUID ikili dosyasıyla etkileşim kurmak için ilk komutu atlayın ve programı orijinal yolunu kullanarak çalıştırın.
Burada
mavi ile işaretlediğimiz komutu çalıştıracağız fakat ./find çalıştırmamıza gerek yok.
find komutu
/usr/bin altında olduğu için yalnızca find kelimesini yazarak find komutuna ulaşabiliriz. ./find yazmamız gerek yok.
Buraya güzel bir örnek bırakalım:
Buraya verilen 1. argümanı yazdıran basit bir bash script yazdık.
Görüldüğü gibi ./ ile çalıştırıyoruz ve verdiğimiz ilk string ifadeyi bize yazdırıyor, /usr/bine-kopyaladık şeklinde argüman verdik ve bize aynısını yazdırdı. Şimdi bunu ./ olmadan çalıştıralım.
Komut bulunamadı diyor.
Peki biz bunu /usr/bin dizinine kopyalarsak ne olur
Gördüğünüz gibi ./ komutunu çalıştırmadan bu scripti yalnızca ismiyle çalıştırabiliriz. Çünkü komutlarımızın çalıştırılması sorgusu arasında /usr/bin dizini var
find komutu da aynı şekilde, ./find şeklinde çalıştırmamıza gerek kalmıyor.
find . -exec /bin/sh -p \; -quit
burada -quiti çalıştırmadık
Shellimizi tekrardan dumb shellden yükseltelim
Yükselttiğimizdeki verilen shell ile, mevcut shell imizin ayrıcalığı geri düştü.
Sonrasında suid komutunu tekrar çalıştırdık
Cevap: find
Soru4-) root.txt
Cevap: It wasn't that hard, was it?
You can complete this with manual enumeration, but do it as you wish ifadesi bizi karşılıyor. Anlamı ise, manuel numaralandırma ile tamamlayabilirsin ama sana bağlı, nasıl istersen öyle yap diyor.
Soru1-) Where was the other users pass stored(no extension, just the name)? : Diğer kullanıcıların parolaları nerede saklanıyor ?
python3 -c ‘import pty; pty.spawn(“/bin/bash”)’ komutunu kullanarak dumb olarak adlandırılan en basit shellden, upgrade shell e yükseltelim kabuğumuzu
Dizini listeledik ve backup.sh dosyasını gördük, bi okuyalım bakalım
Burada bir bash script verilmiş ve ek olarak bir kimlik bilgisi yazılmış. İlk resimde beyaz alan içerisinde belirttim
stoner : superduperp@$$no1knows
cat /etc/passwd dizinini okuyalım ve kullanıcı varsa eğer bi switch user diyerek o kullanıcıya geçelim
evet kullanıcı mevcut, ozaman kullanıcıya geçiş yapalım
Stoner kullanıcısına geçiş yaptık
Kimlik bilgilerini backup.sh dosyasında bulduğumuz için
Cevap: backup (no extension - .sh olmadan)
Soru2-) user.txt
Kullanıcının home dizini kontrol edelim ve muhtemel /etc/stoner dizinindeki bayrağı okuyalım
Bayrağımıza ulaştık
Cevap: You made it till here, well done. (Anlamı buraya kadar geldin, aferin.)
Soru3-) What did you exploit to get the privileged user? : Ayrıcalık yükseltmek için hangi neyi kullandın ?
Öncelikle bi suid bitlerini kontrol edelim.
SUID, set owner user id anlamına gelir. Yani bir dosyayı root kullanıcısı herkesin çalışması için ayarlar (veya unutur). Bunu ise normalde yetkisi olmamasına rağmen çalıştırabileceği anlamına gelir.
Kullanacağımız komut ise:
find / -type f -perm -04000 2>/dev/null
-perm aranan dosya veya dizinin dosya izinlerini içeriyor
baştaki 0 sgid yani group için ayarlanmış s bitini temsil eder
4 user için ayarlanmış s olan suid bitini temsil eder
000 ise dosyaların herhangi bir izni içerebileceği anlamına gelir
Çıktımız yukarıdaki resimdedir.
Burada gtfo bins kullanacağız ( https://gtfobins.github.io/ ). Gtfobins de yukarıdaki komutlardan birçoğu yok. Olanlardan ise su yu deneyelim.
İkilinin sudo tarafından süper kullanıcı olarak çalışmasına izin verilirse, yükseltilmiş ayrıcalıkları düşürmez ve dosya sistemine erişmek, ayrıcalıklı erişimi yükseltmek veya sürdürmek için kullanılabilir.
Şimdi sudo su komutunu çalıştıralım.
Bize diyor ki:
Üzgünüm, stoner kullanıcısının Vulnerable üzerinde root olarak '/bin/su' yürütmesine izin verilmiyor.
Ozaman bu kullanıcının root olarak neyi çalıştırabileceğini görmek için sudo -l komutunu çalıştıralım.
Buradan şu anlamı çıkarıyoruz. Senin root olarak, parola ihtiyacı olmadan kullanabileceğin tek komut:
Yani hiçbir şey.
Ozaman sudo komutunu çalıştıramıyorsak suid bitlerinden en muhtemel komut olan find komutuna bakalım.
SUID
İkili dosyanın SUID biti ayarlanmışsa, yükseltilmiş ayrıcalıkları düşürmez ve dosya sistemine erişmek, bir SUID arka kapısı olarak ayrıcalıklı erişimi yükseltmek veya sürdürmek için kötüye kullanılabilir. sh -p'yi çalıştırmak için kullanılıyorsa, varsayılan sh kabuğunun SUID ayrıcalıklarıyla çalışmasına izin veren Debian (<= Stretch) gibi sistemlerde -p bağımsız değişkenini atlayın.
Bu örnek, ikili dosyanın yerel bir SUID kopyasını oluşturur ve yükseltilmiş ayrıcalıkları korumak için onu çalıştırır. Mevcut bir SUID ikili dosyasıyla etkileşim kurmak için ilk komutu atlayın ve programı orijinal yolunu kullanarak çalıştırın.
Burada
mavi ile işaretlediğimiz komutu çalıştıracağız fakat ./find çalıştırmamıza gerek yok.
find komutu
/usr/bin altında olduğu için yalnızca find kelimesini yazarak find komutuna ulaşabiliriz. ./find yazmamız gerek yok.
Buraya güzel bir örnek bırakalım:
Buraya verilen 1. argümanı yazdıran basit bir bash script yazdık.
Görüldüğü gibi ./ ile çalıştırıyoruz ve verdiğimiz ilk string ifadeyi bize yazdırıyor, /usr/bine-kopyaladık şeklinde argüman verdik ve bize aynısını yazdırdı. Şimdi bunu ./ olmadan çalıştıralım.
Komut bulunamadı diyor.
Peki biz bunu /usr/bin dizinine kopyalarsak ne olur
Gördüğünüz gibi ./ komutunu çalıştırmadan bu scripti yalnızca ismiyle çalıştırabiliriz. Çünkü komutlarımızın çalıştırılması sorgusu arasında /usr/bin dizini var
find komutu da aynı şekilde, ./find şeklinde çalıştırmamıza gerek kalmıyor.
find . -exec /bin/sh -p \; -quit
burada -quiti çalıştırmadık
Shellimizi tekrardan dumb shellden yükseltelim
Yükselttiğimizdeki verilen shell ile, mevcut shell imizin ayrıcalığı geri düştü.
Sonrasında suid komutunu tekrar çalıştırdık
Cevap: find
Soru4-) root.txt
Cevap: It wasn't that hard, was it?
root kullanıcısının kilitlendiği anlamına gelir ! işareti.
stoner:$6$0FTa4IPZ$Cj8vdHgx7C2Zsbd7saTN4qoF0KwnFoYzt4WY3oem5Edq2a2CkFKBqN91smhPVjJpmPJSk7u3T1GQPgnA88N8B.:18130:0:99999:7:::
basterd:$6$nWzyGb69$DwWhd1AQRPMI6OevInJVXP02bojKAlatcI/GgbXQen77ITuGJ9.mPexUNejdXWsOZ.dnp7gtHUzFZLiTPkaB11:18130:0:99999:7:::
Ayrıca stoner ve basterd kullanıcılarının parolalarının hashine de ulaşmış oluyoruz. Parolalarını biliyoruz fakat kırmak isterseniz diye yukarıya bıraktım.
Root kullanıcısına geçiş yaparak root.txt yi okuduk fakat size göstermek istediğim başka bir teknik var.
cd / ile kök dizine geçelim ve ls -al ile root dizininin yetkilerini bi görelim
owner i root, group sahipliği de root. Bu dizine yetki olarak erişemiyoruz.
Şimdi find komutunundan yararlanarak recursive yani yineleyici olarak other a( kullanıcımız root değil, root grubuna da üye değiliz) okuma yetkisi vericez.
root dizinini listeleyemiyoruz
chmod komutu bize dosya, dizin üzerinde işlem yapmaya olanak tanır. 777 ile her kulanıcıya, herşeyi yapma izni verebiliriz ama daha karmaşıklaştırmak için o+rwx komutunu kullanacağım.
Not: Bu arada recursive/yineleyici olarak yetki vermemin sebebi root dizinine girebiliriz ama önemli olan içerisine girdikten sonra root.txt dosyasını da okumak. Bu yüzden dizine içindeki tüm dosya ve dizinleri de dahil edecek şekilde yetki yapılandırması yapmamız önem teşkil ediyor bu noktada.
Komutunu çalıştırdık, sonrasında ise root dizininin yetkilerini tekrar görüntüleyelim.
Burada bizi bekletiyor, Ctrl+c ile komutu bitirelim ve root dizinini listeyelim.
root dizinine others ın okuma, yazma ve çalıştırma yetkilerini tanımlamış olduk. Peki içerisindeki root.txt dosyasına ne oldu ?
Gördüğünüz üzere yineleyici olarak chmoddaki -R parametresiyle bu izinleri tanımladığımız için root.txt dosyasıda aynı dizinlere sahip olmasa bile (burada önemli olan bizim recursive olarak verdiğimiz o+rwx izinlerini aldı) okuyacak dizine sahibiz.
Bayrağımızı ayrıcalık yükseltmeden de find komutunu kullanarak okuyabildik.
Konumun sonuna gelmiş bulunmaktayım. Gözünüzden kaçtıysa diye araçları karşılaştırdığım bir doküman var almak için iletişime geçebilirsiniz. Uzun olması konusuna gelecek olursak da çok detaya inmek istediğim ve gerçekten faydalı olduğunu düşündüğüm şeyleri araya sıkıştırdığım için bu kadar oldu.
Okuduğunuz için teşekkür eder, iyi forumlar dilerim.
BLUE TEAM
