筆者はペネトレーションテストなどを担当しており、お客様が利用されているシステムや端末などにセキュリティ上の問題があるか調査します。業務の中でよくWindowsに認証情報などが残存していないかくまなく調べますが、特定の条件を除き、利用されているアカウントの生のパスワードはWindows上には保存されていません。では、Windowsはどうやって認証情報をチェックするのでしょうか。Windows内部やActive Directoryでのパスワードの管理などについて、2回にわけてご紹介したいと思います。今回は、Windows内部でパスワードはどのように保存されており、どのように認証が行われているかご紹介したいと思います。

Windowsはアカウント名とパスワードによる認証以外にもバージョンによってスマートカードなどの多要素認証もサポートしています。また、アカウント名とパスワードによる認証もActive DirectoryのようにKerberosを用いた方式やローカルに保存された認証情報を用いた方式などがあります。

https://docs.microsoft.com/ja-jp/windows-server/security/windows-authentication/credentials-processes-in-windows-authenticationより引用
※上図のGINA(Graphical Identification and Authentication)はWindows Vistaで廃止され、Credential Providerに置き換わっています。

1. 利用者がSecure Attention Sequence(Ctrl+Alt+Deleteキーを押下する操作)によりWinlogonはログオンユーザのインターフェースプロセスであるLogonUIを開始します。
2. LogonUIは認証情報を取得するためのCredential Providerを呼び出します。
3. WinlogonはLsaLogonUser関数を呼び出します。
4. 利用者がアカウント名とパスワードを入力することで、WinlogonはLSASS(LSA Server Service)のLsaLookupAuthenticationPackede関数を呼び出し、Authentication Packageに認証情報が引き渡されます。
5. Authentication Packageで認証を行い、Winlogonは利用者のログオン処理を継続します。

Authentication Packageはドメインへログオンする際に用いられるKerberos.dllやローカルにログオンする際に用いられるMsv1_0.dllといったDLLになります。ローカルにログオンする際、Msv1_0.dllはアカウント名とHash化されたパスワードをSAM(Security Account Manager)で管理されている情報と比較を行い、認証成否を決定します。

SAMは、ファイルである%SystemRoot%¥system32¥config¥SAMおよびレジストリであるHKLM¥SAMに保存されています。パスワードの保存の仕組みについては、調べた限りどういった手法で行われているか確認できませんでした。ですが、上記のSAMファイルやレジストリにアクセスすることで、パスワードのHashを取得することができる可能です。ただ、実際にAdministratorでアクセスした結果が下図となっています。

SAMファイルはSystemによって開かれているため、ファイル自体がロックされアクセスできませんでした。SAMレジストリはアクセス許可されていないため、同様にアクセスできませんでした。ローカル管理者権限を有するAdministratorでもSAMファイルやレジストリにアクセスできませんでした。SAMレジストリはローカル管理者でもアクセス許可されていないので誰もアクセスできないのかと思ってしまいますが、そういうわけではありません。誰もアクセスできないと認証が行えないし、パスワードを変更することもできなくなってしまいます。ローカル管理者であるAdministratorでさえアクセス権限が付与されていないのです。逆に言うとアクセス権限さえ付与すればAdministratorもアクセスが可能となります。具体的な手法については割愛しますが、アクセス権限を付与することでアクセスエラーがなくなり、レジストリのHKLM¥SAMにアクセスできるようになっています。

パスワードのHashが保存されているSAMにアクセスできたので、これでもうあとは探すだけですが、実はパスワードのHashはそのまま保存されているわけではありません。

以下の手順を踏む必要があります。RIDが500であるAdministratorを例にしています。

長い道のりでしたが、やっとパスワードのNTLM Hashを取得することができました！でも、この方法ではWindows7しか取得することはできません。OSやバージョンによって格納場所や方法が変わっているためです。Windows10 1607以降については、以下の方法で取得することができます。

このようにWindows7とWindows10で大きく異なっています。また、Windows10でもバージョンによって変わる可能性があるものの、ローカル管理者権限を有していれば、OSに関係なくアクセス権を変更し、パスワードのHashを取得できてしまいます。ただ、パスワードのHashなので、生のパスワードではありません。では、パスワードのHashが取得されることによるリスクは何かあるのでしょうか。

ここで突然話が変わりますが、ドメインに参加していないWindowsのファイルサーバなどへアクセス時の認証に、NTLMv2認証が利用されていることが多いです。NTLMv2認証は、Server Challenge、Client Challengeと呼ばれるランダムな数値を双方で発行し、Hash化されたパスワードなどをやりとりすることで認証が行われます。

NTLMv2認証は、以下の通りです。

では、話をパスワードのHashが取られることのリスクについて戻します。NTLMv2認証の際に本来は生のパスワードを利用しなければならいにも関わらず、赤枠箇所の処理を行うことで、生のパスワードを知らなくてもパスワードのHashでNTLMv2認証を突破するPass the Hashという攻撃手法に悪用される可能性があります。これは、Windows独自のリスクでLinuxなどには存在しない攻撃手法です。

Pass the Hashが行えるのは、アカウント名とパスワードのHashを取得しておく必要があります。さてここで、複数のアカウントで同じパスワードを設定し、パスワードのHashを取得してみます。なんと、すべて同じ値になります。これは、WindowsではHash化する際に付加するランダムな文字列であるsaltがないため、同一のパスワードだと同一のHashになってしまいます。そのため、複数台のクライアント端末で同一のパスワードを設定している場合に、アカウント名を特定することでPass the Hashを用いた横断的な侵入が行える可能性があります。一般的に攻撃者は横断的な侵入を行い、各端末から情報収集し最終的に目的となるサーバへの侵入というゴールに達する可能性があります。
※単純なパスワードの場合、Hashから元のパスワードを特定することが可能な場合もあります。

根本的な対策としては、各端末のパスワードを異なるものに設定することですが、手動で行う場合、運用コストが非常にかかってしまいます。そのため、Active Directoryを利用されている場合はLAPS(Local Administrator Password Solution URL)による管理がおすすめです。これは、ドメイン上のすべてのコンピュータで共通のローカル管理者アカウントにランダムで異なるパスワードを設定してくれるため、Pass the Hashによる攻撃が成立しません。筆者が以前調査した際の資料はこちらです。

また、補助的な対策として、利用者のアカウントにローカル管理者権限を付与しないことも挙げられます。ローカル管理者権限がなければ、SAMのアクセス権限を変更できないため、Hash化されたパスワードを取得することができません。ただし、将来的にWindowsやインストールされているアプリケーションに存在する脆弱性を悪用されて権限昇格される可能性もあるため、根本的な対策の実施を推奨いたします。

今回は認証やローカルでのパスワード管理についてご紹介しましたが、次回はActive Directoryでのパスワード管理についてご紹介したいと思います。今回のブログがだいぶ長くなってしまったので、そろそろ飲みに行ってきます、テキーラを。

以前おいしくいただいたテキーラ(ブログの内容と関係ありません)

＜参考＞
・https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2011/04/22/credential-provider-2/
・https://en.wikipedia.org/wiki/Graphical_identification_and_authentication
・https://docs.microsoft.com/en-us/windows/desktop/secauthn/authentication-portal
・https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/5e550938-91d4-459f-b67d-75d70009e3f3
・https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4