【特別放送】仮想通貨取引所とセキュリティ対策の課題 with Bitbank CBO ジョナサン・アンダーウッドさん ver.01

  • ジョナサン
    • Bitbankで取引所の仮想通貨にまつわるセキュリティの開発をしています。
    • Bitbankチーフビットコインオフィサー(CBO)
  • BitPointの件は追っていますか?
    • JVCEAでゆるふわな共有を受けた以外は、一般の人と同じ情報公開レベルでしか情報はもっていない
    • 現在公開されている情報は専門家向けではなく一般の方向け
    • 「暗号鍵」が何を指してるのかなど、詳細は把握できていない
  • ホットウォレットとは?
    • どれだけ盗まれる危険性が高いかで名前を付けています。
    • インターネットに常時接続されている機材に秘密鍵が置かれている状態をいいます。
    • 機械の中で暗号化されていて、その暗号を解くための秘密鍵がその機材の中に無かったとしても私はホットウォレットと言います。
    • 暗号化された秘密鍵を盗んでおいて、その秘密鍵を複合できる暗号化キーを盗むのを待ち伏せしておいて、盗めたら成功してしまうから。
    • 秘密鍵が暗号化されていても、されてなくてもインターネットに常時接続されているところにおかれている状態
    • 辞書とかに定義されているわけじゃないし、人によっては暗号化されてたらコールドでええやんって言う人もいる
  • なんでホットウォレットにあんな金額を取引所はおいてるの?なんで、そんなにリスクのあることをしているの?
    • 取引所を運用していて、ありふれた操作は出金。ほかの取引所に送金したいとか。
      • すぐに対応しないといけないって取引所もあれば、一日以内に対応できていればOKとか取引所毎に規約で定義している。
      • 休日や深夜に大量に出金されると枯渇してしまうことがある。蓄えておくことで社員が出社していなくても無くならない金額。
    • 取引所によっては、ホットウォレットを入金するためのアドレスを発行するために使っているところもあります
      • ビットポイントも顧客の入金アドレスの裏にある秘密鍵てのはホットウォレットになっている
      • 自動化されたアプリがDBに記録して、そのコインを横流してコールドにいれたり、送金にいれたりする
      • ビットコイン、モナコイン、ライトコインとかは10コイン以上拒否しますということがプロトコル上できない
      • 週末放置していたらお客が1000btc入れてきたとかもありうる
      • ホットウォレットなので自動化もできる。ホットウォレットからコールドに自動転送てのはできるけど、逆はできない。
      • コールドに入れすぎると不足してしまうことがある
    • セキュリティとUXのトレードオフ
  • コールドウォレットとは?
    • 一度もインターネットに接続したことのある機材に、一度も置かれたことのない秘密鍵のことをいいます。
    • 新品のPCにインターネットに接続してドライバーとかをインストールして、その後にネットワークインターフェイスを物理的に壊してインターネットに接続できないようにした機械に、USBとかで秘密鍵を置いてもコールドにはなりません。
  • コールドウォレット作るのて大変ですよね?
    • 大変。Bitbankでは儀式とよんでいる。
    • 特別な部屋の中に特別の機材があって、特別なセキュリティが施されている中で、署名の権限を持っている人が数名きて、一人ひとり中に入って鍵を生成して、公開鍵だけを部屋の中から取り出してくる。秘密鍵は物理の世界になります。生成したときに、秘密鍵のフレーズをボールペンと紙で書き留めて、署名マニュアルに従って、どうやって書いてどうやって保存するか。そのメンバーに万が一のことがあったら、どうするか。貸金庫かりて、遺言書残してとか。署名者が2人以上同じ飛行機に同時に乗ってはいけないとか決まってる。
    • そのフレーズをどうやってまもるのか?機関銃をもって会社にきたら?とか。署名者の一人の愛する人が人質になったとしたら?とか、一週間は絶対にコールドから出せないようにするみたいな仕組みがあったりする。
    • USBにいれてるとかはなんちゃってコールド。
  • そういう知識ってどうやって勉強するの?
    • 事例研究。過去のハッキング事件の原因を考える。
    • 例えば、コインチェックがソーシャルハッキングとかだったので、一般的なセキュリティ知識と、一般的な物理セキュリティと、仮想通貨のセキュリティとと、ピラミッドみたいな積み上げ式。
    • 警察との捜査の関係で実際になんで盗まれたのか開示できない時もある。犯人に情報を教えることにもなる。盗まれた直後は情報が開示されないことがある。
    • ビットポイントだけが狙われたとは限らない。新しい手口で巧妙な手口で同時に攻撃して、先駆けてBitpointだけが成功していることもある。同じ攻撃がほかの取引所も狙われることもあり、知っておくと防ぐこともできる。JVCEAで専門家だけきて、極秘で警察とも組んで、情報を共有したほうがいいと思う。
  • 業界団体からもっと情報共有しますという宣言があったけど懐疑的。自社の情報て共有したくないよね?実際どうなん?
    • やられたハッキング手口が一般的とか、簡単な可能性もある。それをみんなに共有するのつらいよね?
      • キャバクラに行ってて、ついうっかり~みたいなのは言えないよね
    • 必ずしも共有しあうというのは理想でもあるけど、共有したくないという場合もあるときは、ごまかしたり嘘のことを言う可能性もあるから、インシデント時にどういう風に協会の中で共有していくは大事な課題になっていく
  • うちは大丈夫って発表したけど、事件が発生したら緊張感でますよね?
    • そうですね。自動で監視いれてるけど、万が一監視システムが破壊されて誤解を生ませる改ざんをしている可能性がないかを点検しました。
    • ちゃんと持ってるよね?ホットにまつわるクレデンシャルが大丈夫かとか、秘密鍵入れ替えてみようとか念のためいろいろやってました。
  • 過去の事例で代表的な物を教えてください
    • 一番よくあるのは、ホットウォレットの秘密鍵を盗んですぐに移すのではなく、顧客の出金に紛れさして少しずつ盗む。
    • MtGOXはそれ。
    • この方式でやるとホットウォレットの5憶だけだけど、一気にやるとばれてしまう。少しずつやれば、補充されるので少しずつやれば、継続して盗み続けられる。ホットウォレットからの取引が顧客だけの出金だよね?という監視を常時やっとかないといけない。
    • ホットウォレットの異常が検知されたら、自動的に出金を停止させるようにしている。
    • エンジニアにアラートとんでSlackで議論する。どうやるとか?金融庁に報告するとか?決まった流れがある。
  • ほかの代表的な攻撃は?
    • ソーシャルハックですね。
    • どこかMeetupとかで仲良くなって、ちょっとみてくれる?とかPDF渡したりしてウィルスをしこむとか。
    • ウィルスを仕込むためのファイルを送り込む
    • Keybaseだけにしぼってます
  • Keybaseとは?
    • 公開鍵暗号を使って、ユーザーアカウントと強く紐づいています。
    • https://keybase.io/
    • セキュリティに関する連絡は、Keybaseをつかってやる。
    • 暗号メッセンジャー。
  • コインチェックもソーシャルハッキングで、この方法ですよね?誰かになりすまして。
    • そー言う感じですね。はい。
    • そうです。
    • ソーシャルハッキングの一部になります
      image
  • ホットウォレットを100%守るのて難しいと思うんですけど、どうですか?
    • 全ての取引所が絶対にやらないといけないことを述べます。
      • 入金アドレスはコールドにしないとだめ。ホットウォレットを盗まれた後、アドレスを消したとしてもお客さんはほかの取引所の出金でアドレスを登録しています。暴落などのアビトラとかで、ハッキングした取引所に入金してしまう。Botトレーダーとかがハッカーに送金することになってしまう。
      • ホットウォレットがあった場合、ホットウォレットにおくお金は自己資本でカバーできる金額にすること。破産しても顧客に100%返せる金額に収める。
      • 出金の要請と実際の要請が必ず1:1であることを確認する。例えば1分毎のJobで。
  • Bitpointの被害は大きかった?
    • 金額だけではなんともいえない。取引所のお財布状況による。35憶多いと思うけど、返金できているからいいと思う。
  • 日本の取引所はセキュリティ甘い?
    • そんなことはないと思うけど、情報のバイアスがある。日本語だけでしか情報を得てなかったら、日本の取引所の情報をよく目にすることになります。

