目次


IoT マルウェア攻撃の徹底調査

IoT デバイスがゾンビ・ボットの群れに加わらないようにする方法

Comments

皆さんの IoT デバイスは攻撃にさらされています!(この警告は聞き飽きていることでしょう)

私ももうだいぶ前から IoT デバイスがいかに安全でないかを聞かされてきて、正直なところ、IoT マルウェア攻撃に無関心になっていました。IoT マルウェア攻撃に目新しい動きはないだけでなくこの類の攻撃は自分には関係がないと思っていたのです。

けれども、この考えは誤っています。自宅の中や企業ネットワーク上 (またはその両方) で IoT デバイスを使っている場合、それらのデバイスはすでに攻撃を受けているかもしれません。そうでないとしても、攻撃を受ける可能性があることに、ほぼ間違いありません。実に恐ろしいのは、デバイスがすでに攻撃を受けていて、そのセキュリティーが侵害されているという事態です。そうだとしても、そのことに気付いてもいないでしょう。

私の話に耳を傾ける気になりましたか? IoT デバイスのセキュリティーがどれほど大きな問題になっているかについてはこのリンク先のページに掲載されている、2015 年の HP の調査結果を読んでください。この調査によると、テスト対象の IoT ホーム・セキュリティー・デバイスの 100% に「顕著な」脆弱性が見つかったそうです。テストされたスマート TV、ホーム・サーモスタット、Web カム、スマート・ロックなどのデバイスはいずれも、スマート・ホームの一部として使用される可能性があります。

これらのデバイスで見つかった脆弱性は、脆弱なパスワード、ネットワークを介して通信する際の暗号化の欠如、アカウントの列挙 (つまり、有効なユーザー・アカウント ID を見つけるためにパスワード・リセット機能を使用すること) などです。

上記の調査結果を踏まえると、IoT デバイスが頻繁にハッカーやボット運用者たちのターゲットになるのも無理はありません。その事例としては、2016 年の 9 月 20 日にはセキュリティー専門のブロガーである Brian Krebs 氏に対する攻撃、10 月 21 日には米国の DNS プロバイダー Dyn に対する分散型サービス妨害 (DDoS) 攻撃が挙げられます。

以前の私のように IoT デバイスのセキュリティーに無関心になっているとしたら、このトピックを真剣に掘り下げるために、以下の点について考えてください。

  • IoT デバイスはどのような仕組みで動作するのか
  • IoT マルウェア攻撃とはどういったものなのか
  • IoT デバイスを攻撃から守るにはどうしたらよいか

この記事で、以上の質問に答えたいと思います。

IoT デバイスの仕組み

IoT デバイスが攻撃に対して脆弱なのはなぜなのかを理解するには、デバイスはどのような仕組みで動作するのかを詳しく調べる価値があります。

「IoT デバイス」という用語の意味は十分におわかりのはずですが、私と皆さんが同じ認識を持てるよう、この記事で使用するこの用語の意味を明らかにさせてください。

IoT デバイスとは、ネットワークにワイヤレスで接続されて、「モノ」(以降、鉤括弧なしでモノと表記します) をモニターまたは制御するためにそのワイヤレス接続を使ってデータを送受信する、特殊な目的を持つデバイスのことです。

IoT デバイスのハードウェア

IoT デバイスの中核となるものを理解するには、IoT デバイスを機能させる、基礎となっているハードウェアの主要な特性を理解する必要があります。その特性とは次のとおりです。

  • データを収集して制御する
  • データを処理して保管する

基本的に、IoT デバイスにはセンサー、アクチュエーター、またはその両方が内蔵されています。センサーがデータを収集し、アクチュエーターがそのデータを制御するか、そのデータに基づいて作用するという仕組みです。

  • センサー: モノをモニターし、モノに関するデータを提供します。これらのデータには、温度、光量、バッテリー・レベルなど、あらゆるものが該当します。
  • アクチュエーター: デバイスに内蔵されたハードウェア (スマート・サーモスタットのコントロール、スマート電球の減光スイッチ、ロボット掃除機のギア・モーターなど) を使用してモノを制御します。アクチュエーターはモノに対する物理インターフェースを表します。このインターフェースによってモノを作動させて、ヒーターをオンにする、照明を消す、ロボット掃除機を充電器まで戻らせるなどを行います。

