SSH鍵によるアクセスを想定したアカウントでも、パスワードログイン経由で攻撃者が侵入できる可能性がある。
この矛盾の核心にあるのが、今回新たに発見されたOpenSSHの脆弱性「SSHole」だ。特定のLinuxシステムでは、被害者のパスワードもSSH秘密鍵も知らない攻撃者が認証を回避できる。
この脆弱性は、OpenSSHと、Alpine Linuxで使われる軽量なC標準ライブラリmuslとの予期せぬ相互作用を悪用し、失敗したパスワードハッシュ処理をログイン成功に変えてしまう。
Ars Technicaは、AlpineのDocker Hubベースイメージが10億回を超えてダウンロードされたと報じている。ただし、この数字から脆弱なシステムの数は判断できない。悪用には、ソフトウェア、設定、アカウント構成の特定の組み合わせが必要だからだ。
OpenSSHは修正をリリース済みだが、管理者はそれをインストールしてSSHサービスを再起動しなければならない。保守可能な時間帯が限られるシステムでは、チームがアップデートを手配する間、直ちに緩和策を講じる必要がある場合もある。
SSHoleの悪用を成功させるために必要な条件
悪用を成功させるには、ソフトウェア、認証設定、アカウント構成の特定の組み合わせが必要になる。
まず、対象システムは、認証をPAM（Pluggable Authentication Modules）が処理していない状態で、musl libcを使うOpenSSHを実行していなければならない。また、パスワードベースのSSH認証が有効になっており、攻撃者が影響を受ける認証機構を通じてパスワードを送信できる必要がある。
さらに、アカウントについて2つの条件が必要になる。
- 対象アカウントの/etc/shadowのパスワード欄にはアスタリスク（*）が入っていなければならない。これは通常のパスワード認証が利用できないことを示す。
- 別のローカルアカウントには、使用可能なSHA-256またはSHA-512のパスワードハッシュが必要だ。OpenSSHは認証時にそこからソルトを借用できる。
Alpineによると、影響を受けるアカウントのユーザー名を知っており、SSHサービスに到達できる攻撃者は、これらの条件を満たすシステムを悪用できる。その後、257～1,024バイトのパスワードを送信すればよい。
muslのcrypt()関数は通常、入力がライブラリの256バイト制限を超えているため拒否する。しかし有効なパスワードハッシュを返す代わりに、ハッシュ処理に失敗したことを示すアスタリスク（*）を返す。
OpenSSHは次に、この結果を対象アカウントに保存されたパスワード欄と比較する。そこにもアスタリスクが入っているため、2つの値は一致する。OpenSSHは誤って、失敗したハッシュ処理を認証成功と解釈し、パスワードもSSH秘密鍵も持たない攻撃者にアカウントへのアクセスを許してしまう。
長年にわたるソフトウェアの挙動がログイン回避を生んだ経緯
SSHoleについて最も不安を感じさせるのは、攻撃者が認証を回避できることだけではない。それを可能にした条件が、これほど長い間見過ごされていたことだ。
この脆弱性は、何年も前から存在していたソフトウェアの挙動に起因する。言い換えれば、個々のコンポーネントは設計どおりに動作していたが、それらの相互作用が、何年にもわたって検知されないセキュリティ障害を生み出した。
また、 PHP2Shellへの対応も同様に、セキュリティチームが修正を適用した状態で稼働していることを確認し、過去のアクセスを調査しなければならない理由を浮き彫りにしている。一方、 AIを活用した脆弱性スキャンを提供するサービスは、見過ごされていた欠陥を見つける取り組みを拡大している。
セキュリティチームにとっての実務的な教訓は、通常のログインチェックでは見逃しかねない失敗経路も含め、認証コンポーネントがどのように相互作用するかをテストすることだ。
長年にわたり、セキュリティ評価、コードレビュー、ペネトレーションテストは組織による脆弱性の特定に役立ってきた。しかし、考えられるあらゆる障害を見つけられる保証はない。AIを活用した脆弱性調査の近年の進歩により、その限界は無視しにくくなっている。何年もの精査をくぐり抜けた欠陥が、これまで見過ごされていた悪用経路を明らかにし得る方法で調査されているためだ。
インターネットに公開されたSSHサービスには、攻撃者がリモートから到達できるため、特に注意が必要だ。
watchTowrで脅威インテリジェンス責任者を務めるJake Knott氏は、「SSHはほぼあらゆる場所に存在し、サーバー管理のために公開されていることも多い。ただし、前提条件があるため、影響を受けないシステムも多数あるだろう」と説明する。
それでも、こうした要件によって、攻撃者は探し出すべき特定の構成を把握できる。Knott氏は「AlpineのAWSおよびAzureイメージ」が「おそらく最初に標的になるものだろう」と指摘する。Alpineによると、影響を受けるtiny-cloudイメージは初回起動時には安全だが、条件を満たすパスワードハッシュが追加されると悪用可能になる。
MikroTikの別のSSH脆弱性が実際に悪用されていることは、公開された管理サービスが直面するリスクを示している。Knott氏は、既存のパスワード推測攻撃にSSHoleの試行も組み込まれる可能性があると警告した。Knott氏の言葉を借りれば、「この脆弱性を悪用するというのは、同じ攻撃者が非常に長いパスワードの試行を総当たり攻撃のリストに加えるだけのことだ」。
「週末までにSSHの総当たり攻撃を行う攻撃者がこれを試しているのを見なかったら、非常に驚くだろう。試すのはほぼ無料で、うまくいけば簡単に成功する」と同氏は付け加えた。
サービスにパッチを適用し、過去のアクセスを調査する
OpenSSHはバイパスに対処するバージョン10.6p2を11月5日にリリースした。Alpineは旧ブランチ向けのパッチ適用済みパッケージも提供しているため、管理者は上流版のバージョン番号だけに頼らず、ディストリビューションのアドバイザリを確認すべきだ。
セキュリティチームは、次の3つの手順を優先すべきだ。
- 露出状況を確認：システムがmuslを使用しているか、パスワード認証が有効か、認証をPAMが処理していないか、必要なアカウント条件が存在するかを確認する。
- 修正を適用：適切なパッチ適用済みパッケージをインストールしてsshdを再起動する。パッケージを更新するだけでは、稼働中のデーモンは置き換わらない。
- 必要に応じて緩和：まず、SSH鍵によるアクセスが機能することを確認する。次にPasswordAuthentication noを設定し、構成を検証してからsshdを再起動する。新しい鍵ベースのログインが成功するまで、現在の管理セッションは開いたままにしておく。
過去のアクティビティも確認する。Alpineは、パスワードが設定されていないアカウントへのパスワードログイン成功記録がないか、/var/log/messagesを確認するよう推奨している。想定外の権限昇格、新たに作成されたユーザー、authorized keysの変更を調査する。
アップデートに成功すれば、この認証回避は解消されるが、それ以前に攻撃者がシステムへアクセスしたかどうかまでは分からない。不審なログインがあれば、インシデント調査を開始すべきだ。
より広い教訓は、サーバーで実際に適用されている認証ポリシーを確認することだ。SSH鍵を使っていても、パスワードログインが自動的に無効になるわけではない。鍵ベースのアクセスを想定したアカウントでも、有効になっている別の認証経路を通じて露出したままになる可能性がある。
詳しく読む： CWPdoorマルウェアの検出と削除方法や、Linuxサーバー管理者が確認すべき警告サインと復旧手順について。