ブロックチェーンサービスのセキュリティを考える

1
ブロックチェーンサービスのセキュリティを
考える
2018/8/17 Neutrino
Naochika Hanamura

View Slide

2
これまでやってきたこと
自己紹介：2017年5月頃からブロックチェーンのエンジニアをしており、特
に仮想通貨監査などに関わってきました
開発・研究
•  ブロックチェーンデータの分析基盤構築
•  ブロックチェーン領域のモニタリングサービス開発
•  Moneroのトレーサブルリング署名研究（大学院）
コミュニティ活
動
•  DashのWhitePaper翻訳
•  技術ブログ「丸ノ内で働くブロックチェーンエンジニアのブログ」
(www.blockchainengineer.tokyo/)
仮想通貨
監査
•  仮想通貨監査の技術アドバイザリー
✓ 特に取引所の監査手続開発
✓ 特定通貨の監査手法などのリサーチ
花村直親（Naochika Hanamura） @naomasabit

View Slide

3
自己紹介：8月からcatabiraという会社を共同創業してChief Blockchain
Officerに就任しました
https://catabira.co/

View Slide

課題感とモチベーション
جຊతͳϙΠϯτͰͷϋοΩϯάඃ֐͕ଟ͘ɺগ͠ͷ஫ҙͱγεςϜରԠͰ๷͛ͨ
Մೳੑ͕͋Δ
4
҉߸௨՟ʹΑͬͯਓ͕ؒಈ͔ͤΔࢿۚྔͷ૿େ
•  オペレーションミスに対応する運用設計
•  簡単なペネトレーションテスト
•  脆弱性診断
だけでもしておけば防げた可能性がある
•  一人で即数百億円動かせる時代はこれまでになかった（現金だと物理的に
重すぎてうごかせなかった）
•  KYCをしている銀行口座より足がつきにくい（少なくとも日本では）

View Slide

課題感とモチベーション
ۚ༥ிʮԾ૝௨՟ަ׵ۀऀ౳ͷݕࠪɾϞχλϦϯάɹதؒͱΓ·ͱΊʯɹओͳϙΠϯτΑΓ
https://www.fsa.go.jp/news/30/virtual_currency/20180810-1.pdf
ٻΊΒΕΔਓࡐཁٻͷߴ͞ͱෆ଍ײ
＞マネロン・テロ資金供与対策や、システムリスクなどの
監査を実施するために必要な専門性・能力を有する監査
要員が確保されていない。
＞取扱い暗号資産（仮想通貨）の選定に当たっては、暗
号資産の利便性や収益性のみが検討されている反面、
取扱い暗号資産ごとにセキュリティやマネロン・テロ資金
供与等のリスクを評価した上で、リスクに応じた内部管理
態勢の整備を行っていない。
ٻΊΒΕ͍ͯΔઐ໳ੑ͕গͳ͘ͱ΋4ͭ͸ݟ͑Δ
IT஌ࣝ
ϒϩοΫνΣʔ
ϯ஌ࣝ
๏ྩ
ηΩϡϦςΟ
5
طଘۚ༥ʹج͍ͮͨࢦఠࣄ߲ͱ҉߸௨՟Ϗδωεݱ৔ײͱͷΪϟοϓ
人数が本当に指標？
（人数と生産性が比例する部門であればわかる
が…）
ۚ༥ிʮԾ૝௨՟ަ׵ۀऀ౳ͷݕࠪɾϞχλϦϯάɹதؒͱΓ·ͱΊʯɹΑΓ
https://www.fsa.go.jp/news/30/virtual_currency/20180810-2.pdf

View Slide

この業界が好きなので、発展のためにブロックチェーンビジネス独
特のセキュリティポイント理解の一助ができれば幸いです
6
規制側は多分…
•  ものすごい可能性とリスクがあると感じている
•  既存金融へのガイドラインしかない状態で、ブロックチェーンビジネス独特の「力点」
が分からないので、業務、システム全方位の対応を要求
　　（エンジニアをもっと雇おう）
ビジネス側は多分…
•  認可をもらわないと営業できないのでなんとか対応しようとしている
•  金融機関的な業務フロー整備と人材不足で大変
•  新規参入ベンチャーは規制のゆるい国外で法人を立てる移行の可能性
監査法人は多分…
•  仮想通貨交換業者の「監査必須」への現場対応
•  ブロックチェーン知識のある人材が足りなくて困っている
　　（年齢や資格有無での給与制度をやめてエンジニアをもっと雇おう）

View Slide

1.  取引所のハッキング事例からセキュリティのポイントを考える
2.  CryptoCurrency SecurityStandardでみるブロックチェーンサービスのセ
キュリティポイント
3.  Ethereumスマートコントラクトのハッキング事例からみるセキュリティポイ
ント
4.  スマートコントラクトの安全性向上のためのツール(mythril)
本日はブロックチェーンサービスを運用する上で基本的なセキュリ
ティポイントを考える会にしたいと思います
AGENDA
7

View Slide

8
取引所のハッキング事例からセキュリティの
ポイントを考える

View Slide

9
本発表に掲載している事例の内容につきましては、実際に起こったハッキングと、その
後発表された内容から被害、原因、その後の結果を推測した内容になります。
本事例集は特定企業に対して被害方法を断定するもの、また特定企業への意見を表
明するものではありません。ユースケースとしてあり得るセキュリティインシデントを抽
出することに主眼をおいたものです。
また推測内容は個人の見解であり、内容の判断は各自の責任でお願いいたします。
免責事項

View Slide