IoT デバイスには例外なく、センサー・データを処理し、必要に応じてデータをローカルに保管し、デバイスを動作させるための計算能力を提供する手段が備わっています。

複数のセンサーからのデータを調整する必要がある場合、あるいはデータを (何らかの理由で) フラッシュ・メモリー内に保管しなければならない場合、それに対処するのは IoT デバイスを構成するデータ処理コンポーネントです。

IoT デバイスのファームウェア

IoT デバイスを動作させるファームウェアは、ハードウェアと外界との間に存在するオンボード・ソフトウェアです。これらのファームウェアは一般に、組み込みファームウェアとオペレーティング・システム・ベース (OS ベース) のファームウェアという 2 つのカテゴリーのいずれかに分類されます。

組み込みファームウェア

IoT デバイスのリソースは限られているため、通常はカスタマイズされた組み込みファームウェアが使用されます。組み込みファームウェアとは、デバイス上で実行されるソフトウェアを意味するもう 1 つの用語です。多くの場合、デバイス製造業者にとって唯一コスト効率の高いソリューションとなるのは、ハードウェアを十分に知り尽くしたプログラマーを雇って、ハードウェアと相互作用する組み込みファームウェアを作成させることです。

組み込みソフトウェアのエンジニアは、2 つの役目をこなさなければなりません。組み込みファームウェアを作成するだけでなく、ハードウェアと相互作用するソフトウェアを作成し、そのアプリケーション・ソフトウェアを介してユーザーがデバイスを操作 (デバイスを構成するなど) できるようにする必要があるためです。

OS ベースのファームウェア

IoT デバイスがセンサーの数を増やしたり、より大量のデータを処理したり、ストレージ機能を強化したりするなどして、より「スマート」に成長するにつれ (より複雑な読み取り処理を行うようになるにつれ)、新しい機能を管理して活用するように複雑化されたソフトウェアに対する需要も大きくなってきました。

初期のコンピューターは、ROM からファームウェアをロードして基本機能を実行するという初期の形から、MS-DOS のようなオペレーティング・システムを使用する形にまでに進化しました。それと同じように、IoT デバイスも成熟してきています。IoT デバイスは現在、オペレーティング・システム (OS) を実行して、デバイス上で実行されるハードウェアと他のソフトウェアとの間に抽象化層を設けるようになっています。

IoT オペレーティング・システムはデバイスのアプリケーション・ソフトウェアに対し、基礎となるハードウェアを抽象化することで、お馴染みの分業を可能にします。つまり、(ハードウェアを理解している) 組み込みソフトウェアのエンジニアは、デバイスのドライバーを作成することに作業時間を費やし、(ハードウェアに精通する必要のない) アプリケーション・プログラマーは、デバイスを「スマート」にさせるソフトウェアを作成することに作業時間を費やせるということです。

多くのデバイス製造業者が OS として選んでいるのは、Busybox です。Busybox は、必要最低限のものだけを装備した Unix オペレーティング・システムのバージョンであり、よく使われているユーティリティーの多くが含まれている一方、フットプリントが極めて小さく、UNIX の多数の機能を単一の実行可能ファイルで提供します。

IoT デバイスのワイヤレス通信

通常、IoT デバイスはワイヤレスで通信します。このことは、自宅内や企業内のどこででも IoT デバイスを使えることを意味します。デバイスの通信のニーズは、そのデバイスがどのように機能するよう意図されているかによって変わります。

802.11 Wi-Fi を使用してルーターに直接接続して機能するよう意図されているデバイスであれば、ルーター経由でインターネットにアクセスできます。このように Wi-Fi を使用するデバイスの好例としては、動きを感知することによって作動するセキュリティー・カメラが挙げられます。セキュリティー・カメラにはかなりの帯域幅が必要になる可能性があるため、Wi-Fi が使用されるというわけです。

また、IoT デバイス・グループのメンバーとして機能するよう意図されているデバイスもあります。例えば、スマート・ホームのゲートウェイ・デバイス (ハブとも呼ばれます) に接続される窓の開閉センサーは、窓が開けられたことを報告できるよう、Z-WaveZigbee などのワイヤレス・プロトコル (または、半ダースほどある同様のプロトコルのいずれか) を使用します。

IoT デバイスの管理

IoT デバイスを管理するには、主に 2 つの方法があります。一方の方法では、デバイスをネットワークに接続する必要があります (つまり、プロビジョニングする必要があります)。もう一方の方法では、デバイスをモニターに接続して制御します。それぞれの方法について、詳しく説明します。

