CVE-2023-22501 の FAQ
全般的な情報
Jira Service Management Server および Data Center で重大な深刻度の認証の脆弱性が見つかりました (CVE-2023-22501)。詳細をこちらでご確認ください。
このページでは、この脆弱性に関するよくある質問をまとめています。新しい情報が公開されたら、アトラシアンのセキュリティ チームがこのページを更新します。
クラウド インスタンスは影響を受けますか?
いいえ、Atlassian Cloud インスタンスは脆弱性を持たず、お客様による対応は不要です。
私のインスタンスはインターネットに公開されていません。この場合もアップグレードは推奨されますか?
はい。インスタンスをインターネットに公開しないことは攻撃対象を大きく狭めますが、セキュリティ修正が利用可能であるときはアップグレードすることを常に推奨しています。当社では、お客様が範囲と影響を判断できるよう、可能な限り多くの情報を提供することを心がけています。インスタンスへの外部アクセスの有無などの脆弱性を軽減する要素が、アップグレードのインストールを見送れるほどビジネスへのリスクを軽減しているかどうかの判断は、最終的にはお客様がこれらの情報に基づいて行う必要があります。
私のインスタンスではパブリック サインアップが有効化されていますが、SSO が有効化された外部のユーザー ディレクトリを利用しています。引き続きアップグレードが推奨されますか?
はい。読み取り専用のユーザー ディレクトリまたは SSO 経由で Jira に同期されたユーザーは影響を受けませんが、そのインスタンスとメールででやり取りするカスタマーは SSO が設定されていても引き続き影響を受けます。
ユーザーのパスワードが攻撃者によって変更された場合に通知は送信されますか?
パスワードの設定時に通知やメールは送信されません。
アカウント作成でメール確認を要求する設定を無効化することでこの脆弱性を軽減できますか?
いいえ、この脆弱性を軽減するのは次のいずれかのアクションのみです。
Jira Service Management を、勧告 (こちら) に記載されたいずれかの修正済みバージョンにアップグレードする
勧告 (こちら) に含まれるバージョンごとの JAR ファイルを更新する。
何らかのプロジェクト権限スキーマでこの脆弱性からインスタンスを保護することはできますか?
いいえ、この脆弱性の利用を防止するには、Jira Service Management のアップグレードまたはバージョンごとの JAR ファイルのアップグレードが必要です。この脆弱性の軽減策は勧告 (こちら) で確認できます。
何らかのプロジェクト設定でこの脆弱性からインスタンスを保護することはできますか?
いいえ、この脆弱性の 利用を防止 するには、Jira Service Management のアップグレードまたはバージョンごとの JAR ファイルのアップグレードが必要です。この脆弱性の軽減策は勧告 (こちら) で確認できます。
Jira Service Management がすでに攻撃を受けているかどうかを確認することはできますか?
恐縮ながら、お客様の Jira Service Management インスタンスが攻撃を受けたかどうかを弊社側で確認することはできません。
しかしながら、Jira Service Management のアップグレードまたはバージョンごとの JAR ファイルでのインスタンス更新後に、影響を受けた可能性のあるアカウントの一覧を取得できます。脆弱性を持つバージョンのインストール以降にパスワード変更とログインが発生したアカウントは攻撃されたアカウントである可能性があります。
攻撃された可能性のあるアカウントを見つける
1. Jira Service Management をアップグレードするか、バージョンごとの JAR ファイルでご利用のインスタンスを更新します。
2. Jira の再起動後、プロパティ com.jsm.usertokendeletetask.completed をポールして値 "TRUE" を確認することでアップグレード タスクの完了を確認します
(200,000 ユーザーのテスト インスタンスで 20 分未満)
select * from propertyentry where property_key = 'com.jsm.usertokendeletetask.completed';3. 次の SQL を実行します。
SELECT CWD_USER.*
FROM CWD_USER_ATTRIBUTES
JOIN CWD_USER ON CWD_USER.ID = CWD_USER_ATTRIBUTES.USER_ID
WHERE (USER_ID in
(SELECT USER_ID
FROM cwd_user_attributes
WHERE attribute_name='password.reset.after.vulnerable.install'))メール アドレスの確認 (および修正)
この一覧を使い、アカウントに関連付けられたメール アドレスが攻撃者によって変更されている可能性がないことを確認します。
内部ユーザーについては正しいメール ドメインを確認します
パブリック サインアップを行ったユーザーについてはユーザー名とメール アドレスが同一であることを確認します
強制パスワード変更
複数ノードの Data Center (コマンドラインのみ)
これはすべてのノードで行う必要があります。
攻撃を受けた可能性のあるすべてのユーザーに対して強制パスワード変更を行うことを推奨します。このため、メール アドレスが正しいことの確認がクリティカルです。
各ユーザーの強制パスワード変更は PUT /rest/api/2/user/password で行なえます。詳細については次のページをご確認ください。 https://docs.atlassian.com/software/jira/docs/api/REST/9.5.0/#api/2/user-changeUserPassword
cURL リクエストの例
curl --location --request PUT 'http://NODE_IP/rest/api/2/user/password?username=USERNAME' \
--header 'Authorization: YOUR_AUTH_INFO' \
--header 'Content-Type: application/json' \
--data-raw '{
"password": "NEW_PASSWORD"
}'これによってセッションが強制的に失効し、攻撃者がいる場合はログアウトされます。その後、影響を受けたユーザーには、パスワードを忘れた場合のワークフローに従ってアカウントを復元するよう依頼します。
サーバーまたはシングルノードの Data Center (UI のオプション)
ユーザー管理画面
jiraBaseUrl/secure/admin/user/UserBrowser.jspaに移動します。ユーザー名を利用して検索および選択します。
さらなる調査
ユーザーの公開プロフィールに移動してアクティビティ ストリームを確認することで、Jira チケットでの最近のやり取りを確認できます。
<jiraBaseUrl>/jira/secure/ViewProfile.jspa?name=customer私のインスタンスが攻撃されていました。どうすればよいですか?
恐縮ながら、お客様のインスタンスが攻撃を受けたかどうかを弊社側で確認することはできません。内部のセキュリティ チームに詳細な調査を依頼することを強くおすすめします。ご利用の Jira Service Management Server/DC インスタンスへの攻撃が確認された場合は、サーバーを即座にシャットダウンしてネットワーク/インターネットから切断することを推奨します。また、攻撃を受けたシステムとユーザー基盤を共有していたり、同じユーザー名/パスワードの組み合わせを利用していたりする他のシステムがあれば、それも即座にシャットダウンします。その後、社内のセキュリティ チームとともに、侵害の範囲や復旧方法を検討します。
ソフトウェア メンテナンスが失効している場合、パッチ/アップグレードをインストールするために更新する必要がありますか?
はい、アップグレードを行う際は、そのバージョンのリリース時点でアクティブであったライセンスが必要です (ライセンスが 25 日に失効している場合、26 日にリリースされたバージョンへのアップグレードは不可能)。ライセンスが有効でない場合、アップグレードが製品でブロックされます。
この脆弱性のことを知りませんでした。アトラシアンはいつどのようにこの情報を共有したのでしょうか
当社で修正の構築後、製品の技術アラートのリストにサブスクライブされたすべてのお客様にアラートを送信しています。このリストへの参加状況は https://my.atlassian.com/email で確認できます。
I updated my instance with the version-specific JAR file to mitigate the vulnerability but my Instance Health Check via the Atlassian Support Tools plugin continues to display that my instance is affected, why is that?
The Instance Health Check is solely based on application version so your application is safe if it has been updated with the version-specific JAR file according to the instructions included in the advisory, located here.