OCO-ServerのMDMに認証不備、1.2.3で修正
自社運用の端末管理ツール OCO-Server のApple向けMDM登録機能に、署名の確認が不十分な欠陥があります。端末のシリアル番号を知る第三者が、認証なしでその端末のMDM用証明書と秘密鍵を取得し、端末になりすませます。MDM機能を使っている場合は、1.2.3 へ更新してください。
急ぎ度: 早めに
CVSS 9.1で認証なしにネットワーク越しで悪用できますが、実際の攻撃での悪用は公表されておらず、影響を受けるのはMDM機能を有効にしている環境です。
関係があるか
OCO-Server 1.2.3より前の版で、Apple端末向けのMDM機能を使っている組織が対象です。MDMのエンドポイントがインターネットや広いネットワークから到達できる環境ほど危険が高まります。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| OCO-Server(schorschii) | 1.2.3より前の版 | 1.2.3 |
確かめ方
- 1OCO-Serverの管理画面、または配置しているソースの版情報を確認し、1.2.3未満かどうかを調べます。
- 2Apple端末（iPhone・iPad・Macなど）のMDM登録にOCO-Serverを使っているかを確認します。使っていなければ、この問題の影響は小さいと考えられます。
- 3
frontend/api-mdm.phpにあたるMDM用の窓口が、社外やゲスト用ネットワークなど、想定外の範囲から到達できるかをWebサーバーやファイアウォールの設定で確認します。 - 4Webサーバーのアクセスログで、
/api-mdm.php/profileへの見覚えのないアクセスがないかを確認します。
何が起きたか
OCO-Serverは、パソコンの資産管理やソフトの配布、モバイル端末の管理（MDM）を行う、自社で運用するアプリケーションです。Apple端末をMDMに登録するとき、端末が送ってくる登録要求には電子署名が付いています。この署名の確認が不十分で、攻撃者が自分で作った証明書で署名しても受け付けてしまいます。
登録要求の中にある端末のシリアル番号は、署名を信頼できると確認する前の内容がそのまま使われます。そのため、登録済み端末のシリアル番号を知っている人が、偽の要求を認証なしで送るだけで、その端末向けに発行されたMDM用の証明書と秘密鍵を受け取れます。これらは登録用の構成プロファイル（.mobileconfig）に入った形で返ります。
技術的には、frontend/api-mdm.php が openssl_pkcs7_verify を PKCS7_NOVERIFY 付きで呼んでいるのが原因です。このオプションは署名者の証明書が信頼できるかの検証を省くため、署名が内部で矛盾していなければ通ってしまいます。分類はCWE-295（証明書の不適切な検証）です。
さらに、被害端末のデータベース上の記録（mobile_device）が、攻撃者が指定したUDIDで黙って上書きされます。後続のMDM通信（/checkin、/mdm、/parameters）は証明書のCN（シリアル番号）で相手を判断するため、盗んだ証明書と鍵があれば、その端末になりすませます。
攻撃の流れ
-
1
シリアル番号の入手
攻撃者が、登録済み端末のシリアル番号を何らかの形で知ります。
-
2
偽の登録要求
自作の証明書で署名した偽の要求を、認証なしでMDMの登録窓口に送ります。
-
3
証明書と鍵の取得
サーバーが署名を信頼してしまい、被害端末用のMDM証明書と秘密鍵を返します。
-
4
端末記録の上書き
被害端末のデータベース上の記録が、攻撃者の指定したUDIDに書き換わります。
-
5
端末へのなりすまし
盗んだ証明書で、その端末として以降のMDM通信に参加します。
どう悪用されるか
悪用に必要なのは、MDMの窓口にネットワークから到達できることと、対象端末のシリアル番号の知識です。ログインなどの認証は不要で、利用者の操作も要りません。CVSSのベクトルでも、ネットワーク経由・低い難易度・権限不要・操作不要と評価されています。シリアル番号は秘密の情報として管理されていないことが多く、機器の外箱や資産台帳、問い合わせ履歴などから知られる可能性があります。
悪用されると、被害端末のMDM上の身元（証明書と秘密鍵）を奪われます。攻撃者はその端末として管理データを読み取り、プッシュ通知用のトークンを差し替え、登録を妨害したり別の場所に向けたりできます。CVSSでは機密性と完全性への影響が高、可用性への影響はなしとされています。
実際の攻撃で悪用されたという情報は、現時点で公表されていません。
今すぐやること
-
1
OCO-Serverを1.2.3に更新する
1.2.3で修正されています。更新前に、データベースと設定ファイルのバックアップを取ってください。更新の手順はベンダーの告知（GitHubのセキュリティアドバイザリ）で確認します。
-
2
MDMの窓口への到達範囲を絞る
更新までの間も更新後も、MDM用のエンドポイントに必要な端末だけが到達できるよう、ファイアウォールやリバースプロキシで制限します。
-
3
アクセスログを点検する
/api-mdm.php/profileへの不審なアクセスや、登録していない送信元からの要求がないかを調べます。 -
4
端末記録の不整合を確認する
管理画面で、モバイル端末のUDIDが実機と食い違っていないかを確認します。食い違いがあれば、上書きされた可能性があります。
-
5
疑わしい端末は再登録を検討する
不審なアクセスや記録の食い違いが見つかった端末は、MDMから登録を解除し、更新後のサーバーで登録し直すことを検討します。証明書が盗まれた可能性があるためです。修正版で既存の発行済み証明書が無効になるかは公表されていません。
すぐ更新できないとき
更新がすぐにできない場合は、MDM用のエンドポイントへのアクセスを、登録済みの管理対象端末が使うネットワークだけに制限してください。MDMを使っていないなら、該当機能を外部から到達できない状態にします。これは被害を減らす一時的な措置で、根本的な解決にはなりません。
背景
MDM（モバイルデバイス管理）は、社給のスマートフォンやタブレット、Macなどに、設定の配布、アプリの管理、紛失時のロックや消去を遠隔で行う仕組みです。端末とサーバーは証明書で互いを確かめ合うため、証明書と秘密鍵は、端末の身分証にあたる重要な情報です。
証明書の検証を省いたり不十分にしたりして、本来は拒否すべき相手を信頼してしまう弱点は、さまざまな製品で繰り返し問題になってきました。証明書を使う仕組みは、検証が正しく行われて初めて安全が成り立ちます。例えるなら、身分証の偽造を見抜く確認を飛ばして、本人が自分で作ったカードを受け付けてしまうようなものです。
よくある質問
Q.MDM機能を使っていなければ影響はありませんか。
Q.シリアル番号は秘密の情報ではないのに、それだけで危険ですか。
Q.実際に攻撃は起きていますか。
まだ分かっていないこと
- 実際の攻撃で悪用されたかどうかは公表されていません。
- 1.2.3への更新後に、すでに盗まれた可能性のある証明書をどう扱うべきか（失効の要否など）は、公表された情報では分かりません。ベンダーの告知を確認してください。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| schorschii | OCO-Server | — | — |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
OCO-Server is a self-hosted endpoint management application for computer inventory, software deployment, and mobile device management. Prior to 1.2.3,the Apple MDM enrollment endpoint frontend/api-mdm.php verifies the signed enrollment-request plist with openssl_pkcs7_verify(..., PKCS7_NOVERIFY, ...). PKCS7_NOVERIFY disables signer certificate chain and trust validation, so the signature only has to be self-consistent with whatever certificate is embedded in the PKCS#7 blob. A self-signed certificate from an unrelated attacker is accepted. Because the endpoint trusts the SERIAL field taken from the unverified payload, anyone who knows a registered device's serial number can sign a forged plist (SERIAL = victim device, attacker-chosen UDID) with an arbitrary self-signed certificate; POST it unauthenticated to /api-mdm.php/profile (Content-Type: application/pkcs7-signature); and receive the victim device's freshly minted MDM identity: a certificate with CN= issued by the server's internal MDM device CA, bundled with its private key in a PKCS#12 payload inside the returned .mobileconfig enrollment profile. Additionally, the victim's mobile_device database row is silently overwritten with the attacker-supplied UDID (device-record hijack). With the stolen certificate and key, the attacker can impersonate the victim device on all subsequent MDM traffic (/checkin, /mdm, /parameters), which authenticate callers by the certificate CN (the serial number) v…
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory github.com
- advisory nvd.nist.gov
- patch github.com
- patch github.com