Finding a P1 in one minute with Shodan.io (RCE)を訳してみた

Hello there, ('ω')ノ

Shodan.io（RCE）で１分でP1を見つけるを。

脆弱性：

　RCE

記事：

　https://medium.com/@sw33tlie/finding-a-p1-in-one-minute-with-shodan-io-rce-735e08123f52

ターゲットにしていた脆弱性報奨金プログラムを持っている会社が。

所有するShodanでランダムサーバを探していると。

スコープ内にある２つのJenkinsインスタンスに出くわして。

そのうちの一つのインスタンスははるかに興味深いもので。

ログイン画面に新しいアカウントを作成するためのリンクがあって。

サインアップすると問題なく動作して。

ログイン後、ユーザ名、ビルド履歴など、すべてを見ることができて。

次にJenkinsには、サーバ上でコマンドを実行する簡単な方法があるので。

試してみることに。

そのために、jenkins-subdomain.redacted.com/scriptにアクセスすると。

コマンドを記述して実行できるコンソールがあって。

上の図では、lsコマンド（“ls /”.execute().text）の出力を確認できて。

これは、サーバのルートディレクトリ内のフォルダを出力として返すのでRCEで。

学んだ教訓：

バグバウンティプログラムを実行している会社が。

Jenkinsインスタンスをこのように誤って構成する可能性が。

あるのではないかと疑問に思われるかもしれませんが。

この場合、Jenkinsをインストールした開発者は。

非標準のポートで実行するだけでインターネット全体から。

隠すことができると考えていたように推測できて。

残念なことに、Shodanのような検索エンジンは。

このような隠すことによるセキュリティは機能せず。

