通信プロトコルの脆弱性(1)
アクセリアは、インターネットやサイバーセキュリティを専門とするスペシャリストが身近におりますので、知見にたけた専門家協力の元、お客様のご要望に沿ったソリューションのご提案も得意としております。また、弊社Webサイトでは、「サイバーレジリエンス」と題し専門家によるコラムも連載しております。
ECのミカタでも、コラムをご紹介させていただくことになりました。皆さまの効果的な対策につなげるためのヒントになれば幸いです。
アクセリア株式会社
https://www.accelia.net/
通信プロトコルに潜む脆弱性
前回までのコラムでは、3回にわたって設定の脆弱性について解説しました。脆弱性なんて開発現場だけの話でしょ、と思っていた人に読んでもらえればと思います。
今回からは、スマートフォンやパソコンでメールやウェブでやりとりするときに皆さんが意識せずに使っている、「通信プロトコル」に潜む脆弱性について解説を試みるとしましょう。
通信プロトコル、というと、いささか古くさいですが、外交など他の分野でも「プロトコール」という言葉が使われることがあるので、あえて使ってみました。今日では「通信プロトコル」と言わず、ITの文脈ではたんに「プロトコル」と書くことが多いので、以降では外交の話はしていないんだな、とご理解ください。
忘れられたプロトコル脆弱性
通信プロトコルに潜む脆弱性、つまりプロトコル脆弱性は、実はとてもやっかいです。プロトコル、つまりスマートフォンやパソコンが通信するときの決まり事に抜けや漏れがあるわけですから、パソコンのOSだけ直しても、スマートフォンのOSだけ直しても、片手落ちです。時にはクラウドで動いているソフトも、ルータのOSも直さないといけません。
プロトコル、つまり通信の決まり事というのは、あらゆるコンピュータの共通言語のようなものですから、そこに抜けや漏れがあるというのはどういうことでしょうか。
人間のやりとりに例えるとこんな感じです。
「ねぇ、あの見積書どうなった?」
「ねぇ、あの見積書どうなった?」
「ねぇ、あの見積書どうなった?」
「ねぇ、あの見積書どうなった?」
「ねぇ、あの見積書どうなった?」
「ねぇ、あの見積書どうなった?」
これをずっとやられると、どうでしょう。まあ催促する手段としては時にはユーモラスで効果的かもしれませんが、100回やられたら、たまったものではないでしょう。人間の場合だと、待ってもらう、とか、少し怒ったポーズを見せて黙ってもらう、とかいろんな手段がとれますが、コンピュータは通信の決まり事にしたがって愚直に処理します。
「ねぇ、あの見積書どうなった?」
見積書のステータスを確認しています…
「ねぇ、あの見積書どうなった?」
見積書のステータスを確認しています…
「ねぇ、あの見積書どうなった?」
見積書のステータスを確認しています…
「ねぇ、あの見積書どうなった?」
見積書のステータスを確認しています…
「ねぇ、あの見積書どうなった?」
見積書のステータスを確認しています…
「ねぇ、あの見積書どうなった?」
見積書のステータスを確認しています…
まあ、ざっとこんな感じです。この例はサービス妨害につながる脆弱性と呼ばれます。いわゆるDoS攻撃とか、DDoS攻撃というのは原理的にはこんな感じだと思ってもらってよいでしょう。
このプロトコル脆弱性に対しては、ある回数を超えたら待ってもらう、とか、要求を送信するたびに待ち時間を倍にする、とか、いろいろな対策が考えられます。しかし、ここで問題となるのは、
全員が共通言語(=プロトコル)をアップデートしないといけない
ということです。しかもその共通言語というのは、世界中から集まったエンジニアが2年以上の時間をかけて合意して、億単位のお金を投資して各メーカーが規格書を読み込んでソフトウェアとして実装したものなのです。
さて、ざっと50億かけて、世界中のエンジニアで協力して、みんなで形にして世に送り出したプロトコルに脆弱性が見つかったとします。何億台というスマホやパソコンのOSに組み込まれている場合、さあ大変です。近年はセキュリティカンファレンスなどで大々的に発表されることも多いですが、日本ではどうしても(対策がないからとか、良心的理由で)扱いが小さくなりがちです。
様子見しているあいだに、他のニュースが飛び込んできます。
「そういえば、あの脆弱性どうなった?」
「みんな対策していない。。。」
「サーバ側はなんとかなるんだけど、クライアントがね。。。」
「このスマホ、ファームウェアの更新がもう止まってるんだよね」
笑えない話ですが、実際によくある話です。皆さんがお使いの最新のスマホも、複数のプロトコル脆弱性を必ず抱えています。もっともメーカーに詰め寄っても、「それはプロトコル(規格)の問題なので弊社のソフトウェアの問題ではありません」「一部の人たちが騒いでいるだけです」と逃げられると思いますが。
関係するすべての人が当事者意識をもってプロトコルを安全なものに刷新する必要がある
以上みてきたように、プロトコル脆弱性は影響範囲が大きく、また対策するには共通言語をアップデートする必要があるので、一斉にアップデートすることが往々にして求められます。
またプロトコルの規格書そのものに抜け漏れがあった場合、規格書の改訂も必要となります。規格書を改訂するには、投票やら標準化会合やらで少なくとも2年はかかると思って間違いないでしょう。また、苦労して稟議書を書いて、50億のソフトウェア開発投資をした各社エンジニアの面目も丸潰れです。
プロトコルの脆弱性を「なかったことにしたい」面々のモチベーションも、良くわかります。それが20年続くと、どうなるでしょうか。
DDoS攻撃。フィッシング詐欺。標的型のメール詐欺。これらは全て、プロトコルの脆弱性を「なかったことにしたい」人たちの集団的無責任が生み出した怪物だと思います。誰か一人、一社に責任があると言っているのではなく、「規格の問題だ」「ソフトウェアの問題だ」「人間の問題だ」などと、他所に責任の所在があるかのように主張して、我関せずと多機能化、高性能化、見た目の改善などに邁進してきたツケを今頃になって払っているのだと思います。
試みに、あるプロトコル脆弱性をとりあげて「これはプロバイダの問題か、メーカーの問題か、標準化の問題か、ユーザの問題か」とサプライサイドの人たちに詰め寄ってみるといいでしょう。「それは我が社の問題です」と認める会社は、ほぼ皆無でしょう。
なぜなら、インターネット全体から訴えられる可能性がありますから。
もっとも無難な言い訳は、「それはマーケットの構造的問題です」というものでしょう。これなら、誰も悪者になりません。プロトコル脆弱性を直すための経済的インセンティブがない、マーケットメカニズムがない、現状把握できていない、等々、美しい言い訳はいろいろ思いつきます。「やらない言い訳」を考えることについて天才的な人は皆さんの周りにもいることでしょう。
私がおすすめする正解は、すべてのプロトコル脆弱性についてプロバイダも、メーカーも、標準化団体も、ユーザも応分の責任分担をすべき、というものです。セキュリティ専門家が、あなたの(ファームウェア更新が止まってしまった)スマホを何とかできるわけもないですし、管理者が遁走してしまったサーバを何とかできるわけでもないので、すべての人が当事者意識をもってネットワークの共通言語=プロトコルを安全なものに刷新していく必要があるのです。
今回はこれくらいにしておきましょう。次回も、プロトコル脆弱性のやっかいな性質について紹介したいと思います。
コラムは以上となります。
ITエンジニア向け動画配信サービスcrash.academy
アクセリアが運営するITエンジニア向け動画配信サービスcrash.academyでは、著者の門林 雄基が講師をつとめる「標準サイバーセキュリティ」シリーズで、サイバーセキュリティの基礎概念を学ぶことができます。
この機会に是非講座を受講いただき、更なるレベルアップを実現していただければと存じます。
http://crash.academy/
ECのミカタで公開しているコラム
サイバーセキュリティに求められる バランス感覚
https://ecnomikata.com/company_blog/15023/
サイバーセキュリティが損なわれる原因を理解する(1)
https://ecnomikata.com/company_blog/15410/
サイバーセキュリティが損なわれる原因を理解する(2)
https://ecnomikata.com/company_blog/15703/
サイバーセキュリティが損なわれる原因を理解する(3)
https://ecnomikata.com/company_blog/16060/
サイバーセキュリティが損なわれる原因を理解する(4)
https://ecnomikata.com/company_blog/16113/
サイバーセキュリティが損なわれる原因を理解する(5)
https://ecnomikata.com/company_blog/16171/
サイバーセキュリティが損なわれる原因を理解する(6)
https://ecnomikata.com/company_blog/16291/
※ECのミカタに掲載していないコラムは、以下ページでご覧いただけます。
https://www.accelia.net/column/
著者
門林 雄基
アクセリア株式会社 主幹研究員
奈良先端科学技術大学院大学 情報科学研究科 教授
Adjunct Professor, Unitec Institute of Technology, New Zealand
日欧国際共同研究「EUNITYプロジェクト」日本側研究代表
WIDEプロジェクトボードメンバー