10
基本知識（ブロックチェーンに詳しくない方向けに）
公開
鍵
秘密
鍵
アドレ
ス
暗号通貨のいわゆる
「口座」
秘密鍵とペアで署名/
署名検証に利用
アドレスの所有権を表す
もの。
これが盗まれると暗号通
貨が盗まれると同義
秘密鍵とアドレスの関係性
不可逆変換不可逆変換

View Slide

11
2012年のA社の事例では、オペレーションミスで暗号化されていない
秘密鍵のバックアップがサーバー侵入者に奪取された
サーバーに侵入し、暗号化されていない
秘密鍵のバックアップを取得した。
オペレーションミス
•  システムのアップグレードを行ったあと、
暗号化していないディスク領域にバック
アップを置いてしまった
•  その後サーバーに侵入したハッカーか
ら秘密鍵を盗まれてしまった
߈ܸख
๏
Πϯγ
σϯτ
ݪҼ
ඃ֐ͱࣄޙରԠ
約15億円相当のBTC
औҾॴΛด࠯͠ɺ࢒
ΓͷࢿۚΛશͯސ٬
ʹ෷͍໭͠
ඃ֐ֹ
ࣄޙର
Ԡ
߈ܸ

View Slide

12
2014年のB社の事例では出金コードの脆弱性をついた攻撃が行われて
総預かり資産の1割強が失われた
ಉ࣌ϦΫΤετΛ࣮ߦ͢Δ͜ͱͰʮग़
ֹۚ ʻ ࢒ߴʯͷνΣοΫΛ͢Γൈ͚
ͯҾ͖ग़͠Λߦͬͨ
残高検証フローの脆弱性
（次スライドで詳述）
߈ܸख
๏
Πϯγ
σϯτ
ݪҼ
ඃ֐ͱࣄޙରԠ
総預り資産の約12%の
BTC
શֹΛސ٬ࢿ࢈ʹอ
ূ
ඃ֐ֹ
ࣄޙର
Ԡ
߈ܸ

View Slide

13
B社の出金フロー
B社事例では、並列に複数のリクエストを投げることで残高チェック
をすり抜けて不正引き出しを達成したと報告されている
ೖྗ஋ͷݕ
ূɻʢϚΠφ
εͳͲෆਖ਼ͳ
஋Ͱͳ͍͔ͳ
Ͳʣ
6.ग़ۚ
5.֬ೝϝʔϧ
4.ग़ۚॲཧ͕
DBʹૠೖ
3.࢒ߴ਺஋
ݮগ
2.࢒ߴݕূ
1.ೖྗ஋ͷݕূ
ग़ֹۚ෼ͷ࢒
ߴ͕͋Δ͔ͷ
νΣοΫ
े෼Ͱ͋Ε͹
࢒ߴࠩ͠Ҿ͖
ग़ۚॲཧ͕σʔ
λϕʔεʹૠೖ
֬ೝϝʔϧ͕
ૹ৴͞ΕΔ
Ϣʔβʔ͕ग़ۚ
Λঝೝͨ͠Βɺ
ϓϩάϥϜଆͰ
ग़͕ۚॲཧ͞Ε
Δ
͜͜Ͱෳ਺ͷϦΫΤετΛ
౤͛Δ͜ͱͰɺ2.࢒ߴݕূͷ
νΣοΫΛ͢Γൈ͚ɻ
࢒ߴҎ্ͷෳ਺ͷҾ͖ग़͠
ϦΫΤετΛ࣮ߦ
ಉ࣌ͳͷͰ
1ճҾ͖ग़
͠෼ͷ࢒ߴ
͕ݮগ
DBʹϨίʔυ
ૠೖ
ഉଞ੍ޚͳͲ
͔͔Γͦ͏ͳ
΋ͷ͕͔͔ͩ
Βͳ͔ͬͨʁ
ग़͕ۚෳ਺ॲཧ͞Εɺෳ਺ग़ۚ෼ͷ
BTC͕ૹΒΕΔ

View Slide

14
2016年のC社の事例ではマルチシグウォレットがハッキングされたが、
取引所トークンを発行するという事後対応で補償・再建できた
߈ܸख
๏
Πϯγ
σϯτ
ݪҼ
ඃ֐ͱࣄޙରԠ
約70億円相当のBTC
औҾॴτʔΫϯΛൃߦ
ͯ͠ɺ8ϲ݄ʹ౉ͬͯ
ސ٬ʹิঈͨ͠
ඃ֐ֹ
ࣄޙର
Ԡ
߈ܸ
•  2of3マルチシグのうち2つが盗難さ
れた
•  取引所に2つ、外部のセキュリティ
会社に1つ秘密鍵を配布して、その
うち2つで署名する「2 of 3」構成だっ
た。
明示されていないが、複数考えられる。
A.  取引所、セキュリティ会社共にハッキング
を受けた
B.  セキュリティ会社の提供ウォレットに脆弱
性があった
C.  取引所のみがハッキングを受けて、セ
キュリティ会社のマルチシグ確認がうまく
機能しなかった
D.  取引所、あるいはセキュリティ会社共犯
の内部犯行

View Slide

15
2014年 D社トランザクション展性をついた攻撃で出金を誤認させて
再出金を繰り返させた
߈ܸख
๏
Πϯγ
σϯτ
ݪҼ
ඃ֐ͱࣄޙରԠ
不明（最大386BTCと
言われる)
ഁ࢈ਃ੥
ʢͨͩ͜͠ΕҎ֎ʹ΋
߈ܸΛड͚ͨՄೳੑ͕
͋Δʣ
ඃ֐ֹ
ࣄޙର
Ԡ
߈ܸ
•  ビットコイントランザクションの特性
を利用して、出金完了していないよ
うに誤認させ、再出金を促した
•  トランザクション展性について次スラ
イドで詳述
•  出金完了を認識する仕組み作り
•  不備があった時に、一定の金額以
上の場合、手動チェックを入れるな
どフールプルーフを入れるべき

View Slide

16
トランザクション展性とは、送金内容を変化させずにトランザク
ションID（ハッシュ値）を変化させる性質
トランザクション展性の例
•  τϥϯβΫγϣϯ಺ʹ͸ɺૹۚऀͷॺ໊Λݕূ͢ΔscriptSigؚ͕·Ε͍ͯΔ
•  ҙຯͷͳ͍σʔλΛೖΕͯ΋ɺॺ໊ݕূͷ݁Ռ͸มΘΒͣɺૹۚ಺༰΋มΘΒͳ͍
•  ͨͩ͠ɺτϥϯβΫγϣϯͷϋογϡ஋ΛٻΊΔݩʹscriptSigΛೖΕΔ࢓༷Ͱ͸txid͸ม
ΘΔ
ϏοτίΠϯʹ͓͚ΔτϥϯβΫγϣϯɺͦͷలੑͱӨڹʢ2014,੪౻ ݡ࣐ʣ
http://member.wide.ad.jp/tr/wide-tr-ideon-bitcoin-transaction2014-00.pdf

View Slide

17
D者事例では、送金の内容を変えずに、トランザクションのハッシュ
値（txid）を変える事で出金が未完了だと誤認させた
攻撃のフロー
①  τϥϯβΫγϣϯΛ఻೻͢Δ஥հऀ͕ɺૹۚऀͷॺ໊Λݕূ͢ΔscriptSigʹɺҙຯͷͳ͍σʔλΛ
ೖΕΔ
②  ॺ໊ݕূͷ݁Ռ͸มΘΒͣɺૹۚ಺༰΋มΘΒͳ͍͕ɺtxid͸มΘΔ
③  txid͕มԽͨ͠τϥϯβΫγϣϯΛड͚औͬͨϚΠφʔ͕ϚΠχϯά੒ޭ͢Δ
④  औҾॴ͕txidʹґଘ͢Δૹۚ֬ೝΛߦͳ͍ͬͯΔͱग़ۚະ׬ྃͩͱޡೝ͢Δ
⑤  ࠶ग़ۚΛ܁Γฦ͢ͱೋॏग़ۚͱͳΔ
①
②
②
③
④ɺ⑤
ϏοτίΠϯʹ͓͚ΔτϥϯβΫγϣϯɺͦͷలੑͱӨڹʢ2014,੪౻ ݡ࣐ʣ
http://member.wide.ad.jp/tr/wide-tr-ideon-bitcoin-transaction2014-00.pdf

View Slide

18
捕捉：BIP141のsegwitはトランザクション展性に対応した内容
>Nonintentional malleability becomes impossible. Since signature data is no
longer part of the transaction hash,
トランザクションハッシュの元データから署名関係のデータを抜くようになるた
め、意図しないトランザクション展性はできなくなる。
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

View Slide

19
システムを俯瞰するとインシデントのポイントが見え、事例からは
鍵保管、入出金誤認などが特にクリティカルな領域と考えられる
ΠϯγσϯτͷϙΠϯτྫ
1. ೖग़ۚγεςϜ
1.  ग़ۚίʔυͷ੬ऑੑʢଟ਺ग़
ۚɾग़ۚઌͷॻ͖׵͑ʣ
2.  ग़ۚϩάͷઃఆ
3.  ސ٬༬ۚΞυϨεੜ੒࣌ʹ੬ऑ
ੑ͸ͳ͍͔
2.  ϗοτ΢ΥϨοτ
1.  อ؅ྖҬͷ҉߸Խ
2.  Ϛϧνγάઃఆͷ༗ແ
3.  Ϛϧνγά͸1Օॴʹ͓͍͍ͯ
ͳ͍͔
4.  ϗοτ΢ΥϨοτͷ࢒ߴൺ཰
ʢ࠷ѱ౪·Εͯ΋ϦΧόϦͰ͖
Δ͔ʣ
5.  ΞΫηεݖݶઃఆ
etc…
औҾॴγεςϜ
ʢ಺෦αʔόʔ or Ϋϥ΢υʣ
Ϣʔβʔ࢒ߴ؅ཧ
ʢRDBͳͲʣ
ΦϑϥΠϯ؀ڥ
ίʔϧυ΢ΥϨοτ
Blockch
ain
Node
ೖग़ۚγεςϜ
औҾγεςϜ
ϗοτɾίʔϧυͷ
ൿີ伴όοΫΞοϓ
①
②
③
④
ϗοτ΢ΥϨοτ
③
Blockchain

View Slide

20
システムを俯瞰するとインシデントのポイントが見え、事例からは
鍵保管、入出金誤認などが特にクリティカルな領域と考えられる
ΠϯγσϯτͷϙΠϯτྫ
3.  ίʔϧυ΢ΥϨοτɺϗοτɾίʔ
ϧυͷൿີ伴όοΫΞοϓ
1.  ίʔϧυ΢ΥϨοτΛઃఆ͠
͍ͯΔ͔
2.  อ؅৔ॴ͕อޢ͞Ε͍ͯΔ͔
3.  อ؅৔ॴͷ෺ཧతΞΫηεઃ
ఆ
4.  อ؅৔ॴ͸҉߸Խ͞Ε͍ͯΔ
͔
4.  ϒϩοΫνΣʔϯϊʔυ
1.  ΫϥΠΞϯτιϑτͰΞΫη
εՄೳͳIP੍ݶ͸͍ͯ͠Δ͔
2.  RPCͷΞΫηεύεϫʔυ͸ઃ
ఆ͍ͯ͠Δ͔ɹetc…
औҾॴγεςϜ
ʢ಺෦αʔόʔ or Ϋϥ΢υʣ
Ϣʔβʔ࢒ߴ؅ཧ
ʢRDBͳͲʣ
ΦϑϥΠϯ؀ڥ
ίʔϧυ΢ΥϨοτ
Blockch
ain
Node
ೖग़ۚγεςϜ
औҾγεςϜ
ϗοτɾίʔϧυͷ
ൿີ伴όοΫΞοϓ
①
②
③
④
ϗοτ΢ΥϨοτ
③
Blockchain

View Slide

21
コールドウォレットは100％安全か？
ి࣓৴߸Ͱൿີ伴Λ౪Έग़͢BeatCoin
https://www.youtube.com/watch?v=ddmHOvT866o

View Slide

22
カストディサービスの台頭により、コールドウォレット構築・保管
を預託する取引所も出てくると考えられる
Coinbase
Xapo
Nomura

View Slide

23
ただしサトシ・ナカモトの元々の問題提起
The cost of mediation increases transaction costs, limiting the minimum practical
transaction size and cutting off the possibility for small casual transactions, and there is
a broader cost in the loss of ability to make non-reversible payments for nonreversible
services.
Bitcoin: A Peer-to-Peer Electronic Cash System (Satoshi Nakamoto, 2008)
஥հऀ͕ೖΔࣄʹΑͬͯίετ͕૿େͯ͠͠·͏

View Slide

24
ハッキング事例から読み取るセキュリティポイント
ü  ൿີ伴ͷอ؅ํ๏ɺೖग़ۚͷޡೝ͸ॏཁͳϙΠϯτ
ü  ΦϖϨʔγϣϯϛεͰࢿ࢈͕ਧ͖ඈͿ͜ͱ΋͋ΔͷͰɺΦϖϨʔγϣϯϛεલఏ
ͷӡ༻ΛઃܭʢAࣾͷΦϖϛεʣ
ü  ͦ΋ͦ΋ϒϩοΫνΣʔϯ෦෼Ҏ֎Ͱ΋ී௨ʹγεςϜͷ੬ऑੑ਍அ΍ϖωτϨ
ςετ͸࣮ࢪਪ঑ʢBࣾͷೖग़ۚ߈ܸʣ
ü  ϋοΩϯάΛड͚ͨࡍͷϓϥϯΛࡦఆ͓ͯ͘͠ͱରԠ͕͠΍͍͢ɻิঈํ๏΍ؔ
܎ऀͷ࿈བྷઌɺτʔΫϯิঈͳͲ΋ࢹ໺͔ɻʢCࣾͷิঈํ๏ʣ
ü  ͦͷଞɺϗοτ΢ΥϨοτ΁ͷอ؅ൺ཰ΛϦΧόϦՄೳֹʹઃఆ͓ͯ͘͜͠ͱ
Ͱɺඃ֐Λ཈͑Δ͜ͱ͕Ͱ͖ΔʢશֹิঈͰ΋ཱͪ௚ΕΔέʔε͕͋Δʣ
ü  ίʔϧυ΢ΥϨοτ͕100ˋ҆શͱ͸ࢥΘͳ͍ʢ಺෦ෆਖ਼ɺσόΠεܦ༝ͰͷϚ
ϧ΢ΣΞײછͳͲʣ

View Slide

25
CryptoCurrency SecurityStandardから学べるブロッ
クチェーンサービスのセキュリティ観点

View Slide

26
•  CryptoCurrency Certification
Consortium(C4)という非営利団体が考案
•  C4のボードメンバーは、
•  Andreas M. Antonopoulos(Mastering
Bitcoinの著者)
•  Vitalik Buterin(Ethereum創始者) など
•  ドラフトができたのが2015年、最後の更新
は2016年
•  現在も使いやすいところも多く、中央集権
性のある取引所には特に当てはまりやすい
CryptoCurrency SecurityStandard（CCSS）では包括的なセキュリティ基
準の提案がされている
https://cryptoconsortium.github.io/CCSS/

View Slide

27
•  Cryptographic Asset Management ʢ҉߸ࢿ࢈ͷ؅ཧʣ
◦  Key / Seed Generationʢ伴ɾγʔυͷੜ੒ʣ
◦  Wallet CreationʢWalletͷੜ੒ʣ
◦  Key Storageʢ伴ͷอ؅ʣ
◦  Key Usageʢ伴ͷར༻ʣ
◦  Key Compromise Protocol (KCP) ʢ伴ͷ࿙Ӯ࣌खॱʣ
◦  Keyholder Grant/Revoke Policies & Proceduresʢ伴อ༗ऀͷݖݶ෇༩/औফϙ
Ϧγʔͱखଓʣ
•  Operations
◦  Security Audits / Pentests ʢηΩϡϦςΟ؂ࠪɾϖωτϨʔγϣϯςετʣ
◦  Data Sanitization Policy (DSP) ʢσʔλͷഁغϙϦγʔʣ
◦  Proof of Reserve (PoR) ʢ෼ผ؅ཧ؂ࠪʣ
◦  Audit Logs ʢ؂ࠪূ੻ɺϩάʣ
CCSSでは2カテゴリ10観点が掲載されており、鍵の生成から管理・破
棄までのライフサイクルをカバーしている

View Slide

28
•  Key / Seed Generation（鍵・シードの生成）
◦  秘密鍵やシード値がオペレーター自身で作成され
たか
◦  秘密鍵の生成方法に脆弱性はないか
◦  鍵の生成方法がDRBG（決定論的乱数生成器）準
拠か
◦  生成時のランダム性エントロピーは十分か
•  Wallet Creation（Walletの生成）
◦  トランザクションごとにユニークなアドレスを作成し
ているか
◦  マルチシグを利用しているか
◦  鍵は冗長構成になっているか
◦  HD Walletを利用しているか
◦  鍵の保管場所は地理的に分散されているか（BCP
観点）
◦  鍵の保管は組織的に分散されているか（内部不正
対応）
Cryptographic Asset Management （暗号資産の管理）では、秘密鍵生
成、管理、利用、破棄まで多くのチェック観点が示されている
Cryptographic Asset Management ʢ҉߸ࢿ࢈ͷ؅ཧʣ 1/2
・Key Storage（鍵の保管）
◦  暗号化されているか
◦  バックアップの秘密鍵はあるか
◦  バックアップの秘密鍵は物理的に安全な環境にあ
るか
◦  バックアップの秘密鍵へのアクセスが制限されて
いるか
◦  バックアップの秘密鍵は未開封シールで保護され
ているか
◦  バックアップの秘密鍵は暗号化されているか

View Slide

29
• Key Usage（鍵の利用）
•  鍵の利用時には複数の認証が設定されているか
•  鍵の利用は信頼されたアクセス環境からのみに限
定されているか
•  オペレーターの経歴チェックはしているか
•  オペレーターの身元チェックはしているか
•  オペレーターのバックグラウンドチェックはしている
か
•  署名前に送金内容をチェックしているか
•  同じデバイスに複数の鍵を入れていないか
•  署名時に入れる数値はDRBG準拠で生成されてい
るか
Cryptographic Asset Management （暗号資産の管理）では、秘密鍵生
成、管理、利用、破棄まで多くのチェック観点が示されている
•  Key Compromise Protocol (KCP) （鍵の漏洩時
手順）
•  漏洩時手順は作成されているか
•  漏洩時手順は訓練とリハーサルされているか
•  Keyholder Grant/Revoke Policies &
Procedures（鍵保有者の権限付与/取消ポリシ
ーと手続）
•  権限付与/取消ポリシーは策定されているか
•  信頼された経路で権限付与/取消はされるか
Cryptographic Asset Management ʢ҉߸ࢿ࢈ͷ؅ཧʣ 2/2

View Slide

30
◦  Security Audits / Pentests ʢηΩϡϦςΟ؂ࠪɾϖωτϨʔγϣϯςετʣ
◦  ֎෦ͷηΩϡϦςΟ؂͕ࠪʢఆظతʹʣ͞Ε͍ͯΔ͔
◦  Data Sanitization Policy (DSP) ʢσʔλͷഁغϙϦγʔʣ
◦  σʔλͷഁغϙϦγʔ͕ࡦఆ͞Ε͍ͯΔ͔
◦  σʔλഁغ࣌ʹ؂ࠪϩά͕࢒͍ͬͯΔ͔
◦  Proof of Reserve (PoR) ʢ࢒ߴূ໌ʣ
◦  ࢒ߴূ໌ͷ؂ࠪ΋͘͠͸४ͣΔ΋ͷ͕࣮ࢪ͞Ε͍ͯΔ͔
◦  Audit Logs ʢ؂ࠪূ੻ɺϩάʣ
◦  ΞϓϦέʔγϣϯͷ؂ࠪϩά͕͋Δ͔
◦  ؂ࠪϩάͷόοΫΞοϓ͕͋Δ͔
Operations （オペレーション）についても言及している

View Slide

31
•  ൿີ伴Λ༬͔Δ৔߹
•  ΦϖϨʔγϣϯɾอ؅ؚΊͯશͯ
ͷ؍఺͕ॏཁ
•  ൿີ伴Λ༬͔Βͳ͍৔߹
•  ΢ΥϨοταʔϏεͳͲͷ৔߹ɺ
伴ͷੜ੒ͳͲ͕͔ͳΓॏཁ
•  DEXͳͲͷ৔߹Ͱ伴ੜ੒ػೳ΋ఏ
ڙ͠ͳ͍৔߹ɺΑΓ؍఺͸ෆཁʹ
ͳΔ
CCSSは秘密鍵を預かるかどうかによって重点を置く観点が大きく異
なる
CCSSͷ؍఺
•  Cryptographic Asset Management ʢ҉߸ࢿ࢈ͷ؅ཧʣ
•  Key / Seed Generationʢ伴ɾγʔυͷੜ੒ʣ
•  Wallet CreationʢWalletͷੜ੒ʣ
•  Key Storageʢ伴ͷอ؅ʣ
•  Key Usageʢ伴ͷར༻ʣ
•  Key Compromise Protocol (KCP) ʢ伴ͷ࿙Ӯ࣌खॱʣ
•  Keyholder Grant/Revoke Policies & Proceduresʢ伴อ༗
ऀͷݖݶ෇༩/औফϙϦγʔͱखଓʣ
•  Operations
•  Security Audits / Pentests ʢηΩϡϦςΟ؂ࠪɾϖωτ
Ϩʔγϣϯςετʣ
•  Data Sanitization Policy ʢDSPʣ ʢσʔλͷഁغϙϦγ
ʔʣ
•  Proof of Reserve (PoR) ʢ෼ผ؅ཧ؂ࠪʣ
•  Audit Logs ʢ؂ࠪূ੻ɺϩάʣ

View Slide

32
CryptoCurrency SecurityStandard（CCSS）から読み取るセキュリティポ
イント
ü  ࠷ޙͷߋ৽͸2016೥͕ͩɺݱࡏ΋ར༻Ͱ͖Δ෦෼͸ଟ͍
ü  ͋Δఔ౓ͷ໢ཏײΛ͍࣋ͬͯΔͷͰɺηΩϡϦςΟΛߟ͑Δࡍͷࢀߟʹ
ü  ஧࣮ʹै͏͜ͱ͕ݱ࣮తʹ೉͍͠؍఺͸ɺརศੑͱ֎ͯ͠͸͍͚ͳ͍ϙΠϯτͱ
ͷόϥϯεΛݟͳ͕Βऔࣺબ୒ਪ঑
ü  ϗοτ΢ΥϨοτɺίʔϧυ΢ΥϨοτͷֹۚอ؅ൺ཰ͳͲ·Ͱ͸ݴٴ͍ͯ͠ͳ
͍ͷͰɺઐ໳ՈΛަ͑ͯ؍఺ͷ௥ՃͳͲ΋஫ҙ
ü  ͜͜·Ͱ͘Δͱ݁ߏΞφϩά෦෼΋ॏཁʹͳΔ

View Slide

33
Ethereumスマートコントラクトのハッキング事
例からみるセキュリティポイント

View Slide

34
スマートコントラクトは、価値の移転をルールに従って起こす仕組
みである
޿͍ҙຯͰ͸ɺܖ໿ΛػցͰ࣮૷͢Δ࢓૊Έʢ˞ʣ
ڱ͍ҙຯͰ͸ɺσδλϧʹදݱ͞ΕΔࢿ࢈Λ༧ΊఆΊΒΕͨϧʔϧʹैͬͯࣗಈతʹҠసͤ͞Δ࢓૊Έ
Ethereumʹ͓͍ͯ͸…
• ίʔυΛΞυϨεʹࡌͤͯϒϩ
οΫνΣʔϯʹσϓϩΠ͢Δ
• σϓϩΠ͞ΕͨίʔυΛϒϩο
ΫνΣʔϯͱͯ͠ಈ͔͢
• ίʔυ͕ಈ͘͝ͱʹಈ͔͢ओମ
ͷΨε͕ফඅ͞ΕΔ
੪౻ݡ࣐ࢯͷϒϩοΫνΣʔϯ࿈ଓߨٛୈճΑΓ
IUUQTXXXESPQCPYDPNTSKCMSJIPHKJDK#D)TNBSUDPOUSBDUBQEG EM
DEXͷྫ

View Slide

35
Reentrancy Attack(再入国攻撃)によってDAO事件では当時の価値約65
億円が被害を受けた
%"0
$POUSBDU
)BDLFS
$POUSBDU
1.攻撃者はあらかじめ
少額のETHをdepositしておく
%"0
$POUSBDU
)BDLFS
$POUSBDU
2.攻撃者は1で預けた分、withdrawコントラクトを呼び出す
が、前提4のFallback関数の動きより、被害者が残高帳を
更新する前に出金が何度も行われる
1.被害者のコントラクトには
- deposit関数（預金）
- withdraw関数（出金）
が定義されており、
銀行的にユーザーの残高を預かったり引き出し
たりできる
2.withdraw関数（出金）は、先にETHの出金をして
から、残高帳の預金数字を減らす
3.攻撃者は自身にコントラクトを持つアドレスであ
る
4.攻撃者は被害者のwithdrawコントラクトを呼び
出し、ETHの出金がされた直後に何度もwithdraw
するような処理をFallback関数に既定しておく
deposit࣮ߦ
withdraw × αճ
Reentrancy AttackʢDAOʣ
લఏ

View Slide

36
Reentrancy Attack(再入国攻撃) DAO事件の攻撃サンプルとハッキング
されたコードを示す
#Ϣʔβʔͷ࢒ߴா
mapping (address => uint) private userBalances;
#Ҿ͖ग़ؔ͠਺
function withdrawBalance() public {
# Ҿ͖ग़͠Մೳֹۚͷऔಘ
uint amountToWithdraw =
userBalances[msg.sender];
#require͔Β߈ܸऀ͸FallbackΛ࣮ߦͯ͠Ҿ͖ग़͠Λ
ϧʔϓ࣮ߦ͢Δ
require(msg.sender.call.value(amountToWithdraw)
());
# Ϣʔβʔͷ࢒ߴாߋ৽Λߦ͏
userBalances[msg.sender] = 0;
}
int private count;
function Attacker() public {
count = 0;
}
# Fallbackؔ਺
function () payable public {
count += 1;
# Ҿ͖ग़͠ΛԿ౓΋ߦ͏ॲཧΛنఆ͓ͯ͠
͘
if (count < 10000) {
VictimContract victimContract =
VictimContract(msg.sender);
victimContract.withdrawBalance();
}
}
DAOContract
AttackContractExample

View Slide

Reentrancy Attackを防ぐためには、繰り返しに耐える処理を実装する
必要があった
#Ϣʔβʔͷ࢒ߴா
#Ҿ͖ग़ؔ͠਺
#͜͜Λى఺ʹ߈ܸऀ͸FallbackΛ࣮ߦͯ͠Ҿ͖ग़͠
Λϧʔϓ࣮ߦ͢Δ
require(msg.sender.call.value(amountToWithdraw)());
# Ϣʔβʔͷ࢒ߴாߋ৽Λߦ͏
}
Original DAOContract
#Ϣʔβʔͷ࢒ߴா
#Ҿ͖ग़ؔ͠਺
# Ϣʔβʔͷ࢒ߴாߋ৽ΛɺҾ͖ग़͠લʹߦ͏
͜ͱͰReentrancy߈ܸʹରԠ͢Δ
require(msg.sender.call.value(amountToWithdraw)
());
}
Protected DAOContract
37

View Slide

38
Etherscanの攻撃トランザクション
Beautychain Token(BEC)では、オーバーフローを利用した攻撃があり、
発行量以上の過剰な供給と引き出しが行われた
https://etherscan.io/tx/
0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f
ڙڅྔ͕7000000000ͷ
τʔΫϯʹରͯ͠ɺ
5789604461865809771
1785492504343953926
6349923328202820197
2879200395656481996
8τʔΫϯ͕2ͭͷΞυ
ϨεʹҾ͖ग़͞Ε͍ͯ
Δ

View Slide

39
BECトークンの不正な引き出しを起こすために、オーバーフローを利
用して所持残高チェックを擦り抜けた
//࢓༷ɿෳ਺ͷΞυϨεʹରͯ͠Ұ౓ʹಉ਺ͷτʔΫϯΛૹ
Δ
//Ҿ਺ɿ1,ΞυϨεͷ഑ྻ 2,ૹΔτʔΫϯྔ
function batchTransfer(address[] _receivers, uint256 _value) public
whenNotPaused returns (bool) {
//① ૹΔτʔΫϯྔʹҾ͖౉͞ΕͨΞυϨεͷ਺Λ͔͚
ͯɺૹΔ૯ྔΛࢉग़͢Δ
uint cnt = _receivers.length;
// ͜͜ͰΦʔόʔϑϩʔΛى͜͢
uint256 amount = uint256(cnt) * _value;
//② ૹΔର৅ΞυϨε͕1Ҏ্20ҎԼ͔ɺૹΓݩʹे෼ͳ
τʔΫϯྔ͕͋Δ͔Λ൑ఆ
require(cnt > 0 && cnt <= 20);
require(_value > 0 && balances[msg.sender] >= amount);
//③ ֤ΞυϨεʹରͯ͠ಉ਺ͷτʔΫϯΛૹΔ
balances[msg.sender] = balances[msg.sender].sub(amount);
for (uint i = 0; i < cnt; i++) {
balances[_receivers[i]] = balances[_receivers[i]].add(_value);
Transfer(msg.sender, _receivers[i], _value);
}
return true;
}
BEC Token Contract
オーバーフローを起こした方法
•  引数はアドレス(_receivers)を2つ、送
るトークン量(value)が2^255
•  攻撃者のBECトークン所持量は0
•  amount = 2^255 *2 となり、uint256
型の限界値2^256が巻き戻って0にな
る
•  引数(value)に設定された2^255BEC
トークンが引数のアドレスにそれぞれ
送られる

View Slide

•  攻撃によるトークン供給量
(攻撃によるトークン供給量) / （単位補正※）
=2^256 / (10^18)
=115,792,089,237,316,000,000,000,000,000,0
00,000,000,000,000,000,000,000,000,000
≒ 1,158阿僧祇（あそうぎ）
※BECトークンの1単位が10^18なので補正す
る
•  倍率
(攻撃によるトークン供給量 + 元の供給量） /
(元の供給量）
= (2^256 / (10^18) + 7,000,000,000) /
7,000,000,000
=16,541,727,033,902,300,000,000,000,000,00
0,000,000,007,000,000,000
≒ 16.5極
結果、元の供給量70億に対して1,158阿僧祇（あそうぎ）量が供給さ
れ、16.5極（ごく）倍のインフレーションが起きて価値が崩壊した
୯Ґ ಡΈํ େ͖͞
ԯ ͓͘ 10^8
ஹ ͪΐ͏ 10^12
ژ ͚͍ɺ͖ΐ͏ 10^16
ᆇ ͕͍ 10^20
䉾 ͡ΐɺ͠ 10^24
য় ͡ΐ͏ 10^28
ߔ ͜͏ 10^32
׾ ͔Μ 10^36
ਖ਼ ͍ͤ 10^40
ࡌ ͍͞ 10^44
ۃ ͘͝ 10^48
߃Տࠫ ͝͏͕͠Ό 10^52
Ѩૐᷫ ͋ͦ͏͗ 10^56
ಹ༝ଞ ͳΏͨ 10^60
ෆՄࢥٞ ;͔͗͠ 10^64
ແྔେ਺ ΉΓΐ͏͍ͨ͢͏ 10^68
ࢀߟɿ਺ͷ୯Ґ
40

View Slide

攻撃を防ぐためにはオーバーフローを考慮した四則演算を行う必要
があった
OpenZeppelinは安全にsolidityを書くためのフレームワークを提供している
function mul(uint256 _a, uint256 _b) internal pure returns (uint256) {
// Gas optimization: this is cheaper than requiring 'a' not being zero, but the
// benefit is lost if 'b' is also tested.
// See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522
if (_a == 0) {
return 0;
}
uint256 c = _a * _b;
// ݕࢉͯ͠ΦʔόʔϑϩʔରԠΛ͍ͯ͠Δ
require(c / _a == _b);
return c;
}
OpenZeppelin SafeMath.sol
41

View Slide

42
Ethereumスマートコントラクトのハッキング事例からみるセキュリテ
ィポイント
ü  ੬ऑੑͷ͋ΔίʔυΛΫϥοΩϯά͢Δ͜ͱͰෆਖ਼ͳࢿ࢈Ҡಈ͕Ͱ͖ͯ͠·͏έʔε
͕͋Δ
ü  Ϣʔβʔͷൿີ伴Λ༬͔Βͳ͍ͱͯ͠΋ɺίʔυͷ҆શੑΛ୲อ͢Δඞཁ͕͋Δ
ü  σϓϩΠͨ͠ίʔυ͸΄΅มߋͰ͖ͳ͍ͨΊɺࣦഊͰ͖ͳ͍ʢϒϩοΫνΣʔϯͷվ
͟ΜෆՄೳੑʣ
ü  ίʔυ͸ϒϩοΫνΣʔϯ্ʹ͋Γɺ୭ʹͰ΋ݟΒΕͯ੬ऑੑΛ୳͠΍͍͢ʢϒϩο
ΫνΣʔϯͷಁ໌ੑʣ
ü  ಗ໊Ͱ௨՟͕खʹೖΔͨΊΫϥοΩϯάͷΠϯηϯςΟϒ΋ߴ͍ʢϒϩοΫνΣʔϯ
ͷಗ໊ੑʣ

View Slide

43
スマートコントラクトの脆弱性を事前に発見
するために

View Slide

44
•  concolic analysis
concolic testingという、コードからカバレッジを最大化する変数を生み出す手法。元論文
は"CUTE: a concolic unittesting engine for C"(Sen, Koushik; Darko Marinov, Gul Agha
2005）
•  テイント解析
注目したいデータに設定したタグを伝搬させて追跡することで，プログラムやデータ間の依
存関係を分析する手法
Mythrilというツールを利用することで、スマートコントラクトの安全
性を向上し、ハッキング被害の事前対応に役立つ
https://github.com/ConsenSys/mythril
Mythril is a security analysis tool for Ethereum smart contracts. It uses concolic analysis,
taint analysis and control ﬂow checking to detect a variety of security vulnerabilities.
(READMEΑΓ)
MythrilはEthereumスマートコントラクトのセキュリティ分析ツール。concolic analysisとテイ
ント解析、制御フロー解析をセキュリティ脆弱性を発見するために利用している。

View Slide

45
例えばMythrilでOverflowAttackを受けたBECトークンのコントラクトを
解析すると、Integer OverflowのWarningが検知される

View Slide

46
mythrilでは約20種類の潜在的な脆弱性を検知してくれる
•  Unprotected functions
•  Missing check on CALL return value
•  Re-entrancy
•  Multiple sends in a single transaction
•  External call to untrusted contract
•  Delegatecall or callcode to untrusted
contract
•  Integer overflow/underflow
•  Timestamp dependence
•  Payable transaction does not revert in
case of failure
•  Use of tx.origin
•  Type confusion
•  Predictable RNG
•  Transaction order dependence
•  Information exposure
•  Complex fallback function (uses
more than 2,300 gas)
•  Use require()instead of assert()
•  Use of depreciated functions
•  Detect tautologies
•  Call depth attack

View Slide

47
ü Mythrilの判断はコードを読む限り、EVM上で動くOPCODEから、脆弱性の可
能性があるものを幅広に出している
ü False Positive / False Negativeもないとは言えなそうであり、Warningを見
て個別に確認する必要性がある
ü そもそも未知の攻撃手法がある場合は検知不能
ü その他、現在oyenteやMAIANといった解析ツールもあり、複数ツールで試
行してみるのが良い
Mythrilの判断基準は完全とまでは言えないものの、デプロイ前に診断
しておく事でセキュリティ向上に利用できる

View Slide

48
なお、Consensysによって公開されているsmart-contract-best-practices
は、known attacksに攻撃事例が掲載されており、攻撃判定に役立つ

View Slide

49
本日はブロックチェーンサービスを運用する上で基本的なセキュリ
ティポイントをご紹介しました
1.  औҾॴͷϋοΩϯάࣄྫ͔ΒηΩϡϦςΟͷϙΠϯτΛߟ͑Δ
Ø 伴ͷอ؅ɺೖग़ۚ͸ΫϦςΟΧϧͳϙΠϯτ
Ø γεςϜ၆ᛌ͢Δ͜ͱͰΠϯγσϯτͷϙΠϯτ͸ݟ͑Δ
2.  CryptoCurrency SecurityStandard͔Βֶ΂ΔϒϩοΫνΣʔϯαʔϏεͷ
ηΩϡϦςΟ؍఺
Ø  伴ͷੜ੒ʙ࡟আ·ͰͷϥΠϑαΠΫϧɺΦϖϨʔγϣϯʹ͍ͭͯ໢ཏ
ײ͕͋Δ
Ø  νΣοΫϦετΛར༻͢Δ
3.  EthereumεϚʔτίϯτϥΫτͷϋοΩϯάࣄྫ͔ΒΈΔηΩϡϦςΟ
ϙΠϯτ
Ø σϓϩΠ͞Εͨίʔυ͸୭ʹͰ΋ݟΒΕͯ੬ऑੑΛ୳͠΍͍͢
Ø ࣄલʹݕ஌͢Δඞཁ͕͋Δ
4.  εϚʔτίϯτϥΫτͷ੬ऑੑΛࣄલʹൃݟ͢ΔͨΊʹ
Ø ੬ऑੑ਍அπʔϧͷར༻
Ø աڈͷ߈ܸࣄྫͷऩू
·ͱΊ

View Slide

50
次回予告：9月26日（水）　セキュリティのイベント第２回をやりま
す

View Slide

ブロックチェーンサービスのセキュリティを考える

ブロックチェーンサービスのセキュリティを考える

Nao Hanamura

More Decks by Nao Hanamura

Other Decks in Technology

Featured

Transcript