Shikata Ga Nai

Private? There is no such things.

Secret Key Exposure in API Config Directoryを訳してみた

Hello there, ('ω')ノ

 

API構成ディレクトリでの秘密鍵の公開を。

 

脆弱性:

 情報開示

 

記事:

 https://ahmdhalabi.medium.com/secret-key-exposure-in-api-config-directory-79cf7e7b976

 

ツール:

 Burp Suite

 Wordlist

 FFUF

 Github

 Google Dorks

 WaybackUrls


今回の範囲は、ダッシュボードのあるウェブサイトに限定されていて。

ダッシュボードをたどると、有効なバグが1つ見つかって。

次に、Burp Suiteのトラフィックを確認しているときに。

このダッシュボードのAPIが次のようになっていることがわかって。

 https://redacted.com/api

 

偵察の時間:

最初に行うべき興味深いことは、APIコンテンツとディレクトリの検出で。

そのため、カスタマイズしたWordlistとFFUFツールを使用して。

APIコンテンツをブルートフォースして。

configという興味深いディレクトリを見つけたので。

 https://redacted.com/api/config


その内容を確認したところ、下記のトークンがあることがわかって。

 LoginUrlSecretKey


その値は下記のようなもので。
 S#@x%^&$!1

f:id:ThisIsOne:20210925104030p:plain

 

キー値について追加の偵察:

おそらく、APIログインの目的で使用される秘密鍵を見つけたと思うので。

その後の目標は、トークンがどこで使用されているかを知ることで。

キーが使用されている場所や、そのキーに関連するその他の有用な情報を。

検出するために、いくつかの方法と手法を試すことに。

 

実行したステップ:

    GithubでターゲットプログラムのGithubリポジトリ内の秘密鍵を検索したものの。

 肯定的な結果は見つからず。

 Google Dorksを使用して、シークレットトークンに関連する情報を。

 見つけようとしても否定的な結果ばかりで。

 WaybackUrlsとJavascriptファイルをチェックしても。

 残念ながら否定的な結果で。

 

これは、2つの可能性があることを意味して。

 1.秘密鍵は、テスト目的で使用されるダミー鍵で。

 2.もしくは、その名前が表すように。

  また偵察でそれに関連する情報が見つからなかったので、キーは本当に秘密で。

そこで、2番目の仮定に基づいて問題を報告することに。

 

学んだ教訓:

秘密鍵、トークン、またはパスワードを見つけて、それをどのように使用できるか。

または、秘密に公開されているかどうかがわからない場合があって。

一部のプログラムは、公開されたキーがどこでどのように使用されているか。

わからないために機密性が高いことを証明できないので報告を受け入れないので。

シナリオを反対に反転させて、キーが秘密であることを証明すればよくて。

 

