Shikata Ga Nai

Private? There is no such things.

How i was able to get free money via sending negative tokensを訳してみた

Hello there, ('ω')ノ

 

ネガティブトークンを送信して無料でお金を得ることができた方法を。

 

脆弱性

 ロジックの欠陥

 支払いの改ざん

 

記事:

 https://0xm5awy.medium.com/how-i-was-able-to-get-free-money-via-sending-negative-tokens-1ed2e0e710e0

 

今回は、負のトークンを送信して無料のお金を手に入れた方法について。

はじめに、ウェブサイトの仕組みを説明することに。

サイトには 2 つの権限があり、1 つはユーザ、もう 1 つはストリーマで。

このサイトでは、ユーザがストリーマをサポートするためにトークンを。

購入することができ、ストリーマは別のストリーマにトークンを送信することもでき。

これはストリーマのお金になり。

 

トークンを購入せずにトークンを所有する方法を見つけようとして。

ストリーマアカウントを作成し、自分用のトークンを無限に送信し。

ユーザがプライベートメッセージをストリームロールに送信できる機能を。

見つけるまで、ウェブサイトのすべての機能を理解し始め。

これを行うには、トークンのプライベート メッセージを購入する必要があり。

残念ながら、ここにはバグは見つからず。

しかし、この後に何が来るかが重要で。

 

ストリーマにメッセージを送信できるようにするために。

プライベート メッセージを購入したところ、プライベート チャット内に。

3 つの機能があることがわかり。

 

・ストリーマにプライベート メッセージを送信して。

 (何も見つからず)

・画像または動画ファイルをストリーマーアップロードして。

 (何も見つからず)
トークン ヒントをストリーマーに送信して。

 (バグ)

 

今、最初に考えるのは、否定的なヒントを送ったらどうなるかということで。

( -5 、 -10 など)のように。

 