デバイスをプロビジョニングする

多くの IoT デバイス (特に、温度センサーなどの小型デバイス) には、ユーザーがデバイスを操作するための組み込みハードウェア (タッチ・スクリーンなど) がありません。そのようなデバイスは、「ヘッドレス」デバイスと呼ばれます。ヘッドレス・デバイスを構成する 1 つの方法は、WPS (Wifi Protected Setup) を使用することです。そのための要件は、デバイスが WPS に対応していること、そして WPS 対応のルーターを使用できることです。最も単純なシナリオでは、IoT デバイス上の WPS ボタンを押した後、ルーター上の WPS ボタンを押します。これにより、2 台のデバイスが最終的に接続されます。

デバイスによっては Wi-Fi アクセス・ポイントを作成するものもあります。この場合、スマートフォンを使用して Wi-Fi アクセス・ポイントに接続することで、Wi-Fi ネットワークの資格情報を入力してセットアップ・プログラムにアクセスすることができます。

また、ゲートウェイなどのデバイスは、他のデバイスをスキャンし、セットアップ・モードやペアリング・モードになっているデバイスを検出して追加します。この場合、インターネットにアクセスするようにゲートウェイを構成し、ゲートウェイに他のデバイスを探り出すよう指示すればよいだけです。そうして検出されたデバイスを、その固有の手順に従ってペアリング・モードにすれば、デバイスがゲートウェイにアクセスできるようになります。

デバイスをモニターして制御する

デバイスがネットワークに接続された後は、そのデバイスをモニターして制御できます。デバイスを制御する方法の 1 つは、スマートフォンを (例えば、自宅内で) ゲートウェイに直接接続するか、インターフェースを介してクラウド・サービスに接続して使用することです。

インターネットに直接接続する CCTV セキュリティー・カメラのようなデバイスには、専用の IP アドレスが割り当てられます。このようなデバイスにはインターネットを介して直接アクセスできるため、クラウド・サービス・プロバイダーやゲートウェイを使用する必要はありません。

多くの IoT デバイスは自宅内や企業内に取り付けられますが、ファイアウォールに変更を加えてポート転送を有効にすると、インターネットに直接公開されます。このようにすれば、インターネット上のどこからでもデバイスにアクセスして、デバイスをモニターおよび制御することが可能になります。

IoT デバイスのセキュリティー

最後になりましたが、IoT デバイスのセキュリティーについて取り上げます。そうです、これが最後のトピックです。あいにく、IoT デバイスではセキュリティーが極めて大きな問題となりますが、ほとんどの場合、セキュリティーは後回しにされます。セキュリティーはいわば、補足部なのです。

リソースに制約はあるものの、ワイヤレス・ネットワークに接続できて、ほんのわずかな電力しか消費せず、しかも (消費者にとって) 最も重要なことに値段が手頃な信頼できるデバイスを作成するのは難しいことです。機能するデバイスを生産するだけでも山のような作業に対処しなければならないことから、開発ライフサイクルにおいてセキュリティーが最後の考慮事項となるのも無理はありません。

指摘するに値する点として、セキュリティーを非常に深刻に受け取っている製造業者も数多くあることがあります。けれども、そのような業者が製造するデバイスは高価になりがちであるというのが、トレードオフです。

ネットワーク上には、ほとんどセキュリティー対策が講じられていない安い (別の言い方をすれば、手頃な価格の、あるいはコスト効率の良い) デバイスが溢れています。このことが、IoT マルウェア攻撃の引き金となっているのです。

IoT マルウェア攻撃の徹底調査

「IoT マルウェア」についての話はよく聞きますが、実際のところ、IoT マルウェアとは何を意味するのでしょうか?詳しく説明させてください。まずは、その攻撃者についてです。

攻撃者

攻撃者は何者であるかと言うと、その簡単な (満足感の得られない) 答えは、はっきりとした答えは誰も知らないというものです。

このリンク先の記事で、高名なセキュリティー専門家である Bruce Schneier 氏が述べているのは、最近の攻撃の規模を踏まえると、攻撃を仕掛ける犯人は活動家や研究者ではなく、犯罪者でさえもないだろうということです。

