NCC Group Plcによりオープンソースとして公開 - http://www.nccgroup.trust/
開発者: Richard Turnbull, richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
AGPLのもとで公開。詳細はLICENSEを参照
Berserkoの今後の開発は https://github.com/rteatea/Berserko で行われます。
Berserkoは、Kerberos認証を実行するためのサポートを追加するBurp拡張機能です。これは、NTLM認証がサポートされていないWindowsドメインでのテストに役立ちます（BurpはすでにNTLMを処理しています）。Berserkoは、Burpを実行しているマシンがドメインに参加している必要はありません（Windowsを実行している必要さえありません）。
Burpを使用してKerberosアプリケーションをテストするための既存の解決策として、現在私たちが知っているのは、Fiddlerをチェーンし、これらの手順に従って認証を設定する方法だけです。しかし、FiddlerはWindows専用であり、プロキシをチェーンすると複雑さが増し、パフォーマンスが低下するため、Burp自体にKerberos機能があると便利です。
最新のBerserko jarファイルをReleasesタブまたはberserko\releasesフォルダから入手してください。
BurpのExtenderタブに移動し、Addを選択し、Extension typeとしてJavaが選択されていることを確認してから、jarファイルを指定します。うまくいけば、BerserkoタブがBurp UIに追加されます。
BurpのBerserkoタブにはさまざまなコントロールがあります。
Do Kerberos authenticationチェックボックスはマスタースイッチです。これが有効になるまで、Berserkoは何も行いません。
Restore defaultsボタンは、Berserkoをデフォルト設定（ドメイン情報やユーザー資格情報が含まれていない状態）に戻します。
Clear Kerberos stateボタンは、クライアント上のすべてのKerberosチケットとその他の状態をクリアします。これを使用する必要があるのは、サーバー側のKerberos設定に変更が加えられ、新しい状態から開始したい場合だけです。
Write tickets to logボタンは、現在のKerberosチケットに関する情報をBerserkoのログストリームに書き込みます。これはデバッグやトラブルシューティングに役立ちます。ログを表示するには、BurpのExtenderタブに移動し、Berserkoを選択して、下のOutputタブを確認します。チケットデータでGUIのログバッファが簡単にいっぱいになるため、ここでSave to fileオプションを使用するのが合理的かもしれません。
一部のコントロールには、詳細情報をポップアップ表示するヘルプボタンがあります。
このセクションのコントロールを使用して、Domain DNS NameとKDC Hostを指定します。テキストボックスは直接編集できません。変更するには'Change'ボタンを使用する必要があります。
Domain DNS Nameは、認証対象のドメインのDNS名（正確にはKerberosレルム）にする必要があります。これはmydomain.acme.localのような形式にします。ドメインのNETBIOS名（MYDOMAINのような形式）であってはなりません。
KDC Hostは、Kerberos KDC（Key Distribution Center）のホスト名（またはIPアドレス）にする必要があります。Windowsドメインでは、KDCは単にドメインコントローラです。
Domain DNS Nameを入力したら、Autoボタンを使用してKDCを自動的に見つけることを試みられます。これは、Kerberosサービスに対してDNS SRVクエリを送信することで行われます。DNSサーバーのいずれかが正しいドメインのドメインコントローラであれば、これは機能するはずです。そうでなければ機能しません。❗この機能は最近のバージョンのBurpでは機能しません。必要なDNSライブラリがバンドルされているJREの一部として提供されていないためです。このREADMEの上部で説明されているように、フルJREで起動することで回避できます。❗
Domain DNS NameとKDC Hostを入力したら、Test domain settingsボタンを使用して接続をテストします。うまくいけば、Successfully contacted Kerberos serviceという応答が返ります。
これらのドメイン設定に正しい値を取得する方法の詳細については、このファイルを参照してください。
このセクションのコントロールを使用して、ドメインアカウントのUsernameとPasswordを指定します。テキストボックスは直接編集できません。変更するには'Change'ボタンを使用する必要があります。
Usernameは単純なユーザー名のみにする必要があります。bobのような形式にします。MYDOMAIN\bobや[email protected]などであってはなりません。
資格情報を入力したら、Test credentialsボタンを使用できます。これにより、指定したユーザーのKerberosチケット発行チケット（TGT）の取得が試行されます。成功すると、TGT successfully acquiredという応答が返ります。失敗した場合、これはドメイン認証の試行であるため、アカウントがロックアウトされないように注意してください。
*Save password in Burp config?*チェックボックスにチェックを入れない限り、パスワードは次回のためにBerserko設定に保存されません。ただし、他のすべての設定は保存されます。
一部のアプリケーションは、サーバー側でKerberos委譲を使用してクライアントのIDを他のサーバーに転送します（ただし、クライアント側からこれが使用されているかどうかを簡単に判断する方法はありません）。
Berserkoはこれをサポートしていますが、1つ問題があります。委譲は、ユーザーがforwardable（転送可能な）TGT（チケット発行チケット）を持っている場合にのみ機能します。残念ながら、JavaのKerberos実装には、転送可能なチケットを取得することをプログラムで指定する方法がありません。これは、krb5.conf設定ファイルに適切なエントリを追加することでのみ行えます。
したがって、委譲を機能させるには、Berserkoを適切なkrb5.confファイルに向ける必要があり、ここでは2つのアプローチが考えられます。
最も簡単な方法であり、推奨されるアプローチは、Create krb5.conf fileボタンを使用することです。これにより、選択した場所に適切なファイルが作成されます。一時ディレクトリ、プロジェクトディレクトリ、その他どこにでも配置できます。ただし、同じファイルを無期限に再利用できるため、より恒久的な場所に配置するのが合理的かもしれません。Changeボタンを使用すると、使用する別のファイルを選択できます。
興味があれば、作成されるkrb5.confファイルは非常に単純で、次の内容になります:
[libdefaults]
forwardable = true
あるいは、Changeボタンを使用して、システム上の既存のkrb5.confファイルを指定することもできます。これを行う必要があるのは、このファイルにBerserkoに読み取らせたい他の重要なKerberos設定がある場合だけです（理論上は問題なく機能するはずですが、実際にはテストされていません）。このファイルのLinuxでのデフォルトの場所は/etc/krb5.confであることに注意してください。他のオペレーティングシステムには存在しない可能性が高くなります。既存のkrb5.confファイルを指定する場合は、転送を有効にするように編集してください。[libdefaults]セクションにforwardable = trueを追加します（または各レルムに個別に追加します）。ただし、注意してください。Berserkoにファイルを作成させる方が99%の場合は良い選択です。
委譲設定が成功しているかどうかを確認したい場合は、Check current configボタンを使用します。これにより、krb5.confファイルが見つかったかどうか、およびforwardable設定が正しいかどうかがわかります。また、Test credentialsボタンを使用すると、Berserkoが転送可能なTGTの取得に成功したかどうかも通知されることに注意してください。
アプリケーションの使用を開始する前に、転送可能なチケットを取得していることを確認することをお勧めします。IISはサーバー側でユーザーの認証ステータスをキャッシュするため、転送可能でないチケットから転送可能なチケットへの切り替えが機能しない場合があるようです。
このセクションの設定は、BerserkoがKerberos認証を「リアクティブ」（サーバーから401応答を受信するのを待ってから、Kerberos認証ヘッダーを追加してリクエストを再送信する）で試行するか、「プロアクティブ」（送信リクエストにKerberos認証ヘッダーを追加する）で試行するかを制御します。
プロアクティブ認証の利点は、HTTPラウンドトリップが1回だけで済むのに対し、リアクティブ認証では2回必要になることです。プロアクティブ認証の欠点は、Kerberos認証ヘッダーがそれを期待していないホストに送信される可能性があることです。また、Berserkoはリアクティブストラテジーを使用する場合に認証エラーをより適切に診断できます。
Proactive Kerberos authentication, only after initial 401 receivedオプションは、これら2つのアプローチのハイブリッドです。Berserkoはホストへの最初のリクエストではリアクティブに認証しますが、その後はプロアクティブになります。
このセクションでは、Kerberos認証のスコープと見なされるホストを定義できます。
デフォルトでは、All hosts in this Kerberos domain in scope for Kerberosボックスがチェックされます。つまり、Berserkoはホスト名がドメインDNS名で終わるWebサーバーに対してのみKerberos認証を試行します。多くの状況ではこれで十分です。ただし、この形式ではないホスト名を持つKerberos対応Webアプリケーションが存在する可能性があります（管理者が適切なサービスプリンシパル名を設定している場合）。これに対応するために、右側のリストボックスを使用して、スコープと見なす追加のホストを追加できます。ワイルドカードを使用できることに注意してください（*は0文字以上の文字に一致、?はドット以外の任意の文字に一致）。
あるいは、All hosts in scope for Kerberos authenticationボックスにチェックを入れることもできます。明らかに、これは手動でスコープを指定する手間が不要になるという利点があります。この設定の潜在的な欠点は、Berserkoがドメイン内にないホストのサービスチケットを取得するためにKDCにKerberosリクエストを送信する可能性があることです。これによりパフォーマンスの問題が発生したり、プライバシーの問題が発生したりする可能性があります（この情報がKDCに漏れることを望まない場合）。これは特にProactive Kerberos authenticationストラテジーで問題になる可能性が高く、その場合BerserkoはBurpを通過するすべてのリクエストにKerberos認証ヘッダーを追加しようとします。このオプションの組み合わせは推奨されず、選択された場合Berserkoは警告を表示します（ただし、実際に防止はしません）。
All hosts in this Kerberos domain in scope for KerberosとAll hosts in scope for Kerberos authenticationのどちらも選択されていない場合、スコープ内のホストはリストボックスに追加されたものだけになります。
Plain hostnames considered part of domainオプションは、選択された場合、「プレーンなホスト名」（つまり単一のコンポーネントのみで構成されるホスト名）がドメインの一部と見なされることを意味します（したがって、All hosts in this Kerberos domain in scope for Kerberosが選択されている場合は自動的にスコープ内になります）。これを無効にしたい主な理由は、マシンがBerserkoを使用して認証しているドメインとは異なるドメインに参加している場合です（その場合、プレーンなホスト名はおそらく参加しているドメイン内のホストを参照します）。
Do not perform Kerberos authentication to servers which support NTLMオプションを選択すると、Kerberosに加えてNTLMもサポートするホスト（つまり、WWW-Authenticate: NTLMとWWW-Authenticate: Negotiateの両方のヘッダーを返すホスト）に対してKerberos認証を試行しないようにBerserkoに指示します。
Alert LevelとLogging Levelは、ここでNONE、NORMAL、またはVERBOSEのいずれかに設定できます。
Alert Levelは、BurpのAlertsタブに送信される情報量を制御します。
Logging Levelは、Berserkoの標準出力に送信される情報量を制御します（これはExtenderタブで表示できます）。Logging LevelをVERBOSEに上げると、発生する可能性のあるエラーや例外についてより多くの情報が提供されることに注意してください。
環境でKerberosドメイン信頼が使用されている場合、ここにガイダンスがあります。
デフォルトでは、BerserkoはKDCとのすべてのKerberos通信をUDP（ポート88）で行います。代わりにTCPを使用したい場合は、それが可能です。これを行う最も一般的な理由は、おそらくTCPポート88のSSHポートフォワードを使用している場合です。krb5.confファイルにudp_preference_limit = 1を追加するだけで、次のようになります:
[libdefaults]
forwardable = true
udp_preference_limit = 1
krb5.confファイルに[berserko_spn_hints]セクションを含めることで、特定のホストに使用されるSPNを設定できます（上記参照）。構文は次のとおりです。
[berserko_spn_hints]
[email protected]
server2.bar.org=app.domain2.local
ターゲットサーバーは等号の左側にあり、使用するSPNは右側にあります。SPNのレルムはオプションで指定できます（指定しない場合、Berserkoは通常どおり正しいレルムを決定しようとします）。ここにSPNのHTTP/部分を含めないでください。
Berserkoはv2020.5.1より前のBurp v2と互換性がありません。 Burp v1には問題ありません。
これは、以前のBurp 2バージョンに同梱されているOpenJDKのバージョンに、Berserkoが使用するKerberos機能の一部が含まれていないことが原因です。これにより、Berserkoを使用しようとするとjava.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContextエラーが発生します。
明らかな回避策は、v2020.5.1以降にアップグレードすることです。あるいは、完全版のJavaランタイム環境（つまり、Burpにバンドルされているものではないもの）を使用して起動すれば、Berserkoは任意のBurp v2バージョンで動作するはずです。
javaがパスに含まれていると仮定します:
java -jar burpsuite_pro.jar
コマンドラインからの起動については、Burpのドキュメントを参照してください。