はじめに
なぜ、LoginMacroについて書こうと思ったのは、
ほとんどのWEBの記事ではLoginMacroについて記載がない為ご紹介しようと思いました。
※もっといいやり方があるから記事がないのかもしれないです。あったら、教えてください。
今回はBurpSuiteでLoginMacroの作り方をご紹介します。
間違っているところや、もっといいやり方があると思いますが生暖かい目でみてください。
LoginMacroとは
簡単に言うと、ログアウトされたら自動でログインしてくれるよってことです。
LoginMacroとはIntruderやActiveScanなどを使用する時、自動ログインをさせる為に作成します。
Intruderとは対象リクエストのパラメータなどに対して任意のペイロードを総当たり的に送りつけることができるBurpSuiteの強力な機能の一つです。
ですが、ログイン後のリクエストに対してIntruderを使用しているとエラーなどの原因でログアウトしてしまう場合があり、ログアウト後の通信に変わってしまいます。
その場合はログインから対象リクエストに辿り付くまでの通信をマクロに設定し、対象通信までアクセスすることがありますがそれでは無駄なログインをしてしまうことで時間がかかってしまいます。
そのような時間を減らすためにLoginMacroを作成します。
LoginMacroといのは一度ログインして発行されたクッキーを保持してクッキーの有効時間が切れるまでログインを行うことなく対象リクエストにパラメータを送信でき、クッキーの有効期間(ログアウト)の時間がきれた時の再度ログインを行うマクロのことです。
※私、個人がそのようなマクロをLoginMacroと呼んでいます。
LoginMacroを作成することにより、毎回不要なログインをすることなく対象リクエストにアクセスすることができるので大量のペイロードを送信する際はIntruderの終了する速度が非常に速くなります。
Intruder以外でもマクロが使用することができれば、LoginMacroを使用することができます。
それでは実際にLoginMacroを作成してみましょう。
LoginMacroの作り方
今回はOWASP Broken Web Apps VM v1.2に入っているDVWA(Damn Vulnerable Web Application)のログインを対象にLoginMacroを作成していきます。
使用するBurpSuiteはCommunityEdition v2020.12.1を使用します。
まずは、ログイン後にある対象リクエストを選びます。
今回はSQL Injectionの脆弱性が存在するリクエストを対象にします。
User ID:の入力欄にシングルクォーテーションを入力するとSQLのエラーが表示されます。この通信をログアウトを行われても、Repeterで再現することができればLoginMacroの作成に成功したといことにします。
ログイン状態(クッキーの有効期限が切れていない状態)であればRepeterでは下記Responseのように通信を発生させることができます。
ですが、クッキーの有効時間がきれてしまいログアウト状態になるとResponseが302 Foundになりログインページにリダイレクトされます。今回はログインクッキーであるPHPSESSIDを削除してログアウト状態としています。
このようにログアウトしてしまった時に、再度ログインを行い対象リクエストにペイロードを送れるように作成していきます。
そこでログインチェックを行うための通信をキャプチャします。今回の場合はログイン後に表示されるTOP画面を表示するリクエストにします。
ログイン状態のResponse
ログアウト状態のResponse
まずは、MacrosのAddボタンをおします。
対象通信を選択し、OKボタンを押します。
続いてはLoginMacro本体を作成していきます。
ProjectOptionsのSession Handling RulesのAddボタンを押します。そしてRuleActionsをCheck session is validを選択します。今回はCheck session is validといのは条件分岐を行うような設定だと思っていればよいと思います。詳しいことはBurpSuiteの公式ドキュメントを読んでみてください。
まずは、Make request(s) to validate session: のRun macroにチェックをいれて、先ほど作成したLogin Checkマクロを選択します。
Define behavior dependent on session validity:のif session is invalid, perform the action below:にチェックを入れます。そして、Addボタンを押します。
そして、ログイン時の通信をキャプチャし、OKボタンをおします。
ログインのマクロを選択状態にします。
その次にログイン状態を判定するためにログアウトされているResponseから文字列を選択します。今回は302 Foundを設定します。ここの判定の文字列はサイトによって大きく変わります。
Inspsect response to determine session validity:の箇所にLocation(s):のチェックをHTTP headersにチェックし、Look for expression:の欄に判定文字列の302 Foundを設定します。
※Location(s):のチェックは判定する文字列がどの場所にあるかによって変更します。
そして、Update only th following parameters:にチェックをいれてOKボタンをおします。
もっかい、OKをおします。
最後にSession Handring RulesのマクロをLoginMacroにチェックをいれます。
これでLoginMacroの完成です。
LoginMacroの動作確認
それではLoginMacroがきちんと動作するかどうか確認していきましょう。
まずは、LoginMacroを作成していた時にキャプチャしているクッキーを無効化するためにサイトをログアウトをします。
はじめに対象にしていたSQLInjectionのリクエストを再度Repeterで送信します。しかし、LoginMacroが動作した為、SQLInjectionのResponseが302 FoundになることはなくSQLのエラーを取得することができました。
Repeter上では実際にLoginMacroが動いているかどうかわかりません。そこで、ExtenderであるLogger++を使用して通信ログより、LoginMacroの動作を確認します。
※Logger＋＋はマクロ組む時にめちゃくちゃ便利です！！
リクエストを送信した際は下記のような通信が発生しログインをおこなっていることがわかります。オレンジ色の部分がログインチェックを行なっています。実際に302 Foundになっている為、その後の通信にログインの通信が発生し対象リクエスに到達しSQLのエラーを取得することができています。
※うまく行かない場合はBurpSuiteがクッキーを保持している場合もあるので、徹底的にクッキーを削除します。
もう一度、SQLInjectionのリクエストを送信します。
今度はログインチェックのResponseでは302 Foundにはなっていない為、ログインの通信が発生していないことがわかります。
以上で、LoginMacroの作成方法となります。
これで大量にペイロードを送りつける時もログインを毎回行わずにIntruderを安心して動作させることができ素早く結果を取得することができます。
※今回はRepeter上での再現しか記載していませんが、Intuderを実行させる前に必ずRepeterで作成する為です。私はRepeterで再現できたとしてもIntruderを実行する時はしばらく正常にマクロが動いているか通信ログをみて確認しています。これは、たまに想定外の通信が発生してしまいLoginMacroが正常に動かない時がある為です。
まとめ
- IntruderやActiveScanなど大量のペイロードを送信したい場合にLoginMacroの恩恵をうけることができる。
- LoginMacroを作成するのはそんなに難しいわけではない。 ※実稼働しているWebサイトはCSRFTokenの引き継ぎが必要だったり、ヘッダーにCSRFTokenが存在したり、もっと作成するのが複雑化する可能性はあります。
- ログインチェックを行う際の文字列はサイトのResponseによって変更する
- Logger＋＋は非常に便利
- Intruderも非常に便利
バージョン
- OWASP Broken Web Apps VM v1.2
- BurpSuite CommunityEdition v2020.12.1
- Logger++ Version:3.13
免責事項
本記事は情報セキュリティにおける攻撃の理解、防衛のスキル向上を目的としたセキュリティに関する内容がございます。本記事の内容を使用し発生した如何なる損害や損失について、当記事作成者は一切の責任を負いません。
本記事の内容を実際に使用して、第三者の個人や組織などを攻撃した場合は
法律により罰せられる可能性がありので、必ず自身が所有している環境のみを
対象とし、他人や組織が所有している環境は決して対象としないようお願いします。