Schneier 氏によると、攻撃者はターゲットの防御態勢をテストすることを目的に、複数の攻撃ベクトルを使う過程でターゲットにその防御策のすべてを露呈させます。Schneier 氏が言うには、このように慎重に実行される攻撃は国家主体 (政府機関) の特徴を備えています。そう考えると恐ろしいことです。Schneier 氏が少々過剰に反応しているのであってほしいと願うばかりです。

いずれにしても、誰が攻撃者であるのかははっきりしませんが、攻撃者が賢く、戦略に優れたハッカーであることは確かです。攻撃者を過小評価しないでください。

攻撃ベクトル

どのようなタイプの攻撃 (マルウェアまたはその他) でも、攻撃者は攻撃面をターゲットにする必要があります。特定のデバイスが持つ脆弱性の全領域として定義される攻撃面を攻撃者が識別し、それを十分理解するようになると、攻撃者には攻撃ベクトルが見えてきます。攻撃ベクトルとは、攻撃者がデバイスを悪用するために取ることのできる道筋のことです。攻撃ベクトルにより、攻撃者はデバイスに当初の意図とは別の内容を実行させることが可能になります。

IoT デバイスの一般的な攻撃ベクトルをいくつか見ていきましょう。

脆弱なパスワード

デバイスの開発ライフサイクルにおいてセキュリティーの優先度が低いことはさておき、製造業者はデバイスを簡単にセットアップできて使いやすいものにすることを目指します。なぜなら、製造業者は、IoT デバイスのエンドユーザーの多くは技術に精通しているわけではないことを理解しているからです。簡単にセットアップできて使いやすいデバイスにするために、製造業者は簡単にデバイスにログインできる手段を設けます。例えば、単一のユーザー ID とパスワードの組み合わせを使用してログインできるようにするといった手段です。

この単純さは、3 つの問題を生じさせます。

  1. デバイスがセットアップされた後、大半のユーザーは何も考えずにデバイスを使い続けて、デバイスのログイン資格情報を変更しないままにします。
  2. デバイスが配送された後、そのデバイスに関して既知となっているセキュリティー上の弱点のリストに、デフォルトのユーザー ID とパスワードが追加されます。
  3. 製造業者は覚えやすいユーザー ID とパスワードの組み合わせ (admin/admin、user/user など) をそのまま使い続けます。あるいは、同じく単純な組み合わせを新しく作り出したとしても、既知の攻撃ベクトルとしてすぐに追加されてしまいます。

暗号化の欠如

IoT デバイスの開発ライフサイクルでは、セキュリティーは結果論となることが多いため、暗号化のようなセキュリティー機能は見落とされるか、考慮もされないことがよくあります。業界では現在、IoT デバイス内での暗号化と認証に対処できる、暗号化コプロセッサーなどの暗号化機能をデバイスに組み込むよう求めています。IoT アプリケーションを設計して作成する際は、(データ暗号化手法に従って) ネットワーク上でのデータ保護を設計に盛り込まなければなりません。

あいにく、多くの IoT デバイスでは暗号化をサポートしていません。したがって、ソリューション全体の一部として使おうとしているデバイスを調査する際は、暗号化に対応するデバイスであることを入念に調べる必要があります。

バックドア

一部の IoT デバイス製造業者は、デバイスにバックドアと呼ばれる「隠された」アクセス・メカニズムを組み込みます。表向きはバックドアによってデバイスをサポートしやすくなりますが、実際のところ、このメカニズムは、ハッカーに対してフロント・ドアを開けることになる可能性もあります。ほとんどのユーザーにはバックドアを解読するだけの技術的ノウハウはありませんが、ハッカーにとって、バックドアを解読するのはたやすいことです。

そうは言っても、バックドアが既知になれば、製造業者はしきりに謝罪して、バックドアを閉じるファームウェア更新プログラムを直ちにリリースするはずだと思うことでしょう。けれどもその期待に反して、デバイス内のバックドアが既知になっても製造業者がそれを削除することはせず、そのバックドアにアクセスしにくくするための (少なくとも本人たちがそう考える) 対策を講じたという例は数えきれないほどあります。

ほとんどの場合、バックドアはユーザー ID とパスワードの組み合わせであるか、デバイス上のオープン・ポートのいずれかです (このポートを閉じることはできません)。このようなものを「バックドア」と呼ぶのは間違っています。ハッカーにとって、バックドアは単純明白な、広く開けられたフロント・ドアです。

