通信プロトコルの脆弱性(1)

サイバーレジリエンス
通信プロトコルに潜む脆弱性
 前回までのコラムでは、3回にわたって設定の脆弱性について解説しました。脆弱性なんて開発現場だけの話でしょ、と思っていた人に読んでもらえればと思います。(前回のコラム
 今回からは、スマートフォンやパソコンでメールやウェブでやりとりするときに皆さんが意識せずに使っている、「通信プロトコル」に潜む脆弱性について解説を試みるとしましょう。
 通信プロトコル、というと、いささか古くさいですが、外交など他の分野でも「プロトコール」という言葉が使われることがあるので、あえて使ってみました。今日では「通信プロトコル」と言わず、ITの文脈ではたんに「プロトコル」と書くことが多いので、以降では外交の話はしていないんだな、とご理解ください。
忘れられたプロトコル脆弱性
 通信プロトコルに潜む脆弱性、つまりプロトコル脆弱性は、実はとてもやっかいです。プロトコル、つまりスマートフォンやパソコンが通信するときの決まり事に抜けや漏れがあるわけですから、パソコンのOSだけ直しても、スマートフォンのOSだけ直しても、片手落ちです。時にはクラウドで動いているソフトも、ルータのOSも直さないといけません。
 プロトコル、つまり通信の決まり事というのは、あらゆるコンピュータの共通言語のようなものですから、そこに抜けや漏れがあるというのはどういうことでしょうか。

 人間のやりとりに例えるとこんな感じです。
 「ねぇ、あの見積書どうなった?」
 「ねぇ、あの見積書どうなった?」
 「ねぇ、あの見積書どうなった?」
 「ねぇ、あの見積書どうなった?」
 「ねぇ、あの見積書どうなった?」
 「ねぇ、あの見積書どうなった?」

 これをずっとやられると、どうでしょう。まあ催促する手段としては時にはユーモラスで効果的かもしれませんが、100回やられたら、たまったものではないでしょう。人間の場合だと、待ってもらう、とか、少し怒ったポーズを見せて黙ってもらう、とかいろんな手段がとれますが、コンピュータは通信の決まり事にしたがって愚直に処理します。

 「ねぇ、あの見積書どうなった?」
 見積書のステータスを確認しています…
 「ねぇ、あの見積書どうなった?」
 見積書のステータスを確認しています…
 「ねぇ、あの見積書どうなった?」
 見積書のステータスを確認しています…
 「ねぇ、あの見積書どうなった?」
 見積書のステータスを確認しています…
 「ねぇ、あの見積書どうなった?」
 見積書のステータスを確認しています…
 「ねぇ、あの見積書どうなった?」
 見積書のステータスを確認しています…

 まあ、ざっとこんな感じです。この例はサービス妨害につながる脆弱性と呼ばれます。いわゆるDoS攻撃とか、DDoS攻撃というのは原理的にはこんな感じだと思ってもらってよいでしょう。
 このプロトコル脆弱性に対しては、ある回数を超えたら待ってもらう、とか、要求を送信するたびに待ち時間を倍にする、とか、いろいろな対策が考えられます。しかし、ここで問題となるのは、

 全員が共通言語(=プロトコル)をアップデートしないといけない

 ということです。しかもその共通言語というのは、世界中から集まったエンジニアが2年以上の時間をかけて合意して、億単位のお金を投資して各メーカーが規格書を読み込んでソフトウェアとして実装したものなのです。
 さて、ざっと50億かけて、世界中のエンジニアで協力して、みんなで形にして世に送り出したプロトコルに脆弱性が見つかったとします。何億台というスマホやパソコンのOSに組み込まれている場合、さあ大変です。近年はセキュリティカンファレンスなどで大々的に発表されることも多いですが、日本ではどうしても(対策がないからとか、良心的理由で)扱いが小さくなりがちです。
 様子見しているあいだに、他のニュースが飛び込んできます。

 「そういえば、あの脆弱性どうなった?」
 「みんな対策していない。。。」
 「サーバ側はなんとかなるんだけど、クライアントがね。。。」
 「このスマホ、ファームウェアの更新がもう止まってるんだよね」

 笑えない話ですが、実際によくある話です。皆さんがお使いの最新のスマホも、複数のプロトコル脆弱性を必ず抱えています。もっともメーカーに詰め寄っても、「それはプロトコル(規格)の問題なので弊社のソフトウェアの問題ではありません」「一部の人たちが騒いでいるだけです」と逃げられると思いますが。
関係するすべての人が当事者意識をもってプロトコルを安全なものに刷新する必要がある
 以上みてきたように、プロトコル脆弱性は影響範囲が大きく、また対策するには共通言語をアップデートする必要があるので、一斉にアップデートすることが往々にして求められます。
 またプロトコルの規格書そのものに抜け漏れがあった場合、規格書の改訂も必要となります。規格書を改訂するには、投票やら標準化会合やらで少なくとも2年はかかると思って間違いないでしょう。また、苦労して稟議書を書いて、50億のソフトウェア開発投資をした各社エンジニアの面目も丸潰れです。
 プロトコルの脆弱性を「なかったことにしたい」面々のモチベーションも、良くわかります。それが20年続くと、どうなるでしょうか。
 DDoS攻撃。フィッシング詐欺。標的型のメール詐欺。これらは全て、プロトコルの脆弱性を「なかったことにしたい」人たちの集団的無責任が生み出した怪物だと思います。誰か一人、一社に責任があると言っているのではなく、「規格の問題だ」「ソフトウェアの問題だ」「人間の問題だ」などと、他所に責任の所在があるかのように主張して、我関せずと多機能化、高性能化、見た目の改善などに邁進してきたツケを今頃になって払っているのだと思います。
 試みに、あるプロトコル脆弱性をとりあげて「これはプロバイダの問題か、メーカーの問題か、標準化の問題か、ユーザの問題か」とサプライサイドの人たちに詰め寄ってみるといいでしょう。「それは我が社の問題です」と認める会社は、ほぼ皆無でしょう。

 なぜなら、インターネット全体から訴えられる可能性がありますから。

 もっとも無難な言い訳は、「それはマーケットの構造的問題です」というものでしょう。これなら、誰も悪者になりません。プロトコル脆弱性を直すための経済的インセンティブがない、マーケットメカニズムがない、現状把握できていない、等々、美しい言い訳はいろいろ思いつきます。「やらない言い訳」を考えることについて天才的な人は皆さんの周りにもいることでしょう。
 私がおすすめする正解は、すべてのプロトコル脆弱性についてプロバイダも、メーカーも、標準化団体も、ユーザも応分の責任分担をすべき、というものです。セキュリティ専門家が、あなたの(ファームウェア更新が止まってしまった)スマホを何とかできるわけもないですし、管理者が遁走してしまったサーバを何とかできるわけでもないので、すべての人が当事者意識をもってネットワークの共通言語=プロトコルを安全なものに刷新していく必要があるのです。

 今回はこれくらいにしておきましょう。次回も、プロトコル脆弱性のやっかいな性質について紹介したいと思います。

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

門林 雄基

アクセリア株式会社 主幹研究員
奈良先端科学技術大学院大学 先端科学技術研究科 教授
日欧国際共同研究「EUNITYプロジェクト」日本側研究代表
WIDEプロジェクトボードメンバー

◆crash.academyで動画講座公開中です。(動画視聴には会員登録が必要です。)
https://crash.academy/lecturer/kadobayashi