POST /endpoint HTTP/1.1
Host: 0xM5awy.com{"message":"negative tips","tokens":-100"}

 

100 のネガティブ トークンがストリーマに送信され。

以前は 150 トークンでしたが、今では 250 になっていて。

 

攻撃のワークフロー:

・攻撃者は 2 つのアカウントを持ち、1 つはストリーマで、もう 1 つはユーザーで。

・攻撃者はプライベート メッセージを購入して。

 自分のストリーマアカウントと会話して。

・攻撃者は自分のストリーマアカウントにネガティブ トークンを送信し。

・攻撃者はストリーマに 100 のマイナス トークンを送信しますが。

 彼のアカウントには 100 フリー コインが追加され。

・攻撃者はこれを 100 回以上実行できるため、1 万ドル以上を獲得できて。

 

影響:

攻撃者は無料のコインを無限に得ることができ、これらのコインはお金に変わり。

彼がどれだけのお金を稼ぐか想像してみて。

 

Best regards, (^^ゞ

AWS SSRF to Root on production instance — A bug worth 1.75Lacsを訳してみた

Hello there, ('ω')ノ

 

AWS SSRF から本番インスタンスのルートへを。

 

脆弱性

 SSRF

 RCE

 パスワードのリセット

 

記事:

 https://logicbomb.medium.com/a-bug-worth-1-75lacs-aws-ssrf-to-rce-8d43d5fda899

 

今回は、AWS SSRF をエスカレートして。

インドで成長しているトレーディング スタートアップの 1 つで。

リモート コード実行 (RCE) を実行する方法を。

 

 

アプリのさまざまなセクションに手動で移動して。

機密性の高い API エンドポイントを探していて。

並行して、ターゲット スコープを Burp Suite の「Crawl and Audit」に追加して。

アプリには、通常の「パスワード リセット」機能があり。

エンドポイントをよく見ると「return_url」というパラメータがあり。

このようなパラメータには、簡単に見つけられるバグが含まれる可能性が常にあり。

 

そして、Burp Suite が同じエンドポイントで。

「外部サービス インタラクション (DNS)」の脆弱性を発見したとき。

自分の期待は正しかったことが証明され。

 

さまざまな HTTP リクエスト ヘッダをチェックしているときに。

レスポンス ヘッダが X-Amz-Cf-Id であることがわかり。

プロファイル写真を取得するための S3 バケットのやり取りもあったため。

アプリケーションが AWS 経由であることは明らかで。

 

次の動きは、SSRF が可能かどうかを確認することで。

AWS メタデータ URL (http://169.254.169.254/latest/meta-data/) に。

アクセスしてみましたが、以下は CURL 要求に対する応答で。

 

 

インスタンスメタデータからセキュリティ認証情報を取得していて。

 

 

それはSSRFを確認することに。

AWS は、AWS システム マネージャと呼ばれるサービスを提供して。

AWS クラウドで実行されているアプリケーションと。

インフラストラクチャを管理し。

これは、コマンドライン ツールでも使用できて。

 

https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html

 

ここで気に入ったのは、SSM を介してインスタンスでリモート コマンドを。

実行するには関連するロールがインスタンスに関連付けられている必要があることで。

 

1.上記のセキュリティ認証情報を使用して、AWS CLI をインストールして設定して。

 

 $ export AWS_ACCESS_KEY_ID=
 $ export AWS_SECRET_ACCESS_KEY=
 $ export AWS_DEFAULT_REGION=
 $ export AWS_SESSION_TOKEN=

 

2.以下のコマンドを使用して。

 最初のステップで使用されたリージョンを見つけることができ。

 

 http://169.254.169.254/latest/meta-data/placement/availability-zone

 

3.send-command を使用してコマンドを実行し。

 クエリは次のようになり。

 

 $ aws ssm send-command --document-name "AWS-RunShellScript" --comment "AnyComment" --instance-ids="[Instance-id]" --parameters "commands=whoami"

 

 このコマンドの出力は CommandId を提供し。

 

 

4.3番目のステップで使用されるインスタンス ID を取得するには。

 

 http://169.254.169.254/latest/meta-data/instance-id

 

5.実行されたコマンドの出力を確認するための最終ステップ。

 (ステップ 3 の「whoami」で使用)

 

 $ aws ssm list-command-invocations --command-id="[Command_Id]" --details

 

 

ついにコマンドを実行することができ、 出力は「root」として表示され。

これが、AWS SSRF を RCE にエスカレートする方法で。

 

Best regards, (^^ゞ

A 250$ CSS Injection — My First Finding on Hackerone!を訳してみた

Hello there, ('ω')ノ

 

250 ドルの CSS インジェクションを。

 

脆弱性

 CSS インジェクション

 

記事:

 https://medium.com/@dsonbacker/a-250-css-injection-my-first-finding-on-hackerone-8863ad253560

 

今回は、どのように CSS インジェクションを発見し、ハッカーの公開プログラム内。

それを悪用したかを伝えるための初めての媒体で。

 

ページを開くと、国旗を変更する機能があることに気がついたので。

この機能がどのように機能するかを分析して。

国旗を変更するには、このエンドポイントに GET リクエストを送信するだけで済んで。

 

 https://redacted.com/search?q=a&country=BR

 

そこで、「country」パラメータの値をランダムな値に変更すると値が反映されて。

サイトは style 属性内で国パラメータを呼び出し、「.svg)」の後に追加し。

 

 <div class="language" style="background-image: url(/BR.svg)"><div>

 

これを見て、XSS を悪用するさまざまな手法をテストし始めましたが。

残念ながら効果はなく。

しばらくして、CSSを作成したとき、「/*」を使用して「.svg)」を。

コメントしたことを思い出したので。

これをロードの最後に配置すると、その要素のスタイル全体を制御できるようになり。

 

概念実証:

https://redacted.com/search?q=a&country=);width:100vw;height:100vh;background-image:url(//myserver/minions.png);/*

 

この欠陥はフィッシング攻撃に利用される可能性がありますが。

ユーザ情報を盗むには、被害者が古いブラウザを使用する必要があり。

残念ながら、「スタイル」属性から抜け出すことはできず。

そこで、低い失敗として報告することに。


学んだ教訓:

このエンドポイントはかなり前から利用可能であり、多くのハッカーはこの時点で。

Dalfox のようなツールを通過したばかりであり。

Dalfox には欠陥が見つからなかったため、この機能は安全であると結論付けて。

ツールを 100% 信頼してはならず、常にコンテキストを分析して。

反省することを学んでいただければ幸いで。

 

https://github.com/hahwul/dalfox

 

Best regards, (^^ゞ

Hatalı Yapılandırılmış AWS S3 Bucket Üzerinde Bulunan Güvenlik Açığının Yarattığı Etkiler を訳してみた

Hello there, ('ω')ノ

 

AWS S3 バケットの設定ミスによる脆弱性で情報漏えいとサブドメインの乗っ取りを。

 

脆弱性

 AWS の設定ミス

 

記事:

 https://medium.com/@gguzelkokar.mdbf15/hatal%C4%B1-yap%C4%B1land%C4%B1r%C4%B1lm%C4%B1%C5%9F-aws-s3-bucket-%C3%BCzerinde-bulunan-g%C3%BCvenlik-a%C3%A7%C4%B1%C4%9F%C4%B1n%C4%B1n-yaratt%C4%B1%C4%9F%C4%B1-etkiler-cb073179360d

 

今回は、HackerOne プラットフォームに接続されている民間企業で。

発見したセキュリティの脆弱性について。

まずは、攻撃側と防御側の両方を調べて。

会社名を XYZ とすると。


1.発見と悪用

XYZ 社では、xyz.com (*.xyz.com) のすべてのサブドメインを含むように。

カバレッジが追加され。

ここで最初のステップは、すべてのサブドメインを見つけることで。

これに使用できるツールはたくさんあり。

subfinder ツールを使用して、約 250 のサブドメインを見つけて。

 

次のステップは、これらのサイトをあらゆる角度から 1 つずつ調べることで。

見つけたすべてのドメインを一度に開く Chrome 拡張機能を使用し。

すべてのサブドメインを開いて検索を開始して。

 

https://chrome.google.com/webstore/detail/open-multiple-urls/oifijhaokejakekmnjmphonojcfkpbbh

 

次に、AWS S3 バケットサブドメイン abc.xyz.com で実行されていることがわかり。

ここで読み取り権限が制限されていない、つまり公開されていることがわかったとき。

機密情報が漏洩している可能性があると考えて。

すぐに内部のファイルを調べ始めて。

AWS cli で次のコマンドを実行した後、バケットが公開されていることを確認して。

 

 aws s3 ls abc.xyz.com

 

 

次に、サンプルを調べたところ、20 近くのサンプル テスト プロジェクトがあり。

これらは、ログインといくつかのトークンが試行された別の。

Web アプリケーションで。

 

 aws s3 ls abc.xyz.com/samples/

 

それらすべてを 1 つずつ参照し始めた後、プロジェクトのページ ソースの。

js コード内のコード ブロックが注意を引いて。

 

 

Bucket 内の別のBucketが。

開発者はここでBucket を使用していましたが、js コードで自分の名前を忘れており。

コードでも使用していて。

Bucket の名前を def とすると、このバケット、つまり def.s3.amazonaws.com に。

アクセスしたときの反応は興味深いもので。

 

 The specified bucket does not exist

 指定されたバケットは存在しません

 

つまり、このBucket を自分で取ることができ。

このタイプの脆弱性サブドメインの乗っ取りを呼んでいて。

こちらのプロジェクト https://github.com/EdOverflow/can-i-take-over-xyz から。

この脆弱性をホストしている製品と、それが悪用される可能性がある状況を。

確認でき。

つまり、当社の管理下にある会社に属するサブドメインを取得して。

 

https://github.com/EdOverflow/can-i-take-over-xyz

 

実際、コード内のBucket は使用されて削除されましたが、これには問題はなく。

外から見るとセキュリティ ホールのようには見えませんが。

Bucket を取るところからすべてが始まり。

突然、コード ブロックを発見したページにアクセスしたときに。

ログが自分たちで取ったコードのBucket に落ち始めていることを発見して。

これらのログには IP アドレスと http リクエストに関する情報が含まれているため。

ログは続行されず、エクスプロイト フェーズは終了して。

ここでは、この例で見たように、はるかに重要な情報が。

背後の API またはクラウドに安全に送信されない可能性があって。

 


2.イベントで気をつけたいこと

・機密情報を含む可能性のあるストレージ領域は、決して公開しないで。

・使用されているアプリケーションが削除された場合、作業コードが。

 残されることはなく。

 たとえば、Rest API の 3 番目のバージョンを作成している場合。

 必要でない限り v1 を使用しないように。

・S3 Bucket を使用する場合、読み取り、アップロード、および。

 削除のアクセス許可を適切に構成する必要があり。

 この例では、アップロード機能が機能していませんでしたが。

 機能していれば効果ははるかに大きかったでしょう。

・機密情報は、Javascript コードにハードコーディングしないように。

 

Best regrads, (^^ゞ

$750+ Bug Bounties: PII Disclosure W/ IDORを訳してみた

Hello there, ('ω')ノ

 

750 ドル以上のバグ報奨金:IDOR 付きの PII 開示を。

 

脆弱性

 IDOR

 

記事:

 https://thegrayarea.tech/1-000-p1-pii-disclosure-w-idor-cb344c55d52e

 

IDOR (Insecure Direct Object Reference) は、アクセス制御のバグの一種で。

これは、ユーザが管理者機能を持っているかどうかなど。

ユーザの権限に影響を与える可能性があることを意味して。

IDOR の脆弱性は通常、横方向の権限昇格 (別のユーザで同じ権限) に関連して。

発生しますが、縦方向の権限昇格 (別のユーザで高い権限) が発生する場合もあり。

ハッキングしようとしている Web サイトでは、URL は次のように表示されて。

 

 https://website.com/friend-request/?id=MjQzNDU%3D

 

その「id」パラメータは、URL エンコードされた文字列があるようで。

次のパートでは、暗号とエンコーディングについて少し知識が必要で。

これは、0 ~ 9、a ~ z、または A ~ Z 以外の何らかの文字があったことを。

示す % のおかげでわかり。

これは特殊文字でなければならないため、特殊な形式でエンコードされ。


URL のデコードとエンコード - オンライン

https://www.urldecoder.org/


Base64 デコードとエンコード - オンライン

https://www.base64decode.org/

 

id パラメータの「MjQzNDU%3D」値をデコードすると「MjQzNDU=」が得られ。

末尾の 1 つ以上の「=」の表記に基づいて、Base64 エンコーディングを。

使用している可能性があることがわかり。

これを Base64 デコーダに接続すると、数値が得られ。

 

「MjQzNDU%3D」をURL デコード

「MjQzNDU=」をbase64 デコード

24345

 

これは、ID パラメータを数値に関連付けて、いくつかの異なるエンコーディングを。

適用し、ブラウザが ID パラメータを識別すると。

パラメータを 24345 にデコードする方法を指示されていることを意味して。

 

逆に処理するには、別の数値をエンコードし。

有効な応答を返す可能性が最も高いため、24344 を使用して。

これは、論理的には、24345 がある場合、その前に番号が。

連続する必要がある可能性が高いためで。

 

24344

base64エンコードされた「MjQzNDQ=」

URL エンコードされた「MjQzNDQ%3D」

 

似ていますが、実際には「U」が「%3D」(「=」) の前の「Q」に変更されていて。

次のように URL に貼り付けて。

 

 https://website.com/friend-request/?id=MjQzNDQ%3D

 

「MjQzNDU%3D」を使用してリクエストとは異なるレスポンスを取得した場合は。

IDOR があり。

これは低レベルで、名前と HTML 上の小さな情報のみを表示して。 

 

Best regards, (^^ゞ