Best regards, (^^ゞ

OTP Bypass - Developer’s Checkを訳してみた

Hello there, ('ω')ノ

OTPバイパスを。

脆弱性：

　OTPバイパス

記事：

　https://shahjerry33.medium.com/otp-bypass-developers-check-5786885d55c6

概要 ：

OTPは、１回のログイン試行に使用するために自動的に生成される。

文字または数字の文字列で。

OTP、完全なワンタイムパスワードは、SMSまたはプッシュメッセージングを介して。

ユーザの電話に送信でき、Webベースのサービス、プライベート資格情報、および。

データを保護するために使用されて。

今回、OTPのいくつかのバイパスをチェックしていると。

アプリケーションのコードといくつかのボタンを確認しているときに見つけたので。

これをDeveloper’s Checkと呼ぶことに。

ここでの間違いは、アプリケーションがクライアント側でOTPチェックしていて。

簡単に識別できるので、誰でも簡単にOTPをバイパスできて。

この脆弱性を見つける方法は下記のとおりで。

１．ターゲットのWebサイトに移動して。

２．ここで登録するオプションがあり。

　ログイン用のOTPが送信されるとOTPを受信して。

３．[Continue]ボタンを右クリックし、要素の検査をクリックして。

　OTPチェックを検証するいくつかの機能をチェックして。

４．以下のスクリーンショットで、それらが「checkOTP（event）」と呼ばれる。

　関数であることがわかって。

５．矢印をクリックして、ブラウザのコンソールにイベントを入力するだけで。

６．矢印をクリックすると、デバッガでファイルが開き。

　モバイルに送信されたOTPが表示されて。

論理コード：

<script type=’text/javascript’>
function checkOTP(e)
{
　if (document.getElementById(“txtOtp”).value == 8951)
　{
　　var formSignUp = document.getElementById(“formSignUp”);
　　formSignUp.submit();
　}
　else
　{
　　var divWrongOTP = document.getElementById(‘divWrongOTP’);
　　divWrongOTP.style.display = ‘inline’;
　　e.preventDefault();
　　return;
　}
}

function resubmitOtp()
{
　location.reload();
}
</script>

ここで、「(document.getElementById(“txtOtp”).value == 8951)」かどうかを。

確認できて。

これは、入力したOTPが「8951」と一致する場合、ログインが成功するわけで。

Best regards, (^^ゞ

How I got access to critical data of a Company in no time ?を訳してみた

Hello there, ('ω')ノ

会社の重要なデータにすぐにアクセスするにはどうすればよいかを。

脆弱性：

　情報開示

　レート制限の欠如

　ブルートフォース

記事：

　https://medium.com/@kaustubhk80/how-i-got-access-to-critical-data-of-a-company-in-no-time-6c396aee21c0

今回、見つけたバグの１つは、データがいかに重要でありながら。

悪意のある人の手に渡った場合に非常に危険であるかについて。

企業に認識を広めるために、それを記事で説明するきっかけとなって。

端的に言えば、この会社のプライベートプログラムを長い間フォローしており。

バグを頻繁に報告していて。

プライマリドメインの１つは、ユーザが会社のソフトウェアを使用して。

またはWebコンソールを介して接続できるようにする一意の会議IDを。

入力することで、企業の会議に接続するためのゲートウェイで。

招待状または有効な会議IDがないと、会議に接続できず。

下記は、会議に接続するためのコンソールで。

コンソールは会議を接続するために一意の桁数を受け入れていたので。

最初に頭に浮かんだのは、レート制限を確認して。

時間を節約するために数字の範囲を見つけることで。

すぐに、その会社の会議IDを調べて、推測するためにGoogleを起動して。

会社のサブドメインで公開されているFAQドキュメントから。

いくつかのIDを取得することができて。

回答を確認するために、それらのドキュメントに記載されているIDを。

ランダムに入力すると、入力したIDがかつて有効な会議IDであったことが。

下記の会議ID入力後の応答で確認できて。

応答を見た後、有効な会議IDを取得できるかどうかを確認するために。

さまざまな番号を想定することを考えて。

Burpでリクエストをキャプチャし、Number’s Payloadによって。

INtruderを介して攻撃することに。

以下は、攻撃が実行された後に得られた応答で。

IDのLengthが変更されたため、それらが有効な会議IDである可能性があると。

確信して。

取得したすべてのIDが有効な会議IDとして受け入れられ。

コンソールをバイパスしてさまざまな場所で複数の会議を接続することができて。

これは非常に重大な欠陥であり。

組織の評判を損なう可能性のある誤った意図を持っている人によって。

悪用される可能性があって。

下記は、会議にアクセスした後のコンソールで。

この種の脆弱性は、重要なクライアントデータ、つまり組織の評判を損なうために。

さまざまな方法で悪用される可能性のあるユーザデータに関係する可能性があるため。

真剣に受け止める必要があって。

Best regards, (^^ゞ

nucleiを使用してキャッシュポイズニングの脆弱性を発見する方法について書いてみた

Hello there, ('ω')ノ

Nucleiを使用したキャッシュポイズニング

nucleiを使用して、Webアプリケーションの。

キャッシュポイズニングの脆弱性を発見するには。

次のような一般的なキーなし入力ヘッダを使用する必要があって。

　X-Forwarded-Prefix: cache.my_evil_dns.com
　X-Forwarded-Host: cache.my_evil_dns.com
　X-Forwarded-For: cache.my_evil_dns.com
　X-Originating-IP: cache.my_evil_dns.com
　X-Remote-IP: cache.my_evil_dns.com
　X-Remote-Addr: cache.my_evil_dns.com
　X-Client-IP: cache.my_evil_dns.com

キャッシュポイズニングの脆弱性をトリガするには。

次の２つのリクエストが必要で。

　１．サーバがポイゾニングされた応答をキャッシュ
　２．サーバからポイゾニングされた応答を取得

このシナリオを実行するために。

以下に示すようにnucleiテンプレートを作成して。

id: cache-poisoning    
​
info:
  name: HTTP Cache Poisoning
  author: sirpedrotavares / seguranca-informatica.pt
  severity: medium
​
requests:
  - raw:
      - |
        GET /?evil=007 HTTP/1.1
        X-Forwarded-Prefix: cache.my.evil.dns.com
        X-Forwarded-Host: cache.my.evil.dns.com
        X-Forwarded-For: cache.my.evil.dns.com
        X-Originating-IP: cache.my.evil.dns.com
        X-Remote-IP: cache.my.evil.dns.com
        X-Remote-Addr: cache.my.evil.dns.com
        X-Client-IP: cache.my.evil.dns.com
​
      - |
        GET /?evil=007 HTTP/1.1
​
    req-condition: true
    matchers:
      - type: dsl
        dsl:
          - 'contains(body_2, "cache.my.evil.dns.com") == true'

このテンプレートは、下記のPortSwiggerLabを使用してテストできて。

https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-with-an-unkeyed-header

下記を実行して、取得に成功して。
　.\nuclei.exe -u target_url -t .\nuclei-templates-master\sirpedrotavares\cache-poisoning.yaml

Best regards, (^^ゞ

H2.CL request smugglingをやってみた

Hello there, ('ω')ノ

フロントエンドサーバがHTTP/2リクエストの長さがあいまいな場合でも。

ダウングレードするため、リクエストの密輸に対して脆弱で。

ラボを解決するには、リクエストの密輸攻撃を実行して。

被害者のブラウザがエクスプロイトサーバから。

悪意のあるJavaScriptファイルをロードし、alert(document.cookie)を呼び出して。

被害者のユーザは10秒ごとにホームページにアクセスして。

リクエストをリピータへ。

Content-Length:0ヘッダを含めて、HTTP/2リクエストの本文に。

任意のプレフィックスを密輸してみると。

送信するリクエストが404レスポンスを受信することを確認して。

バックエンドが密輸されたプレフィックスに。

後続のリクエストを追加したことを確認して。

次にGET /resourcesのリクエストを送信すると。

https://YOUR-LAB-ID.web-security-academy.net/resources/に。

リダイレクトされるので。

下記のリクエストを作成して、任意のHostヘッダとともに。

/resourcesのリクエストを密輸することに。

このプレフィックスをフロントエンドを超えて密輸すると。

接続時の後続のリクエストを任意のホストにリダイレクトできるので。

エクスプロイトサーバで、ファイルパスを/resourcesに変更して。

本文にalert(document.cookie)を入力し、エクスプロイトを保存して。

Hostヘッダがエクスプロイトサーバを指すようにして。

リクエストを数回送信し、エクスプロイトサーバへのリダイレクトを受信すると。

被害者がエクスプロイトサーバーにリダイレクトされて。

クリアできた。

Best regards, (^^ゞ