研究者がGNU InetUtilsのtelnetdに、リモートの攻撃者がパスワードなしでroot権限を取得できる可能性のある脆弱性を発見した。これにより、外部に公開されたTelnetサービスはシステム全体の侵害リスクにさらされる。
この脆弱性はユーザーの操作を必要とせず、細工したログイン要求をネットワーク経由で送信することで悪用できる。
この脆弱性を悪用すると、クライアントは「通常の認証プロセスを回避して、自動的にrootとしてログインさせられる」ことを述べた研究者は。
Telnetdの認証バイパス
この認証バイパスはGNU InetUtilsのバージョン1.9.3から2.7までに影響し、InetUtilsのtelnetdサービスを実行しているシステムを、リモートから侵害される可能性にさらす。
Telnetはレガシープロトコルと見なされているものの、古いLinuxやUnix環境、組み込みデバイス、分離されたネットワークでは今も使われている。そのため、信頼できないホストからtelnetdにアクセスできる場合、この脆弱性は特に危険だ。
根本原因は、GNU InetUtilsのtelnetdが、受信接続の処理時にシステムの/usr/bin/loginプログラムを呼び出す方法にある。
Telnetセッション中、telnetdはリモートクライアントからUSER環境変数を受け取り、入力を無害化せずにそのままloginへ渡すことがある。
この安全でない受け渡しによりパラメーターインジェクションが可能になり、攻撃者は細工したUSER値に-f rootを含めることができる。
多くのUnix系システムでは、loginが-fオプションを、特定の条件下で通常の認証チェックを回避できる、信頼済みログイン用のフラグとして解釈する。
そのためtelnetdがユーザーの指定した値をそのまま転送すると、攻撃者は認証を完全に回避し、パスワードを求められることなく、直ちにroot権限を取得できる可能性がある。
この問題が重大と見なされるのは、リモートから認証なしで悪用でき、必要な労力も少ないうえ、root権限によるシステム全体の侵害につながるためだ。
この脆弱性は2015年3月に行われたコード変更で入り込み、GNU InetUtils 1.9.3で初めて出荷され、その後のすべてのリリースでバージョン2.7まで残っていた。
Telnetへの露出を減らす方法
この脆弱性により認証なしでrootアクセスが可能になるため、外部に公開されたTelnetサービスは緊急性の高いセキュリティリスクとして扱うべきだ。
最善の防御策はTelnetを完全に廃止することだが、多くの組織はいまだにレガシーシステムや運用ワークフローでTelnetに依存している。
- 可能な限りtelnetdを無効化し、リモート管理をSSHへ移行するか、その他の安全な代替手段を利用する。
- パッチを適用するか、GNU InetUtilsを修正版へアップグレードして、認証バイパスのリスクをなくす。
- 厳格な許可リスト、ネットワークのセグメンテーション、信頼できないアクセスを遮断するファイアウォールルールによってTelnetへの露出を制限する。
- VPNまたは踏み台ホスト経由のアクセスを必須とすることで、残存するTelnetの利用を一般ユーザー向けネットワークやインターネットに面したネットワークから切り離す。
- ローカルファイアウォールなどのホストベースの制御を適用し、必須のアクセス制御ポリシーと併せて、Telnetセッションが到達できる範囲を制限する。
- 監視し、不審なTelnetアクティビティを検知したらアラートを出す。予期しないrootログイン、異常なセッション数、新たな永続化の痕跡などが対象となる。
- レガシーなアクセスサービス向けのインシデント対応計画を定期的にテストし、封じ込め、認証情報のローテーション、復旧手順を検証する。
これらの対策を組み合わせることで、Telnetへの露出を減らし、この脆弱性が完全なroot侵害につながるのを防げる。
この脆弱性は、Telnetのようなレガシーサービスが、外部または広範囲からアクセス可能な状態にあると、わずかなコーディング上の欠陥を重大なセキュリティインシデントに変えてしまうことを改めて示している。
Telnetを限られた運用上の用途にしか使っていない場合でも、認証なしのrootアクセスは対処が必要なリスクだ。まずはtelnetdを無効化するか、影響を受けるシステムにパッチを適用し、アクセス制御と監視を強化する必要がある。
これが、組織がゼロトラストソリューションを採用する理由の一つだ。こうしたソリューションは暗黙の信頼を最小限に抑え、レガシーかどうかを問わず、あらゆるシステムへのアクセスを厳格に制御する。