インターネットへの公開

デバイスがインターネットに公開されるということは、常にデバイスが着信トラフィックを受け入れることを意味します。つまり、トラフィックによる攻撃にさらされるということです。インターネットへの公開にはこのような危険性が伴うということは、私が保証します。

実際に私が体験した事例を挙げます。私は仮想サーバーを何台か借りて、Web サイトを実行するために使用しています。これらのサーバーには SSH で接続できるよう、ポート 22 を開いた状態に維持していますが、デフォルトのファイアウォール・ルールをそのまま使用すると、これらのホストが常に攻撃にさらされます。具体的には、1 時間あたり数百件ものログインが試行されるのです!もちろん、私は管理するサーバーのすべてに対して iptables を実行し、スクリプト化された攻撃を無力にするだけの十分な時間、ログイン試行が失敗した IP アドレスをブロックするためのルールを設定しました。その結果、世界中から試行され失敗するログインは 1 時間あたり「わずか」5 件から 10 件になっています。

私が何を言いたいのかと言うと、インターネットに公開すれば、それが何であれ、必ず攻撃されるということです。また、ファイアウォールやホストへのアクセス方法を制御できるよう強化されたサーバーとは異なり、大半の IoT デバイスではほとんど、あるいはまったくセキュリティー対策が講じられていません。そのため、IoT デバイスはとりわけ攻撃を受けやすいのです。

それだけはありません...

前述したように、IoT デバイスには脆弱性が溢れています。パスワードが脆弱であるというだけでなく、デバイスがインターネットに直接公開されたり、デバイスにバックドアがあったりすれば、高度な知識がほとんどないハッカー (ちなみに、このようなハッカーは「スクリプト・キディー」と呼ばれます) でさえも、IoT デバイスを簡単な餌食にすることができます。

IoT デバイスをハッキングするスキルを持っているのは、国家主体や高度な知識を持つハッカーだけだと思っているとしたら、その考えを改めるべきです。

OWASP (Open Web Application Security Project) の一環となっている IoT Attack Surface Area Project というサブプロジェクトでは、IoT 攻撃面に含まれる潜在的な脆弱性をまとめてリストにしています。

攻撃

攻撃者がどのように IoT デバイス内に侵入するのかを説明したところで、次は攻撃自体について考えましょう。

お膳立てとなる IoT デバイスを攻撃の核心は、デバイスを乗っ取り、ハッカーの意思に従わせることにあります。このことから、攻撃には 2 つのフェーズがあります。1 つはスキャンして乗っ取るためのフェーズ、そしてもう 1 つは、その後の攻撃開始のフェーズです。どちらのフェーズも、通常は CNC (Command and Control) プログラムによって実行されます。

スキャンと乗っ取り

CNC プログラムは、インターネット上の IP アドレスをスキャンして、ポートが開いているホストを調べます。そのようなホストが見つかると、一連の既知となっているデフォルトのユーザー ID とパスワードの組み合わせ (admin/admin、root/admin、user/user など) を使用してログインを試行します。

ログインに成功した場合、使用したログイン資格情報と併せてデバイスの IP アドレスを報告するスクリプトが実行されます。CNC プログラムはスクリプトから報告された IP アドレスに従って、攻撃を実行させるデバイスにマルウェアをプッシュします。これで、デバイスは乗っ取られ、CNC からの以降の攻撃開始命令を待機します。

攻撃スキャン・プログラムは新しいデバイスをできるだけ多く乗っ取るために、このプロセスを続けます。このようにして乗っ取られたデバイスのそれぞれが、ボットと呼ばれます。

IoT デバイスがボットになってから攻撃に使われるまでにどれくらいの時間がかかるのかは、誰もはっきりとはわかりません。ボットが呼び出されてアクションを起こすまでの時間は 1 時間であることも、数日、数週間、あるいは数か月であることもあります。その間、デバイスの所有者はほぼ確実に、何が行われているのかに気付きません。

攻撃の開始

通常、単一の IoT デバイスにはそれほどの力はありません。したがって、ボットが 1 つだけであれば、大きな脅威にはなりません。けれども多数のボットをまとめてネットワークで接続すれば一般的な目的を達成できるので、注意しなければなりません。このようなボットネット攻撃は、いずれもハッカーの制御下にある数百、数千、あるいは数十万ものボットから行われます。恐ろしいほどの数です。

