イベントレポート
BCCC第8回リスク管理部会
なぜ仮想通貨は流出したのか？――コインチェック事件から学ぶセキュリティ対策
2018年5月1日 06:05
4月25日、一般社団法人ブロックチェーン推進協会（BCCC）によるリスク管理部会の第8回が開催された。今回のテーマは「ウェブセキュリティーの基礎と攻撃のトレンド」、講師は EGセキュアソリューションズ株式会社のセキュリティーエンジニアである細野英朋氏だ。細野氏はこれまでもIIJやJPCERT/CCでのキャリアがあり、インシデント対応支援、セキュリティ情報分析に従事してきたこの分野の専門家である。今回の会合では、一般に「安全」と信じられていた仮想通貨（暗号通貨）が、なぜこれほどまでに簡単に流出をしたのかという観点から、セキュリティ対策の基本的な考え方について解説した。以下では、その講演の概略を報告する。
講演の全体を通じ、人間の「思い込み」をいかに排除するのかという点が強調された。標的型攻撃によるマルウェア感染も「思い込み」に起因するし、通信経路を暗号化して運用しているから安全だということも「思い込み」だという。とりわけ、同じ組織に集まり、同じ問題に取り組んでいる人たちは、だんだんとお互いの視野が重なってきて、さらに思い込みに陥りやすくなる可能性もあると思われる。それを避けるためにも、さまざまな情報収集や、外部の知見と価値観の導入なども有効ではないかと思う。ここではブロックチェーンに固有のセキュリティ対策ではなく、一般的なセキュリティ対策の積み上げこそが本質な対策であると語られている。
暗号通貨流出事件の本質は認証の突破
一般に、暗号通貨が「安全」と言われているのは、ハッシュ関数を応用することで、取引の改ざん、つまり過去の情報を書き換えたり、偽のトランザクションが作り出せたりしない仕組みになっているというブロックチェーンの仕組みを指している。しかし、コインチェックの暗号通貨流出事件の原因はこうしたブロックチェーンの仕組みにはない。原因がどこにあったのかというなら、事件を起こした交換所のシステムそのものの認証が突破されてしまったというところにある。
そもそも、ブロックチェーンの情報を操作するためには、ほとんどの場合、なんらかのウェブアプリケーションが介在していて、それをインターフェースとして機能する。ウェブアプリケーションというと、ウェブブラウザー上で動くアプリケーションのことと思いがちだが、ここではウェブサービスAPIを使っているアプリもウェブアプリケーションの1つといってよいだろう。ウェブサービスAPIを利用するのはなにも仮想通貨の交換所だけではなく、これらブロックチェーンの仕組みを取り入れた各種のサービスも同様である。
一般に、セキュリティとして、最も気を付けなければならないのは「なりすまし」「否認」「情報漏えい」の3つだといわれるが、とりわけ、今回の事件は「なりすまし」、つまり情報へ正規にアクセス権限がある人であるかのように振る舞われたというのが問題の本質である。
悪意のある人にとっての侵入経路は2つ考えられる。1つは認証の突破（なりすまし）であり、もう1つはソフトウェアの脆弱性である。最近では、さまざまな手法により、正規の人になりすまして、認証を突破しようというのがトレンドである。なぜならば、認証さえ突破できれば、ブロックチェーンの情報を改ざんするような困難なことに取り組まなくても、ブロックチェーンとして「正当な操作」をすることができ、自在にコントロールすることができるからだ。そのための手法としてのフィッシングはとても魅力的な手段である。今回のコインチェック事件では、具体的にどのような状況で当事者が陥れられたかは明らかになってはいないようだが、悪意のある人は、さまざまな情報を収集したうえで、ソーシャルエンジニアリング（人間の心理的なスキや行動のミスなど）を駆使して、巧みに陥れたということだろう。
認証の突破を防ぎ、仮に突破されても最悪の事態を防ぐことが肝要
そもそもコインチェック事件では、同社が資産を管理するのにコールドウォレットに対応していなかったことやマルチシグに対応していなかったことなどが指摘されているが、これでは悪意のある人に認証を突破されてしまえば、あとはいとも簡単に目的を達成されてしまうことを意味する。つまり、仮に認証が突破されたとしても、そのあとで、簡単には送金できないようなシステムを構築したり、運用体制にしたりする必要があるわけだ。そこで時間が稼げれば、たとえ侵入されたとしても、組織として認識して、なんらかの対応をすることもできる。
今回の事件の発端は標的型攻撃によるマルウェア感染で、そこから認証を突破される事態に陥ったわけだが、本質的な対策としては、いかにマルウェアに感染しないようにするかではなく、感染したとしても認証を突破されないようにするということである。マルウェアの感染というのは認証を突破するための手段の1つにしかすぎないのである。
さらに、組織内部では通信経路を暗号化しているから安全だというような「思い込み」もあったのではないだろうか。仮に通信経路が暗号化されていたとしても、悪意のある人は容易に暗号を解いている場所を見つけ出し、そこを狙ってくることも考えられる。
認証が突破されないためには、パスワードにハッシュをかけて保存するという手法は一般的に行われているが、単純にハッシュをかけただけでは俗に「レインボーテーブル」といわれる対応表を使って解読される危険がある。レインボーテーブルで解読されないようにするためには、冗長なデータを付加するなどして、より解読を困難にする必要があるとともに、複数人のパスワードがなければ機能しないようにする方法も有効である。
もう1つ重要なことは、ログである。なんらかの事件が起きたら、顧客、取引先、捜査当局、メディアなどへの説明が必要になる。そもそもログに十分な情報が残っていなければ、事件の発生の把握が遅れたり、原因の追求ができなかったりするばかりか、社会的な説明責任も果たすことができない。いまやそのようなことでは許されない状況である。だからといって、なにからなにまで残しておけばいいというものではなく、パスワードやクレジットカード番号などをログに残すようなことをしていては、それを悪意のある人に狙われることになりかねない。何をログに残して、何をログに残さないかという設計は重要な点である。
常に変化する攻撃手法と継続した対応の必要性
過去の大規模なウェブ攻撃のトレンドを振り返ると、SQLインジェクションやクロスサイトスクリプティングといった手法が思い起こされる。これらも、そんなことはありえないだろうという「思い込み」が仇となった例である。最近では対策が進んだことから沈静化しているが、悪意のある人からすると、このように対策が取られれば、次々と新たな「思い込み」ポイントを探し出し、そこを突くような攻撃の手法を考え出して繰り出してくるという、「イタチごっこ」ともいえるような状況にある。いまの段階における対策が将来にも有効ということではないことにも留意すべきだ。
さらに、暗号技術の選択も重要な点である。残念なことに、一般に知られる暗号技術ではなく、よく知られていない独自の「謎な暗号技術」を使う例がいまだにある。一般に知られる暗号技術では処理が遅いことから、「謎な暗号技術」を採用することで、処理の高速化が実現できるということが顧客に対して、自社のアドバンテージとしてアピールできるというのがその理由のようだが、こうしたお手製のセキュリティ技術は容易に破られると知るべきだ。世界中で暗号技術の研究が進んでいるので、悪意のある人からしてもこうしたお手製技術はたいしたハードルにはならないのである。
そして、一般に現在のところ安全と言われている暗号技術であっても、いつかは死んでいく運命にあるということも念頭におくべきだ。過去にも安全といわれていたアルゴリズムは破られてきている。今後も、量子コンピューターなどで高速な処理が可能になれば、ますます早まることだろう。
つまり、暗号を使っているから安全と思うことも危険な「思い込み」の1つである。こうした暗号の特性を理解しながら、仮に認証が突破されたとしても、巨額の価値が流出するような最悪の事態に至らないようにするさまざまな工夫を考えるべきであろう。
