このページの本文へ

Black Hat USA 2017/DEF CON 25 ラスベガス現地レポート 第6回

インターネット上でSSL接続を利用していないブローカーを8万7000以上発見

刑務所のドア開放や電車の不正操作も? 無防備なMQTTのM2M接続

2017年08月29日 07時00分更新

文● 谷崎朋子 編集● 大塚/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 「今年のBlack Hat講演で最も簡単な“ハッキング”をご紹介しよう」。2017年7月に開催されたセキュリティカンファレンス「Black Hat USA 2017」で登壇したIOActiveのルーカス・ラングレン氏は、講演冒頭、半分冗談めかしながらも真面目な口調で述べた。

IOActiveのルーカス・ラングレン氏

 MQTT(MQ Telemetry Transport)は、元々は産業制御システム用に開発されたオープンソースのメッセージプロトコルだ。メッセージは軽量で帯域を効率的に使え、設定も簡単なことから、現在はM2M(マシンツーマシン)の主流プロトコルの1つとして広く採用されている。

 MQTTによるM2M通信の構成は非常にシンプルで、デバイスの状態をメッセージとして発信する「パブリッシャー」、それを受け取る「サブスクライバー」、それぞれの通信を仲介するサーバーとなる「ブローカー」から構成される。プログラムを書いて、これらの情報に基づきデバイスをリモートから操作することも可能だ。

MQTTはあらゆるモノが「ブローカー」を介してつながり、メッセージをやり取りする世界だ

 ブローカーへの接続方法は、デフォルトで設定されているポート1883(TCP接続)と暗号化通信に対応したポート8883(SSL)が用意されている。Webの世界で“常時SSL化”が当たり前となった現在、MQTTでも当然、後者(SSL)による接続が多いだろうと想像するかもしれない。

 しかし、ラングレン氏は「今回のBlack Hat会期中に、ポート1883を使うブローカーがインターネット全体でいくつかあるか調べたら8万7000以上あった」と明かす。つまり、インターネット上を流れる多くのMQTT通信は暗号化で保護されていないわけだ。加えて、ID/パスワードの基本的なセキュリティ対策すらしていないブローカーが大半だという。

MQTTにはセキュリティ機能(接続時の認証や通信暗号化)も用意されているが、使われていないケースも多々あるという

路線運行情報から刑務所の監房のドアセンサーまでが“丸見え”

 そんな無防備な状態でどんな通信が行われているのだろうか。MQTTでは、送信したい/受信したいメッセージを示す「トピック」という仕組みがあり、これはスラッシュ(/)で区切って表現する。たとえば「情報通信/MQTT/セキュリティ」とすれば、IT分野のMQTTで、セキュリティに関するメッセージを受け取ることができる。メッセージの範囲をおおまかに指定する場合は「+」または「#」を使う。

 というわけで、ラングレン氏は無防備な状態にあるブローカーに対して「#」を指定して10秒ほどリスンし(メッセージを待ち)、送られてきた膨大なメッセージを検証した。その結果、「これは見せちゃダメだろう……」というメッセージを大量に発見したという。

 たとえば、Deutsche Bahn AG(ドイツ鉄道)の路線運行状況だ。どの電車がどの路線を走っているのかを、リアルタイムに知らせてくれる。

ドイツ鉄道の路線の運行状況に関するメッセージが丸見え

 また、おそらく所有者の趣味で追加されたテスラ車のセンサー情報も発見した。車種やエアコンの温度設定のほか、緯度経度の位置情報まで参照できた。これを継続的に傍受されると、車が止まっている位置から、自宅やオフィス、行きつけの店などが簡単に推測できてしまうだろう。

位置情報を継続的に取得すれば行動パターンがわかってしまう

 そのほか、刑務所の監房のドアセンサー、入院患者の心拍計の数値、粒子加速器や原子力発電所の計器データなど、デリケート過ぎるメッセージが無防備な状態で流れていたという。

原子力発電所から流れてきたメッセージには、冷却装置やモーターの状況などが分かる

「問題はMQTT自体ではない、安全に実装しない人間だ」

 もちろん、ただメッセージが見られるだけではない。前述したとおり、MQTTではリモート操作をプログラミングして送信することが可能だ。

 たとえば監房のドアをロック解除できるし、計器データに異常値が出ているように見せかけて間違った対応を誘うこともできる。鉄道の路線運行情報にニセの情報を流せば、間違った情報に基づいて線路の切り替えを誤り、大事故につながるかもしれない。「攻撃が成功したかどうかは、当日や翌日のニュースで分かるだろう」。

 また、ある医療機関では入院患者の心拍計やインシュリンポンプの情報をいつでもチェックできるよう、Webページを開設していた。「こうしたWebページはセキュリティ対策がされていないものがほとんどで、この医療機関もしかり。SQLインジェクションやXSSで患者情報を取得したり、うまくいけば医療機関のシステム内部に侵入したりすることも可能だった」と言う。

 「今回のケースで問題なのは、MQTT自体ではない。それを安全に利用するための情報を得ることなく実装している人間だ」とラングレン氏は強調する。そして利用者には「ユーザー/パスワード認証やSSL通信の採用を必須と考えてほしい」と訴えた。実は、同氏は昨年のDEF CONでもこのMQTTの問題を取り上げたが、真剣に取り合ってくれるところは少なかったと言う。

 なお、Amazon Web Service(AWS)やIBM Watson、Microsoft Azure IoTといった一部クラウドプラットフォームでは、ブローカーとなるサーバーのセキュリティ対策を「必須」としている。実際、ラングレン氏がテストでAWSに何ら認証方法を持たないデバイスを接続しようと試みたところ、即座に遮断されたという。

 「IoT接続で利用されるインターネットは、攻撃者がウヨウヨいる世界だ。IoT全般に言えることだが、ただつながればいいというものではない。それが一体“何をするものなのか”をよく考え、安全にMQTTを活用してほしい」

カテゴリートップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります

この連載の記事

アクセスランキング

  1. 1位

    sponsored

    60年の時を超え「COBOL」がGitHub Copilotでよみがえる 勘定系アプリの“超難関”モダナイに7社が挑戦

  2. 2位

    ビジネス・開発

    富士ソフトがエンジニア1万人超を「AIネイティブ」化 実装力を武器にフィジカルAIなど3本柱に注力

  3. 3位

    ITトピック

    IT技術者の8割超「AI生成コードには人間のレビューが必要」/「偽・誤情報を見破れる」と自信を持つ人はICTリテラシーテストの正答率が低い、ほか

  4. 4位

    sponsored

    「現場に行くのが当たり前」を変えたアズビルのリモート調整 効果はプライスレス

  5. 5位

    TECH

    攻撃するAIと防御するAI 日本企業のセキュリティ対策にいま何が必要か?

  6. 6位

    デジタル

    東京タワー相当の紙を“完全撤廃” 点検業務をkintone化した“現場ファースト”な改善術

  7. 7位

    ITトピック

    実用化が楽しみすぎるスマート技術たち 「長距離ワイヤレス給電」から「室内向け太陽電池」「超音波センサー」まで

  8. 8位

    TECH

    パンや酒、チョコづくりにも関わる微生物「酵母」の進化を追求

  9. 9位

    デジタル

    IoTデバイスをサイバー攻撃から守る IoT向けゼロトラストの“3つのアプローチ”

  10. 10位

    ITトピック

    6割超の企業で「セキュリティは取引条件」 SCS対応も進む/パワハラと指導の違い、あなたの基準は?/AIへの危機感か 転職希望のIT人材が増加、ほか

集計期間:
2026年07月22日~2026年07月28日
  • 角川アスキー総合研究所