攻撃者がボットネット軍団を使用する目的は、通常は DDoS 攻撃またはスパム・ボットのいずれかにあります。

  • サービス妨害 (DoS) 攻撃は、ホストが処理しきれないほどの大量の HTTP (およびその他の) トラフィックを送ることで、ターゲット・ホストの機能を損なうことを目的とします。ターゲット・ホストは大量のトラフィックについに応答できなくなり、事実上ダウンします。

    DDoS (Distributed Denial of Service) 攻撃では、1 台の強力なコンピューター (またはコンピューターのクラスター) から攻撃を仕掛けるのではなく、多数 (数千または数十万) のホスト・コンピューターから攻撃を仕掛けます。IoT ボットネット攻撃の場合、これらのホスト・コンピューターに該当するのは多数の IoT デバイスです。これだけの数の IoT デバイスから攻撃されてしまうと、ターゲットは太刀打ちできません。

  • スパム・ボットによって、現在、スパム業界は勢いを増しています。このリンク先の記事で説明しているように、スパム業界では巨額の利益が生み出されています。システム管理者は、ユーザーの受信トレイに届くスパム送信者からのメールがほんの一握りになるよう願いつつ、既知のスパム・リレーをブラックリストに登録する作業に大量の時間と労力を費やしています。

    けれども、ブラックリストには登録されていない IP アドレスからスパムが送信されているとしたらどうなるでしょうか?昔ながらの正当なネットワーク上で正当なルーターを経由して稼働する IoT デバイスだとしたら、その IP アドレスがブラックリスト上に浮上するとは考えられません。しかも、正当なスマート TV がスパムを送信する数十万ものボットのうちの 1 つでしかなかったとしたらどうなるでしょう?それらの IP アドレスのうちのどれをブラックリストに登録すべきか突き止める際の管理部門の悪夢を想像してみてください。

攻撃者がボットネット軍団を意のままに使えるようになると、それらの無数の小型デバイスを使用して恐ろしいほどの量のインターネット・トラフィックを送り出したり、世界中にスパムを送信したりできるようになるのです。

IoT マルウェア攻撃の最近の事例

すでに耳にしているかもしれませんが、最近の IoT マルウェア攻撃の事例をいくつか紹介しましょう。

Mirai

Mirai は Busybox 攻撃です。Mirai の仕組みとしては、まず、インターネットをスキャンしてポート 23 (telnet) が開いているホストを探し出し、脆弱なパスワードの攻撃ベクトルを使用して、Busybox を実行しているデバイスにアクセスします。デバイス内に侵入すると、Mirai がインストールされます。すると、このマルウェアが CNC サーバーに接続して以降の命令を待機します。CNC サーバーは攻撃する際に、制御下にあるすべてのボットに対し、ターゲット・ホストが処理できないほどの各種のトラフィックを大量に発生させるよう指示します。

Mirai はおそらく最も有名な攻撃であり、主に、感染した CCTV カメラを使用して攻撃を仕掛けることが明らかになっています。Mirai を特異な攻撃にしている点には、以下があります。

  • Mirai には、General Electric、Hewlett Packard、米国国防省のサーバーをはじめ、「対象外」とするサーバーのリストが含まれています。
  • 「Anna-senpai」としてのみ知られている Mirai の作成者は、2016 年 9 月 30 日の Hack Forums でそのソース・コードを公表しました。

Mirai には何度かの大きな高まりがありました。最初の攻撃は、セキュリティー専門のブロガーである Brian Kreb 氏のサイトに対して 2016 年 9 月 20 日に行われました。翌月の 2016 年 10 月 21 日には、米国の DNS プロバイダー Dyn が攻撃されて、Twitter、Airbnb などの他に、人気の高いストリーミング配信サービス Netflix がサービス停止状態に追い込まれました。

Errata Security ブログのセキュリティー研究者である Robert Graham 氏は、2017 年に米国カリフォルニア州サンフランシスコで開催された RSA Security Conference で、この攻撃の分析を発表しています。

Brickerbot

セキュリティー会社の Radware が、「Brickerbot」と名付けた潜在的攻撃について初めて警告したのは、2017 年 4 月 4 日のことです。

同じく Busybox ベースの攻撃であるこのマルウェアは、デバイスを操作不可能 (使用不可能) にすることから、この名前が付けられました。