Best regards, (^^ゞ

Exploiting CORS to perform an IDOR Attack leading to PII Information Disclosureを訳してみた

Hello there, ('ω')ノ

 

CORSを悪用してIDOR攻撃を実行し、PII情報の開示につながるを。

 

脆弱性:

 CORSの設定ミス

 情報開示

 

記事:

https://notmarshmllow.medium.com/exploiting-cors-to-perform-an-idor-attack-leading-to-pii-information-disclosure-95ef21ecf8ee

 

ツール:

 Burp Suite

 

アプリケーションは、Eコマースプラットフォームで。

アプリケーションのビジネスロジックの脆弱性を探して。

最初の数時間は、アプリケーションのワークフローを理解しながら。

データを操作して、リピータにリクエストを送信して。

XSSなどの他の脆弱性を探していたものの、アプリケーションはかなり安全で。

 

次に、チェックアウト機能のテストを開始することに。

チェックアウト時に、アプリケーションは期待どおりに。

ユーザの配送先住所とクレジットカードの詳細を要求していて。

チェックアウトページのURLを確認すると下記のとおりで。

 https://redcorp.com/20183638/checkout/700dd776teu8890abcdpo12ha0

 

このハッシュを他のユーザのハッシュと交換すると。

チェックアウトページのカート内のアイテムが変更されるので。

これは承認の欠如を示していたものの。

アプリケーションはアカウントを交換したり。

カート内のアイテムを変更したりしていなくて。

しかも、チェックアウト時のみで。十分な影響を与えず。

他のユーザのカートのアイテムを読み込むために使用されていて。

 

その後、Burp Suiteの履歴を調べていたところ。

上記と同じハッシュを含む別のエンドポイントがみつかって。

 /wallets/checkouts/700dd776teu8890abcdpo12ha0.json

 

このハッシュは、ユーザのアカウントのデータを保存するために使用されていて。

エンドポイント「/wallets/checkouts/」は、ユーザがデータへのアクセスを。

許可されているかどうかを確認しておらず。

攻撃者のハッシュを被害者のハッシュと交換すると。

応答で被害者のアカウントのデータが読み込まれて。

 

さて、「/wallet/checkout/random_hash.json」エンドポイントで。

他のユーザのハッシュを置き換えることで。

他のユーザのすべての詳細を盗むことができるものの。

ランダムハッシュは推測が難しく、ブルートフォース攻撃は時間の無駄で。

他のユーザのハッシュを盗むことができれば。

そのユーザの名前、自宅の住所、クレジットカードの詳細などを表示できて。

 

f:id:ThisIsOne:20210925074751p:plain

 

そこで、検索機能を使用してBurp Suiteでハッシュを検索して。

どこかにリークしていないかどうかを確認すると。

トランザクションのターゲットアプリケーションに統合されて。

クレジットカード番号を検証するサードパーティアプリケーションが。

このハッシュにアクセスできて。

CORSは、リクエストからデータにアクセスすることを許可していて。

アプリケーションは、データを検証するために。

サードパーティのアプリケーションとデータを共有する必要があって。

 

さらに、これはデータへのアクセスにも役立って。

CORSは、任意のドメインがリクエストからデータを。

フェッチできるように構成されているので。

これらのデータをフェッチすることもできて。

 

攻撃者は最初にCORSを悪用してユーザのランダムハッシュを取得して。

ハッシュを置き換えて被害者のデータにアクセスして。

これには、名前、住所、クレジットカード情報、支払い情報、および。

ユーザのアカウントに関連するすべてのものが含まれていて。

CORSはブロックできないので。

エンドポイントへの不正アクセスを検証してブロックすることで修正できて。

 

Best regards, (^^ゞ

Finding Hidden Login Endpoint Exposing Secret `Client ID`を訳してみた

Hello there, ('ω')ノ

 

秘密の `Client ID`を公開している隠しログインエンドポイントの検索を。

 

脆弱性:

 情報開示

 

記事:

 https://ahmdhalabi.medium.com/finding-hidden-login-endpoint-exposing-secret-client-id-88c3c2a1af45

 

今回は、HackerOneのプライベートプログラムでの。

情報開示のバグに関するクールな発見の1つを共有することに。

 

概要 :

下記のサブドメインに出くわしたもののログインフォームがなくて。

Client IDが見つかりませんというエラーが表示されて。

 https://accounts.redacted.com/redacted/login

 

次にいくつかの偵察手順を実行して。

下記のURLにClient ID値があるログインエンドポイントを見つけて。

 https://accounts.redacted.com/redacted/redacted?client_id=hashvalue

 

このエンドポイントをどのようにして発見できたかというと。

 

ログインエンドポイントとclient_id値の検出:

下記に移動すると、Client IDが見つかりませんというエラーメッセージが表示されて。

 https://accounts.redacted.com/redacted/login

 

上記のエラーから、client_idまたはclientidという名前のパラメータが。

必要であることがわかったので。

下記のシンプルなGoogle Dorkを実行すると。

 site:accounts.redacted.com inurl:client_id


ログインエンドポイントとclient_id値が見つかって。https://accounts.redacted.com/redacted/redacted?client_id= 11111111111122222222222test222223333111

 

f:id:ThisIsOne:20210924103904p:plain

 

f:id:ThisIsOne:20210924103923p:plain

 

このclient_id値を公開することで、この値で報告された古いバグを連鎖させて。

秘密のように見えて公開されている複数のトークンを見つけることができて。


学んだ教訓 :

ログインフォームを非表示にしているエンドポイントを見つけた後に。

非表示のログインフォームを見つけることができた場合は。

これは有効なバグである可能性が高くて。

検出されたログインフォームで追加のバグを特定して。

Google Dorkを使用してclient_id値を検索すると。

非表示のログインページが見つかって。

 

Best regards, (^^ゞ

Finding Basic Authtoken in JAVASCRIPT file BY Full Automationを訳してみた

Hello there, ('ω')ノ

 

フルオートメーションによるJAVASCRIPTファイルでの基本的な認証トークンの検索を。

 

脆弱性:

 情報開示

 

記事:

 https://notifybugme.medium.com/finding-basic-authtoken-in-javascript-file-by-full-automation-6188ca1b1f56

 

Androidアプリケーションによってリークされた本番アクセストークンと。

ステージング環境のアクセストークンを見つけて。

インフラストラクチャ全体を引き継ぐ方法について説明することに。

 

必要なツール:
 gf (tomnomnom) — https://github.com/tomnomnom/gf

f:id:ThisIsOne:20210924095327p:plain


 gau(Corben) — https://github.com/lc/gau

f:id:ThisIsOne:20210924095401p:plain


 waybackurls(tomnomnom) — https://github.com/tomnomnom/waybackurls

f:id:ThisIsOne:20210924095424p:plain


 subjs(Corben) — https://github.com/lc/subjs

f:id:ThisIsOne:20210924095448p:plain

 

ステップ1:ウェイバックマシンからすべてのjsファイルの収集

ターゲットドメインがexample.comであるとすると。

すべてのサブドメインとワイルドカードがスコープ内にあって。

 

 ターゲットの範囲:*.example.com

 

 gau -subs example.com | grep “.js$” >> jsfile.txt
 subfinder -d example.com -silent | waybackurls | grep “.js$” >> jsfile.txt
 subfinder -d example.com -silent | httpx -silent | subjs >> jsfile.txt

 

 注:

 ホストをBurpでスパイダーして。

 すべてのjsファイルリンクをburpからコピーして。

 jsファイルを見逃さないようにして、jsfile.txtファイルに貼り付けて。

 ウェイバックマシンとBurpからすべてのjsファイルを抽出した後に。

 jsファイルのURLを並べ替えてファイルから。

 デッドリンクを削除するかどうかを確認して。

 シンプルに実行するだけで、デッドリンクを並べ替えて削除できて。

 

 cat jsfile.txt | sort -u | anew | httpx -silent >> jsfile_totest.txt

 

ステップ2:自動化の部分

 ケース1:curlおよびgrepコマンドを使用した自動化

 自動化のための複雑なツールやスクリプトは使わずに。

 curlやgrepなどのシンプルなツールを使用するだけで自動化できて。

 

 cat jsfile_totest.txt | xargs -I % -P 10 curl -sk “%” | grep -E -i -w -n ‘BASIC[\\-|_|A-Z0–9]*(\’|\”)?(:|=)(\’|\”)?[\\-|_|A-Z0–9]{10}’


 ケース2:wgetおよびgrepコマンドを使用した自動化

 wgetを使用して、ローカルマシンにすべてのjsファイルをダウンロードして。

 ホワイトボックステストを実行できるかどうかを確認して。

 

 mkdir localpathjs; cd localpathjs
 cat jsfile_totest.txt | xargs -I % -P 10 wget -r “%”

 

 次に、jsファイルをダウンロードしたディレクトリを変更して。

 自分のディレクトリのがlocalpathjsだとすると。

 ターミナルを使用してgrepコマンドで開いて。

 

 cd localpathjs
 root@kali:~/localpathjs# grep -E -i -w -n -r -H ‘BASIC[\\-|_|A-Z0–9]*(\’|\”)?(:|=)(\’|\”)?[\\-|_|A-Z0–9]{10}’

 

Best regards, (^^ゞ

My Fourth Account takeover through password resetを訳してみた

Hello there, ('ω')ノ

 

パスワードのリセットによる4番目のアカウントの乗っ取り

 

脆弱性:

 アカウントの乗っ取り

 パスワードリセットの欠陥

 

記事:

 https://infosecwriteups.com/my-fourth-account-takeover-through-password-reset-28a36dfebaf

 

今回は、redacted.comと呼ぶことに。

プログラムを偵察した後に、パスワードリセットを調べ始めて。

いつも(Account Takeover (ATO) 、ホストヘッダインジェクション)の脆弱性から。

ユーザがパスワードをリセットしたい場合は、メールアドレスを入力すると。

パスワードリセットリンクがメールアドレスに送信されて。

アカウントのパスワードのリセットをリクエストすると。

パスワードのリセットリンクは下記のとおりです。

 

 https://redacted.com/update-password/12d52catcbc344ec-9871-85ac6390d863/1621264272

 

パスワードリセットリンクは、ユーザIDとランダムな10桁のコードで構成されて。

ここで興味深かったのは、任意のユーザアカウントを引き継ぐことができる点で。

これは、10桁のコードがシリアルコードであるため。

ランダムな値は生成されずにシリアル値で。

つまり、パスワードをリセットするように求められた場合は。

アカウントとコードが「1618963650」で、リセットをリクエストしていて。

被害者のアカウントのパスワードは、コード「1618963720」になっていて。

最後の3つの数字のみが異なっているので、000から999の範囲で。

ブルートフォース攻撃を実行できるわけで。

 

現在の問題は、ユーザIDが公開されておらず。

このIDをリークしたエンドポイントを検索することで。

GoogleDorksを使用しても何も得られなくて。

 

そこでサイトは、ユーザが記事を公開できて。

特定の記事をユーザに報告する機能があって。

ユーザに記事を報告すると、ユーザの記事が見つかることがわかったので。

リクエストで、IDがリークされるので。

 

再現する手順 :

1.アカウントのパスワードのリセットをリクエストして。

2.被害者のアカウントのパスワードのリセットをリクエストして。

3.次に、IDを被害者IDに変更して。

 同じ10桁のコードを使用して、最後の3桁に対して。

 ブルートフォース攻撃のみを実行すると正常に完了して。

4.このリンクでブルートフォース攻撃を実行して。

 10桁のコードの下の3桁を指定して。

  https://redacted.com/update-password/12d52catcbc344ec-9871-85ac6390d863/1621264272

 

Best regards, (^^ゞ