npx parcel で、「Cannot read property ‘length’ of undefined」とエラーが出た場合

次のコマンドを実行してデバッグを開始します。

npx parcel index.html

こんなエラーが出ることがあります。

×  Cannot read property ‘length’ of undefined
     at lineCounter (d:\test\node_modules\parcel-bundler\src\utils\lineCounter.js:3:30)
     at JSPackager.writeModule (d:\test\node_modules\parcel-bundler\src\packagers\JSPackager.js:127:60)
     at <anonymous>

慌てずに、一旦終了して、ディレクトリにある「.cache」ディレクトリを削除して再度、実行すれば直ることがあります。

AWS CodeDeploy でデプロイしたときのhookスクリプトの場所

AWS CodeDeploy の hooks を使う際に直感と反する動きをする箇所があります。
その部分を予め理解しておかないと、罠にはまって悩みまくることになります。

CodeDeployのfilesセクションでコピーした後、コピー先のファイルを実行すると思いがちなのですが、そうではありません。
例えば以下のようなappspecを定義したとします。

version: 0.0
os: linux
files:
   – source: /
     destination: /home/ubuntu/hogeProject
hooks:
   ApplicationStart:
     – location: deploy.sh
       timeout: 180
       runas: ubuntu

この時に、「deploy.sh」は、「project-a」を暗黙的に期待します。
しかし、実際には、「/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive/deploy.sh」が実行されます。