PDoS (Permanent Denial of Service) 攻撃として知られるこのタイプの攻撃中に、Brickerbot は一連の Busybox コマンドを使用します。具体的には、カーネルを再構成するコマンドとともに Unix の rm コマンドを使用してデバイスの内部ストレージを消去し、最終的に (使い物にならなくなった) デバイスをリブートします。

同じ 4 月の後半に、Hack Forums で「Janit0r」というユーザー ID を持つ、「gray-hat」というハッカーがこのマルウェアの作成者であると名乗り、HackForums の投稿で、このウィルスはあまりにも簡単にハッキングできるデバイスを製造している「不注意な製造業者」をターゲットにしたものだと発表しました。詳細については、このリンク先の投稿を参照してください。

スパム・ボット

e-メールはスパム送信者の活力源です。スパム送信者の真の目標は、興味を引く件名やわいせつな内容 (クリックベイト) を使った e-メールによって、顧客の Web サイトへのアクセスを促すことだからです。e-メールを受け取った相手にリンクをクリックさせる気にするために、さまざまな戦術が使われます (「一晩で 100 ポンドの減量を実現しましょう!今すぐここをクリックしてください!」、「iPhone を無料で手に入れるには、ここをクリック!」といった宣伝で誘惑するなど)。

このような戦略が成功するかどうかは、そもそも攻撃相手の受信トレイに e-メールが届くかどうかにかかっています。スパム送信者にとって一番の問題は、スパム・フィルターに引っかからないように e-メールを送信することです。スパム・フィルターの多くは、スパム送信者によって使われていることが知られている (第三者中継メール・サーバーなどの) SMTP (Simple Mail Transport Protocol) サーバーの IP アドレスを登録した「ブラックリスト」を使用してスパムを検出します。

けれども、スパム送信者の SMTP サーバーで、ブラックリストに IP アドレスが登録されていない、正当に見えるプロキシー (SOCKS プロキシー) を使っているとしたら (正当なスマート TV の例を思い出してください)、スパム e-メールがターゲットの元に辿り着く可能性は大きくなります (このような e-メールが届いたとしても、残念ながら無料の iPhone を手に入れられるわけではありません)。

Linux.ProxyM ウィルスは、2 次ペイロードとしてのトロイの木馬です。最初のトロイの木馬がコンピューターに感染すると、Linux.ProxyM が活動を開始します。その仕組みはと言うと、例えばターゲットが「無料の iPhone を今すぐ入手!」という言葉に騙されてリンクをクリックし、リンク先のページで「シンプルな無料の iPhone プラグイン」のインストールに同意すると、コンピューターが感染します。コンピューターが感染した時点でスクリプトがスキャンを開始し、脆弱な IoT デバイスを探します。脆弱な IoT デバイスが見つかると、もうお馴染みの脆弱な資格情報を悪用して、デバイスにアクセスします。

アクセスされたデバイスは、攻撃を実行する実際のマルウェアが含まれる 2 次ペイロードに感染します。このマルウェアは CNC サーバーに接続してそこから e-メール・アドレスのリストを入手し、SMTP サーバーに接続します。この時点で、デバイスは SOCKS プロキシーとして機能するようになり、CNC サーバーの命令に従ってスパム e-メールを送信します。

IoT デバイスを保護する方法

IoT デバイスを感染から保護するには、どうすればよいのでしょうか?そもそも、デバイスが感染することを阻止する必要があります。そのために実に役立つアドバイスを紹介しましょう。

デバイスがすでにデプロイされているとしたら、良いニュースと悪いニュースがあります。悪いニュースは、(前述したように) デバイスが直接インターネットに公開されている場合、それらのデバイスはすでにプローブされているか、最悪の場合はボットに変身させられています。

良いニュースは、ほとんどの IoT マルウェアはメモリー内に存在するということです。そのため、デバイスの電源が入っている限りマルウェアは存続しますが、デバイスを再起動すれば、マルウェアは消え去ります。

冗談は抜きにして、それでもやはり、最初からデバイスが感染しないよう保護することが最善です。当たり前のことを指摘するようですが、いくつかのヒントを紹介しましょう。

デフォルトのパスワードを必ず変更すること

新しいデバイスをプロビジョニングする際は、デフォルトのパスワードを必ず変更してください。あまりにも単純なことのように思えますが、それでも新しいデバイスをいじくり回せるように (つまり、実用に移すために) セットアップする作業に追われていると、この肝心なステップを忘れがちです。このステップは決して省かないでください!

