検索
連載

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

連載「OSS脆弱性ウォッチ」では、さまざまなオープンソースソフトウェアの脆弱性に関する情報を取り上げ、解説する。今回は、OpenSSHでリモートからユーザー名を列挙できる脆弱性について。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

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)」


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       

Security & Trust 記事ランキング

  1. 3割程度のSaaS事業者が標準的なセキュリティ対策をしていない アシュアードがSaaS事業者を調査
  2. 中小企業の20%の経営層は「自社はサイバー攻撃に遭わない」と信じている バラクーダネットワークス調査
  3. 「このままゼロトラストへ進んでいいの?」と迷う企業やこれから入門する企業も必見、ゼロトラストの本質、始め方/進め方が分かる無料の電子書籍
  4. 「生成AIのサイバー攻撃への悪用」は増加する? 徳丸浩氏が予測する2025年のセキュリティ
  5. AWS、組織のセキュリティインシデント対応を支援する「AWS Security Incident Response」を発表 アラートに圧倒されるセキュリティチームをどう支援?
  6. ChatGPTやClaudeのAPIアクセスをかたってマルウェアを配布するPython用パッケージ確認 Kasperskyが注意喚起
  7. 商用国家安全保障アルゴリズム(CNSA)の期限となる2030年までに暗号化/キー管理サービス市場が60億ドルに達するとABI Researchが予測 急成長の要因とは?
  8. 高度なAIでAIをテスト OpenAIが実践するAIモデルのレッドチーム演習とは
  9. 従業員は「最新のサイバー脅威との戦い」を強いられている セキュリティ教育に不満を持つ理由の1位は?
  10. 約9割の経営層が「ランサムウェアは危ない」と認識、だが約4割は「問題解決は自分の役割ではない」と考えている Vade調査
ページトップに戻る