脆弱性とは呼べない？――OpenSSHでリモートからユーザー名を列挙できる脆弱性：OSS脆弱性ウォッチ（9）（2/2 ページ）

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

PoCの確認

　今回の脆弱性では、PoCが早い段階から出てきているので、そちらを基にして解説します。

検証環境

SSHDサーバ（OpenSSH 7.2p2-4）：Ubuntu 16.04.5 LTS（IP：172.16.148.128）

外部攻撃元：Debian（Stretch）：172.16.148.1

　PoCのサンプルコードはexploit-dbからダウンロードできるものを使用します。細工したSSHのパケットを送るため、Python＋Paramikoで記述されています。

　図5はPoC用のサンプルコードの抜粋です。

図5　PoCコード（サンプル）

　公開鍵認証によるログインでわざと違う鍵を送ることで、下記のような方法でユーザーが存在するか否かを確認しています。

• ユーザー名でのexception（MSG_USERAUTH_FAILURE）が出た場合にはユーザーは存在しない
• ユーザー名のチェック以降でエラーになった場合にはユーザーが存在する

PoC【1】ユーザーが存在する場合と存在しない場合

　まず、実験環境（172.16.148.1）からPoCコードにより、ターゲットのサーバ上で「existuser」の存在と「noexistuser」がいないことが分かるかの確認です。

　図6のように、「existuser」は外部からのPoCコードで「Valid username」で存在を確認できますが、「noexistuser」は「Invalid username」で存在しないと出力されます。

図6　PoC結果（1）存在するユーザー（existuser）、存在しないユーザー（nonexistuser）の確認

　/etc/passwdを確認すると、確かに「existuser」は/etc/passwdに登録があるので存在していますが、「noexistuser」は存在していません。

PoC【2】/etc/passwdでログインが無効（/bin/falseなど）になっている場合

　次に、実験環境（172.16.148.1）からPoCコードにより、ターゲットのサーバ上で「messagebus（/bin/falseになっている）」の存在と「sshd（/usr/sbin/nologinになっている）」の存在を確認できるか見てみます。

　図7のように、「messagebus」「sshd」も、ログインが無効に設定されていますが、存在自体は外部から確認できてしまうことが分かります。

図7　PoC結果（2）存在するユーザーで/etc/ssh/sshd_configでsshログインが可能なユーザーを設定した場合（デフォルトは拒否、明示的に記載したものだけ許可）

PoC【3】/etc/ssh/sshd_configでログインが明示的に無効になっている場合

　最後に、ターゲットのサーバ（172.16.148.128）上で、/etc/ssh/sshd_configを設定することにより下記のようにシステムを作ることができます。

• デフォルトのユーザーではSSHログインは不許可
• /etc/ssh/sshd_configに記載したユーザーだけログインを許可

　これにより、「/etc/ssh/sshd_config」で指定していない「nosshuser」と明示的にログインを許可した「sshuser」の両方について、外部から存在を確認できるかを見てみます。

　図8のように、明示的にログインを許可している「sshuser」は外部から存在が確認できますが、許可していない「nosshuser」は外部から存在が確認できないことが分かります。

図8　PoC結果（3）存在するユーザーで/etc/ssh/sshd_configでログインを制御している場合

脆弱性の修正と緩和方法

　今回の脆弱性の修正は、根本的にはソースコード自体に修正が加わったバージョンを待つのが正しい形になります。

　一方で、ワークアラウンドとして、/etc/ssh/sshd_configをきちんと使い、sshのレベルでも明示的にログインの許可／拒否を設定することで外部からのユーザー名列挙は回避できます。

追加の脆弱性と開発元の見解

　今回の脆弱性が公開されたのが2018年8月14日でしたが、さらに同様の脆弱性としてCVE-2018-15919がQualysによって報告されました。

　一方で、今回の「ユーザー名列挙」に関しては、開発元のOpenBSDブロジェクトから「脆弱性とは呼べない」と言われています。

　これは、今回の脆弱性に関しては「ユーザー名のリストを漏えいしてしまう」というような問題ではなく、結局、一ユーザーずつログインの可能／不可能を確認することになり、一般的なアプリケーションと同様に、適当にユーザー名を指定してログイン行為を行うことで「そのユーザーが存在するか否か」を確認していくものと本質的に同じためです（そのため、今回の脆弱性は、重要度がLowに位置付けられています）。

　一方で、ユーザー名の有無を確認できるため、根気よく続けていけば存在するユーザーのリストもある程度はつかめることになります。ユーザー名が分かってしまえば、ユーザー名が分からない状態よりもログインを突破される可能性は大きくなります。

　そのため、今回のような脆弱性の利用も未然に防ぐために、/etc/ssh/sshd_configを設定してsshのレベルでも明示的にログインの許可／拒否を行うことで今回のようなユーザー名列挙は回避した方が無難です。また、そもそもsshが可能なIPアドレスをあらかじめ指定しておき、iptablesなどで対処しておけば、指定していないIPアドレスからの攻撃は防げることになります。

　このように、セキュリティで設定できるところを確認してきっちりと対処しておくことが、特にサーバなどでシステムをさらす場合には重要です。皆さまも、サーバを公開する際には、接続IPの制限やログイン可能IDの制限など、基本的なセキュリティ設定を忘れないようにしましょう。

筆者紹介

面和毅

略歴：OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログを連載中。

CISSP：#366942

近著：『Linuxセキュリティ標準教科書』（LPI-Japan）」