SID スプーフィングの脆弱性

Dirk-jan Mollema は最近 Certifried のような攻撃を Intune に拡張する方法を説明しました。記事では AD CS と NDES を使っていましたが、そこで説明されている問題はそれらに固有のものではなく、一般に SCEP 登録に Intune を使用するすべての PKI、SCEPman を含むすべてに当てはまります。

ただし、他の PKI にはいくつか追加の制約があります。最も重要なのは、これが一般的な Certifried の脆弱性に基づいているため、CA 証明書がドメインの NTAuth ストアに存在している必要があることです。AD CS は既定で NTAuth ストアに入っていますが、SCEPman は入っていないため、SCEPman ユーザーが影響を受けるのは、CA 証明書を NTAuth ストアに明示的に追加している場合に限られます。もしそれを行っていなければ、安全です。ただし、CA 証明書を NTAuth ストアに追加する必要があるユースケースもあり、特に Domain Controller の証明書 および 証明書ベースの RDP 認証が挙げられます。CA 証明書が NTAuth ストアにあり、SCEPman で Intune 登録を有効にしている場合、通常は Intune 管理者がこれを悪用し、証明書を登録してドメインを乗っ取れるようになります。つまり、Intune 管理者は Tier-0 管理者として扱うべきです。

しかし、Dirk-jan はさらに別の、より深刻な問題を説明しました。Intune は、ユーザーが指定した SID が、そのユーザーまたはデバイスの onPremisesSecurityIdentifier 属性と一致するかどうかを確認していないようで、Microsoft が Strong Mapping の強制によって講じた緩和策を無効にしています。権限のないユーザーでも（まあ、端末上のローカル管理者権限が必要かどうかは不明ですが）、別のユーザーの SID を持つ証明書を登録できてしまいます。そのユーザーはなお、他のユーザーの UPN を証明書に入れる必要がありますが、現時点ではそれに対する既知の悪用方法は把握していません。それでも、セキュリティ上のハードルが 1 つ減ります。デバイス証明書では状況はさらに悪く、Dirk-jan は、通常ユーザーが Domain Controller システムとして認証し、マシンを乗っ取ることを可能にする証明書を登録できる具体的な要件を示しました。

もし NTAuth ストアに SCEPman の CA 証明書がすでにあり、この攻撃を防ぎたいのであれば、 AppConfig:IntuneValidation:AllowRequestedSidExtension から falseを設定できます。これにより、偽装されたものを含む SID 拡張が除外されます。これは、SCEPman 2.11.1460 以降でこの設定の既定値でもあります。以前のバージョンの SCEPman では、この設定を行うと通常は正当な SAN 拡張内の SID URI も削除されるため、有効なユースケースを妨げる可能性があります。