Windows ローカルログオンによる脆弱性も考慮しないと危険！

データを一元管理できるファイルサーバーがあると、とっても便利。

最近ではWindowsのファイル共有機能を利用すれば、簡単にファイルサーバーの構築が可能です。
そのため自宅でファイル共有機能を利用したファイルサーバーを運用している、という方もいらっしゃると思います。

この時普通にファイル共有を設定するだけでは、もしかしたら脆弱性が残っているかもしれないので危険かも！
というのが、今回のお話。

はじめに

今回ご紹介する脆弱性は、Active Directory環境でもWindows ネットワーク(WORKGROUP)環境でも起こり得るものです。

ですが話がややこしくなるので、とりあえずはActive Directoryを構築していない、Windows ネットワーク(WORKGROUP)環境でのファイル共有の例で説明することにします。

またその脆弱性は、悪意のあるユーザーがアクセスが許可されていないファイルやフォルダへのアクセスが可能になる、というものです。

そのため誰でもどこでもアクセスOK！
という環境であれば、脆弱性にはならないのかも。

Windowsのファイル共有機能を実現する設定方法

さて、Windowsによるファイル共有で特定のユーザーのみアクセス可能、といった仕様を実現する場合、通常は以下のような設定を行うはず。

前提設定

1. サーバー機(ファイルを公開する ＝ アクセスを受けるPC)の特定フォルダ(もしくはファイル)に、特定ユーザーのみがアクセス可能となるように共有を設定する。(共有アクセス権とNTFSアクセス権を、アクセス可能なように設定。)
2. サーバー機に、そのファイルにアクセス可能と設定したユーザーアカウントを用意する。

アクセス方法1

クライアント(ファイルにアクセスするユーザー)は共有フォルダにアクセスする際に表示される、アカウントとパスワードを入力する認証ダイアログで、サーバー機に用意したアクセス可能と設定したユーザーアカウントのアカウント名とパスワードを入力する。

アクセス方法2

クライアント機(ファイルにアクセスするのに使用するPC)に、サーバー機に用意したアクセス可能と設定したユーザーアカウントと同じユーザー名・パスワードのユーザーアカウントを用意し、そのユーザーでログインしてから、共有フォルダにアクセスする。

この場合は共有フォルダにアクセス可能なユーザー ＝ クライアント機にログインしているユーザーとなり、認証ダイアログが表示されずに共有フォルダにアクセス可能です。

ローカルログオンによる脆弱性

今回ご紹介する脆弱性は、先の設定方法の前提設定を行ったサーバー機に存在する場合があります。

それは、ローカルログオンによる脆弱性。

ポイントはサーバー機に存在するユーザー

前提設定では、サーバー機に共有フォルダにアクセス可能なユーザーアカウントを作成しています。
そしてこのユーザーアカウントは、作成直後は通常Usersグループに属します。

ポイントはこのUsesグループに属するユーザーが、初期設定ではローカルログオンが可能であるということ。(Active Directory環境のドメインコントローラーは除く。)

これがどういうことかというと、サーバー機にキーボードをつないでユーザー名とパスワードを入力すれば、そのユーザーアカウントでサーバー機にログインできてしまう、ということです。

サーバー機にログインできてしまえば、NTFSアクセス権の設定が適切に行われていない場合、Usersグループのユーザーでもサーバー上のほとんどのファイルにアクセス可能です。

これが、ローカルログオンによる脆弱性です。

つまり共有設定では許可していないフォルダやファイルに、直接サーバー機にローカルログオンすることで、アクセスできてしまうかもしれない、ということ。

ローカルログオンによる脆弱性を利用できる条件

このローカルログオンによる脆弱性を利用するためには、いくつかの条件がそろう必要があります。

ローカルログオンが物理的に可能

ローカルログオンが可能、つまりサーバー機にキーボードを接続し、ユーザー名とパスワードを入力してログオンが可能な状態でなければ、この脆弱性を利用できません。

