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

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

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

しかし、Dirk-jan はさらに深刻な問題を指摘しました。Intune はユーザーが提供した SID がユーザーまたはデバイスの onPremisesSecurityIdentifier 属性と一致するかどうかをチェックしていないようで、Microsoft が Strong Mapping の強制で行った緩和策を無効にしています。昇格された権限を持たないユーザー（そのマシンのローカル管理者権限が必要かどうかは不明ですが）が別のユーザーの SID を使って証明書を登録することが可能です。ユーザーは依然として別のユーザーの UPN を証明書に含める必要があり、そのための既知のエクスプロイトは現在知られていませんが、セキュリティ上のハードルが一つ減ることになります。デバイス証明書の場合はさらに深刻で、Dirk-jan は通常のユーザーがドメイン コントローラー システムとして認証しマシンを乗っ取ることを可能にする証明書を登録できる具体的な要件を概説しました。

もし SCEPman の CA 証明書が NTAuth ストアにあり攻撃を防ぎたい場合は、次の設定を行うことができます AppConfig:IntuneValidation:AllowRequestedSidExtension へ false。これにより、偽装を含む SID 拡張がフィルタリングされます。これは SCEPman 2.11.1460 以降のこの設定のデフォルト値でもあります。以前のバージョンの SCEPman では、この設定を構成すると通常は正当な SAN 拡張内の SID URI も削除され、正当なユースケースを妨げる可能性があります。