門林 雄基氏によるコラム、【通信プロトコルの脆弱性(3)】を公開

第10回：通信プロトコルの脆弱性(3)

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

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

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

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

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


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

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

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

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

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

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

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

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


・・・ここから先は、アクセリア株式会社で公開中のコラム本編でご覧ください。
(リンク »)


【門林 雄基氏のコラム】
・第1回：サイバーセキュリティに求められるバランス感覚 (リンク »)
・第2回：サイバーセキュリティが損なわれる原因を理解する(1) (リンク »)
・第3回：サイバーセキュリティが損なわれる原因を理解する(2) (リンク »)
・第4回：サイバーセキュリティが損なわれる原因を理解する(3) (リンク »)
・第5回：サイバーセキュリティが損なわれる原因を理解する(4) (リンク »)
・第6回：サイバーセキュリティが損なわれる原因を理解する(5) (リンク »)
・第7回：サイバーセキュリティが損なわれる原因を理解する(6) (リンク »)
・第8回：通信プロトコルの脆弱性(1) (リンク »)
・第9回：通信プロトコルの脆弱性(2) (リンク »)