これを図にすると下記になります。
「/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive」にzipの中身が展開され、そこから、「files」セクションの内容に沿ってファイルがコピーされます。
コピーされた後、「hooks」セクションは定義に沿ってイベントハンドルをしますが、そこで指定したファイルは、「/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive」配下のファイルが実行されます。

image

なので下記のような処理をdeploy.shに記載すると問題が発生します。

docker-compose build
docker-compose restart

この際に、読み込まれるdocker-compose.ymlは、「/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive/docker-compose.yml 」になります。
ファイルコピー先を読み込ませたい場合は、次のようにしないとだめです。

docker-compose -f /home/ubuntu/hogeProject/docker-compose.yml build
docker-compose -f /home/ubuntu/hogeProject/docker-compose.yml restart

このあたりの説明は、公式ドキュメントだと、次のように記載されています。

DownloadBundle – このデプロイライフサイクルイベント中に、CodeDeploy エージェントはアプリケーションリビジョンファイルを一時的な場所にコピーします。

Amazon Linux、Ubuntu Server、および RHEL Amazon EC2 インスタンスの /opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive フォルダ。

クラスメソッドさんのBlogを読まないと理解できない部分がありますね。

参考

AWS CodeDeploy が途中で動かなくなった。次回はデプロイされない件の対応

EC2の載せているCodeDeploy Agentが不調かなと思いステータスを見たり、サービスをリスタートしたりしてみた。

sudo service codedeploy-agent status
sudo service codedeploy-agent restart
sudo service codedeploy-agent stop
sudo service codedeploy-agent start

それでも変化はなかった。仕方ないので、CodeDeploy Agentのログを確認してみた。

less /var/log/aws/codedeploy-agent/codedeploy-agent.log

ログを見ると不穏な文字が。

Could not acquire lock on /opt/codedeploy-agent/state/.pid/codedeploy-agent.pid.lock – aborting start!

なるほど。ロックが取れないから中断したぜと。
軽く調べても、あまりどうこうという情報が見つけられなかったので、消してみた。

いけた。