Fortinetは、2020年7月に初めて公開された脆弱性FG-IR-19-283（CVE-2020-12812）が、現実世界の攻撃で再び悪用されているとして管理者に警告しました。特定のFortiGate構成では、この欠陥により攻撃者が二要素認証を回避し、2FAがまったく存在しないかのようにログインできてしまいます。同社は回避の仕組みを概説し、特定の構成がリスク領域に該当するかどうかを迅速に判断する方法を説明しています。
問題の核心には、微妙な不整合があります。FortiGateはデフォルトでユーザー名を大文字・小文字を区別して扱う一方、LDAPディレクトリは区別しません。この不一致のため、ユーザー名を異なる大文字・小文字で入力したユーザーをデバイスが認識できず、FortiGateがアクセス・ポリシーで定義された代替の認証経路にフォールバックする可能性があります。
脆弱となるシナリオは、2FAを有効にしたローカルのFortiGateアカウントがLDAPにリンクされ、認証ポリシーでLDAPグループが参照されている場合に発生します。たとえば管理者アクセスやSSL/IPsec VPNなどです。すべては「似ているが同一ではない」ユーザー名にかかっています。ユーザーがjsmithとしてログインすると、FortiGateはローカルアカウントに一致させ、第二要素トークンを要求します。
しかし、同じユーザー（またはパスワードを入手した攻撃者）がJsmith、jSmith、あるいはローカルアカウントと完全一致しない別の大文字・小文字のバリエーションでログインすると、FortiGateはそのログインをローカルユーザーに関連付けられず、別途設定されたLDAPグループによる認証などの代替手段へ切り替わります。有効な認証情報があればLDAP経由でアクセスが許可され、強制2FAや、さらには無効化されたアカウントといったローカルユーザー設定が事実上無視されます。
その結果、管理者やVPNユーザーが第二要素なしで認証できてしまう可能性があります。Fortinetは、この回避がすでに悪用されたと考える理由が少しでもある場合、システム構成は侵害されたものと見なすべきであり、すべての認証情報—特にLDAPやActive Directory連携に使用されるもの—をリセットすべきだと強調しています。
この挙動に対する緩和策は2020年の時点で導入されており、FortiOS 6.0.10、6.2.4、6.4.1に修正が含まれています。これら、またはそれ以降のバージョンへアップグレードできない場合、Fortinetはローカルユーザー名の大文字・小文字の区別を明示的に無効化することを推奨しています。古いブランチではusername-case-sensitivityをdisableに設定します。より新しいリリース（おおむねFortiOS 6.0.13、6.2.10、6.4.7、7.0.1以降）では、パラメータusername-sensitivityをdisableに設定します。適用後、FortiGateはjsmith、JSmith、およびあらゆる大文字・小文字のバリエーションを同一ユーザーとして扱い、大文字・小文字の不一致によって引き起こされる代替LDAP認証へのフォールバックを防止します。
Fortinetはまた、問題の実務的な根本原因として、ローカルユーザー検証が失敗した際に認証を引き継ぐ二次的なLDAPグループの存在を挙げています。そのようなグループが業務上厳密に必要でない場合は、構成から削除すべきです。また、認証ポリシーでLDAPグループがまったく使用されていない場合、この回避経路は完全に消滅し、ローカルアカウントとの不一致は単にログイン拒否となります。
翻訳元: https://meterpreter.org/how-a-capital-letter-bypasses-fortinet-2fa/
