セキュリティ
Zbtlink曰く「単なるリモート保守機能に過ぎない」
中国のWi-FiルーターベンダーであるZbtlinkは、自社製品にバックドアが含まれているとの指摘を否定しました。しかしその一方で、未公表のセキュリティ脆弱性を修正するため、ファームウェアのダウンロードを一時停止しています。
バックドア混入の指摘を行ったのは、脅威インテリジェンスプラットフォームを提供するVulnCheckです。
VulnCheckの最高技術責任者(CTO)であるJacob Baines氏は水曜日、投稿の中でこのバックドア疑惑を明らかにし、自身の机の上にあるZbtlink製デバイスが「インターネット上のコマンド&コントロール(C2)サーバーへの接続を絶えず試みている」と述べました。
「Zbtlinkのルーターは指令を待って本国と通信します。ハッキングされたからではありません。最初からそう作られて出荷されているのです」
Baines氏はこのバックドアを「ENDLESSDOORS」と名付け、次のように説明しています。「これは『rctl(remote control linux)』と呼ばれる小さなツールです。2015年1月14日にGitHubにアップロードされて以来、一度も更新されていないこのマイナーなリポジトリは、単純なコマンド&コントロールのクライアント・サーバー機構を実装しています。サーバーはポート7000で待ち受け、クライアントに個々のシェルコマンドを送信したり、リバースbashシェルを起動させたりすることができます」
このCTOは、問題のバックドアが専用のLinuxカーネルスレッドとしてではなく動作している点を発見したと述べています。「これらは通常のユーザーランドプロセスとしてroot権限で動作しており、実際のメモリフットプリントを持ちながら、正規のプロセス群に紛れて見つからないような名前が付けられています」と同氏は記しています。
「これらはインプラント、つまり本国と通信するトロイの木馬なのです」
Baines氏はさらに続けます。「ハンドシェイクも、鍵交換も、ネゴシエーションも一切ありません。インプラントがサーバーに到達すると、固定長39バイトのhelloメッセージを送信します。これはヌルでパディングされた33バイトのクラスラベルと、それに続くLANのMACアドレスで構成されています。登録処理はそれだけです。クライアント側にもサーバー側にも検証は存在しません」
このCTOは「ネットワーク経路上にいる者なら誰でもクライアント・サーバー間の通信を乗っ取ることができる」とし、このソフトウェアが接続先とする「rbdg4nzqadui[.]wikaba[.]com」というエンドポイントの一つを制御できる者は誰であれ「本国通信を試みるあらゆるENDLESSDOORSインプラントを制御できることになる」と付け加えています。
The RegisterはZbtlinkにコメントを求めたところ、同社の広報担当者はVulnCheckが発見したコードの性質を誤って伝えていると回答しました。
「この機能はあくまでアフターサービスの保守を目的としたものであり、それ以外の用途はありません」と同社担当者はThe Registerに語りました。「通常はサンプル機にのみ残されており、顧客のソフトウェアデバッグ支援を目的としたもので、量産出荷製品には含まれません」
しかし、The RegisterがZbtlinkのダウンロードページを確認したところ、この説明はあまり説得力のあるものには思えませんでした。Baines氏は20機種を超えるルーターのファームウェアにバックドアが含まれていると主張していますが、そのページには次のような文言が掲載されていたのです。
ルーターファームウェアのセキュリティ対応に関するお知らせ
一部のルーターファームウェアのリリースに影響するセキュリティ脆弱性を検出しました。
予防措置として、影響を受けるファームウェアバージョンをダウンロードチャンネルから一時的に取り下げています。
当社エンジニアリングチームは、修正済みの安全なファームウェアの開発と検証に全力で取り組んでいます。
Wayback Machineに残る同ページの最新のスナップショット(7月31日取得)には、こうした記述は一切なく、多数のファームウェアダウンロードのリストが掲載されていたのみでした。
つまりZbtlinkは、セキュリティ上の問題を公に認めている一方で、The Registerに対しては問題がないと説明していたことになります。
Zbtlinkの広報担当者はまた、同社が「OEMおよびODMのカスタマイズサービスを専門としており、顧客はZBTのデフォルトファームウェアではなく、自社開発のソフトウェアを使用している」とも述べました。
実際、カスタムコードの開発はさほど難しいことではないでしょう。オープンソースのルーターファームウェアプロジェクトであるOpenWrtは、少なくとも1つのZbtlink製品に対応しています。同社はこれまでにも、OpenWrtの活用を宣伝しており、顧客がわずか30分でカスタムファームウェアパッケージを作成できるオプションも提供してきました。
VulnCheckによれば、同社が検証したデバイスが接続を試みるエンドポイントはわずか4つしかなく、そのうちZbtlinkと関連のあるドメイン名を使用しているのは1つだけだといいます。Baines氏はこの接続を「決定的な証拠」だと表現しました。The Registerが指摘するように、ルーターのファームウェアはサプライチェーン攻撃の実行者にとって格好の標的となり得ます。
事前の情報開示なし
Baines氏は、事態があまりに深刻であるため、責任ある協調的な情報開示の慣例は今回のケースには当てはまらないと判断しました。
「協調的な情報開示は、ベンダーに欠陥を修正する時間を与えるために存在するものです」と同氏は記しています。「それは、ベンダーがその挙動を意図していなかったという前提に基づいています」
「しかし今回はその前提が成り立ちません。これはパーサーにおけるメモリ破損バグのようなものではないのです。ベンダー自身の起動スクリプトによってブート時に開始される、ベンダー製品内のコンポーネントであり、20機種、そして何年分ものイメージにわたって出荷されてきたものです。調整すべきパッチなど存在しません。出荷元に『あなたたちはこれを出荷しましたよ』と伝えたところで、これらのデバイスの所有者には何の得もなく、むしろそのインフラを運用している者に警告を与えてしまうだけです」
VulnCheckによると、Zbtlink製品は同社ブランドのほか、ZBT、ZBTWiFi、Wiflyerといった名称でも販売されており、Amazon、Alibaba、Shopifyでの販売も確認されています。Zbtlinkが自社ハードウェアのカスタマイズを顧客に許可していることを認めている以上、他にも無数のデバイスがリスクにさらされている可能性があります。
Baines氏の投稿には、ルーターが接続を試みるエンドポイントへのアクセスを遮断するための、Suricata、Snort、YARA向けのルールに加え、感染の疑いがある機器を検出する方法についてのアドバイスも含まれています。
同氏はさらに、利用者に対して「デバイスを交換するか、少なくとも厳格な出口制御の内側に配置し、そのLANを信頼できないものとして扱う」よう勧めています。®
