ADドメインコントローラーとして動作しているSamba 4.xに関する脆弱性とは：OSS脆弱性ウォッチ（5）（2/3 ページ）

[面和毅，OSSセキュリティ技術の会]

ユーザー情報（脆弱性）の確認

　今回の脆弱性の情報を基に、ユーザーID（test1）の情報を確認します。Samba本家のCVE-2018-1057.htmlを基に確認していきます。

　今回問題になっているACE（Access Control Entry：アクセス制御エントリ）を確認します。今回注目すべきACEは図5の2つです。

self:  (OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;PS)
world: (OA;;CR;ab721a53-1e2f-11d0-9819-00aa0040529b;;WD)

図5　今回問題になっているACE（Access Control Entry）

　Red Hatのbugzillaにあるようにldbsearchコマンドを用いて下記のようにしてtest1ユーザーの情報を確認します。

/usr/local/samba/bin/ldbsearch -H /usr/local/samba/private/sam.ldb cn=test1 ntSecurityDescriptor --show-binary

　問題のACLが確認できます（図6の14行目）。

# record 1
dn: CN=test1,CN=Users,DC=jsosug,DC=jp
nTSecurityDescriptor:     NDR: struct security_descriptor
        revision                 : SECURITY_DESCRIPTOR_REVISION_1 (1)
        type                     : 0x8c17 (35863)
               1: SEC_DESC_OWNER_DEFAULTED 
               1: SEC_DESC_GROUP_DEFAULTED 
               1: SEC_DESC_DACL_PRESENT    
----省略---
                            flags                    : 0x00000001 (1)
                                   1: SEC_ACE_OBJECT_TYPE_PRESENT
                                   0: SEC_ACE_INHERITED_OBJECT_TYPE_PRESENT
                            type                     : union security_ace_object_type(case 1)
                            type                     : ab721a53-1e2f-11d0-9819-00aa0040529b
                            inherited_type           : union security_ace_object_inherited_type(case 0)
                        trustee                  : S-1-5-10
                    aces: struct security_ace

図6　ldsapsearchを用いてtest1ユーザーの情報を確認

　Windows上で情報を確認します。Windows 7にこちらのMicrosoftのリンクにある「Windows 7 Service Pack 1（SP1）」用のリモートサーバ管理ツールをダウンロードしてインストールします。

　Windows 7をSambaサーバのドメイン（JSOSUG.JP）に参加させ、JSOSUG.jp\Administratorでログインします。

　Windowsのサーバ管理ツールでドメインユーザーの情報を見ます。「ActiveDirectory ユーザーとコンピュータ」→「表示」→「拡張機能」にチェックを入れます（これを入れないと、今回見たい拡張機能が入っている「セキュリティ」のタブが出てきません（図7）。

図7

　ユーザーの情報を確認します。「Everyone」「SELF」の「パスワードの変更」にチェックが入っているのが分かります（図8、図9）。

図8　「Everyone」に「パスワードの変更」権限

図9　「SELF」に「パスワードの変更」権限

　ちなみに、この「チェックが入っている」という状態自体は今回問題になった状態ではありません。通常のWindows Server 2016でADを立ててユーザーを確認した場合にも、同じように「Everyone」「SELF」の「パスワード変更」にチェックが入っています（図10、図11）。

図10　「Everyone」に「パスワードの変更」権限（Windows Server 2016のドメイン）

図11　「SELF」に「パスワードの変更」権限（Windows Server 2016のドメイン）