Linux Privilege Escalation
Last updated
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
実行中のOSについての知識を得ることから始めましょう。
もしあなたがPATH
変数内の任意のフォルダーに書き込み権限を持っている場合、いくつかのライブラリやバイナリをハイジャックできるかもしれません:
環境変数に興味深い情報、パスワード、またはAPIキーはありますか?
カーネルのバージョンを確認し、特権を昇格させるために使用できるエクスプロイトがあるかどうかを調べます。
良い脆弱なカーネルのリストといくつかの既にコンパイルされたエクスプロイトはここにあります: https://github.com/lucyoa/kernel-exploits と exploitdb sploits。 他にコンパイルされたエクスプロイトを見つけることができるサイト: https://github.com/bwbwbwbw/linux-exploit-binaries、https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
そのウェブからすべての脆弱なカーネルバージョンを抽出するには、次のようにします:
カーネルの脆弱性を検索するのに役立つツールは次のとおりです:
linux-exploit-suggester.sh linux-exploit-suggester2.pl linuxprivchecker.py (被害者で実行、カーネル2.xの脆弱性のみをチェック)
常にGoogleでカーネルバージョンを検索してください。おそらくあなたのカーネルバージョンがいくつかのカーネル脆弱性に記載されており、その場合、この脆弱性が有効であることが確認できます。
Linux特権昇格 - Linuxカーネル <= 3.19.0-73.8
脆弱なsudoバージョンに基づいて、次のように表示されます:
From @sickrov
smasher2 box of HTBの例を確認して、この脆弱性がどのように悪用されるかを確認してください。
もしあなたが Docker コンテナ内にいる場合、そこから脱出しようとすることができます:
Docker Security何がマウントされていて、何がアンマウントされているか、どこで、なぜそれが行われているのかを確認してください。もし何かがアンマウントされている場合、それをマウントしてプライベート情報を確認することができるかもしれません。
有用なバイナリを列挙する
また、コンパイラがインストールされているかどうかを確認してください。これは、カーネルエクスプロイトを使用する必要がある場合に便利です。使用するマシン(または類似のマシン)でコンパイルすることが推奨されます。
インストールされたパッケージとサービスのバージョンを確認してください。特権昇格に悪用される可能性のある古いNagiosのバージョンがあるかもしれません… より疑わしいインストールされたソフトウェアのバージョンを手動で確認することをお勧めします。
SSHアクセスがある場合、openVASを使用して、マシン内にインストールされている古いおよび脆弱なソフトウェアをチェックすることもできます。
これらのコマンドは、ほとんど役に立たない多くの情報を表示するため、インストールされているソフトウェアのバージョンが既知の脆弱性に対して脆弱かどうかをチェックするOpenVASや同様のアプリケーションを推奨します。
どのプロセスが実行されているかを確認し、権限が必要以上に高いプロセスがないかをチェックします(例えば、rootによって実行されているtomcatなど)。
常に可能な [electron/cef/chromiumデバッガー] が実行されているか確認してください。これを悪用して特権を昇格させることができます。Linpeas はプロセスのコマンドライン内の --inspect
パラメータをチェックすることでそれを検出します。
また、プロセスのバイナリに対する権限を確認してください。誰かを上書きできるかもしれません。
pspy のようなツールを使用してプロセスを監視できます。これは、脆弱なプロセスが頻繁に実行されているか、特定の要件が満たされたときに特定するのに非常に役立ちます。
サーバーの一部のサービスは、メモリ内に平文で資格情報を保存します。 通常、他のユーザーに属するプロセスのメモリを読むにはroot権限が必要です。したがって、これは通常、すでにrootであり、さらに資格情報を発見したいときにより有用です。 ただし、通常のユーザーとしては、自分が所有するプロセスのメモリを読むことができることを忘れないでください。
現在、ほとんどのマシンはデフォルトでptraceを許可していないため、特権のないユーザーに属する他のプロセスをダンプすることはできません。
ファイル /proc/sys/kernel/yama/ptrace_scope はptraceのアクセス可能性を制御します:
kernel.yama.ptrace_scope = 0: 同じuidを持つ限り、すべてのプロセスをデバッグできます。これがptracingが機能していた古典的な方法です。
kernel.yama.ptrace_scope = 1: 親プロセスのみがデバッグできます。
kernel.yama.ptrace_scope = 2: 管理者のみがptraceを使用できます。これはCAP_SYS_PTRACE権限が必要です。
kernel.yama.ptrace_scope = 3: ptraceでトレースできるプロセスはありません。一度設定されると、ptracingを再度有効にするには再起動が必要です。
FTPサービスのメモリにアクセスできる場合(例えば)、ヒープを取得し、その中の資格情報を検索できます。
特定のプロセスIDに対して、mapsはそのプロセスの仮想アドレス空間内でメモリがどのようにマッピングされているかを示します。また、各マッピングされた領域の権限も示します。mem擬似ファイルはプロセスのメモリ自体を公開します。mapsファイルから、どのメモリ領域が読み取り可能であるかとそのオフセットがわかります。この情報を使用して、memファイルにシークし、すべての読み取り可能な領域をファイルにダンプします。
/dev/mem
はシステムの 物理 メモリへのアクセスを提供します。カーネルの仮想アドレス空間には /dev/kmem を使用してアクセスできます。
通常、/dev/mem
は root と kmem グループのみに読み取り可能です。
ProcDumpは、WindowsのSysinternalsツールスイートからのクラシックなProcDumpツールのLinux版です。入手先はhttps://github.com/Sysinternals/ProcDump-for-Linuxです。
プロセスのメモリをダンプするには、次のものを使用できます:
https://github.com/hajzer/bash-memory-dump (root) - _ルート要件を手動で削除し、あなたが所有するプロセスをダンプできます
https://www.delaat.net/rp/2016-2017/p97/report.pdf のスクリプト A.5 (root が必要)
認証プロセスが実行中であることがわかった場合:
プロセスをダンプできます(プロセスのメモリをダンプするさまざまな方法を見つけるには前のセクションを参照してください)し、メモリ内の資格情報を検索します:
ツール https://github.com/huntergregal/mimipenguin は メモリからの平文の資格情報を盗む ことができ、いくつかの よく知られたファイル からも取得します。正しく動作するには root 権限が必要です。
GDM パスワード (Kali デスクトップ、Debian デスクトップ)
gdm-password
Gnome キーチェーン (Ubuntu デスクトップ、ArchLinux デスクトップ)
gnome-keyring-daemon
LightDM (Ubuntu デスクトップ)
lightdm
VSFTPd (アクティブ FTP 接続)
vsftpd
Apache2 (アクティブ HTTP ベーシック認証セッション)
apache2
OpenSSH (アクティブ SSH セッション - Sudo 使用)
sshd:
スケジュールされたジョブが脆弱であるか確認してください。もしかしたら、rootによって実行されるスクリプトを利用できるかもしれません(ワイルドカードの脆弱性?rootが使用するファイルを変更できる?シンボリックリンクを使用する?rootが使用するディレクトリに特定のファイルを作成する?)。
例えば、/etc/crontab の中に次のようなPATHが見つかります: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
(ユーザー "user" が /home/user に対して書き込み権限を持っていることに注意してください)
このcrontabの中で、rootユーザーがパスを設定せずにコマンドやスクリプトを実行しようとするとします。例えば: * * * * root overwrite.sh その場合、次のようにしてrootシェルを取得できます:
もしrootによって実行されるスクリプトがコマンド内に“*”を含んでいる場合、これを利用して予期しないこと(例えば、権限昇格)を引き起こすことができます。例:
もしワイルドカードが /some/path/* のようなパスの前にある場合、それは脆弱ではありません( ./* もそうです)。
次のページを読んで、他のワイルドカードの悪用テクニックを学んでください:
Wildcards Spare tricksもしrootによって実行されるcronスクリプトを変更できるなら、非常に簡単にシェルを取得できます:
もしrootによって実行されるスクリプトがあなたが完全にアクセスできるディレクトリを使用している場合、そのフォルダを削除し、あなたが制御するスクリプトを提供する別のフォルダへのシンボリックリンクフォルダを作成することが有用かもしれません。
1分、2分、または5分ごとに実行されているプロセスを検索するためにプロセスを監視できます。これを利用して特権を昇格させることができるかもしれません。
例えば、1分間0.1秒ごとに監視し、実行回数が少ないコマンドでソートし、最も実行されたコマンドを削除するには、次のようにします:
あなたはまた pspy を使用できます(これは開始されるすべてのプロセスを監視してリストします)。
コメントの後にキャリッジリターンを入れたcronジョブを作成することが可能です(改行文字なし)、そしてcronジョブは機能します。例(キャリッジリターン文字に注意):
任意の .service
ファイルに書き込むことができるか確認してください。できる場合は、それを 修正して サービスが 開始、再起動、または 停止 されたときに バックドアを実行 するようにすることができます(マシンが再起動されるまで待つ必要があるかもしれません)。
例えば、.service ファイル内に ExecStart=/tmp/script.sh
を使ってバックドアを作成します。
サービスによって実行されるバイナリに 書き込み権限 がある場合、それらをバックドアに変更できることを念頭に置いてください。そうすれば、サービスが再実行されるとバックドアが実行されます。
systemd によって使用される PATH は次のコマンドで確認できます:
もし、パスのフォルダのいずれかに書き込むことができる場合、特権を昇格させることができるかもしれません。サービス構成ファイルで使用されている相対パスを探す必要があります。
その後、書き込み可能なsystemd PATHフォルダー内に相対パスバイナリと同じ名前の実行可能ファイルを作成し、サービスが脆弱なアクション(Start、Stop、Reload)を実行するように求められたときに、あなたのバックドアが実行されます(特権のないユーザーは通常サービスを開始/停止できませんが、sudo -l
を使用できるか確認してください)。
man systemd.service
でサービスについて詳しく学んでください。
タイマーは、**.service**
ファイルやイベントを制御する**.timer**
で終わるsystemdユニットファイルです。タイマーは、カレンダー時間イベントと単調時間イベントのサポートが組み込まれているため、cronの代替として使用でき、非同期で実行できます。
すべてのタイマーを列挙するには、次のコマンドを使用します:
タイマーを変更できる場合、systemd.unitのいくつかの実行(.service
や.target
など)を実行させることができます。
ドキュメントでは、ユニットが何であるかを読むことができます:
このタイマーが経過したときにアクティブにするユニット。引数はユニット名で、その接尾辞は「.timer」ではありません。指定されていない場合、この値はタイマー単位と同じ名前のサービスにデフォルト設定されます(接尾辞を除く)。(上記を参照。)アクティブにされるユニット名とタイマー単位のユニット名は、接尾辞を除いて同一の名前にすることが推奨されます。
したがって、この権限を悪用するには、次のことが必要です:
書き込み可能なバイナリを実行している systemd ユニット(例えば .service
)を見つける
相対パスを実行している systemd ユニットを見つけ、systemd PATH に対して 書き込み権限 を持つ(その実行可能ファイルを偽装するため)
タイマーについて詳しくは man systemd.timer
を参照してください。
タイマーを有効にするには、root 権限が必要で、次のコマンドを実行します:
Note the timer is activated by creating a symlink to it on /etc/systemd/system/<WantedBy_section>.wants/<name>.timer
Unix Domain Sockets (UDS) は、クライアント-サーバーモデル内で同じまたは異なるマシン間のプロセス通信を可能にします。これらは、コンピュータ間通信のために標準のUnixディスクリプタファイルを利用し、.socket
ファイルを通じて設定されます。
ソケットは.socket
ファイルを使用して構成できます。
man systemd.socket
でソケットについてもっと学びましょう。 このファイル内では、いくつかの興味深いパラメータを設定できます:
ListenStream
, ListenDatagram
, ListenSequentialPacket
, ListenFIFO
, ListenSpecial
, ListenNetlink
, ListenMessageQueue
, ListenUSBFunction
: これらのオプションは異なりますが、ソケットがどこでリッスンするかを示すために要約が使用されます(AF_UNIXソケットファイルのパス、リッスンするIPv4/6および/またはポート番号など)。
Accept
: ブール引数を取ります。trueの場合、各接続ごとにサービスインスタンスが生成され、接続ソケットのみがそれに渡されます。falseの場合、すべてのリッスンソケット自体が開始されたサービスユニットに渡され、すべての接続に対して1つのサービスユニットが生成されます。この値は、単一のサービスユニットが無条件にすべての受信トラフィックを処理するデータグラムソケットおよびFIFOでは無視されます。デフォルトはfalseです。パフォーマンスの理由から、Accept=no
に適した方法でのみ新しいデーモンを書くことが推奨されます。
ExecStartPre
, ExecStartPost
: リッスンするソケット/FIFOがそれぞれ作成されてバインドされる前または後に実行される1つ以上のコマンドラインを取ります。コマンドラインの最初のトークンは絶対ファイル名でなければならず、その後にプロセスの引数が続きます。
ExecStopPre
, ExecStopPost
: リッスンするソケット/FIFOがそれぞれ閉じられて削除される前または後に実行される追加のコマンドです。
Service
: 受信トラフィックでアクティブ化するサービスユニット名を指定します。この設定は、Accept=noのソケットにのみ許可されます。デフォルトでは、ソケットと同じ名前のサービス(サフィックスが置き換えられたもの)になります。ほとんどの場合、このオプションを使用する必要はありません。
書き込み可能な.socket
ファイルを見つけた場合、[Socket]
セクションの最初に次のようなものを追加できます:ExecStartPre=/home/kali/sys/backdoor
、これによりソケットが作成される前にバックドアが実行されます。したがって、おそらくマシンが再起動されるまで待つ必要があります。
&#xNAN;Note that the system must be using that socket file configuration or the backdoor won't be executed
書き込み可能なソケットを特定した場合(ここではUnixソケットについて話しており、構成.socket
ファイルについてではありません)、そのソケットと通信することができ、おそらく脆弱性を悪用することができます。
悪用の例:
Socket Command InjectionHTTPリクエストを待ち受けているソケットがいくつか存在する可能性があります(私は.socketファイルではなく、Unixソケットとして機能するファイルについて話しています)。これを確認するには、次のコマンドを使用できます:
もしソケットがHTTPリクエストで応答する場合、あなたはそれと通信でき、場合によってはいくつかの脆弱性を悪用できるかもしれません。
Dockerソケットは、通常/var/run/docker.sock
に見られる重要なファイルであり、保護されるべきです。デフォルトでは、root
ユーザーとdocker
グループのメンバーが書き込み可能です。このソケットへの書き込みアクセスを持つことは、特権昇格につながる可能性があります。これを行う方法と、Docker CLIが利用できない場合の代替手段を以下に示します。
Dockerソケットへの書き込みアクセスがある場合、次のコマンドを使用して特権を昇格させることができます:
These commands allow you to run a container with root-level access to the host's file system.
Docker CLIが利用できない場合でも、DockerソケットはDocker APIとcurl
コマンドを使用して操作できます。
Dockerイメージのリスト: 利用可能なイメージのリストを取得します。
コンテナの作成: ホストシステムのルートディレクトリをマウントするコンテナを作成するリクエストを送信します。
新しく作成したコンテナを起動します:
コンテナに接続: socat
を使用してコンテナへの接続を確立し、その中でコマンドを実行できるようにします。
socat
接続を設定した後、ホストのファイルシステムに対してルートレベルのアクセスを持つコンテナ内で直接コマンドを実行できます。
docker
グループの中にいるためにdockerソケットに対する書き込み権限がある場合、特権を昇格させる方法がさらにあります。もしdocker APIがポートでリスニングしている場合、あなたはそれを妥協することもできるかもしれません。
dockerから抜け出す方法やそれを悪用して特権を昇格させる方法を確認してください:
Docker Security**ctr
**コマンドを使用できる場合は、特権を昇格させるために悪用できるかもしれないので、以下のページを読んでください:
**runc
**コマンドを使用できる場合は、特権を昇格させるために悪用できるかもしれないので、以下のページを読んでください:
D-Busは、アプリケーションが効率的に相互作用し、データを共有できるようにする高度なプロセス間通信(IPC)システムです。現代のLinuxシステムを念頭に設計されており、さまざまな形式のアプリケーション通信のための堅牢なフレームワークを提供します。
このシステムは多用途で、プロセス間のデータ交換を強化する基本的なIPCをサポートし、強化されたUNIXドメインソケットを思わせます。さらに、イベントや信号をブロードキャストするのを助け、システムコンポーネント間のシームレスな統合を促進します。たとえば、Bluetoothデーモンからの着信コールに関する信号は、音楽プレーヤーをミュートさせ、ユーザー体験を向上させることができます。加えて、D-Busはリモートオブジェクトシステムをサポートし、アプリケーション間のサービスリクエストやメソッド呼び出しを簡素化し、従来は複雑だったプロセスを効率化します。
D-Busは許可/拒否モデルで動作し、メッセージの権限(メソッド呼び出し、信号の送信など)を、ポリシールールの累積的な効果に基づいて管理します。これらのポリシーはバスとの相互作用を指定し、これらの権限を悪用することで特権昇格を可能にする場合があります。
/etc/dbus-1/system.d/wpa_supplicant.conf
にあるそのようなポリシーの例が提供されており、rootユーザーがfi.w1.wpa_supplicant1
からメッセージを所有、送信、受信するための権限を詳細に説明しています。
ユーザーまたはグループが指定されていないポリシーは普遍的に適用され、"デフォルト"コンテキストポリシーは他の特定のポリシーにカバーされていないすべてに適用されます。
D-Bus通信を列挙し、悪用する方法をここで学びましょう:
D-Bus Enumeration & Command Injection Privilege Escalationネットワークを列挙し、マシンの位置を特定することは常に興味深いです。
常に、アクセスする前に対話できなかったマシン上で実行されているネットワークサービスを確認してください:
トラフィックをスニッフィングできるか確認してください。できる場合、いくつかの認証情報を取得できるかもしれません。
whoで自分が誰であるか、どのprivilegesを持っているか、システムにどのusersがいるか、どのユーザーがloginでき、どのユーザーがroot privilegesを持っているかを確認します:
一部のLinuxバージョンは、UID > INT_MAXを持つユーザーが特権を昇格させることを可能にするバグの影響を受けました。詳細情報: here, here と here。
Exploit it using: systemd-run -t /bin/bash
あなたがルート特権を付与する可能性のあるグループのメンバーであるか確認してください:
Interesting Groups - Linux Privescクリップボード内に興味深いものがあるか確認してください(可能であれば)。
もし環境のパスワードを知っている場合は、各ユーザーとしてログインを試みてください。
多くのノイズを出すことを気にしない場合、su
とtimeout
バイナリがコンピュータに存在するなら、su-bruteforceを使用してユーザーをブルートフォースすることができます。
Linpeasの-a
パラメータを使用すると、ユーザーをブルートフォースすることも試みます。
もし**$PATHのいくつかのフォルダ内に書き込むことができる**ことがわかった場合、書き込み可能なフォルダ内にバックドアを作成することによって特権を昇格させることができるかもしれません。そのバックドアは、異なるユーザー(理想的にはroot)によって実行されるコマンドの名前であり、あなたの書き込み可能なフォルダよりも前に位置するフォルダからは読み込まれない必要があります。
sudoを使用していくつかのコマンドを実行することが許可されているか、suidビットを持っている可能性があります。それを確認するには:
いくつかの予期しないコマンドは、ファイルを読み書きしたり、コマンドを実行したりすることを可能にします。 例えば:
Sudoの設定により、ユーザーはパスワードを知らなくても他のユーザーの権限でいくつかのコマンドを実行できる場合があります。
この例では、ユーザー demo
は root
として vim
を実行できます。これにより、ルートディレクトリにsshキーを追加するか、sh
を呼び出すことでシェルを取得することが簡単になります。
このディレクティブは、ユーザーが何かを実行している間に環境変数を設定することを許可します:
この例は、HTBマシンAdmirerに基づいており、スクリプトをrootとして実行する際に任意のPythonライブラリを読み込むためのPYTHONPATHハイジャックに脆弱でした:
ジャンプして他のファイルを読むか、シンボリックリンクを使用します。例えば、sudoersファイルでは: hacker10 ALL= (root) /bin/less /var/log/*
もしワイルドカード(*)が使用されると、さらに簡単になります:
対策: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/
sudo権限が単一のコマンドにパスを指定せずに与えられている場合: hacker10 ALL= (root) less、PATH変数を変更することでこれを悪用できます。
この技術は、suid バイナリが パスを指定せずに別のコマンドを実行する場合にも使用できます(常に奇妙な SUID バイナリの内容を strings で確認してください)。
もし suid バイナリが パスを指定して別のコマンドを実行する場合、その場合は、suid ファイルが呼び出しているコマンドと同名の 関数をエクスポートしてみることができます。
例えば、suid バイナリが /usr/sbin/service apache2 start を呼び出す場合、関数を作成してエクスポートする必要があります:
Then, when you call the suid binary, this function will be executed
The LD_PRELOAD 環境変数は、ローダーによって他のすべてのライブラリ、標準Cライブラリ(libc.so
)を含む前に読み込まれる1つ以上の共有ライブラリ(.soファイル)を指定するために使用されます。このプロセスはライブラリのプリロードとして知られています。
しかし、システムのセキュリティを維持し、この機能が悪用されるのを防ぐために、特にsuid/sgid 実行可能ファイルに対して、システムはいくつかの条件を強制します:
ローダーは、実ユーザーID(ruid)が有効ユーザーID(euid)と一致しない実行可能ファイルに対してLD_PRELOADを無視します。
suid/sgidの実行可能ファイルに対しては、suid/sgidでもある標準パスのライブラリのみがプリロードされます。
特権昇格は、sudo
を使用してコマンドを実行する能力があり、sudo -l
の出力にenv_keep+=LD_PRELOADという文が含まれている場合に発生する可能性があります。この構成により、LD_PRELOAD 環境変数が持続し、sudo
でコマンドが実行されるときでも認識されるため、特権のある状態で任意のコードが実行される可能性があります。
/tmp/pe.cとして保存してください
次にコンパイルします:
最後に、権限を昇格させる 実行中
攻撃者が LD_LIBRARY_PATH 環境変数を制御している場合、同様の特権昇格が悪用される可能性があります。なぜなら、攻撃者はライブラリが検索されるパスを制御しているからです。
SUID権限を持つバイナリに遭遇した際に、異常に見える場合は、正しく**.so**ファイルを読み込んでいるか確認することが良い習慣です。これは、次のコマンドを実行することで確認できます:
例えば、“open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (そのようなファイルやディレクトリはありません)” のようなエラーに遭遇することは、悪用の可能性を示唆しています。
これを悪用するには、次のコードを含むCファイル、例えば "/path/to/.config/libcalc.c" を作成します:
このコードは、コンパイルして実行すると、ファイルの権限を操作し、特権のあるシェルを実行することで特権を昇格させることを目的としています。
上記のCファイルを共有オブジェクト(.so)ファイルにコンパイルするには:
最終的に、影響を受けたSUIDバイナリを実行することで、エクスプロイトがトリガーされ、システムの侵害の可能性が生じます。
今、書き込み可能なフォルダーからライブラリを読み込むSUIDバイナリを見つけたので、そのフォルダーに必要な名前のライブラリを作成しましょう:
エラーが発生した場合は、例えば
それは、生成したライブラリに a_function_name
という関数が必要であることを意味します。
GTFOBins は、攻撃者がローカルのセキュリティ制限を回避するために悪用できるUnixバイナリのキュレーションされたリストです。GTFOArgs は、コマンドに引数のみを注入できる場合の同様のリストです。
このプロジェクトは、制限されたシェルから抜け出し、特権を昇格または維持し、ファイルを転送し、バインドおよびリバースシェルを生成し、他のポストエクスプロイトタスクを容易にするために悪用できるUnixバイナリの正当な関数を収集します。
gdb -nx -ex '!sh' -ex quit sudo mysql -e '! /bin/sh' strace -o /dev/null /bin/sh sudo awk 'BEGIN {system("/bin/sh")}'
sudo -l
にアクセスできる場合、ツール FallOfSudo を使用して、任意のsudoルールを悪用する方法を見つけることができます。
sudoアクセスはあるがパスワードがない場合、sudoコマンドの実行を待ってからセッショントークンをハイジャックすることで特権を昇格させることができます。
特権を昇格させるための要件:
ユーザー "sampleuser" としてシェルを持っている
"sampleuser" が過去15分間に sudo
を使用して何かを実行している(デフォルトでは、これはパスワードを入力せずに sudo
を使用できるsudoトークンの期間です)
cat /proc/sys/kernel/yama/ptrace_scope
が 0 である
gdb
にアクセス可能である(アップロードできる必要があります)
(echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
で一時的に ptrace_scope
を有効にするか、/etc/sysctl.d/10-ptrace.conf
を永続的に修正して kernel.yama.ptrace_scope = 0
を設定できます)
これらの要件がすべて満たされている場合、次の方法で特権を昇格させることができます: https://github.com/nongiach/sudo_inject
最初のエクスプロイト (exploit.sh
) は、/tmp にバイナリ activate_sudo_token
を作成します。これを使用してセッション内でsudoトークンをアクティブにすることができます(自動的にルートシェルは取得できませんので、sudo su
を実行してください):
二番目のエクスプロイト (exploit_v2.sh
) は、_ /tmp _ に setuid を持つ root 所有の sh シェルを作成します
第三のエクスプロイト (exploit_v3.sh
) は sudoersファイルを作成し、sudoトークンを永続化し、すべてのユーザーがsudoを使用できるようにします
フォルダー内のファイルに書き込み権限がある場合、バイナリwrite_sudo_tokenを使用してユーザーとPIDのためのsudoトークンを作成できます。 例えば、ファイル_/var/run/sudo/ts/sampleuser_を上書きでき、PID 1234のそのユーザーとしてシェルを持っている場合、パスワードを知ることなくsudo権限を取得できます。
ファイル /etc/sudoers
と /etc/sudoers.d
内のファイルは、誰が sudo
を使用できるか、そしてその方法を設定します。これらのファイルは デフォルトではユーザー root とグループ root のみが読み取ることができます。
もし このファイルを 読む ことができれば、興味深い情報を取得できる かもしれません。そして、もしあなたが 任意のファイルに書き込む ことができれば、特権を昇格させる ことができるでしょう。
もし書き込みができれば、この権限を悪用することができます。
これらの権限を悪用する別の方法:
sudo
バイナリの代替として、OpenBSD の doas
などがあります。 /etc/doas.conf
でその設定を確認することを忘れないでください。
もしユーザーが通常マシンに接続し、sudo
を使用して特権を昇格させることを知っていて、そのユーザーコンテキスト内でシェルを取得した場合、新しいsudo実行可能ファイルを作成して、あなたのコードをrootとして実行し、その後ユーザーのコマンドを実行させることができます。次に、ユーザーコンテキストの$PATHを変更します(例えば、.bash_profileに新しいパスを追加するなど)ので、ユーザーがsudoを実行すると、あなたのsudo実行可能ファイルが実行されます。
ユーザーが異なるシェル(bash以外)を使用している場合は、新しいパスを追加するために他のファイルを修正する必要があることに注意してください。例えば、sudo-piggybackは~/.bashrc
、~/.zshrc
、~/.bash_profile
を修正します。別の例はbashdoor.pyで見つけることができます。
または、次のようなコマンドを実行します:
ファイル /etc/ld.so.conf
は 読み込まれる設定ファイルの場所 を示します。通常、このファイルには次のパスが含まれています: include /etc/ld.so.conf.d/*.conf
これは、/etc/ld.so.conf.d/*.conf
からの設定ファイルが読み込まれることを意味します。この設定ファイルは 他のフォルダを指し示し、そこに ライブラリ が 検索される ことになります。例えば、/etc/ld.so.conf.d/libc.conf
の内容は /usr/local/lib
です。 これは、システムが /usr/local/lib
内でライブラリを検索することを意味します。
何らかの理由で ユーザーが書き込み権限を持っている 場合、次のパスのいずれかに対して: /etc/ld.so.conf
, /etc/ld.so.conf.d/
, /etc/ld.so.conf.d/
内の任意のファイル、または /etc/ld.so.conf.d/*.conf
内の設定ファイル内の任意のフォルダに対して、特権を昇格させることができるかもしれません。
次のページで この誤設定を悪用する方法 を見てください:
/var/tmp/flag15/
にlibをコピーすることで、RPATH
変数で指定されたこの場所でプログラムによって使用されます。
その後、/var/tmp
に gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6
を使用して悪意のあるライブラリを作成します。
Linux capabilitiesは、プロセスに利用可能なroot権限のサブセットを提供します。これにより、rootの権限がより小さく、独自の単位に分割されます。これらの単位は、プロセスに独立して付与できます。この方法で、権限の完全なセットが削減され、悪用のリスクが低下します。 capabilitiesとそれを悪用する方法について詳しく学ぶには、以下のページをお読みください:
Linux Capabilitiesディレクトリ内で、"execute"のビットは、影響を受けるユーザーがフォルダに"cd"できることを示します。 "read"ビットは、ユーザーがファイルをリストできることを示し、"write"ビットは、ユーザーが新しいファイルを削除および作成できることを示します。
アクセス制御リスト(ACL)は、裁量的権限の二次的な層を表し、従来のugo/rwx権限を上書きすることができます。これらの権限は、所有者やグループの一部でない特定のユーザーに対して権利を付与または拒否することにより、ファイルやディレクトリへのアクセスをより制御します。このレベルの粒度は、より正確なアクセス管理を保証します。詳細はこちらで確認できます。
ユーザー"kali"にファイルに対する読み取りおよび書き込み権限を付与します:
特定のACLを持つファイルをシステムから取得します:
古いバージョンでは、他のユーザー(root)のいくつかのシェルセッションをハイジャックすることができます。 最新のバージョンでは、自分のユーザーのスクリーンセッションにのみ接続できるようになります。しかし、セッション内に興味深い情報が見つかるかもしれません。
スクリーンセッションのリスト
セッションに接続する
これは古い tmux バージョンの問題でした。特権のないユーザーとして root によって作成された tmux (v2.1) セッションをハイジャックすることはできませんでした。
tmux セッションのリスト
セッションに接続する
Check Valentine box from HTB for an example.
Debianベースのシステム(Ubuntu、Kubuntuなど)で2006年9月から2008年5月13日までに生成されたすべてのSSLおよびSSHキーは、このバグの影響を受ける可能性があります。 このバグは、これらのOSで新しいsshキーを作成する際に発生します。可能な変種は32,768種類のみでした。これは、すべての可能性を計算できることを意味し、ssh公開鍵を持っていれば、対応する秘密鍵を検索できます。計算された可能性はここで見つけることができます: https://github.com/g0tmi1k/debian-ssh
PasswordAuthentication: パスワード認証が許可されているかどうかを指定します。デフォルトはno
です。
PubkeyAuthentication: 公開鍵認証が許可されているかどうかを指定します。デフォルトはyes
です。
PermitEmptyPasswords: パスワード認証が許可されている場合、サーバーが空のパスワード文字列を持つアカウントへのログインを許可するかどうかを指定します。デフォルトはno
です。
rootがsshを使用してログインできるかどうかを指定します。デフォルトはno
です。可能な値:
yes
: rootはパスワードと秘密鍵を使用してログインできます
without-password
またはprohibit-password
: rootは秘密鍵のみでログインできます
forced-commands-only
: rootは秘密鍵を使用してのみログインでき、コマンドオプションが指定されている必要があります
no
: いいえ
ユーザー認証に使用できる公開鍵を含むファイルを指定します。%h
のようなトークンを含むことができ、これはホームディレクトリに置き換えられます。絶対パス(/
で始まる)またはユーザーのホームからの相対パスを指定できます。例えば:
その設定は、ユーザー "testusername" の private キーでログインしようとすると、ssh があなたのキーの公開鍵を /home/testusername/.ssh/authorized_keys
と /home/testusername/access
にあるものと比較することを示します。
SSH エージェントフォワーディングを使用すると、サーバーに鍵を置かずに(パスフレーズなしで!)ローカルの SSH 鍵を使用することができます。これにより、ssh を介してホストにジャンプし、そこから 初期ホスト にある キー を使用して 別の ホストに ジャンプ することができます。
このオプションを $HOME/.ssh.config
に次のように設定する必要があります:
注意してください、Host
が*
の場合、ユーザーが異なるマシンにジャンプするたびに、そのホストはキーにアクセスできるようになります(これはセキュリティの問題です)。
ファイル/etc/ssh_config
はこのオプションを上書きし、この設定を許可または拒否できます。
ファイル/etc/sshd_config
はキーワードAllowAgentForwarding
を使用してssh-agentフォワーディングを許可または拒否できます(デフォルトは許可です)。
フォワードエージェントが環境で設定されている場合は、次のページを読んでください。特権を昇格させるために悪用できるかもしれません:
SSH Forward Agent exploitationファイル/etc/profile
および/etc/profile.d/
内のファイルは、ユーザーが新しいシェルを実行するときに実行されるスクリプトです。したがって、これらのいずれかを書き込むまたは変更することができれば、特権を昇格させることができます。
もし奇妙なプロファイルスクリプトが見つかった場合は、機密情報を確認する必要があります。
OSによっては、/etc/passwd
と /etc/shadow
ファイルが異なる名前を使用しているか、バックアップが存在する場合があります。したがって、すべてを見つけることをお勧めし、それらを読み取れるかどうかを確認して、ファイル内にハッシュがあるかどうかを確認してください:
時には、/etc/passwd
(または同等の)ファイル内にパスワードハッシュを見つけることができます。
まず、次のコマンドのいずれかを使用してパスワードを生成します。
次に、ユーザー hacker
を追加し、生成されたパスワードを追加します。
E.g: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash
あなたは今、hacker:hacker
でsu
コマンドを使用できます。
また、次の行を使用してパスワードなしのダミーユーザーを追加できます。 警告: 現在のマシンのセキュリティが低下する可能性があります。
NOTE: BSDプラットフォームでは /etc/passwd
は /etc/pwd.db
および /etc/master.passwd
にあり、また /etc/shadow
は /etc/spwd.db
に名前が変更されています。
あなたは いくつかの機密ファイルに書き込むことができるか 確認する必要があります。例えば、いくつかの サービス設定ファイル に書き込むことができますか?
例えば、マシンがtomcatサーバーを実行していて、/etc/systemd/内のTomcatサービス構成ファイルを変更できる場合、次の行を変更できます:
あなたのバックドアは、次回tomcatが起動したときに実行されます。
以下のフォルダにはバックアップや興味深い情報が含まれている可能性があります: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root(最後のものはおそらく読み取れませんが、試してみてください)
linPEASのコードを読むと、パスワードを含む可能性のあるいくつかのファイルを検索します。 もう一つの興味深いツールは、LaZagneで、これはWindows、Linux、Macのローカルコンピュータに保存された多くのパスワードを取得するために使用されるオープンソースアプリケーションです。
ログを読むことができれば、その中に興味深い/機密情報を見つけることができるかもしれません。ログが奇妙であればあるほど、興味深いものになるでしょう(おそらく)。 また、「悪い」設定(バックドア?)の監査ログは、この記事で説明されているように、監査ログ内にパスワードを記録することを許可するかもしれません: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/。
ログを読むために、グループ adm は非常に役立ちます。
ファイル名または内容に「password」という単語が含まれているファイルをチェックし、ログ内のIPやメール、またはハッシュの正規表現も確認してください。 これをすべて行う方法をここにリストするつもりはありませんが、興味があれば、linpeasが実行する最後のチェックを確認できます。
Pythonスクリプトが実行される場所を知っていて、そのフォルダー内に書き込むことができる、またはPythonライブラリを変更できる場合、OSライブラリを変更してバックドアを仕掛けることができます(Pythonスクリプトが実行される場所に書き込むことができる場合、os.pyライブラリをコピーして貼り付けます)。
ライブラリをバックドア化するには、os.pyライブラリの最後に次の行を追加します(IPとPORTを変更してください):
logrotate
の脆弱性により、ログファイルまたはその親ディレクトリに書き込み権限を持つユーザーが特権を昇格させる可能性があります。これは、logrotate
がしばしばrootとして実行され、特に_/etc/bash_completion.d/のようなディレクトリで任意のファイルを実行するように操作できるためです。 /var/log _だけでなく、ログローテーションが適用される任意のディレクトリでも権限を確認することが重要です。
この脆弱性はlogrotate
バージョン3.18.0
およびそれ以前のバージョンに影響します
脆弱性に関する詳細情報は、次のページで確認できます: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.
この脆弱性はlogrottenを使用して悪用できます。
この脆弱性はCVE-2016-1247 **(nginxログ)**に非常に似ているため、ログを変更できることがわかった場合は、誰がそのログを管理しているかを確認し、シンボリックリンクでログを置き換えることで特権を昇格できるかどうかを確認してください。
脆弱性の参照: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
何らかの理由で、ユーザーが_/etc/sysconfig/network-scripts_にifcf-<whatever>
スクリプトを書き込むことができるか、既存のものを調整できる場合、あなたのシステムは侵害されています。
ネットワークスクリプト、例えば_ifcg-eth0_はネットワーク接続に使用されます。これらは.iniファイルのように見えます。しかし、LinuxではNetwork Manager(dispatcher.d)によって~ソースされます~。
私のケースでは、これらのネットワークスクリプトでNAME=
が正しく処理されていません。名前に空白がある場合、システムは空白の後の部分を実行しようとします。これは、最初の空白の後のすべてがrootとして実行されることを意味します。
例えば: /etc/sysconfig/network-scripts/ifcfg-1337
ディレクトリ /etc/init.d
は System V init (SysVinit) のための スクリプト のホームです。これは クラシックなLinuxサービス管理システム であり、サービスを start
、stop
、restart
、時には reload
するためのスクリプトが含まれています。これらは直接実行することも、/etc/rc?.d/
に見られるシンボリックリンクを通じて実行することもできます。Redhatシステムの代替パスは /etc/rc.d/init.d
です。
一方、/etc/init
は Upstart に関連しており、これはUbuntuによって導入された新しい サービス管理 で、サービス管理タスクのための設定ファイルを使用します。Upstartへの移行にもかかわらず、SysVinitスクリプトはUpstartの設定と共に利用され続けており、Upstartには互換性レイヤーがあります。
systemd は現代的な初期化およびサービスマネージャーとして登場し、オンデマンドでのデーモン起動、自動マウント管理、システム状態のスナップショットなどの高度な機能を提供します。ファイルは配布パッケージ用に /usr/lib/systemd/
に、管理者の変更用に /etc/systemd/system/
に整理されており、システム管理プロセスを効率化しています。
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: Linuxと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
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)