通信プロトコルの脆弱性(3) - 「ひらけごま」はバックドアへ続く合言葉？！

　前回の記事からずいぶん時間が経ってしまいましたが、今回も前回に引き続き、ネットワークの通信プロトコルに潜む脆弱性について見ていきましょう。
　前回は「モバイルで脆弱」「自動設定で脆弱」という話をしました。このように、ひろく使われている状況で懸念されるプロトコル脆弱性ですが、他にはどんな状況で気をつけるべきでしょうか。

　プロトコルというと、せいぜいパソコンやスマホでインターネットを使う時のものだと思っている人もおおいと思います。ところが実際には、私たちの身の回りのさまざまなインフラで、数多くのプロトコルが使われています。
　例えば自動車がじつはコンピュータの塊だというのは最近よく聞く話です。自動車のブレーキやパワーウインドウなどにくっついた小さいコンピュータが、独自のプロトコルで「状況報告」や「指令」を送っているわけです。

　この、独自プロトコルというのがじつは曲者です。

　最近、高級車がハッキングされて海外では億単位の窃盗被害が出ていますが、これが実は独自プロトコルの脆弱性を突いたものだと言われています。自動車のキーレスエントリーを作っているエンジニアは「独自プロトコルだから大丈夫」とたかをくくったのかもしれませんが、独自プロトコルの解析は、実はさほど難しくありません。また解析できないほど複雑なプロトコルを作ったら、それはそれで脆弱性の発生源になってしまいます。
　安全なプロトコルを設計するのは、実はとても難しく、欧米のITトップ企業はこのために、情報科学でドクターをとった研究者を何人も抱えています。例えば TLS (SSLの最新版) の脆弱性を発見できる研究者は貴重です。TLS そのものが電子商取引の礎であり、その安全性が数百万人の顧客のプライバシや財産の安全に直結するのはもちろんのことですが、それ以上に、自社で設計するプロトコルに脆弱性がないか徹底的に検査してくれる、というメリットがあります。
　プロトコルの安全性検証というのは、ソフトウェアの安全性検証とならんで３０年以上のノウハウの蓄積をもつ世界です。もちろんITトップ企業は、そういう博士号を持った人材を囲い込むことがコア・コンピタンスですから、こういう人材を一定数雇うことが競争優位につながる、なんてことは殆ど言いません。

　さて、プロトコルの安全性検証のノウハウを持たない企業が、自動車のキーレスエントリーを作ったらどうなるでしょうか？ うちは大企業だから大丈夫、と強弁する設計・開発担当者もいますが、本当でしょうか？ せいぜい LAMP を覚えた程度の専門学校生や、情報科学で修士をとったぐらいのアマチュアには絶対に務まらない、難しい設計業務があるのだということを、企業トップも知るべきです。

　最近、自動車とならんで騒がれているのが IoT です。特に一般家庭むけ IoT 製品は出荷台数も多く、セキュリティアップデートされることも稀で、また見た目は一般家電製品なのにパソコン同様の OS を搭載していることから、ひとたび悪用された場合の効果は絶大で、このためバックドア（抜け穴）がないか執拗に探しているグループが世界中にいます。
バックドアとは、実際にはどのようなものでしょうか？　会話にたとえると、こんな感じです。

「いらっしゃい。パスワードをどうぞ」
「ひらけごま」
「ようこそ、管理者さま」

　この場合、「ひらけごま」がバックドア（抜け穴）に通じる合言葉となります。一般家庭むけ IoT 製品で問題なのは、おなじ合言葉を使えてしまう製品が数万台、時には数十万台出荷されている、ということです。
　そんなバカな、と思われるかもしれませんが、昨年話題になった Mirai ボットネットは、世界中の監視カメラにバックドアから侵入して制御を乗っ取り、非常に大規模なサイバー攻撃で世界を騒がせました。ちなみに「Mirai ボットネットは始まりでしかない」という報告も複数出ているので、今年は IoT 製品のバックドアを悪用したボットネットがさらに大規模な問題を引き起こすことでしょう。
　けしからん、バックドアは禁止しろ、と呻く声が聞こえてきそうですが、ここは現実を直視して、なぜバックドアを作り込んでしまうのか動機を探ってみましょう。

　まず挙げられるのがデバッグとトラブル対応です。特に IoT 製品はちょっとした電球やカメラ程度のモノに小さなパソコン相当の機能を組み込むわけですから、ディスプレイとキーボードがない。遠隔操作ができないと、うまく動作しなかった場合、お手上げです。

「監視カメラがうまく動かないんだけど？」
「お手上げです」

　あなたがヘルプデスクだったとして、こんな対応しか記載されていない製品、サポートできるでしょうか。もちろんできません。
　では開発チームがセキュリティマニアで、個体ごとに違うパスワードを設定したとしたらどうでしょう。

「監視カメラがうまく動かないんだけど？」
「ではカメラの裏側に記載のシリアル番号を読み取って、それに xyzabcdef をアペンドして、SHA-256ハッシュをbase64エンコードしてパスワードとして入力してください」
「え？ SHA-256 って何？ base64 って何？ うちビル管理会社なんだけど？」

　。。。これもダメそうです。というわけで、IoT 機器の導入先であるユーザ企業のリテラシや、ヘルプデスクの技術レベルなどを考えると、トラブル対応とセキュリティを両立するために複雑なことをやらせるのは考えものです。

　かくして、単純なバックドアが作り込まれるのです。もちろんバックドアを善しとしているのではなく、ヘルプデスクやユーザ企業のリテラシを考えて、その範囲内でできることを工夫していくべきでしょう。さきほどの例でいえば、シリアル番号を読み取るとその個体にあわせたリモートメンテナンス用のパスワードが表示されるアプリを作る、というのもひとつの案でしょう。もちろんこの場合、アプリの管理を厳重にしないといけませんが。

　この他にも、バックドアが作り込まれる要因がいくつかあります。冒頭に挙げた独自プロトコルは、バックドアを意図せず作ってしまう一大要因ですが、この他にも、プロトコルが複雑すぎる場合や、プロトコルを本来意図した使い方とはちがった使い方をした場合など、さまざまな状況でバックドアが生まれます。この話は深いので、また機会を改めて話をすることにしましょう。

　今回はこれくらいにしておきましょう。次回からはハードウェアの脆弱性についてお話ししたいと思います。

■関連ページ
【アクセリアのサービス一覧】
　・サービスNAVI