今回の脆弱性では、PoCが早い段階から出てきているので、そちらを基にして解説します。
SSHDサーバ(LibSSH 0.7.5):CentOS 7.4(IP:172.16.148.130)
外部攻撃元:Debian(Stretch):172.16.148.1
PoCのサンプルコードは「exploit-db」からダウンロードできるものを使用します。細工したSSHのパケットを送るため、PythonとParamikoで記述されています。
図5はPoC用のサンプルコードの抜粋ですが、ログイン時にMSG_USERAUTH_SUCCESSを送っています。この「SSH_MSG_USERAUTH_SUCCESS」は、「RFC4252」にあるように、認証が完了したときに送られるメッセージです。
今回の脆弱性では、このSSH_MSG_USERAUTH_SUCCESSがクライアントから来た際に、それ以降の認証を行わずに処理を続けてしまうことが問題になっています。
まずは、通常の動作と併せて、PoCの内容を確認してみましょう。
最初に、通常のsshでユーザー認証を行ってみましょう。samplesshd-cbのソースコードに直接書いてありますが、ユーザー名は「myuser」、パスワードは「mypassword」です。このときのログは図6です。
図6では、不要なログを省略していますが、最初にユーザー名「myuser」、パスワード「mypassword」でログインしています。これがうまくいったことで「Session channel」がAllocateされていることが分かります。
次に、同じようにsshでユーザー認証を行ってみたが、パスワードを間違えた場合を見てみます。この際のログは図7のようになります。
図7でも不要なログを省略していますが、ユーザー名「myuser」でパスワード「machigai」でログインを試み、それが失敗したため「auth failure」を送って再度パスワードを要求してきます。数回パスワードを間違えると、ソケットが切断されます。
今度は、PoCのexploitコードを用いたときを見てみます。このときのログが図8です。
図8でも不要なログを省略しています。ユーザー名などを検証する前に、いきなりクライアントから「SSH_MSG_USERAUTH_SUCCESS」が送られてきたため、「Authentication Successfull」ということで処理され、認証を試みずに「session channel」をAllocateしてしまっていることが分かります。
今回の問題は、認証に関する箇所で、「SSH2_MSG_USERAUTH_SUCCESS」を“クライアントから”受け取った際の処理が漏れていたことが原因です。本来は、SSH2_MSG_USERAUTH_SUCCESSはサーバからクライアントに対して送ります。
そのため、今回の修正では、サーバに対して“SSH2_MSG_USERAUTH_SUCCESS”が送られてきた際には無視するようになっています(図9)。
今回の脆弱性の修正は、ソースコード自体に修正が加わったバージョン(ディストリビューションを用いているのであれば、ディストリビューションからの提供)を待つのが正しい形になります。
一方で、今回の問題はLibSSHを「サーバとして」用いた場合にのみ発生するため、OpenSSHは対象には入っておらず、クライアントとして使用している際にも問題になりません。そのため、被害は限定的といえます。
しかし、今回の脆弱性はあちこちで話題になりました。これは、LibSSHを用いて自前のサーバを、特にIoTなどで使っているユーザーが一定数いたからのようです。
現在、IoTは当たり前のように身の回りで活用されてきていますが、今回のような脆弱性も潜んでいることを考慮しなくてはなりません。ユーザー側のキャッチアップも重要ですが、IoT周りではセキュリティパッチを当てにくいため、提供側も攻撃を限定的に抑える仕組みや有効なアップデート方法などを考慮しなくてはならない時代になっているといえます。
略歴:OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍し、同社でSIOSセキュリティブログを連載中。
CISSP:#366942
近著:『Linuxセキュリティ標準教科書』(LPI-Japan)」
Copyright © ITmedia, Inc. All Rights Reserved.