<summary><strong>Sıfırdan kahraman olmaya kadar AWS hackleme öğrenin</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Kırmızı Takım Uzmanı)</strong></a><strong>!</strong></summary>
* **Şirketinizi HackTricks'te reklam görmek istiyorsanız** veya **HackTricks'i PDF olarak indirmek istiyorsanız** [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* [**The PEASS Ailesi'ni**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* **Katılın** 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** takip edin.**
* **Hacking püf noktalarınızı paylaşarak PR göndererek HackTricks** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına katkıda bulunun.
İyi bir zayıf çekirdek listesi ve bazı zaten derlenmiş **saldırılar** burada bulunabilir: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) ve [exploitdb sploits](https://github.com/offensive-security/exploitdb-bin-sploits/tree/master/bin-sploits).\
Bazı**derlenmiş saldırıları** bulabileceğiniz diğer siteler: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack)
[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (sadece kurban üzerinde çalıştırılmalı, yalnızca kernel 2.x için exploit'leri kontrol eder)
Her zaman **Google'da kernel sürümünü arayın**, belki kernel sürümünüz bazı kernel exploit'lerinde yazılıdır ve bu sayede bu exploit'in geçerli olduğundan emin olabilirsiniz.
**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ış güvenlik politikalarını güçlendirmek için tasarlanmıştır. SElinux, dosya izinleri ve ağ bağlantıları gibi sistem kaynaklarına erişimi kontrol etmek için zorlayıcı bir politika uygular. Bu, kötü amaçlı yazılımların ve saldırganların sistem üzerindeki etkisini sınırlamaya yardımcı olabilir.
ASLR (Adres Alanı Rastgele Konumlandırma), bir saldırganın hedef sisteme saldırı düzenlemesini zorlaştırmak için kullanılan bir güvenlik önlemidir. ASLR, bellek bölgelerinin rastgele konumlandırılmasını sağlayarak saldırganların hedeflenen bellek adreslerini tahmin etmesini zorlaştırır. Bu, saldırıların etkisini azaltmaya yardımcı olabilir.
**Nelerin 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.
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.
_Bu komutlar genellikle gereksiz bilgileri gösterecektir, bu nedenle kurulu 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 mi?)
Her zaman çalışan olası**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.\
[**pspy**](https://github.com/DominicBreuker/pspy) gibi araçları kullanarak süreçleri izleyebilirsiniz. Bu, sık çağrılan zayıf süreçleri veya belirli gereksinimlerin karşılandığı durumları tespit etmek için çok yararlı olabilir.
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ı olduğunuzda ve daha fazla kimlik bilgisi keşfetmek istediğinizde daha kullanışlı olacaktır.\
Günümüzde çoğu makinenin **varsayılan olarak ptrace izin vermediğini** unutmayın, bu da kendi ayrıcalıksız kullanıcınıza ait diğer süreçleri dump edemeyeceğiniz anlamına gelir.
* **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.
Verilen bir işlem kimliği için **haritalar, belleğin o işlemin** sanal adres alanı içinde nasıl eşlendiğini gösterir; aynı zamanda **her eşlenmiş bölgenin izinlerini** de gösterir. **Mem** yalancı dosyası**işlemlerin belleğini kendisi açığa çıkarır**. **Haritalar** dosyasından hangi **bellek bölgelerinin okunabilir** olduğunu ve konumlarını öğreniriz. Bu bilgileri kullanarak **mem dosyasına gitmek ve tüm okunabilir bölgeleri bir dosyaya dökmek** için kullanırız.
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](https://github.com/Sysinternals/ProcDump-for-Linux) adresinden edinebilirsiniz.
Copyright (C) 2020 Microsoft Corporation. All rights reserved. Licensed under the MIT license.
Mark Russinovich, Mario Hewardt, John Salem, Javid Habibi
Monitors a process and writes a dump file when the process meets the
specified criteria.
Process: sleep (1714)
CPU Threshold: n/a
Commit Threshold: n/a
Thread Threshold: n/a
File descriptor Threshold: n/a
Signal: n/a
Polling interval (ms): 1000
Threshold (s): 10
Number of Dumps: 1
Output directory for core dumps: .
Press Ctrl-C to end monitoring without terminating the process.
[20:20:58 - WARN]: Procdump not running with elevated credentials. If your uid does not match the uid of the target process procdump will not be able to capture memory dumps
* [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Kök gereksinimlerini manuel olarak kaldırabilir ve size ait olan işlemi dökebilirsiniz
Araç [**https://github.com/huntergregal/mimipenguin**](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.
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? semboller kullanabilir mi? root'un kullandığı dizinde belirli dosyalar oluşturabilir mi?).
Örneğin, _/etc/crontab_ dosyası içinde PATH'i şu şekilde bulabilirsiniz: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_
Bu crontab dosyası içinde root kullanıcısı bir komut veya betik çalıştırmaya çalışırken yol belirtmeden denemesi durumunda. Örneğin: _\* \* \* \* root overwrite.sh_\
Eğer bir betik kök kullanıcısı 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 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:
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 **durduğunda** (belki makinenin yeniden başlatılmasını beklemeniz gerekebilir) **arka kapınızı çalıştırabilirsiniz**.\
Örneğin, arka kapınızı .service dosyasının içine **`ExecStart=/tmp/script.sh`** şeklinde oluşturun.
Unutmayın ki eğer hizmetler tarafından **yürütülen ikili dosyalara yazma izniniz varsa**, onları arka kapılar için değiştirebilirsiniz, böylece hizmetler yeniden yürütüldüğünde arka kapılar da yürütülecektir.
Eğer yolun herhangi bir klasörüne **yazma** izniniz olduğunu fark ederseniz, muhtemelen **yetki yükseltme** yapabilirsiniz. Servis yapılandırma dosyalarında kullanılan **göreceli yolları** aramanız gerekebilir:
Ardından, **yürütülebilir** bir dosya oluşturun ve yazabileceğiniz systemd PATH klasöründeki **göreceli yol ikili dosya ile aynı isme sahip** olacak şekilde, hizmetin **Başlat, Durdur, Yeniden Yükle** gibi zafiyetli eylemi gerçekleştirmesi istendiğinde, **arka kapınız çalıştırılacak** (genellikle yetkisiz kullanıcılar hizmetleri başlatıp durduramaz ancak `sudo -l` komutunu kullanıp kullanamadığınızı kontrol edin).
**Zamanlayıcılar**, adı`**.timer**` ile biten systemd birim dosyalarıdır ve `**.service**` dosyalarını veya olayları kontrol eder. **Zamanlayıcılar**, takvim zaman olayları ve monotonik zaman olayları için yerleşik destek sağladıkları için cron'un alternatifi olarak kullanılabilir ve asenkron olarak çalıştırılabilirler.
> 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ı ada 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ç aynı şekilde adlandırılması önerilir.
* **Göreceli bir yol yürüten** ve **systemd PATH** üzerinde **yazma izinleriniz** olan bir systemd birimi bulun (o yürütülebilir dosyayı taklit etmek için)
Unix Domain Sockets (UDS), istemci-sunucu modelleri içinde aynı veya farklı makinelerde **işlem iletişimini** sağlar. Standart Unix tanımlayıcı dosyalarını kullanarak bilgisayarlar arası iletişim için kurulurlar ve `.socket` dosyaları aracılığıyla yapılandırılırlar.
-`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 mantıksal argüman alır. Eğer **true** ise, her gelen bağlantı için bir **hizmet örneği başlatılır** ve sadece bağlantı soketi ona iletilir. Eğer **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ığı datagram soketleri ve FIFO'lar için göz ardı edilir. **Varsayılan olarak false**. Performans nedeniyle, 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ını alır, bu komutlar dinleme **soketleri**/FIFO'lar **oluşturulmadan önce** veya **sonra** yürütülür 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 **soketleri**/FIFO'lar **kapatılmadan önce** veya **sonra** yürütülen ek **komutlar**.
-`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 (sonek değiştirilmiş olarak). Çoğu durumda, bu seçeneği kullanmanın gerekli olmaması gerekmektedir.
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 soket oluşturulmadan önce arka kapı çalıştırılacaktır. Bu nedenle, muhtemelen makinenin yeniden başlatılmasını**beklemeniz gerekecektir.**\
_Not: Sistem o soket dosyası yapılandırmasını kullanıyor olmalı veya arka kapı çalıştırılmayacaktır_
Eğer **yazılabilir bir soket** belirlerseniz (_şu anda Unix Soketleri hakkında konuşuyoruz ve yapılandırma `.socket` dosyaları hakkında değil_), o soketle **iletişim kurabilir** ve belki bir zafiyeti sömürebilirsiniz.
Unutmayı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 bulunur ve güvenli bir şekilde korunmalıdır. Varsayılan olarak, bu soket `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. İşte bunun nasıl yapılabileceğine ve Docker CLI kullanılamıyorsa alternatif yöntemlere dair ayrıntılar:
`socat` bağlantısını kurduktan sonra, kök düzey erişimine sahip olarak ana bilgisayar dosya sisteminde doğrudan komutları konteynerde 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**](interesting-groups-linux-pe/#docker-group). [**Docker API'nin bir portta dinlediği durumda, bunu tehlikeye atabilirsiniz**](../../network-services-pentesting/2375-pentesting-docker.md#compromising).
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) sistemi**dir. Modern Linux sistemi göz önünde bulundurularak tasarlanmış olup, farklı uygulama iletişimi için sağlam bir çerçeve sunar.
Sistem, işlemler arası veri alışverişini artıran temel IPC'yi destekler ve **gelişmiş UNIX alan soketlerini** hatırlatan 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, müzik çaların sessizleşmesine neden olabilir, kullanıcı deneyimini artırır. Ayrıca, D-Bus, uygulamalar arasında 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, eşleşen politika kurallarının kümülatif etkisine dayanarak mesaj izinlerini (yöntem çağrıları, sinyal yayınları vb.) yöneten bir **izin/engelleme modeli** üzerinde çalışır. Bu politikalar, otobüsle etkileşimleri belirtir ve bu izinlerin kötüye kullanılmasıyla 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 alma izinlerini 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.
Kendiniz **kim** olduğunuzu, hangi **yetkilere** sahip olduğunuzu, sistemlerde hangi **kullanıcıların** bulunduğunu, hangilerinin **giriş yapabileceğini** ve hangilerinin **kök yetkilerine** 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](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [buraya](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) ve [buraya](https://twitter.com/paragonsec/status/1071152249529884674).\
Eğer çok fazla gürültü yapmaktan çekinmiyorsanız ve bilgisayarda `su` ve `timeout` ikilisi mevcutsa, [su-bruteforce](https://github.com/carlospolop/su-bruteforce) kullanarak kullanıcıyı brute-force deneyebilirsiniz.\
[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite), `-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ı oluşturarak ayrıcalıkları yükseltebilirsiniz ve bu komutun $PATH'teki yazılabilir klasörünüzden önceki bir klasörden yüklenmediğinden emin olabilirsiniz.
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ı**:
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 komutu çalıştırıyorsa**, o zaman, suid dosyanın çağırdığı komut adında bir **fonksiyon ihraç etmeyi** deneyebilirsiniz.
**LD\_PRELOAD** çevresel değişkeni, yükleyicinin diğer tüm kütüphanelerden önce, standart C kütüphanesi (`libc.so`) dahil olmak üzere belirtilen bir veya daha fazla paylaşılan kütüphaneyi (.so dosyaları) yüklemek için kullanılır. Bu işlem, bir kütüphaneyi önceden yükleme 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:
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 kalması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.
Benzer bir ayrıcalık yükseltme saldırısı, saldırganın kütüphanelerin aranacağı yolunu kontrol ettiği **LD\_LIBRARY\_PATH** çevresel değişkeni 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, bir zafiyet potansiyelini işaret edebilir.
Bu kod, derlendikten ve çalıştırıldıktan sonra dosya izinlerini manipüle ederek ve yüksek ayrıcalıklarla bir kabuk çalıştırarak ayrıcalıkları yükseltmeyi amaçlar.
[**GTFOBins**](https://gtfobins.github.io), bir saldırganın yerel güvenlik kısıtlamalarını atlamak için kullanabileceği Unix ikililerinin derlenmiş bir listesidir. [**GTFOArgs**](https://gtfoargs.github.io/), yalnızca bir komuta argüman enjekte edebileceğiniz durumlar için aynı işlevi görür.
Proje, Unix ikililerinin meşru işlevlerini toplar ve bunların kısıtlı 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 kötüye kullanılabileceği durumları içerir.
`sudo -l`'ye erişebiliyorsanız, [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) adlı aracı kullanarak herhangi bir sudo kuralını nasıl kötüye kullanabileceğinizi kontrol edebilirsiniz.
**Sudo erişiminiz** var ancak şifreniz yoksa, **bir sudo komutunun yürütülmesini bekleyerek ve ardından oturum belirtecinin ele geçirilmesiyle** ayrıcalıkları yükseltebilirsiniz.
* "_sampleuser_" **son 15 dakika içinde `sudo` kullanmış** (varsayılan olarak, şifre gerektirmeden `sudo` kullanmamıza izin veren sudo belirtecinin süresi budur)
* Üçü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**](https://github.com/nongiach/sudo\_inject/tree/master/extra\_tools) 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 kabuk erişiminiz varsa, ş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ı**yazabiliyorsanız**, ayrıcalıkları**yükseltebilirsiniz**.
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 o kullanıcı 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'yu çalıştırdığında, kendi 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](https://github.com/APTy/sudo-piggyback) `~/.bashrc`, `~/.zshrc`, `~/.bash_profile` dosyalarını değiştirir. Başka bir örnek için [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire\_modules/bashdoor.py) adresine bakabilirsiniz.
`/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` yolundan 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, belirtilen yollardan herhangi birinde: `/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örde, ayrıcalıkları yükseltebilir.\
Bu yapılandırmanın nasıl **sömürüleceğine** aşağıdaki sayfada bakın:
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:
Bir dizinde "çalıştır" biti, etkilenen kullanıcının klasöre "cd" yapabileceği anlamına gelir.\
"Oku" biti, kullanıcının dosyaları listeleyebileceği anlamına gelir ve "yaz" 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 ve belirli kullanıcılara belirli hakları vererek veya reddederek grup üyeleri veya sahipleri olmayan kullanıcılara hak verir. Bu ayrıntı düzeyi, daha hassas erişim yönetimi sağlar. Daha fazla ayrıntıya [buradan](https://linuxconfig.org/how-to-manage-acls-on-linux) ulaşılabilir.
**En yeni sürümlerde**, yalnızca **kendi kullanıcınızın** ekran oturumlarına **bağlanabileceksiniz**. Bununla birlikte, oturum içinde **ilginç bilgiler bulabilirsiniz**.
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.
Eylül 2006 ile 13 Mayıs 2008 arasında Debian tabanlı sistemlerde (Ubuntu, Kubuntu, vb.) oluşturulan tüm SSL ve SSH anahtarları bu hatadan etkilenebilir.\
Bu hata, bu işletim sistemlerinde yeni bir ssh anahtarı oluşturulduğunda meydana gelir, çünkü **yalnızca 32,768 varyasyon mümkündür**. 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](https://github.com/g0tmi1k/debian-ssh)
* **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.
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, eğer "**testusername**" kullanıcısının **özel** anahtarı ile giriş yapmaya çalışırsanız, ssh anahtarınızın genel anahtarını`/home/testusername/.ssh/authorized_keys` ve `/home/testusername/access` konumundaki anahtarlarla karşılaştıracağını belirtecektir.
SSH ajan yönlendirmesi, sunucunuzda (şifresiz!) anahtarları bırakmak yerine **yerel SSH anahtarlarınızı kullanmanıza izin verir**. Bu sayede, ssh üzerinden **bir ana makineye** atlayabilecek ve oradan **başka bir** ana makineye **başka bir** anahtar kullanarak **atlayabileceksiniz**.
Dosya `/etc/sshd_config` ssh-agent yönlendirmesine izin verebilir veya reddedebilir ve `AllowAgentForwarding` anahtar kelimesiyle yapılandırılabilir (varsayılan olarak izin verilir).
`/etc/profile` dosyası ve `/etc/profile.d/` altındaki dosyalar, bir kullanıcı yeni bir kabuk çalıştırdığında **çalıştırılan betiklerdir**. Bu nedenle, bunlardan herhangi birini **yazabilir veya değiştirebilirseniz yetkileri yükseltebilirsiniz**.
İşletim sistemine bağlı olarak `/etc/passwd` ve `/etc/shadow` dosyalarının farklı bir isim kullanıyor olabileceği veya bir yedek dosya olabileceği için **hepsini bulmanız** ve içerisinde **hash'lerin olup olmadığını** görmek için onları okuyup okuyamadığınızı kontrol etmeniz önerilir:
**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.
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody
for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user
Örneğin, eğer 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**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) kodunu okuyun, **şifre içerebilecek çeşitli dosyaları arar**.\
Bunu yapmak için kullanabileceğiniz **başka ilginç bir araç** ise: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) Windows, Linux ve Mac için yerel bir bilgisayarda depolanan birçok şifreyi almak için kullanılan açık kaynaklı bir uygulamadır.
Günlükleri okuyabiliyorsanız, içlerinde **ilginç/gizli bilgiler bulabilirsiniz**. Günlük ne kadar garip olursa, o kadar ilginç olacaktır (muhtemelen).\
Ayrıca, bazı "**kötü**" yapılandırılmış (arkadan açık kapılı?) **denetim günlükleri**, size şifreleri **denetim günlüklerinin içine kaydetmenize** izin verebilir, bu konuyla ilgili olarak şu yazıda açıklanmıştır: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/).
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'ler ve e-postaları veya hash'leri regexlerini kontrol edin.\
Bunların hepsini nasıl yapacağını burada listelemeyeceğim, ancak ilgileniyorsanız [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) 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).
`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 için 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, [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx günlükleri)** ile çok benzerdir, bu nedenle günlükleri değiştirebileceğiniz durumlarda, günlükleri kimin yönettiğini kontrol edin ve günlükleri sembollerle değiştirerek ayrıcalıkları yükseltebileceğinizi kontrol edin.
Herhangi bir nedenden dolayı bir kullanıcı_/etc/sysconfig/network-scripts_ dizinine bir `ifcf-<ne_olursa>` 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**.
`/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**. Upstart'e geçişe rağmen, Upstart'ta bir uyumluluk katmanı nedeniyle SysVinit betikleri hala Upstart yapılandırmalarıyla birlikte kullanılmaktadır.
**systemd**, gelişmiş özellikler sunan modern bir başlatma ve hizmet yöneticisi olarak ortaya çıkar, örneğin ihtiyaç duyulan daemon başlatma, otomatik bağlama yönetimi ve sistem durumu anlık görüntüleri. 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.
### **Linux yerel yetki yükseltme vektörlerini aramak için en iyi araç:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS)