丸の内で働くブロックチェーンエンジニアのブログ

丸の内やその他でフリーのブロックチェーンエンジニアとして働いています。勉強している技術情報やニュースを紹介します。

仮想通貨取引所のハッキング(GOX)と攻撃手法一覧【随時更新】

仮想通貨取引所のセキュリティが非常に話題になっています。

仮想通貨は中央管理者のいないシステムのため、一度盗まれると取り返しがききません。フォークを話し合って決めた後でさえ、ハードフォークの場合、ハッキング自体を受け入れる世界線としてチェーンが進んでいくこともありえます。

お金がWEBの世界に取り込まれ始めた事で、主にWEB系ベンチャーから仮想通貨取引所は生まれています。ただし、私は取引所システムの本質は「金融システム」だと思っています。WEBの知見と、セキュリテイの知見を組み合わせる事が非常に重要だと思います。

なるべくハッキングにあわないよう対策を講じること。過去から学ぶ事が重要です。Goxした情報、ハッキングの手口をまとめておくことで業界の一助になれば、と思いこの記事にまとめていきます。

私一人では調べきれなかった情報もあるので、どんどん教えてもらいたいと思っています。

ハッキング事例の概要

ハッキング事例の概要を以下表にまとめました。 個別の事例については次の章で見ていきます。

時期 取引所 被害額 攻撃手法 ハッキング後の結果
2011年6月 Mt.gox 750,000BTC トランザクション展性をついた攻撃 破産
2012年9月 BitFloor 24,000BTC サーバーに侵入し、暗号化されていない秘密鍵のバックアップを取得 取引所を閉鎖し、残りの資金を全て顧客に払い戻し
2014年3月 Poloniex 総預り資産の12.3%のBTC(金額は不明) 出金コードの脆弱性をついた攻撃 全額を顧客資産に保証
2015年1月 Bitstamp 19,000BTC 不明(知っている人がいたら教えてください) 1週間後に営業再開。マルチシグウォレットの導入含む、セキュリティ強化
2016年8月 Bitfinex 120,000BTC マルチシグのうち2つが盗難された BFXトークンの発行と8ヶ月かけての補償

ハッキングの個別事例

Mt.GOXトランザクション展性を利用した攻撃

  • 時期

    • 2011年6月
  • 被害額

    • 750,000Bitcoin
  • 攻撃手法

  • ハッキング後の結果

    • 破産
  • 攻撃手法について

Mt.GoxはBitcoinの当時の仕様であるトランザクション展性をついた攻撃を受けて流出しました。

トランザクション展性攻撃の流れは以下の通りです。

Bitcoinのトランザクションハッシュ値を変更する事で攻撃を行っています。

  1. トランザクション検証スクリプトの意味を変えないまま、スクリプトを変更することで、トランザクションハッシュ値(TXID)を変化させる
  2. 取引所のウォレット実装がTXIDによる送金確認を行なっている場合、変化前のTXIDを追いかけて送金完了していないと誤認させる事ができる
  3. 送金されていないと誤認させて、二重送金させる

Mt.Goxは度々攻撃を受けています。

今回取り上げるのはこの攻撃だけですが、他にも明らかになっていない攻撃があるなど、不明点があるとも言われています。

  • 参考

参考として、Mt.Goxの攻撃について解説したレポートをWIDE テクニカルレポート インデックスより掲載します。

ビットコインにおけるトランザクション、その展性と影響(2014-05-16) http://member.wide.ad.jp/tr/wide-tr-ideon-bitcoin-transaction2014-00.pdf

前述のように、取引データを署名する際には、入力のスクリプトは署名の対象から除外されている。従って、 入力のスクリプトの意味を変えず、その表現を変化させることができれば、トランザクションの意味を変えず、 署名も検証可能なまま、取引データの内容を改ざんすることが可能になる。 このことが問題となるのは、トランザクションが、そのハッシュ値である TXID により識別されるからであ る。トランザクション展性が利用されると、同一の取引でありながら、TXID が変化してしまうことになる。 (中略) トランザクション展性の問題は、遅くとも 2011 年にはビットコインの開発コミュニティの中で知られており、 Mt.Gox にて混乱があったような問題に関しては、現在のリファレンス実装では改修されている。 交換所のソフトウェアは、多くの顧客を相手に大量のトランザクションをさばく必要があるため、Mt.Gox に 限らず、ウォレットに独自の実装を採用している場合が多い。特に Mt.Gox は古くから営業を始めた交換所だっ たため、処理に古いスタイルが残ってしまったと考えられる。

BitFloorのオンラインバックアップ秘密鍵のハッキング

  • 時期
    • 2012年9月
  • 被害額

    • 24,000BTC
  • ハッキングの原因

    • サーバーに侵入し、暗号化されていない秘密鍵のバックアップを取得
  • ハッキング後の結果

    • 閉鎖し、残りの資金を全て顧客に払い戻し

システムのアップグレードを行ったあと、暗号化していないディスク領域にバックアップを置いてしまったようで、サーバーに侵入したハッカーから秘密鍵を盗まれてしまっています。

bitfloorの管理人shtylmanの投稿では、

Yes. It was made when I manually did an upgrade and was put in the unencrypted area on disk.

システムのアップグレードを行ったあと、暗号化していないディスク領域にバックアップを置いてしまったようです。 それに対して

Why was the majority of this not in a cold wallet?

なぜコールドウォレットに入れておかなかったのか、と質問している人もいます。

  • 参考

