危険なICOプロジェクトの見分け方(チーム運営編・前編)

今年に入り仮想通貨のICOが盛り上がりを見せている。それに伴い、いくつかのプロジェクトでクラッキング被害や偽情報によるユーザー資金の損失が発生してしまっている。

原因はなんなのか? 防げる事態なのか? 今後ICOへ参加する上で、投資家はどのような点に注意すればよいのか?

今回から何度かに分けて、主に技術的な視点から上記の疑問に答えられるよう検証してゆく。

第一回目はチーム運営編と題して、そもそも技術うんぬん以前のプロジェクトチームの運営体制に焦点を当てて記載する。

ここでは以下のプロジェクトを取り上げる。

  • CoinDash
  • Bancor
  • Status
  • inflex

どれも意欲的なプロジェクトだが、残念なことにICOに伴いユーザ資金の損失が発生してしまった。

例1: ICOウェブサイトのクラッキング

先日、イスラエルのスタートアップであるCoinDashはICOを実施したが、その際にICO用のサイトをクラックされ約8億円弱をクラッカーに奪取されてしまった。

http://www.cnbc.com/2017/07/17/coindash-website-hacked-7-million-stolen-in-ico.html

原因はICO開始直後にサイトをクラックされICO用Ethereumアドレスを書き換えられてしまったこととアナウンスされた。

この自体を防ぐことはできたか。私は以下のような対策で大幅にリスクを下げることが可能と考えている。

  • ICO用サイトは静的ページとし、サーバーレスとする
  • サイトを更新可能なメンバーを必要最小限に絞る。

順に詳細を記載する。

ICO用サイトは静的ページとし、サーバーレスとする

私はCoinDashの問題が発生した直後、ICO用のウェブサイトを確認してみた。その際、少なくともサイトにNginxが使用されていることが確認できた。

詳細は不明だが、現在のCoinDashのウェブサイトでも使用されている。
おそらくだが同じインフラに乗っていたのではないか。

サイトに使用されている技術を確認できるWappalyzerというChrome拡張を使用して確認した画像。

ユーザーの情報を入力するようなフォームが存在したことも記憶している。あるいはHerokuのようなインフラだったのかもしれないが、ここから言えることは動的なアプリケーションが動く環境であったということだ。あるいは自前でサーバを運用していたのかもしれない。

動的なアプリケーションが動くということは、つまりクラックされた時にサイトを改ざんされる可能性があるということを意味する。私の意見としては、本当に必要でない限りは静的ページとすべきであり、サーバを運用すべきではない

なぜならセキュリティリスクを負うからだ。

この点を考慮し、ALISではAWSのS3を静的ホスティング用のインフラとし、ICO完了までこれを維持する。不要なフォームなどを用いて情報を収集しない。なぜなら必要無いからだ。なぜならセキュリティリスクを負うからだ。

ご興味のある方はぜひALISのサイトを上記のChromeプラグインで検証してみてほしい。

サイトを更新可能なメンバーを必要最小限に絞る。

あるいは今回の事件は技術的にクラッキングされたのではなく、サイトを更新できるメンバーの権限が不正に使用されたのかもしれない。こちらの方が可能性としては高いように思える。

概してプロジェクトチームの権限管理はおざなりになりがちだ。チームメンバーがお互いを信用している良いチームであればなおさらだ。

しかし私は、ことセキュリティ担保の文脈においては、悪い意味ではなくメンバーを一切信用すべきではないと考えている。ぬるま湯のセキュリティ意識がプロジェクトを窮地に陥らせる例などは枚挙にいとまがない。重用な部分については、メンバーがお互いに健全な疑いを持つべきだ。

前述の通り、ALISではWEBサイトをS3に配置している。
S3はAWSのサービスであるため、AWSの認証機能がサイト更新の鍵を握っている。

少々技術的な話になってしまい恐縮だが、ALISではAWSのルートアカウントは言うまでもなく二段階認証で保護されており、かつ基本的に一切使用しない体制を採用している。