たとえばサーバー機が鍵付きサーバーラック内に入っている場合、開錠しないとキーボードを接続できないため、管理者以外はログオンできません。

共有の設定の際に、NTFSアクセス権の設定が不適切であった

共有の設定には、共有アクセス権とNTFSアクセス権の設定の2種類が必要。

このうちNTFSアクセス権の設定が初期設定のままで、共有アクセス権の設定のみでアクセス許可を制限している場合は、今回の脆弱性を利用可能な場合があります。

これは共有アクセス権で許可していないユーザーのアクセスをNTFSアクセス権で拒否(不許可)に設定していないと、その記憶領域にローカルログオンでアクセス可能なため。(初期設定ではUsersグループに属するユーザーは、記憶領域のほとんどに読み取り許可の権限が与えられています。)

ローカルセキュリティポリシーなどで、ローカルログオンを許可している

ローカルセキュリティポリシーやグループポリシーによる権限設定で、アクセス権のないユーザーのローカルログオンを制限していない場合がこれに該当します。

これらの条件がそろうと…。

以上の条件がそろえばローカルログオンによる脆弱性が利用可能です。

一見全部の条件がそろうのは難しいのでは？と思われるかもしれません。
ですがこの条件がそろっている環境は結構多いのではないか、というのがはるるの考え。

というのもActive Directory環境のドメインコントローラーを除いては、初期設定のまま手軽に共有の利用設定をすると、これらの条件はそろってしまうことが多いから。

ただこのローカルログオンによる脆弱性は、サーバー機に直接アクセスが可能な(キーボードを接続できる)ユーザーが利用可能な脆弱性です。
そのためこの脆弱性を利用可能なのは、たいていの場合内部犯(家族や社員など)ということになるでしょう。

ローカルログオンによる脆弱性への対策

ローカルログオンによる脆弱性を利用するには、先に書いた条件がそろわなければなりません。
逆に言えばそのどれかに対処すれば良い、というわけです。

そこで今回は、最も簡単に対処可能な対策をご紹介します。

ローカルログオンが許可されているユーザーを見直す

ローカルログオンを可能にする条件として、ローカルログオンが許可されている必要がある、と言うのは先ほど書いたとおり。

そこでローカルログオンが可能なユーザーを制限することで、この脆弱性の利用を防ぐことが可能です。

ローカルログオンの許可の設定方法

まずはローカル セキュリティ ポリシーを起動します。

ローカル セキュリティ ポリシーは、デスクトップなどで『Windows』キーを押しながら、『R』キーを押し、『ファイル名を指定して実行』ウィンドウを表示させ、『secpol.msc』と入力し、『OK』をクリックすることで起動可能です。

次に、ローカルポリシー→ユーザー権利の割り当て→ローカルログオンを許可を選択します。

そこでダブルクリックを行うと、プロパティが表示されるので、ローカルログオンをさせたくないユーザーを一覧から削除します。

たいていの場合、今回の脆弱性が利用可能な理由は、Usersが許可されているためでしょう。
Guestは初期設定では、拒否にも設定されているので拒否が優先されます。

初期設定のままであれば、Usersを許可リストから外せば、管理者権限と一部の特殊権限のユーザーしか、ローカルログオンができなくなります。
そのため一般のユーザーは今回の脆弱性が利用できなくなる、というわけ。

尚、ローカル セキュリティ ポリシーは、Professional以上のエディションのWindowsかWindows Serverでないと、使用できません。
その場合は、NTFSアクセス権の設定変更で対応することになります。

見逃しがちですが…

今回ご紹介したローカルログオンによる脆弱性は見逃しがちな問題だと思います。
ですが自宅や小規模オフィスでは、サーバー機を鍵付きサーバーラックに入れないことも多く、この脆弱性が利用可能である、というケースが結構多いのではないかと。

というわけで、気になる方はぜひ一度設定を確認してみてくださーい！