bitfloorの管理人shtylmanの投稿

bitfloor needs your help!

bitfloorの閉鎖を報道する記事

www.cnet.com

Poloniexの出金コードの脆弱性攻撃

  • 時期

    • 2014年3月
  • 被害額

    • 総預り資産の12.3%のBTC(金額は不明)
  • 攻撃手法

    • 出金コードの脆弱性をついた攻撃
  • ハッキング後の結果

    • 全額を顧客資産に保証

Poloniexの出金プロセスは以下の通りです。

  1. 入力した値の検証。(おそらくマイナスなど不正な値でないかなど)
  2. あなたの残高が十分かどうかを確認するために残高がチェックされる
  3. 十分であれば残高が差し引かれる
  4. 出金処理がデータベースに挿入される
  5. 確認メールが送信される
  6. ユーザーが出金を承認したら、プログラム側で出金が処理される

この2の処理の時、同じタイミングで複数の出金依頼をかけると、チェックをすり抜けて出金が処理されてしまうと言う脆弱性がありました。 これらの出金処理をキューに入れて直列に処理せずに、並列に処理していた部分があった事が問題と説明しています。

  1. Input validation.
  2. Your balance is checked to see if you have enough funds.
  3. If you do, your balance is deducted.
  4. The withdrawal is inserted into the database.
  5. The confirmation email is sent.
  6. After you confirm the withdrawal, the withdrawal daemon picks it up and processes the withdrawal. The hacker discovered that if you place several withdrawals all in practically the same instant, they will get processed at more or less the same time. This will result in a negative balance, but valid insertions into the database, which then get picked up by the withdrawal daemon.
  • 参考

BitcointalkフォーラムのPoloniex管理人の投稿

BTC Stolen from Poloniex

Bitstampのホットウォレット攻撃

  • 時期
    • 2015年1月
  • 被害額
    • 19,000BTC
  • ハッキングの原因

    • 不明。見つけられませんでした。(知っている人がいたら教えてください)
  • ハッキング後の結果

    • 1週間後に営業再開
    • マルチシグウォレットの導入含む、セキュリティ強化

コールドウォレットに85%から90%の資産を保管していたため、 全体の預かり資産額からすると大きくはなく、被害が抑えられたようです。

  • 参考

bitstampのハッキング報道記事

www.zdnet.com

Bitfinexのマルチシグウォレットのハッキング

  • 時期

    • 2016年8月
  • 被害額

    • 120,000BTC
  • 攻撃手法

    • マルチシグのうち2つが盗難された
    • Bitfinexに2つ(管理者、ユーザーにそれぞれ1つ)、BitGoに1つの3つのキーを配布して、そのうち2つで署名する「2 of 3」構成だった
  • ハッキング後の結果

    • BFXトークンを発行して、8ヶ月に渡って顧客に補償した

ユーザーから出金要請を受けると、

「Bitfinexでトランザクションに署名を行う→BitGoに署名依頼を行う」

というオペレーションで業務が回っていたようです。 原因として言われているのは、

  • Bitfinex、BitGo共にハッキングを受けた
  • BitGoのみがハッキングを受けて、BitGoの提供ウォレットに脆弱性があった
  • Bitfinexのみがハッキングを受けて、BitGoのマルチシグ確認がうまく機能していなかった
  • Bitfinex、あるいはBitGo共犯の内部犯行

といった事のようです。

  • 参考

bitfinexのハッキング報道記事

www.coindesk.com

www.coinfox.info

bitfinexのハッキングについて質問しているスレッド

www.reddit.com

対策に関わるキーワード

こちらでは、対策となるキーワードを羅列していこうと思います。

  • マルチシグ

送金などに複数の署名を必要とするアドレス。シングルよりも、マルチシグの方が堅牢であることは間違いないですが、ホットウォレットで同じ場所に複数の秘密鍵を置いていたら、ハッキングに対してはあまり効果を発揮しません。

複数のサーバーに分散して鍵を置いておく事などでセキュリティを高める事ができると考えられます。ただしbitfinexのように分散化していてもハッキングされた事例があります。

ビットコイナー反省会で言及されていましたが、マルチシグは内部的な犯行に対する統制、またオペレーションミスを防ぐという役割が強いと考えられます。

www.youtube.com

なお、Ethereum、Rippleなどはマルチシグの実装方法が確立しきっていないため、現段階ではマルチシグを導入しない取引所も多いようです。

  • コールドウォレット

オフラインのウォレット。秘密鍵の作成から署名までオフラインで実施する。 6年前のbitfloor事件からもコールドウォレットに入れておけばハッキングされることは無かった、とbitcoinforumで議論されています。

ホットウォレットの秘密鍵をどのように保管するかは悩ましいところです。

もちろん、暗号化の方法などは焦点になると思います。

ただし、ブロックチェーン関係なく、アプリケーション、ネットワークなど、セキュリティ一般の話が密接に絡まってくると思います。

  • Crypto Currencies Security Standard

暗号通貨のセキュリティスタンダード規定を自主団体が作成しています。 秘密鍵のシードが堅牢なものであるか、管理者権限を渡すプロセスが規定されているかなど。 こちらも参考になるでしょう。

cryptoconsortium.github.io

  • システム以外の話

ホットウォレットは、GOX積立金みたいなものを積んで考えておいたほうがいいのかもしれません。

より細かいキーワードについては、こちらに為になる記事が書かれています。

qiita.com