操作をする場合はIAMで適切な権限が与えられる。
一例として、そのIAMでマネージメントコンソールへログインできる権限が与えられているのは、私とファウンダーの安のたった二人だけである。権限を最小限に保つことがセキュリティの担保に直結するからだ。当然、このIAM権限でのログインについても二段階認証を設定している。

従来、ALISのWEBサイトはGitHub Flowに従いmasterブランチへのマージをCI環境から直接本番運用サイトへとデプロイしていた。こちらもIAMで適切に権限が設定されたキーを用いており、当然GitHubアカウントのセキュリティも最高度の警戒をしているためリスクは低いと言える。

しかし今回の事件を受けてチームで議論し、少なくともICO完了時まではこの設定を除却すべきという結論に至った(該当プルリクエスト)。警戒はするに越したことは無い。

例2: Slackbotを悪用した詐取

次はICOにおいて常套手段とも言えるSlackの仕様を突いた詐欺を検証する。

Slackはビジネスのプロジェクトチームに向けて作られたチャットサービスで、ICOを行う各プロジェクトでもチームメンバーと投資家・サポーター間のコミュニケーションツールとしてデファクトスタンダードの地位を占めている。Slackチームを設置していないプロジェクトを探すほうが難しいくらいだ。

Slackbotを利用したこの詐欺の手口はシンプルで、詐欺の対象はプロジェクトの公式Slackに登録しているユーザーだ。ある日、この公式Slack上でメンバー宛にプライベートメッセージが来る。送り主はSlackbotだ。

ALISメンバーが実際に受け取った詐欺メッセージ

これは、いかにも公式から発せられたメッセージであるように装うことでユーザーを信用させ、Myetherwallet.com等の似せたスキャムサイトへと誘導しユーザーの資産を送信させる。しかしこのメッセージは実はスキャマーからのメッセージであり、ユーザは資産を失う。私の把握している限りでも、Bancor, Inflex, TokenCardで同じ手口の詐欺が行われた。さらに調べればいくらでも事例が見つかることだろう。

なぜこの詐欺が成り立つか?
理由の一つにSlackの仕様があげられる。SlackではSlash Commandsという機能あり、その中に /remind というコマンドがある。これは特定のユーザーに特定のタイミングでSlackbotからのメッセージとしてリマインドメッセージを送る機能だ。この機能には以下のような弱点がある。

  • 管理者でなく一般ユーザーでも使用可能
  • 仕様上、Slash Commandsを使用不可とすることはできない
  • Slackbotからのメッセージとして通知される。つまり公式からのメッセージと誤認し易い。

個人的には、金銭的な被害が発生している以上、Slackはただちに仕様を変更すべきと考えている。しかし2017/07/27現在はまだ仕様上、このスキャムが発生する余地がある。

対処法としては、Slackを利用しないのが最も安全だ。しかしSlackはデファクトスタンダードであり、重用なチャンネルだ。ALISを含め、各プロジェクトでも引続き使用し続けられると考えられる。上記の知識は、ICOに参加する際の自衛の手段として役立つだろう。

ALISではSlackにおいて以下のような対策を練りつつ、最大限の警戒をしている。

  • #generalのTopicに本件の警告メッセージを表示。ここはSlackの仕様上、誰もが参加し離脱不可であり、ユーザが最初に見るチャンネルである。すなわち全員が確認することとなる。(ALISでは#announcementと名前を変えている)
  • #announcementに投稿できるのは公式アカウントのみ
  • チーム全体へ届く@everyoneにメンションできるのは公式アカウントのみ
  • 公式アカウント、メンバーが2段階認証を使用

この問題については随時、Slack上でもアナウンスするなど対策を強化する予定である。ALISのSlackへの参加は以下のリンクから可能だ。


長くなってしまったので、このチーム運営編は2回に分けて記載させていただく。後編も近日中に公開予定である。

蛇足として付記させて頂くが、ALISチームでは各種公式アカウントだけではなく、プロジェクトに参画するメンバーの個人アカウントについても可能な限り2段階認証を設定するなど最大限の警戒を行っている。今後もその警戒態勢は維持する予定である。


Show your support

Clapping shows how much you appreciated ALIS’s story.