IoT
第三者によるデータの盗聴や改ざんの可能性も：MQTTプロトコルやM2M通信におけるリスク
クラウドコンピューティングやM2M通信（Machine-to-Machine：機器同士の直接通信）が広まる中、ソフトウェアや機器のベンダーは、利用顧客のデータを保護する重要な役割を担っています。しかし、顧客側がこの点を十分に認識せず、ベンダーに対してセキュリティの確保を求めない、または確認しない場合があります。
クラウドコンピューティングやM2M通信（Machine-to-Machine：機器同士の直接通信）が広まる中、ソフトウェアや機器のベンダーは、利用顧客のデータを保護する重要な役割を担っています。しかし、顧客側がこの点を十分に認識せず、ベンダーに対してセキュリティの確保を求めない、または確認しない場合があります。結果、当該顧客が知らない間にソフトウェアや機器からデータが外部に流出し、危険な事態に発展する可能性があります。こうした状況を防ぐためにも、ソフトウェアや機器に組み込まれた通信プロトコルやセキュリティ対策について、検証を行う必要があります。近年に入って利用が急増しているMQTT（Message Queuing Telemetry Transport）プロトコルについては、特にそのことが言えるでしょう。
MQTTは、メッセージをキュー（Queue：待ち行列）に蓄えて配信する標準的なプロトコルであり、エンドポイント間における「サブスクライブ（登録）」、「パブリッシュ（送信）」方式のやり取りをサポートします。このやり取りは、「ブローカー」と呼ばれる中間的なエージェントの中立ちを介して行われます。MQTTのエンドポイントは、ブローカー経由でメッセージを送信できる他、自身をブローカーに登録することで、特定のメッセージを受け取れるようになります。メッセージは「トピック」と呼ばれる文字列によって分類され、これにより、登録済みエンドポイントへの配信や調整が的確に行われます。
トレンドマイクロでは2018年、IoT（Internet-of-Things：モノのインターネット）とIIoT（Industrial IoT：製造業のIoT）の双方に広く利用されるMQTTに着目し、そこに潜むさまざまな脆弱性や実装上の不備について報告しました。その後継となる本稿では、攻撃者によってMQTTのセキュリティ不備がいかに容易に発見されるか、そのMQTTから利用顧客や通信に関する情報がいかに流出するか、その情報やMQTTブローカー自体がいかに不正利用されるかについて、潜在的なリスクも視野に入れて解説します。
不備を抱えたブローカーの発見
オンラインのスキャンツール「Shodan」、「Censys」、「ZoomEye」を用いた調査により、TLSで保護されたMQTTS（TLS-secured MQTT）ブローカーの中でも、認証不要で公開されているものが数万件に渡って発見されました。次に、ネットワーク・ツール「Nmap（Network Mapper）」やスクリプト「mqtt-subscribe」を使用してブローカーの稼働状況を調べたところ、およそ9,000件が実質的に稼働中であることが判明しました。また、ホスト名やドメイン名に基づくフィルタリングの結果、調査対象のシステムがおよそ100件程度に絞り込まれました。続いて、対象システムのMQTTが送信するデータを取得、分析することにより、そのデータの内容や、どのような業務に使用されているかを、ある程度まで推測できることが判明しました。
利用顧客の業務種別を特定
MQTTSの利用顧客やその業務種別を知る手がかりは、先述のブローカーから取得される細かな通信データだけでなく、より基本的な汎用データも含まれます。例えば、ドメイン名（例：mqtt.companyX.com）やサブドメイン名（例：companyX.mqttbroker.com）、その他の識別情報（例：email@companyX.com）が挙げられます。攻撃者は、認証不要なアクセス経路を発見し、さらにその利用顧客をも特定することで、標的企業のデータを監視、または操作しようとする可能性があります。認証不要なままでシステムを公開した場合、そこで用いられるデータの機密性や完全性が損なわれるリスクがあることに注意する必要があります。
先述の通り2018年に実施した調査では、主にMQTTのプロトコル自体に絡む脆弱性や、不備を抱えたまま配備されている状況に着目しました。この時の調査では、MQTT利用顧客の業務種別として、ヘルスケア・モニタリング、アシスティブ・テクノロジー、アセット・トラッカー、メッセージアプリ、スマートファーミングなどが確認されました。
MQTTSに関する2022年の調査では、より具体的なユースケースが特定されました。例えば、産業用の温度モニタリング（冷凍庫、冷蔵庫、製造プロセスで使用）、人数集計（施設、モール、イベント会場への入場者数や収容可能人数を監視）、生産管理（会議室の予約、議事録の作成、実施要項の記録、リマインダの送信）、倉庫の在庫管理システム（RFIDの追跡、倉庫および出荷に関する情報）などが挙げられます。
送信データの内容と不正利用のリスク
以降、本調査で発見された送信データの一部について、その内容を交えて解説します。今回は90以上のサーバを調査しましたが、その中でも特に言及する価値のあるユースケースについて取り上げます。攻撃者が当該データを盗み出した場合、サービスの利用顧客を特定した上で、さまざまな不正行為に及ぶ可能性があります。例えば、プリント基板用乾燥器における温度設定情報の入手、社内秘会議メモの入手、公共施設への入場者数が多い時間帯や少ない時間帯の遠隔監視、在庫状況に基づく生産・出荷情報の盗み出し、などが挙げられます。また、攻撃者が実際と異なるデータを対象システムに送信できる場合は、さらに危険な事態に発展します。例えば、製品の保管に必要な温度条件を逸脱した際に発せられる警報を意図的に発動させる、施設の来場者数や従業員数を過大または過小に見せかけることで安全性に支障をきたさせる、倉庫間で製品を移動させる、機器を誤った場所に配送させる、などのケースが挙げられます。
温度のモニタリング
最初の調査対象は、温度測定器と、温度記録のデータです。今回は、2台の温度モニターの間でやり取りされる通信データを分析しました。当該機器の1つからは認証不要のMQTTSが発見され、「中間者（MitM：Man-in-the-Middle）」による通信傍受攻撃に脆弱なことが判明しました。はじめに、送信されるデータの種類を特定した上で、当該サーバを約1週間に渡って監視しました。結果、MQTTブローカーに届けられた温度データの一部が取得されました。図1に、得られた温度の分布やその区分けを示します。
- 極低温：－273℃ ～ －123℃
- 急速凍結温：－122℃ ～ －20℃
- 凍結温：－20℃ ～ 0℃
- 冷蔵温：1℃ ～ 15℃
- 室温：15℃ ～ 30℃
- 室温以上
- 調理または焼成温
本データから、温度のモニタリングを行っているさまざまな顧客や、使われている測定器の種別を推定できます。ワクチン貯蔵や不妊治療などの科学的用途であればおよそ－50℃以下、食品や医用材料の貯蔵などであれば－50℃から0℃、または冷蔵温が多いでしょう。家庭内用途、建築環境、苗床自動化などの場合は、室温に収まると考えられます。また、調理、プリント基板の製造、サウナなどは、室内以上の温度に達するでしょう。
続いて図2に、ある住宅の温度推移を1時間に渡って記録した結果を示します。本データは、MQTTブローカーに送信され、オンラインで参照可能な状態となっていました。全体として、滑らかな曲線を描いているように見えます。
次に、送信されたデータを傍受し、その値を改変した上で再送信した場合に何が起こるかを確認しました。結果としては図3の通り、未修正データと改変済みデータの双方が表示され、ギザギザの線が描かれました。この様子より、攻撃者が温度モニタリングシステムのデータをいかに改ざんしうるかが示唆されます。想定される攻撃シナリオとして、意図的に特殊な警報や対応を発動させ、厳格な温度調整が求められる医療用品や食品を損失させる可能性があります。
生産管理
今回調査したMQTTブローカーの1つは、生産管理ツールを扱う企業によるものです。その製品が提供する機能として、会議の予約管理、議事録の作成、次回参加者への通知、アラートやアクションに関連するアイテムの設定などが含まれます。調査結果に関する限り、当該のMQTTは、メールまたはSMSのアラートシステム宛てにメッセージを送信します。MQTTブローカーが受け取ったメールメッセージを図4に、SMSメッセージを図5にそれぞれ示します。
MQTTを介して送信されるメッセージは、会議のスケジュール、リマインダ、議事録、アラートだけではありません。今回の調査では、セキュリティ関連のメッセージも確認されました。例えば、新規ユーザの作成を通知するメッセージには、当該のユーザ名、本人のフルネーム、さらにはパスワードまでが含まれていました。また、パスワード再設定の通知メッセージには、確認用コードが含まれていました（図6）。新規ユーザの作成を通知するメッセージは下記の通りであり、MQTTから平文状態で送信されました。
userservices/user/create || {"tst":"2022-09-19T01:26:35.181671-0600","topic":"userservices/user/create","qos":0,"retain":0,"payloadlen":133,"payload":"{\"login\":\".\",\"password\":\".36\",\"firstname\":\"\",\"lastname\":\"\",\"mail\":\"@.\",\"language\":\"\"}"} ||
在庫管理
以上の他、大規模リテーラー向けにMQTTブローカーを提供している6つのサブドメインが発見されました。そのうちの4つは、「フォーチュン500（Fortune 500）」にも選定されています。また、当該のドメインは、在庫追跡サービスの企業に所属していることが判明しました。MQTTのメッセージを確認したところ、RFIDのトラッキング情報、倉庫に関する情報、出荷情報などが含まれていました（図7）。発見されたメッセージの一部を下記に示します。
- “Returnable container added to wrong shipment.”（返品可能なコンテナが誤った出荷グループに追加されました。）
- “Batch belongs on a pallet.”（物品一式が同じ荷台に属しています。）
- “Shipment will be updated with a quantity different than Expected.”（予定と異なった分量で出荷情報が更新されます。）
- “The RFID tag is loaded to wrong dock E02, the assigned dock is E03.”（RFIDが誤ったドック「E02」に格納されました。割り当てられているドックはE03です。）
人数集計システム
人数集計システムは、特にショッピングモールやイベント会場で導入が進んでいます。近年の人数集計システムは、カメラや人口知能（AI）を搭載し、ドアやゲートの通過者を自動で認識します。そして、入場者（イングレス：Ingress）や退場者（イーグレス：Egress）の数を、監視用のブローカーやダッシュボードに送信します。図8に有名な観光スポットのショッピングモールから取得されたデータを、図9に郊外の交通拠点に接するショッピングモールから取得されたデータを、それぞれ示します。
データの所有者
安全ではないMQTTブローカーを所有、運用しているのは、多くの場合、ソフトウェアや機器のベンダーであり、利用者や顧客自身ではないことが分かりました。このことは、現代の企業や組織にとって、データの場所を把握して安全性を確保することが、それほど容易ではなくなっていることを示唆しています。懸念される状況の1つとして、機密データや運用データをサードパーティ製システム経由で送信する際に、安全ではない手法や、実績不明の新規手法が用いられるパターンが挙げられます。
EU一般データ保護規則（GDPR：General Data Protection Regulation）によると、データ管理者（顧客）は、データ処理者（サードパーティ・ベンダー）が企業情報や個人情報の保護方針に準拠していることを確認する必要があります。このことは、データ管理者（顧客）がデータ処理者（ベンダー）に対し、データ保護に向けた強固なセキュリティ対策やアクセス制御を必ず実装するように、評価や監査、契約を通じて要請することを意味します。
データ管理者（顧客）がデータ処理者（ベンダー）を選ぶ際には、当該ベンダー側のサイバーセキュリティ、開発方式の安全性、ペネトレーションテストの実施状況、レッドチームの運用、脆弱性対策を購入条件に含めることができます。これは、ベンダー側が顧客側のセキュリティ対策やリスク許容度に準拠しているかを判断するためです。
しかし、トレンドマイクロの見立てとして、ベンダーによるサイバーセキュリティ対策には依然として改善の余地があります。ここでの問題は、セキュリティ不備を抱えたMQTTブローカーが多数配備されていたことのみにとどまりません。むしろ全般的に、ベンダー側では、脆弱性のレポートに十分対応しきれていないケースが見受けられます。今回の調査において、弊社はMQTTブローカーのベンダーに連絡を取り、セキュリティ不備や、認証および暗号処理の脆弱性について報告しました。しかし、本稿で挙げた温度モニタリングのベンダーを除き、問題点に対する認識や対策を示す回答は得られませんでした。
セキュリティ推奨事項
以降、今回取り上げた製品を利用するデータ管理者（顧客）、および同製品の設計、ビルド、コーディングを担うデータ処理者（ベンダー）側で実施できるベストプラクティスについて、解説します。
顧客の方は、使用する機器やシステムの安全性を確保するために、下記を実施することを推奨します。
- 機器やソフトウェアの購入に際しては、まず、当該製品が用いるプロトコルの安全性を確認する。
- 認証の仕組みが適切に組み込まれているかを確認する。
- 暗号化処理やセキュリティ対策が適切に実装されているかを、セキュリティチームを通して確認する。
- 利用する機器、ソフトウェア、サービスを介して企業の機密情報や識別情報が流出する事態を防ぐため、当該製品が用いるインフラ、証明書、セットアップの安全性を確認する。
- 対象ベンダーによる開発方針の安全性、ペネトレーションテストの実施状況、レッドチームの運用、脆弱性対策を精査する。これらに基づき、自社のサイバーセキュリティ要件に準拠しているかを確認する。
一方、開発チームやベンダーの方は、下記を実施することを推奨します。
- 機器やソフトウェアのインスタンス内に、認証や証明書チェックの仕組みが適切に実装されているかを確認する。
- 機器やソフトウェアのインスタンスが有する読み込み権限や書き込み権限は、実際にアクセスを必要するトピックのみに限定されているかを確認する。いかなる場合も、「最小権限」のルールに基づいて設計を行う。
- サービスの利用顧客向けドメインとして曖昧な名前（例：cmqttbroker.com）を使用しない。また、顧客が明示的に同意した場合を除き、サブドメインとして顧客の名前を使用しない。違反した場合、秘密保持契約（NDA：Non-Disclosure Agreement）などの法的条項に抵触する可能性がある。
- MQTTを介して送信するデータの種類を限定する。セキュリティ関連の情報、個人識別情報（PII：Personal Identifiable Information）、企業情報などの送信に際しては、より安全なプロトコルか、別の独立した経路を使用する。
まとめ
MQTTは非常に柔軟性に富んだプロトコルであり、さまざまな産業向けに展開する事が可能です。しかし、その安全性は、実装するベンダーに依存しています。もし証明書の照合が適切に行われていなければ、MitM攻撃に遭う可能性がありあす。また、アクセス元から有効な認証情報を求める手続きが欠落している場合は、誰でも当該のMQTTブローカーにサブスクライブできることになります。
これまでの調査に基づくと、MQTTの実装や利用に関するセキュリティ改善の必要性が、以前にも増して高まっています。その根拠として、特に下記2点が挙げられます。
- MQTTを用いるソフトウェアや機器の数が急増傾向にあり、すでに顧客側で管理できる範囲を超えている。ビジネスモデル「as-a-service」の拡大により、その傾向にさらなる拍車がかかっている。
- 運用データや企業データの作成や処理にサードパーティ・プロバイダを使用するパターンが増加している。
以上の事項は、インフラ、技術、実装に関する情報が、顧客の目に届きにくくなっていることを示唆します。結果、顧客のデータや「ヒント」がどこから流出しているかを見極めることも、難しくなります。さらに、データの流れも不明瞭なものとなります。このために、実際にどのようなデータが共有されているのか、データへのアクセス権が想定の企業や機器のみに付与されているのかどうかを、顧客側で判断できなくなる可能性があります。
上で挙げた両事項のいずれについても、顧客に関する識別情報を取り除き、データの作成や加工、送信、保存時の安全性を確保する能力を有するのは、ベンダー側となります。顧客はベンダーと協力し、使用するソフトウェアや機器、サービスに関する理解を深め、情報流出のリスクが高い領域を見極める必要があります。以上に加え、対象の製品やサービス、データの扱い方が、自社の求めるサイバーセキュリティの基準や方針に合致しているかを検証することも重要です。
こうした状況であるからこそ、サードパーティ・ベンダーによるセキュリティ対策やデータの扱い方について、抜本的に検討していく必要があります。購入検討中の機器やソフトウェア、サービスについては、その安全性を確認し、送信したデータが偵察活動や産業スパイ活動に利用されないか、製品が損傷する事態に至らないかどうか、十分に精査することを推奨します。MQTTの場合は、ユーザのメッセージを認証なしで受け入れるブローカーが数多く発見されました。そのため、問題はデータの流出のみにとどまらず、データの不正操作にまで及びます。不正操作が行われた場合、データの完全性が損なわれるだけでなく、業務工程や製造工程に直接的な影響が発生し、追加の監査を強いられる可能性もあります。以上のことは、MQTTがそれだけ強力なシステムであることを示すものであり、だからこそ、そのセキュリティ対策について真剣に取り組んでいく必要があります。
参考記事：
MQTT and M2M: Do You Know Who Owns Your Machine’s Data?
By: Ryan Flores, Charles Perine
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）