Linux Privilege Escalation
Last updated
Last updated
AWS Hacking'i öğrenin ve uygulayın:HackTricks Eğitimi AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve uygulayın: HackTricks Eğitimi GCP Kırmızı Takım Uzmanı (GRTE)
Çalışan işletim sistemi hakkında bazı bilgiler edinmeye başlayalım.
Eğer PATH
değişkeni içindeki herhangi bir klasörde yazma izniniz varsa, bazı kütüphaneleri veya ikili dosyaları ele geçirebilirsiniz:
Ortam değişkenlerinde ilginç bilgiler, şifreler veya API anahtarları var mı?
Kernel sürümünü kontrol edin ve ayrıcalıkları yükseltmek için kullanılabilecek bir açık olup olmadığını kontrol edin.
İyi bir zayıf çekirdek listesi ve zaten derlenmiş bazı saldırıları burada bulabilirsiniz: https://github.com/lucyoa/kernel-exploits ve exploitdb sploits. Bazı derlenmiş saldırıları bulabileceğiniz diğer siteler: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
O web sitesinden tüm zayıf çekirdek sürümlerini çıkarmak için:
Kernel exploits aramak için yardımcı olabilecek araçlar:
linux-exploit-suggester.sh linux-exploit-suggester2.pl linuxprivchecker.py (sadece kurban üzerinde çalıştırılmalı, yalnızca kernel 2.x için exploitleri kontrol eder)
Her zaman Google'da kernel sürümünü arayın, belki kernel sürümünüz bazı kernel exploitlerinde yazılıdır ve bu sayede bu exploitin geçerli olduğundan emin olabilirsiniz.
Linux Yetki Yükseltme - Linux Kernel <= 3.19.0-73.8
Vulnerabl sudo sürümlerine dayanarak:
Sudo sürümünün zayıf olup olmadığını bu grep kullanarak kontrol edebilirsiniz.
@sickrov tarafından
Bu zafiyetin nasıl sömürülebileceğine dair bir örnek için HTB'nin smasher2 kutusuna bakın
SElinux (Security-Enhanced Linux), Linux çekirdeğine entegre edilmiş bir güvenlik modülüdür. SElinux, Linux işletim sisteminde zayıf yapılandırılmış izinlerden kaynaklanan güvenlik açıklarını azaltmaya yardımcı olur. SElinux, uygulamaların ve kullanıcıların erişebileceği kaynakları sınırlamak için zorlayıcı bir politika uygular. Bu sayede, kötü amaçlı yazılımların ve saldırganların sisteme sızma olasılığını azaltır.
Adres Alanı Rastgele Konumlandırma (ASLR), saldırganların hedef sistemdeki bellek bölgelerinin konumunu tahmin etmesini zorlaştıran bir güvenlik önlemidir. Bu yöntem, bellek bölgelerinin rastgele adreslere yerleştirilmesini sağlayarak saldırıların etkisini azaltır.
Eğer bir docker konteynerinin içindeyseniz, ondan kaçmaya çalışabilirsiniz:
Docker SecurityNelerin bağlandığını ve bağlanmadığını, nerede ve neden kontrol edin. Eğer bir şey bağlanmamışsa, onu bağlamayı deneyebilir ve özel bilgileri kontrol edebilirsiniz.
Yararlı ikili dosyaları listeleyin
Ayrıca, herhangi bir derleyicinin yüklü olup olmadığını kontrol edin. Bu, bazı kernel açıklarını kullanmanız gerektiğinde faydalıdır çünkü derlemeyi kullanacağınız makinede (veya benzer bir makinede) derlemeniz önerilir.
Yüklü paketlerin ve hizmetlerin sürümlerini kontrol edin. Belki de ayrıcalıkları yükseltmek için sömürülebilecek eski bir Nagios sürümü gibi bir yazılım bulunabilir... Daha şüpheli yüklü yazılımların sürümlerini manuel olarak kontrol etmeniz önerilir.
Eğer makineye SSH erişiminiz varsa, makine içinde yüklü olan eski ve savunmasız yazılımları kontrol etmek için openVAS'ı da kullanabilirsiniz.
Bu komutlar genellikle gereksiz bilgileri gösterecektir, bu nedenle yüklü yazılım sürümünün bilinen saldırılara karşı savunmasız olup olmadığını kontrol edecek OpenVAS veya benzeri uygulamalar önerilir
Hangi işlemlerin yürütüldüğüne bakın ve herhangi bir işlemin olması gerekenden daha fazla ayrıcalığa sahip olup olmadığını kontrol edin (belki de root tarafından yürütülen bir tomcat olabilir mi?)
Her zaman çalışan electron/cef/chromium hata ayıklayıcılarını kontrol edin, ayrıcalıkları yükseltmek için bunu istismar edebilirsiniz. Linpeas, sürecin komut satırında --inspect
parametresini kontrol ederek bunları tespit eder.
Ayrıca süreç ikili dosyaları üzerindeki ayrıcalıklarınızı kontrol edin, belki birinin üzerine yazabilirsiniz.
pspy gibi araçları kullanarak süreçleri izleyebilirsiniz. Bu, sık sık yürütülen savunmasız süreçleri veya belirli gereksinimlerin karşılandığı durumları tanımlamak için çok yararlı olabilir.
Bir sunucunun bazı hizmetleri kimlik bilgilerini açık metin olarak belleğin içine kaydeder. Genellikle diğer kullanıcılara ait süreçlerin belleğini okumak için kök ayrıcalıklarına ihtiyacınız olacaktır, bu nedenle bu genellikle zaten kök kullanıcıysanız ve daha fazla kimlik bilgisi keşfetmek istiyorsanız daha yararlı olacaktır. Ancak, normal bir kullanıcı olarak sahip olduğunuz süreçlerin belleğini okuyabilirsiniz.
Günümüzde çoğu makine varsayılan olarak ptrace izin vermez, bu da başka bir kullanıcıya ait diğer süreçleri dökemeyeceğiniz anlamına gelir.
Proc/sys/kernel/yama/ptrace_scope dosyası ptrace erişilebilirliğini kontrol eder:
kernel.yama.ptrace_scope = 0: aynı uid'ye sahip süreçlerin hepsi hata ayıklanabilir. Bu, ptracing'in klasik çalışma şeklidir.
kernel.yama.ptrace_scope = 1: yalnızca bir üst süreç hata ayıklanabilir.
kernel.yama.ptrace_scope = 2: Yalnızca yönetici ptrace kullanabilir, çünkü CAP_SYS_PTRACE yetkisi gerektirir.
kernel.yama.ptrace_scope = 3: Hiçbir süreç ptrace ile izlenemez. Bir kez ayarlandığında, ptracing'i yeniden etkinleştirmek için bir yeniden başlatma gereklidir.
Örneğin bir FTP hizmetinin belleğine erişiminiz varsa, Heap'i alabilir ve kimlik bilgilerini içinde arayabilirsiniz.
Verilen bir işlem kimliği için haritalar, o işlemin sanal adres alanı içinde nasıl belleğe haritalandığını gösterir; ayrıca her haritalanmış bölgenin izinlerini de gösterir. Mem sahte dosyası işlemlerin belleğini kendisi açığa çıkarır. Haritalar dosyasından hangi bellek bölgelerinin okunabilir olduğunu ve ofsetlerini bildiğimizden, bu bilgiyi kullanarak mem dosyasına gitmek ve tüm okunabilir bölgeleri bir dosyaya dökmek için kullanırız.
/dev/mem
, sanal bellek değil, sistemin fiziksel belleğine erişim sağlar. Çekirdeğin sanal adres alanına /dev/kmem kullanılarak erişilebilir.
Genellikle, /dev/mem
yalnızca root ve kmem grupları tarafından okunabilir.
ProcDump, Windows için Sysinternals araç takımından klasik ProcDump aracının Linux için yeniden hayal edilmiş halidir. https://github.com/Sysinternals/ProcDump-for-Linux adresinden edinebilirsiniz.
Bir işlem belleğini dökmek için şunları kullanabilirsiniz:
https://github.com/hajzer/bash-memory-dump (kök) - _Kök gereksinimlerini manuel olarak kaldırabilir ve size ait olan işlemi dökebilirsiniz
https://www.delaat.net/rp/2016-2017/p97/report.pdf adresindeki Script A.5 (kök gereklidir)
Eğer doğrulayıcı işleminin çalıştığını bulursanız:
Prosesi dökümleyebilirsiniz (farklı yöntemleri bulmak için önceki bölümlere bakın) ve bellek içinde kimlik bilgilerini arayabilirsiniz:
Araç https://github.com/huntergregal/mimipenguin açık metin kimlik bilgilerini bellekten çalar ve bazı tanınmış dosyalardan çalar. Doğru çalışabilmesi için kök ayrıcalıklarına ihtiyaç duyar.
Özellik | İşlem Adı |
---|---|
GDM şifresi (Kali Masaüstü, Debian Masaüstü) | gdm-password |
Gnome Keyring (Ubuntu Masaüstü, ArchLinux Masaüstü) | gnome-keyring-daemon |
LightDM (Ubuntu Masaüstü) | lightdm |
VSFTPd (Aktif FTP Bağlantıları) | vsftpd |
Apache2 (Aktif HTTP Temel Kimlik Doğrulama Oturumları) | apache2 |
OpenSSH (Aktif SSH Oturumları - Sudo Kullanımı) | sshd: |
Kontrol edin eğer herhangi bir zamanlanmış işlem savunmasız ise. Belki root tarafından yürütülen bir betikten faydalanabilirsiniz (joker açığı mı? root'un kullandığı dosyaları değiştirebilir mi? sembollü bağlantıları kullanabilir mi? root'un kullandığı dizinde belirli dosyalar oluşturabilir mi?).
Örneğin, /etc/crontab dosyasının içinde PATH'i şu şekilde bulabilirsiniz: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
("user" kullanıcısının /home/user üzerinde yazma izinlerine sahip olduğuna dikkat edin)
Eğer bu crontab dosyasının içinde root kullanıcısı bir komut veya betik çalıştırmaya çalışırken yol belirtmeden deneme yaparsa. Örneğin: * * * * root overwrite.sh O zaman, bir root kabuğuna şu şekilde erişebilirsiniz:
Eğer bir betik root tarafından çalıştırılıyorsa ve komut içinde "*" karakteri varsa, bunu istenmeyen şeyler yapmak için (örneğin ayrıcalık yükseltme) kullanabilirsiniz. Örnek:
Eğer joker karakteri bir yolun önünde gelirse /bazı/yol/* şeklinde, bu zayıf değildir (hatta ./* değil).
Daha fazla joker karakteri sömürüsü hilesi için aşağıdaki sayfayı okuyun:
Wildcards Spare tricksEğer kök tarafından yürütülen bir cron betiğini değiştirebiliyorsanız, çok kolay bir şekilde bir kabuk alabilirsiniz:
Eğer root tarafından yürütülen betik, tam erişiminiz olan bir dizini kullanıyorsa, belki o klasörü silip yerine sizin kontrol ettiğiniz bir betiği hizmet eden başka bir dizine sembolik bağlantı oluşturmak faydalı olabilir.
Her 1, 2 veya 5 dakikada bir çalıştırılan işlemleri aramak için süreçleri izleyebilirsiniz. Belki bundan faydalanarak ayrıcalıkları yükseltebilirsiniz.
Örneğin, her 0.1 saniyede bir dakika boyunca izlemek için, daha az çalıştırılan komutlara göre sıralamak ve en çok çalıştırılan komutları silmek için şunu yapabilirsiniz:
Ayrıca pspy kullanabilirsiniz (bu, başlatılan her işlemi izleyip listeleyecektir).
Bir cron işi oluşturmak mümkündür bir yorumdan sonra bir satır sonu karakteri ekleyerek (newline karakteri olmadan), ve cron işi çalışacaktır. Örnek (satır sonu karakterine dikkat edin):
Herhangi bir .service
dosyasını yazabilir mi diye kontrol edin, eğer yapabilirseniz, onu değiştirebilirsiniz böylece hizmet başlatıldığında, yeniden başlatıldığında veya durdurulduğunda sizin arka kapınızı çalıştırabilir (belki makinenin yeniden başlatılmasını beklemeniz gerekebilir).
Örneğin, arka kapınızı .service dosyasının içine ExecStart=/tmp/script.sh
şeklinde oluşturun.
Hizmetler tarafından çalıştırılan ikili dosyalara yazma izniniz varsa, onları arka kapılar için değiştirebilirsiniz, böylece hizmetler yeniden çalıştırıldığında arka kapılar çalıştırılacaktır.
systemd tarafından kullanılan PATH'ı görebilirsiniz:
Eğer yolun herhangi bir klasörüne yazma izniniz olduğunu fark ederseniz, muhtemelen yetki yükseltme yapabilirsiniz. Hizmet yapılandırmalarında kullanılan göreceli yolları aramalısınız gibi dosyalar:
Sonra, yürütülebilir bir dosya oluşturun ve yazabileceğiniz systemd PATH klasöründeki ilişkili yol ikili dosyasıyla aynı ada sahip oluşturun ve hizmete bağlı eylemi yürütmesi istendiğinde, arka kapınız çalıştırılacaktır (genellikle yetkisiz kullanıcılar hizmetleri başlatamaz/durduramaz ancak sudo -l
komutunu kullanıp kullanamadığınızı kontrol edin).
Hizmetler hakkında daha fazla bilgi edinin man systemd.service
.
Zamanlayıcılar, adı **.timer**
ile biten systemd birim dosyalarıdır ve **.service**
dosyalarını veya etkinlikleri kontrol eder. Zamanlayıcılar, takvim zamanı etkinlikleri ve monotonik zaman etkinlikleri için yerleşik destek sağladıkları için cron'un alternatifi olarak kullanılabilir ve asenkron olarak çalıştırılabilir.
Tüm zamanlayıcıları şu şekilde sıralayabilirsiniz:
Bir zamanlayıcıyı değiştirebiliyorsanız, onu bir .service
veya .target
gibi systemd.unit varlıklarını çalıştırmak için kullanabilirsiniz.
Belgede Ünite'nin ne olduğunu okuyabilirsiniz:
Bu zamanlayıcı süresi dolduğunda etkinleştirilecek birim. Argüman, ".timer" olmayan bir birim adıdır. Belirtilmezse, bu değer zamanlayıcı biriminin adı hariç aynı isme sahip bir hizmete varsayılan olarak ayarlanır. (Yukarıya bakınız.) Etkinleştirilen birim adının ve zamanlayıcı biriminin birim adının, sonek hariç olmak üzere aynı şekilde adlandırılması önerilir.
Bu izni kötüye kullanmak için şunlara ihtiyacınız olacaktır:
Yazılabilir bir ikili dosya yürüten bir systemd birimi (örneğin .service
) bulun
Göreceli bir yol yürüten ve sisteminizde yazma izinleriniz olan systemd YOLU üzerinde yürütülebilir dosyayı taklit etmek için yazma izinleriniz olan bir systemd birimi bulun
Zamanlayıcılar hakkında daha fazla bilgi için man systemd.timer
komutunu kullanın.
Bir zamanlayıcıyı etkinleştirmek için kök ayrıcalıklarına ihtiyacınız vardır ve şunu yürütmeniz gerekir:
Not ⏲️ oluşturarak etkinleştirilir /etc/systemd/system/<WantedBy_section>.wants/<name>.timer
üzerine bir sembolik bağ oluşturarak.
Unix Domain Sockets (UDS), istemci-sunucu modelleri içinde aynı veya farklı makinelerde işlem iletişimini sağlar. İnter-bilgisayar iletişimi için standart Unix tanımlayıcı dosyalarını kullanır ve .socket
dosyaları aracılığıyla kurulur.
Soketler .socket
dosyaları kullanılarak yapılandırılabilir.
Soketler hakkında daha fazla bilgi edinin man systemd.socket
. Bu dosya içinde birkaç ilginç parametre yapılandırılabilir:
ListenStream
, ListenDatagram
, ListenSequentialPacket
, ListenFIFO
, ListenSpecial
, ListenNetlink
, ListenMessageQueue
, ListenUSBFunction
: Bu seçenekler farklıdır ancak bir özet, sokete nerede dinleyeceğini belirtmek için kullanılır (AF_UNIX soket dosyasının yolu, dinlemek için IPv4/6 ve/veya port numarası vb.).
Accept
: Bir boolean argüman alır. true ise, her gelen bağlantı için bir hizmet örneği başlatılır ve yalnızca bağlantı soketi ona iletilir. false ise, tüm dinleme soketleri kendileri başlatılan hizmet birimine iletilir ve tüm bağlantılar için yalnızca bir hizmet birimi başlatılır. Bu değer, tek bir hizmet biriminin tüm gelen trafiği koşulsuz olarak ele aldığı veri yuvaları ve FIFO'lar için yoksayılır. Varsayılan olarak false. Performans nedenlerinden dolayı, yeni daemon'ların yalnızca Accept=no
için uygun bir şekilde yazılması önerilir.
ExecStartPre
, ExecStartPost
: Bir veya daha fazla komut satırı alır, bunlar dinleme soketlerinden önce veya sonra yürütülür/FIFO'lar oluşturulur ve bağlanır. Komut satırının ilk belirteci mutlaka mutlak bir dosya adı olmalı, ardından işlem için argümanlar gelmelidir.
ExecStopPre
, ExecStopPost
: Dinleme soketlerinden önce veya sonra ek komutlar yürütülür/FIFO'lar kapatılır ve kaldırılır.
Service
: Gelen trafiği etkinleştirmek için hizmet birimi adını belirtir. Bu ayar yalnızca Accept=no olan soketler için izin verilir. Varsayılan olarak, aynı adı taşıyan hizmeti belirtir (soneki değiştirilmiş olarak). Çoğu durumda, bu seçeneği kullanmanın gerekli olmaması gerekir.
Eğer yazılabilir bir .socket
dosyası bulursanız, [Socket]
bölümünün başına şöyle bir şey ekleyebilirsiniz: ExecStartPre=/home/kali/sys/backdoor
ve arka kapı soket oluşturulmadan önce yürütülecektir. Bu nedenle, muhtemelen makinenin yeniden başlatılmasını beklemeniz gerekebilir.
Not: Sistem o soket dosyası yapılandırmasını kullanıyor olmalı veya arka kapı yürütülmeyecektir
Eğer herhangi bir yazılabilir soket belirlerseniz (şu anda Unix Soketleri hakkında konuşuyoruz ve .socket
dosyaları yapılandırması hakkında değil), o soketle iletişim kurabilir ve belki bir zafiyeti sömürebilirsiniz.
Sömürü örneği:
Socket Command InjectionUnutmayın ki bazı HTTP isteklerini dinleyen soketler olabilir (Ben .socket dosyalarından bahsetmiyorum, ancak unix soketleri olarak hareket eden dosyalardan bahsediyorum). Bunun kontrolünü şu şekilde yapabilirsiniz:
Docker soketi, genellikle /var/run/docker.sock
konumunda bulunan ve güvenli olması gereken kritik bir dosyadır. Varsayılan olarak, bu dosya root
kullanıcısı ve docker
grubundaki üyeler tarafından yazılabilir durumdadır. Bu sokete yazma erişiminin olması, ayrıcalık yükseltmeye yol açabilir. Bunun nasıl yapılabileceği ve Docker CLI kullanılamıyorsa alternatif yöntemler aşağıda açıklanmıştır.
Eğer Docker soketine yazma erişiminiz varsa, aşağıdaki komutları kullanarak ayrıcalıkları yükseltebilirsiniz:
Bu komutlar, ana bilgisayar dosya sisteminin kök düzey erişimine sahip bir konteyneri çalıştırmanıza olanak tanır.
Docker CLI kullanılamadığında Docker soketi, Docker API ve curl
komutları kullanılarak hala manipüle edilebilir.
Docker Görüntülerini Listeleme: Mevcut görüntülerin listesini alın.
Bir Konteyner Oluşturma: Ana sistem kök dizinini bağlayan bir konteyner oluşturmak için bir istek gönderin.
Yeni oluşturulan konteyneri başlatın:
Konteynere Bağlanma: socat
kullanarak bir bağlantı kurarak, içinde komut yürütme imkanı sağlayan bir bağlantı oluşturun.
socat
bağlantısını kurduktan sonra, ana bilgisayar dosya sisteminin kök düzey erişimine sahip olarak konteynerde doğrudan komutlar yürütebilirsiniz.
Docker soketi üzerinde yazma izinleriniz varsa çünkü docker
grubu içindesiniz, ayrıcalıkları yükseltmek için daha fazla yolunuz olabilir. Docker API'nin bir portta dinlediği durumda, bunu tehlikeye atabilirsiniz.
Docker'dan kaçmak veya ayrıcalıkları yükseltmek için daha fazla yolunuzu kırmak için kontrol edin:
Docker SecurityEğer ctr
komutunu kullanabildiğinizi fark ederseniz, ayrıcalıkları yükseltmek için bunu kötüye kullanabilirsiniz:
Eğer runc
komutunu kullanabildiğinizi fark ederseniz, ayrıcalıkları yükseltmek için bunu kötüye kullanabilirsiniz:
D-Bus, uygulamaların etkili bir şekilde etkileşimde bulunmasını ve veri paylaşmasını sağlayan sofistike bir İşlem Arası İletişim (IPC) sistemidir. Modern Linux sistemi göz önünde bulundurularak tasarlanmış olup, farklı uygulama iletişim biçimleri için sağlam bir çerçeve sunar.
Sistem, işlem arası iletişimi geliştiren temel IPC'yi destekler ve veri alışverişini artırır, gelişmiş UNIX etki alanı soketlerini hatırlatır. Ayrıca olayları veya sinyalleri yayınlamaya yardımcı olur, sistem bileşenleri arasında sorunsuz entegrasyonu teşvik eder. Örneğin, bir Bluetooth hizmetinden gelen bir arama sinyali, bir müzik çaların sessizleşmesine neden olabilir, kullanıcı deneyimini artırır. Ayrıca, D-Bus, hizmet isteklerini ve yöntem çağrılarını basitleştiren bir uzak nesne sistemi destekler, geleneksel olarak karmaşık olan süreçleri basitleştirir.
D-Bus, mesaj izinlerini (yöntem çağrıları, sinyal yayınları vb.) eşleşen politika kurallarının kümülatif etkisine dayanarak yöneten bir izin/izin verme modeli üzerinde çalışır. Bu politikalar, otobüsle etkileşimleri yönetir ve bu izinlerin sömürülmesi yoluyla ayrıcalık yükseltmesine olanak tanır.
Örneğin, /etc/dbus-1/system.d/wpa_supplicant.conf
dosyasındaki bir politika, kök kullanıcısının fi.w1.wpa_supplicant1
'e ait mesajları sahiplenme, gönderme ve almasına ilişkin izinleri detaylandırır.
Belirli bir kullanıcı veya grup belirtilmeyen politikalar evrensel olarak uygulanırken, "varsayılan" bağlam politikaları, diğer belirli politikalarla kapsanmayan tüm uygulamalar için geçerlidir.
D-Bus iletişimini nasıl sıralayıp istismar edeceğinizi öğrenin:
D-Bus Enumeration & Command Injection Privilege EscalationMakinenin konumunu belirlemek için ağın sıralanması her zaman ilginçtir.
Her zaman, erişmeden önce etkileşimde bulunamadığınız makinede çalışan ağ hizmetlerini kontrol edin:
Trafik dinleyebildiğinizi kontrol edin. Eğer yapabiliyorsanız, bazı kimlik bilgilerini ele geçirebilirsiniz.
Kendinizin kim olduğunu, hangi ayrıcalıklara sahip olduğunuzu, sistemlerde hangi kullanıcıların bulunduğunu, hangilerinin giriş yapabileceğini ve hangilerinin kök ayrıcalıklarına sahip olduğunu kontrol edin:
Bazı Linux sürümleri, UID > INT_MAX olan kullanıcıların ayrıcalıklarını yükseltmelerine izin veren bir hata ile etkilenmiştir. Daha fazla bilgi için: buraya, buraya ve buraya.
Exploit etmek için: systemd-run -t /bin/bash
Kök ayrıcalıklarını size verebilecek bazı grup üyesi olup olmadığını kontrol edin:
Interesting Groups - Linux PrivescPanoda ilginç bir şey olup olmadığını kontrol edin (mümkünse)
Eğer ortamın herhangi bir şifresini biliyorsanız, her bir kullanıcı olarak giriş yapmaya çalışın.
Eğer çok fazla gürültüye neden olmaktan çekinmiyorsanız ve bilgisayarda su
ve timeout
ikilisi bulunuyorsa, su-bruteforce kullanarak kullanıcıyı brute-force deneyebilirsiniz.
Linpeas, -a
parametresi ile kullanıcıları brute-force denemeye çalışır.
Eğer $PATH'in içindeki bazı klasörlere yazabileceğinizi fark ederseniz, yazılabilir klasörün içine geri kapı oluşturarak ayrı bir kullanıcı (genellikle root) tarafından çalıştırılacak bazı komutların adını taşıyan bir geri kapı oluşturarak ayrıcalıkları yükseltebilirsiniz ve bu komutun $PATH içindeki yazılabilir klasörünüzden önce yer almayan bir klasörden yüklenmediğinden emin olabilirsiniz.
Bazı komutları sudo kullanarak veya suid bitine sahip olabilirsiniz. Bunu kontrol etmek için:
Bazı beklenmeyen komutlar dosyaları okumanıza ve/veya yazmanıza hatta komut çalıştırmanıza olanak tanır. Örneğin:
Sudo yapılandırması, bir kullanıcının şifreyi bilmeden başka bir kullanıcının ayrıcalıklarıyla bazı komutları çalıştırmasına izin verebilir.
Bu örnekte, demo
kullanıcısı root
olarak vim
çalıştırabilir, şimdi bir ssh anahtarı ekleyerek veya sh
çağırarak kabuk almak çok kolaydır.
Bu yönerge, bir şeyi yürütürken bir çevre değişkeni ayarlamayı kullanıcıya olanak tanır:
Bu örnek, HTB makinesi Admirer'a dayanarak, betiği kök olarak çalıştırırken keyfi bir python kütüphanesini yüklemek için PYTHONPATH yönlendirmesine karşı savunmasızdı:
Diğer dosyaları okumak veya sembolik bağlantıları kullanmak için atla. Örneğin sudoers dosyasında: hacker10 ALL= (root) /bin/less /var/log/*
Eğer bir joker karakter (*) kullanılıyorsa, işlem daha da kolaylaşır:
Karşı önlemler: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/
Eğer sudo izni bir komuta yol belirtilmeden verilmişse: hacker10 ALL= (root) less PATH değiştirilerek bunu sömürülebilirsiniz.
Bu teknik ayrıca bir suid ikili dosyasının yolunu belirtmeden başka bir komutu çalıştırması durumunda da kullanılabilir (her zaman garip bir SUID ikilisinin içeriğini strings ile kontrol edin).
Eğer suid ikili dosyası yolu belirterek başka bir komut çalıştırıyorsa, o zaman, suid dosyanın çağırdığı komut adında bir fonksiyon ihraç etmeyi deneyebilirsiniz.
Örneğin, bir suid ikili dosya /usr/sbin/service apache2 start komutunu çağırıyorsa, bu fonksiyonu oluşturup ihraç etmeyi denemelisiniz:
LD_PRELOAD çevresel değişkeni, yükleyicinin diğer tüm kütüphanelerden önce, özellikle libc.so
gibi standart C kütüphanesinden önce yüklenmesi gereken bir veya daha fazla paylaşılan kütüphane (.so dosyaları) belirtmek için kullanılır. Bu işlem, bir kütüphanenin önceden yüklenmesi olarak bilinir.
Ancak, sistem güvenliğini korumak ve özellikle suid/sgid yürütülebilir dosyalarla bu özelliğin kötüye kullanılmasını önlemek için sistem belirli koşulları zorlar:
Yükleyici, gerçek kullanıcı kimliği (ruid) etkin kullanıcı kimliği (euid) ile eşleşmeyen yürütülebilir dosyalarda LD_PRELOAD'u yok sayar.
Suid/sgid'li yürütülebilir dosyalar için, yalnızca standart yollardaki ve aynı zamanda suid/sgid olan kütüphaneler önceden yüklenir.
Ayrıcalık yükseltmesi, sudo
ile komutları yürütme yeteneğine sahipseniz ve sudo -l
çıktısı env_keep+=LD_PRELOAD ifadesini içeriyorsa meydana gelebilir. Bu yapılandırma, LD_PRELOAD çevresel değişkeninin kalıcı olmasına ve sudo
ile komutlar çalıştırıldığında tanınmasına izin verir, bu da potansiyel olarak yükseltilmiş ayrıcalıklarla keyfi kodun yürütülmesine yol açabilir.
Kaydet as /tmp/pe.c
Ardından şunu kullanarak derleyin:
Son olarak, izinleri yükseltin çalıştırarak.
Benzer bir ayrıcalık yükseltme saldırısı, saldırganın kütüphanelerin aranacağı yolunu kontrol ettiği için LD_LIBRARY_PATH çevresel değişkenini kontrol ediyorsa istismar edilebilir.
Eğer normalden farklı görünen SUID izinlerine sahip bir ikili dosya ile karşılaşılırsa, bu dosyanın .so dosyalarını düzgün bir şekilde yükleyip yüklemediğini doğrulamak iyi bir uygulamadır. Bu kontrol aşağıdaki komut çalıştırılarak yapılabilir:
Örneğin, "open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)" gibi bir hata ile karşılaşmak, sömürü potansiyeli olduğunu düşündürür.
Bunu sömürmek için, aşağıdaki kodu içeren bir C dosyası oluşturarak devam edilir, diyelim ki "/path/to/.config/libcalc.c":
Bu kod, derlendikten ve çalıştırıldıktan sonra dosya izinlerini manipüle ederek ayrıcalıkları yükseltmeyi ve yükseltilmiş ayrıcalıklarla bir kabuk çalıştırmayı amaçlar.
Yukarıdaki C dosyasını paylaşılan nesne (.so) dosyasına derlemek için:
Son olarak, etkilenen SUID ikili dosyasını çalıştırmak, potansiyel sistem tehlikesine yol açacak olan saldırıyı tetiklemelidir.
Şimdi yazma iznimizin olduğu bir klasörden bir kütüphane yükleyen bir SUID ikili bulduğumuza göre, o klasörde gerekli isme sahip kütüphaneyi oluşturalım:
Eğer şu gibi bir hata alırsanız:
Bu, oluşturduğunuz kütüphanenin a_function_name
adında bir işlev içermesi gerektiği anlamına gelir.
GTFOBins, bir saldırganın yerel güvenlik kısıtlamalarını atlamak için kullanabileceği Unix ikililerinin derlenmiş bir listesidir. GTFOArgs, yalnızca bir komuta argüman enjekte edebileceğiniz durumlar için aynı işlevi görür.
Proje, kısıtlanmış kabuklardan kaçınmak, ayrıcalıkları yükseltmek veya sürdürmek, dosyaları transfer etmek, bağlama ve ters kabuklar oluşturmak ve diğer son aşama saldırı görevlerini kolaylaştırmak için Unix ikililerinin meşru işlevlerini toplar.
gdb -nx -ex '!sh' -ex quit sudo mysql -e '! /bin/sh' strace -o /dev/null /bin/sh sudo awk 'BEGIN {system("/bin/sh")}'
sudo -l
'ye erişebiliyorsanız, FallOfSudo aracını kullanarak herhangi bir sudo kuralını nasıl sömürüleceğini kontrol edebilirsiniz.
Sudo erişiminiz var ancak şifreniz yoksa, bir sudo komutu yürütülmesini bekleyerek ve ardından oturum belirtecinin ele geçirilmesiyle ayrıcalıkları yükseltebilirsiniz.
Ayrıcalıkları yükseltmek için gereksinimler:
Zaten "sampleuser" kullanıcısı olarak bir kabuğunuz var
"sampleuser"'ın son 15 dakika içinde sudo
kullanmış olması (varsayılan olarak, şifre gerektirmeden sudo
kullanmamıza izin veren sudo belirtecinin süresi budur)
cat /proc/sys/kernel/yama/ptrace_scope
değeri 0 olmalı
gdb
erişilebilir olmalı (yükleme yapabilmelisiniz)
(Bu gereksinimlerin tümü karşılanıyorsa, aşağıdaki kullanarak ayrıcalıkları yükseltebilirsiniz: https://github.com/nongiach/sudo_inject
İlk saldırı (exploit.sh
), activate_sudo_token
adlı ikili dosyayı /tmp/ dizininde oluşturacaktır. Bu dosyayı kullanarak oturumunuzda sudo belirtecini etkinleştirebilirsiniz (otomatik olarak kök kabuğa erişmeyeceksiniz, sudo su
komutunu kullanın):
İkinci saldırı (exploit_v2.sh
) /tmp dizininde root'a ait setuid ile bir sh kabuğu oluşturacaktır.
Üçüncü saldırı (exploit_v3.sh
) sudoers dosyası oluşturacak ve sudo belgelerini sonsuz hale getirerek tüm kullanıcıların sudo kullanmasına izin verecek.
Eğer klasörde veya klasör içinde oluşturulan dosyalardan herhangi birinde yazma izinleriniz varsa, write_sudo_token adlı ikili dosyayı kullanarak bir kullanıcı ve PID için sudo belirteci oluşturabilirsiniz. Örneğin, /var/run/sudo/ts/örnekkullanıcı dosyasını üzerine yazabilir ve PID'si 1234 olan o kullanıcı olarak bir kabuk elde ettiyseniz, şifreyi bilmeden sudo ayrıcalıklarını elde edebilirsiniz.
Dosya /etc/sudoers
ve /etc/sudoers.d
içindeki dosyalar, kimin sudo
kullanabileceğini ve nasıl kullanabileceğini yapılandırır. Bu dosyalar varsayılan olarak yalnızca root kullanıcısı ve root grubu tarafından okunabilir.
Eğer bu dosyayı okuyabiliyorsanız, bazı ilginç bilgilere erişebilirsiniz, ve eğer herhangi bir dosyayı yazabilirseniz, ayrıcalıkları yükseltebilirsiniz.
Eğer yazabilirseniz, bu izni kötüye kullanabilirsiniz.
Başka bir yol bu izinleri kötüye kullanmaktır:
sudo
binary için doas
gibi bazı alternatifler vardır OpenBSD için, yapılandırmasını kontrol etmeyi unutmayın /etc/doas.conf
Eğer bir kullanıcının genellikle bir makineye bağlandığını ve ayrıcalıkları yükseltmek için sudo
kullandığını biliyorsanız ve bu kullanıcının bağlamında bir kabuk elde ettiyseniz, kök olarak kodunuzu çalıştıracak yeni bir sudo yürütülebilir dosya oluşturabilirsiniz ve ardından kullanıcının komutunu çalıştırabilirsiniz. Sonra, kullanıcı bağlamının $PATH'ini değiştirin (örneğin, yeni yolu .bash_profile içine ekleyin), böylece kullanıcı sudo komutunu çalıştırdığında, sizin sudo yürütülebilir dosyanız çalıştırılır.
Kullanıcının farklı bir kabuk kullandığını (bash değil) biliyorsanız, yeni yolu eklemek için diğer dosyaları değiştirmeniz gerekecektir. Örneğin sudo-piggyback ~/.bashrc
, ~/.zshrc
, ~/.bash_profile
dosyalarını değiştirir. Başka bir örnek için bashdoor.py adresine bakabilirsiniz.
Veya şunu çalıştırarak:
/etc/ld.so.conf
dosyası, yüklü yapılandırma dosyalarının nereden geldiğini gösterir. Genellikle, bu dosya aşağıdaki yolu içerir: include /etc/ld.so.conf.d/*.conf
Bu, /etc/ld.so.conf.d/*.conf
yolundaki yapılandırma dosyalarının okunacağı anlamına gelir. Bu yapılandırma dosyaları, kütüphanelerin aranacağı diğer klasörlere işaret eder. Örneğin, /etc/ld.so.conf.d/libc.conf
dosyasının içeriği /usr/local/lib
şeklindedir. Bu, sistemin kütüphaneleri /usr/local/lib
klasörü içinde arayacağı anlamına gelir.
Eğer bir kullanıcının herhangi bir nedenden dolayı yazma izinleri varsa: /etc/ld.so.conf
, /etc/ld.so.conf.d/
, /etc/ld.so.conf.d/
içindeki herhangi bir dosya veya /etc/ld.so.conf.d/*.conf
içindeki yapılandırma dosyasındaki herhangi bir klasör, o zaman ayrıcalıkları yükseltebilir.
Bu yanlış yapılandırmayı nasıl sömürüleceğine aşağıdaki sayfada bakın:
lib
dosyasını /var/tmp/flag15/
dizinine kopyalayarak, programın bu konumda belirtilen RPATH
değişkeni tarafından kullanılacaktır.
Daha sonra /var/tmp
dizininde gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6
komutunu kullanarak kötü niyetli bir kütüphane oluşturun.
Linux yetenekleri, bir işleme mevcut kök ayrıcalıklarının bir alt kümesini sağlar. Bu, kök ayrıcalıklarını daha küçük ve ayırt edici birimlere böler. Bu birimlerden her biri daha sonra işlemlere bağımsız olarak verilebilir. Bu şekilde ayrıcalıkların tam seti azaltılarak, sömürü riskleri azaltılır. Yetenekler hakkında daha fazla bilgi edinmek için aşağıdaki sayfayı okuyun:
Linux CapabilitiesBir dizinde "çalıştır" biti, etkilenen kullanıcının klasöre "cd" yapabileceği anlamına gelir. "Okuma" biti, kullanıcının dosyaları listeleyebileceği anlamına gelir ve "yazma" biti, kullanıcının dosyaları silebileceği ve yeni dosyalar oluşturabileceği anlamına gelir.
Erişim Kontrol Listeleri (ACL'ler), geleneksel ugo/rwx izinlerini geçersiz kılabilen ikincil bir ayrıcalık katmanını temsil eder. Bu izinler, dosya veya dizin erişimini denetlemeyi geliştirir, belirli kullanıcılara belirli hakları vererek veya reddederek grup sahipleri veya grup üyeleri olmayan kullanıcılara. Bu ayrıntılı erişim yönetimi seviyesi, daha hassas erişim yönetimini sağlar. Daha fazla ayrıntıya buradan ulaşılabilir.
Kullanıcı "kali"ye bir dosya üzerinde okuma ve yazma izinleri verin:
Sistemden belirli ACL'ye sahip dosyaları alın:
Eski sürümlerde, farklı bir kullanıcının (root) bazı kabuk oturumlarını ele geçirebilirsiniz. En yeni sürümlerde, yalnızca kendi kullanıcı oturumlarınıza bağlanabileceksiniz. Bununla birlikte, oturum içinde ilginç bilgiler bulabilirsiniz.
Ekran oturumlarını listeleme
Bir oturuma bağlanın
Bu, eski tmux sürümleri ile ilgili bir sorundu. Root tarafından oluşturulan bir tmux (v2.1) oturumunu ayrıcalıklı olmayan bir kullanıcı olarak ele geçiremedim.
Tmux oturumlarını listeleme
Bir oturuma bağlanın
HTB'den Valentine kutusunu bir örnek için kontrol edin.
Tüm Debian tabanlı sistemlerde (Ubuntu, Kubuntu, vb.) Eylül 2006 ile 13 Mayıs 2008 arasında oluşturulan SSL ve SSH anahtarları bu hatadan etkilenebilir. Bu hata, bu işletim sistemlerinde yeni bir ssh anahtarı oluşturulduğunda ortaya çıkar, çünkü yalnızca 32,768 varyasyon mümkündü. Bu, tüm olasılıkların hesaplanabileceği anlamına gelir ve ssh genel anahtarı olan kişi, karşılık gelen özel anahtarı arayabilir. Hesaplanmış olasılıkları burada bulabilirsiniz: https://github.com/g0tmi1k/debian-ssh
PasswordAuthentication: Parola kimlik doğrulamasının izin verilip verilmediğini belirtir. Varsayılan no
'dur.
PubkeyAuthentication: Genel anahtar kimlik doğrulamasının izin verilip verilmediğini belirtir. Varsayılan yes
'tir.
PermitEmptyPasswords: Parola kimlik doğrulamasına izin verildiğinde, sunucunun boş parola dizelerine sahip hesaplara giriş yapmasına izin verip vermediğini belirtir. Varsayılan no
'dur.
Root'un ssh kullanarak giriş yapmasına izin verilip verilmediğini belirtir, varsayılan no
'dur. Olası değerler:
yes
: root, parola ve özel anahtar kullanarak giriş yapabilir
without-password
veya prohibit-password
: root, yalnızca özel anahtarla giriş yapabilir
forced-commands-only
: Root, yalnızca özel anahtar kullanarak ve komut seçenekleri belirtildiğinde giriş yapabilir
no
: hayır
Kullanıcı kimlik doğrulaması için kullanılabilecek genel anahtarları içeren dosyaları belirtir. %h
gibi belirteçler içerebilir, bu belirteçler ev dizini tarafından değiştirilecektir. Mutlak yolları (başlangıç /
) veya kullanıcının evinden başlayan göreceli yolları belirtebilirsiniz. Örneğin:
O yapılandırma, "testkullanıcıadı" kullanıcısının özel anahtarı ile giriş yapmaya çalışırsanız, ssh'nin anahtarınızın genel anahtarıyla /home/testkullanıcıadı/.ssh/authorized_keys
ve /home/testkullanıcıadı/erişim
konumlarındaki anahtarları karşılaştıracağını belirtecektir.
SSH ajan yönlendirmesi, sunucunuzda (şifresiz!) anahtarları bırakmak yerine yerel SSH anahtarlarınızı kullanmanıza olanak tanır. Bu sayede, ssh üzerinden bir ana makineye ve oradan da başka bir ana makinaya atlayabilirsiniz ve bu sırada ilk ana makinedeki anahtarı kullanabilirsiniz.
Bu seçeneği $HOME/.ssh.config
dosyasında şu şekilde ayarlamanız gerekmektedir:
Eğer Host
*
ise, her seferinde kullanıcı farklı bir makineye geçtiğinde, o makine anahtarlarına erişebilecektir (bu bir güvenlik sorunudur).
/etc/ssh_config
dosyası bu seçenekleri geçersiz kılabilir ve bu yapılandırmayı izin verebilir veya reddedebilir.
/etc/sshd_config
dosyası AllowAgentForwarding
anahtar kelimesi ile ssh-agent yönlendirmesine izin verebilir veya reddedebilir (varsayılan olarak izin verilir).
Eğer bir ortamda Forward Agent yapılandırıldığını fark ederseniz, yetkileri yükseltmek için bunu kötüye kullanabilirsiniz:
SSH Forward Agent exploitation/etc/profile
dosyası ve /etc/profile.d/
altındaki dosyalar, bir kullanıcı yeni bir kabuk çalıştırdığında yürütülen betiklerdir. Dolayısıyla, bunlardan herhangi birini yazabilir veya değiştirebilirseniz yetkileri yükseltebilirsiniz.
Eğer herhangi bir garip profil betiği bulunursa, onu duyarlı detaylar açısından kontrol etmelisiniz.
İşletim sistemine bağlı olarak /etc/passwd
ve /etc/shadow
dosyalarının farklı bir isim kullanıyor olabileceği veya bir yedek kopya olabileceği unutulmamalıdır. Bu nedenle hepsini bulmanız ve içerisinde hash'lerin olup olmadığını görmek için onları okuyup okuyamadığınızı kontrol etmeniz önerilir:
Bazı durumlarda, /etc/passwd
(veya eşdeğeri) dosyası içinde şifre karmaları bulabilirsiniz.
İlk olarak, aşağıdaki komutlardan biri ile bir şifre oluşturun.
Ardından kullanıcı hacker
ekleyin ve oluşturulan şifreyi ekleyin.
Örn: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash
Artık hacker:hacker
kullanarak su
komutunu kullanabilirsiniz.
Alternatif olarak, şu satırları kullanarak şifresiz bir sahte kullanıcı ekleyebilirsiniz. UYARI: Makinenin mevcut güvenliğini düşürebilirsiniz.
NOT: BSD platformlarında /etc/passwd
dosyası /etc/pwd.db
ve /etc/master.passwd
konumunda bulunur, ayrıca /etc/shadow
dosyası /etc/spwd.db
olarak yeniden adlandırılmıştır.
Bazı duyarlı dosyalara yazabilir mi kontrol etmelisiniz. Örneğin, bazı hizmet yapılandırma dosyalarına yazabilir misiniz?
Örneğin, makine tomcat sunucusunu çalıştırıyorsa ve /etc/systemd/ içindeki Tomcat servis yapılandırma dosyasını değiştirebiliyorsanız, o zaman şu satırları değiştirebilirsiniz:
Aşağıdaki klasörler yedeklemeler veya ilginç bilgiler içerebilir: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Muhtemelen sonuncusunu okuyamayacaksınız ama deneyin)
linPEAS kodunu okuyun, şifre içerebilecek çeşitli dosyaları arar. Bunu yapmak için kullanabileceğiniz başka ilginç bir araç ise: LaZagne Windows, Linux ve Mac'te saklanan birçok şifreyi almak için kullanılan açık kaynaklı bir uygulamadır.
Kayıtları okuyabiliyorsanız, içlerinde ilginç/gizli bilgiler bulabilirsiniz. Kayıt ne kadar garipse, o kadar ilginç olacaktır (muhtemelen). Ayrıca, bazı "kötü" yapılandırılmış (arka kapılı?) denetim kayıtları, size denetim kayıtlarının içine şifre kaydetmenize izin verebilir. Bu konuyla ilgili olarak şu yazıda açıklandığı gibi: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.
Günlükleri okumak için adm grubu gerçekten yardımcı olacaktır.
Ayrıca, adında "password" kelimesini içeren dosyaları ve içeriğinde de bu kelimeyi içeren dosyaları kontrol etmelisiniz, ayrıca log dosyalarında IP'leri ve e-postaları veya hash'leri regexlerle kontrol etmelisiniz. Bunların hepsini nasıl yapacağını burada listeleyeceğim, ancak ilgileniyorsanız linpeas tarafından gerçekleştirilen son kontrolleri kontrol edebilirsiniz.
Eğer bir python betiğinin nereden çalıştırılacağını biliyorsanız ve o klasöre yazabilirsiniz veya python kütüphanelerini değiştirebilirseniz, işletim sistemi kütüphanesini değiştirip arkasına kötü amaçlı yazılım ekleyebilirsiniz (python betiğinin çalıştırılacağı yere yazabilirseniz, os.py kütüphanesini kopyalayıp yapıştırın).
Kütüphaneye kötü amaçlı yazılım eklemek için sadece os.py kütüphanesinin sonuna aşağıdaki satırı ekleyin (IP ve PORT'u değiştirin):
logrotate
'daki bir zafiyet, bir günlük dosyasında veya üst dizinlerinde yazma izinlerine sahip olan kullanıcıların ayrıcalıklarını yükseltebilmelerine olanak tanır. Bu, genellikle root olarak çalışan logrotate
'un, özellikle /etc/bash_completion.d/ gibi dizinlerde keyfi dosyaları çalıştırmak üzere manipüle edilebileceği anlamına gelir. İzinleri sadece /var/log dizininde değil, aynı zamanda günlük döndürmenin uygulandığı herhangi bir dizinde kontrol etmek önemlidir.
Bu zafiyet, logrotate
sürümü 3.18.0
ve daha eski sürümleri etkiler.
Bu zafiyet hakkında daha detaylı bilgiye şu sayfada ulaşabilirsiniz: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.
Bu zafiyeti logrotten ile sömürebilirsiniz.
Bu zafiyet, CVE-2016-1247 (nginx günlükleri) ile çok benzerdir, bu yüzden günlükleri değiştirebileceğinizi fark ettiğinizde, günlükleri kimin yönettiğini kontrol edin ve simgelerle günlükleri değiştirerek ayrıcalıkları yükseltebileceğinizi kontrol edin.
Zafiyet referansı: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
Herhangi bir nedenden dolayı bir kullanıcı /etc/sysconfig/network-scripts dizinine bir ifcf-<neolursa>
betiği yazabilirse veya var olan bir betiği ayarlayabilirse, o zaman sisteminiz ele geçirilmiştir.
Ağ betikleri, örneğin ifcg-eth0, ağ bağlantıları için kullanılır. Tam olarak .INI dosyalarına benzerler. Ancak, Linux'ta Network Manager (dispatcher.d) tarafından ~kaynaklanır~.
Benim durumumda, bu ağ betiklerindeki NAME=
özniteliği doğru bir şekilde işlenmiyor. Eğer isimde boşluk varsa, sistem boşluktan sonraki kısmı çalıştırmaya çalışır. Bu, ilk boşluktan sonraki her şeyin root olarak çalıştırıldığı anlamına gelir.
Örneğin: /etc/sysconfig/network-scripts/ifcfg-1337
/etc/init.d
dizini, Sistem V init (SysVinit) için betikleri içerir, klasik Linux hizmet yönetim sistemi. Hizmetleri başlatmak
, durdurmak
, yeniden başlatmak
ve bazen yeniden yüklemek
için betikler içerir. Bu betikler doğrudan yürütülebilir veya /etc/rc?.d/
dizininde bulunan sembolik bağlantılar aracılığıyla yürütülebilir. Redhat sistemlerinde alternatif bir yol ise /etc/rc.d/init.d
dizinidir.
Öte yandan, /etc/init
Upstart ile ilişkilidir, Ubuntu tarafından tanıtılan daha yeni bir hizmet yönetimi kullanarak hizmet yönetimi görevleri için yapılandırma dosyaları kullanır. Upstart'e geçişe rağmen, Upstart yapılandırmalarıyla birlikte SysVinit betikleri hala kullanılmaktadır çünkü Upstart'te bir uyumluluk katmanı bulunmaktadır.
systemd, modern bir başlatma ve hizmet yöneticisi olarak ortaya çıkar, ihtiyaç duyulan daemon başlatma, otomatik bağlama yönetimi ve sistem durumu anlık görüntüleme gibi gelişmiş özellikler sunar. Dağıtım paketleri için dosyaları /usr/lib/systemd/
ve yönetici değişiklikleri için /etc/systemd/system/
dizinlerine düzenler, sistem yönetimi sürecini kolaylaştırır.
Statik impacket ikili dosyaları
LinEnum: https://github.com/rebootuser/LinEnum(-t seçeneği) Enumy: https://github.com/luke-goddard/enumy Unix Privesc Check: http://pentestmonkey.net/tools/audit/unix-privesc-check Linux Priv Checker: www.securitysift.com/download/linuxprivchecker.py BeeRoot: https://github.com/AlessandroZ/BeRoot/tree/master/Linux Kernelpop: Linux ve MAC'te çekirdek zafiyetlerini sıralar https://github.com/spencerdodd/kernelpop Mestaploit: multi/recon/local_exploit_suggester Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester EvilAbigail (fiziksel erişim): https://github.com/GDSSecurity/EvilAbigail Daha fazla betik derlemesi: https://github.com/1N3/PrivEsc
AWS Hacking öğrenin ve uygulayın:HackTricks Eğitim AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve uygulayın: HackTricks Eğitim GCP Red Team Expert (GRTE)