管理インターフェースを表示して、パスワードを変更します。デバイスをインターネットに公開することを予定している場合、パスワードを変更する手段がないとしたら、デバイスを返品してください。もちろん楽観的に考えて、デバイスがボットにならないようひたすら願うという選択肢もありますが、マルウェアの作成者たちは楽観主義者が大好きであることをお忘れなく。

telnet バックドアが設けられているデバイスを除去すること

ベンダーはバックドアを設けるのは賢いことだと考えるかもしれませんが、決してそうではありません。製造業者にとって、バックドアがあればサポートしやすくなりますが、その代償はユーザーが払うことになります。

telnet バックドアが開いているデバイスはネットワークから除去する必要がありますが、そもそもバックドアが開いているかどうかはどのように判断すればよいのでしょうか?このリンク先にある BullGuard のスキャナーなどの IoT デバイス・スキャナーがあります。BullGuard のスキャナーでは Shodan という名前の IoT 検索エンジンをスキャンして、スキャンを開始したコンピューターの IP アドレスを基に、デバイスが脆弱であるかどうかを明らかにします。経験則として、スキャンする対象は、自分が所有している IP アドレスや、所有者からスキャンする許可をもらっている IP アドレスだけにしてください。

以下に、私のコンピューターから実行したスキャンの結果を示します。

図 1. 未加工のパブリック IP アドレスに対する BullGuard スキャンの結果
未加工のパブリック IP アドレスに対する BullGuard スキャンの結果を示す画面のスクリーンキャプチャー
未加工のパブリック IP アドレスに対する BullGuard スキャンの結果を示す画面のスクリーンキャプチャー

以下のスクリーンキャプチャーのようなスキャン結果が表示される場合は、問題がある可能性があります。

図 2. 潜在的な問題を示す BullGuard スキャンの結果
VPN IP アドレスに対する BullGuard スキャンの結果を示す画面のスクリーンキャプチャー
VPN IP アドレスに対する BullGuard スキャンの結果を示す画面のスクリーンキャプチャー

決してデバイスをインターネットに直接公開しないこと

ファイアウォールを開いてデバイスをインターネットに公開するかどうかを判断しなければならない場合、その答えはほぼ必ず「いいえ」です。

BullGuard では、ISP によって割り当てられた、一般公開されている IP アドレス上で開いているポートがあるかどうかをチェックする「ディープ・スキャン」を実行することもできます。このディープ・スキャンによって、私はルーター上に開いているポートがあるかどうかを確認することができました。その結果、開いているポートがないことがわかり、安心しました。

図 3. 未加工のパブリック IP アドレスに対する BullGuard ディープ・スキャンの結果
未加工のパブリック IP アドレスに対する BullGuard ディープ・スキャンの結果を示す画面のスクリーンキャプチャー
未加工のパブリック IP アドレスに対する BullGuard ディープ・スキャンの結果を示す画面のスクリーンキャプチャー

すべてのマシン上でポート・スキャンを実行すること

BullGuard のようなスキャナーによって、IP アドレスが安全であるというある程度の安心感を得ることはできますが、皆さんが私と同じであれば、自分でもツールを実行したいはずです。

私は借りている仮想ホストでどのポートが開いているかを確認するために、Mac Network Utility を使って仮想ポートのうちの 1 つをスキャンしました。

図 4. Mac Network Utility のスキャン結果
Mac Network Utility のスキャン結果を示す画面のスクリーンキャプチャー
Mac Network Utility のスキャン結果を示す画面のスクリーンキャプチャー

私はこの結果にそれほど驚かされませんでした。この仮想サーバーは Web サイトをホストし、Apache を実行し、Tomcat AJP バックエンドを備え、管理目的で SSH アクセスを使用します。

まとめ

この記事では、IoT デバイスの仕組みについて詳しく調査した後、IoT マルウェア攻撃について徹底的に調査し、ニュースになったマルウェア攻撃をいくつか紹介しました。そして最後に、デフォルトのパスワードを変更し、IP アドレスのスキャンを実行することによって IoT デバイスを保護する方法を説明しました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=セキュリティ, Internet of Things
ArticleID=1060651
ArticleTitle=IoT マルウェア攻撃の徹底調査
publish-date=05242018