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

参考URL

2P
丸の内で働くブロックチェーンエンジニアのブログ
http://www.blockchainengineer.tokyo/

3P
catabira
https://catabira.co/

5P
金融庁「仮想通貨交換業者等の検査・モニタリング　中間とりまとめ」　主なポイント
https://www.fsa.go.jp/news/30/virtual_currency/20180810-1.pdf

16,17P
ビットコインにおけるトランザクション、その展性と影響（斉藤 賢爾,2014）
http://member.wide.ad.jp/tr/wide-tr-ideon-bitcoin-transaction2014-00.pdf

18P
BIP141
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

21P
BeatCoin
https://www.youtube.com/watch?v=ddmHOvT866o

26P
CryptoCurrency SecurityStandard（CCSS）
https://cryptoconsortium.github.io/CCSS/

34P
斉藤 賢爾氏のブロックチェーン連続講義 第7回より
https://www.dropbox.com/s/rjblri8h3ogjicj/BcH-smart-contract20160408a.pdf?dl=0

38P
Etherscan
https://etherscan.io/tx/0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f

44P
Mythril
https://github.com/ConsenSys/mythril

Transcript

1. 1 ブロックチェーンサービスのセキュリティを 考える 2018/8/17 Neutrino Naochika Hanamura
2. 2 これまでやってきたこと 自己紹介：2017年5月頃からブロックチェーンのエンジニアをしており、特 に仮想通貨監査などに関わってきました 開発・研究 •  ブロックチェーンデータの分析基盤構築 •  ブロックチェーン領域のモニタリングサービス開発 •  Moneroのトレーサブルリング署名研究（大学院） コミュニティ活 動 •  DashのWhitePaper翻訳 •  技術ブログ「丸ノ内で働くブロックチェーンエンジニアのブログ」 (www.blockchainengineer.tokyo/) 仮想通貨 監査 •  仮想通貨監査の技術アドバイザリー ✓ 特に取引所の監査手続開発 ✓ 特定通貨の監査手法などのリサーチ 花村直親（Naochika Hanamura） @naomasabit
3. 3 自己紹介：8月からcatabiraという会社を共同創業してChief Blockchain Officerに就任しました https://catabira.co/
4. 課題感とモチベーション جຊతͳϙΠϯτͰͷϋοΩϯάඃ֐͕ଟ͘ɺগ͠ͷ஫ҙͱγεςϜରԠͰ๷͛ͨ Մೳੑ͕͋Δ 4 ҉߸௨՟ʹΑͬͯਓ͕ؒಈ͔ͤΔࢿۚྔͷ૿େ •  オペレーションミスに対応する運用設計 •  簡単なペネトレーションテスト •  脆弱性診断 だけでもしておけば防げた可能性がある •  一人で即数百億円動かせる時代はこれまでになかった（現金だと物理的に 重すぎてうごかせなかった） •  KYCをしている銀行口座より足がつきにくい（少なくとも日本では）
5. 課題感とモチベーション ۚ༥ிʮԾ૝௨՟ަ׵ۀऀ౳ͷݕࠪɾϞχλϦϯάɹதؒͱΓ·ͱΊʯɹओͳϙΠϯτΑΓ 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
6. この業界が好きなので、発展のためにブロックチェーンビジネス独 特のセキュリティポイント理解の一助ができれば幸いです 6 規制側は多分… •  ものすごい可能性とリスクがあると感じている •  既存金融へのガイドラインしかない状態で、ブロックチェーンビジネス独特の「力点」 が分からないので、業務、システム全方位の対応を要求 　　（エンジニアをもっと雇おう） ビジネス側は多分… •  認可をもらわないと営業できないのでなんとか対応しようとしている •  金融機関的な業務フロー整備と人材不足で大変 •  新規参入ベンチャーは規制のゆるい国外で法人を立てる移行の可能性 監査法人は多分… •  仮想通貨交換業者の「監査必須」への現場対応 •  ブロックチェーン知識のある人材が足りなくて困っている 　　（年齢や資格有無での給与制度をやめてエンジニアをもっと雇おう）
7. 1.  取引所のハッキング事例からセキュリティのポイントを考える 2.  CryptoCurrency SecurityStandardでみるブロックチェーンサービスのセ キュリティポイント 3.  Ethereumスマートコントラクトのハッキング事例からみるセキュリティポイ ント 4.  スマートコントラクトの安全性向上のためのツール(mythril) 本日はブロックチェーンサービスを運用する上で基本的なセキュリ ティポイントを考える会にしたいと思います AGENDA 7
8. 8 取引所のハッキング事例からセキュリティの ポイントを考える
9. 9 本発表に掲載している事例の内容につきましては、実際に起こったハッキングと、その 後発表された内容から被害、原因、その後の結果を推測した内容になります。 本事例集は特定企業に対して被害方法を断定するもの、また特定企業への意見を表 明するものではありません。ユースケースとしてあり得るセキュリティインシデントを抽 出することに主眼をおいたものです。 また推測内容は個人の見解であり、内容の判断は各自の責任でお願いいたします。 免責事項
10. 10 基本知識（ブロックチェーンに詳しくない方向けに） 公開 鍵 秘密 鍵 アドレ ス 暗号通貨のいわゆる 「口座」 秘密鍵とペアで署名/ 署名検証に利用 アドレスの所有権を表す もの。 これが盗まれると暗号通 貨が盗まれると同義 秘密鍵とアドレスの関係性 不可逆変換 不可逆変換
11. 11 2012年のA社の事例では、オペレーションミスで暗号化されていない 秘密鍵のバックアップがサーバー侵入者に奪取された サーバーに侵入し、暗号化されていない 秘密鍵のバックアップを取得した。 オペレーションミス •  システムのアップグレードを行ったあと、 暗号化していないディスク領域にバック アップを置いてしまった •  その後サーバーに侵入したハッカーか ら秘密鍵を盗まれてしまった ߈ܸख ๏ Πϯγ σϯτ ݪҼ ඃ֐ͱࣄޙରԠ 約15億円相当のBTC औҾॴΛด࠯͠ɺ࢒ ΓͷࢿۚΛશͯސ٬ ʹ෷͍໭͠ ඃ֐ֹ ࣄޙର Ԡ ߈ܸ
12. 12 2014年のB社の事例では出金コードの脆弱性をついた攻撃が行われて 総預かり資産の1割強が失われた ಉ࣌ϦΫΤετΛ࣮ߦ͢Δ͜ͱͰʮग़ ֹۚ ʻ ࢒ߴʯͷνΣοΫΛ͢Γൈ͚ ͯҾ͖ग़͠Λߦͬͨ 残高検証フローの脆弱性 （次スライドで詳述） ߈ܸख ๏ Πϯγ σϯτ ݪҼ ඃ֐ͱࣄޙରԠ 総預り資産の約12%の BTC શֹΛސ٬ࢿ࢈ʹอ ূ ඃ֐ֹ ࣄޙର Ԡ ߈ܸ
13. 13 B社の出金フロー B社事例では、並列に複数のリクエストを投げることで残高チェック をすり抜けて不正引き出しを達成したと報告されている ೖྗ஋ͷݕ ূɻʢϚΠφ εͳͲෆਖ਼ͳ ஋Ͱͳ͍͔ͳ Ͳʣ 6.ग़ۚ 5.֬ೝϝʔϧ 4.ग़ۚॲཧ͕ DBʹૠೖ 3.࢒ߴ਺஋ ݮগ 2.࢒ߴݕূ 1.ೖྗ஋ͷݕূ ग़ֹۚ෼ͷ࢒ ߴ͕͋Δ͔ͷ νΣοΫ े෼Ͱ͋Ε͹ ࢒ߴࠩ͠Ҿ͖ ग़ۚॲཧ͕σʔ λϕʔεʹૠೖ ֬ೝϝʔϧ͕ ૹ৴͞ΕΔ Ϣʔβʔ͕ग़ۚ Λঝೝͨ͠Βɺ ϓϩάϥϜଆͰ ग़͕ۚॲཧ͞Ε Δ ͜͜Ͱෳ਺ͷϦΫΤετΛ ౤͛Δ͜ͱͰɺ2.࢒ߴݕূͷ νΣοΫΛ͢Γൈ͚ɻ ࢒ߴҎ্ͷෳ਺ͷҾ͖ग़͠ ϦΫΤετΛ࣮ߦ ಉ࣌ͳͷͰ 1ճҾ͖ग़ ͠෼ͷ࢒ߴ ͕ݮগ DBʹϨίʔυ ૠೖ ഉଞ੍ޚͳͲ ͔͔Γͦ͏ͳ ΋ͷ͕͔͔ͩ Βͳ͔ͬͨʁ ग़͕ۚෳ਺ॲཧ͞Εɺෳ਺ग़ۚ෼ͷ BTC͕ૹΒΕΔ
14. 14 2016年のC社の事例ではマルチシグウォレットがハッキングされたが、 取引所トークンを発行するという事後対応で補償・再建できた ߈ܸख ๏ Πϯγ σϯτ ݪҼ ඃ֐ͱࣄޙରԠ 約70億円相当のBTC औҾॴτʔΫϯΛൃߦ ͯ͠ɺ8ϲ݄ʹ౉ͬͯ ސ٬ʹิঈͨ͠ ඃ֐ֹ ࣄޙର Ԡ ߈ܸ •  2of3マルチシグのうち2つが盗難さ れた •  取引所に2つ、外部のセキュリティ 会社に1つ秘密鍵を配布して、その うち2つで署名する「2 of 3」構成だっ た。 明示されていないが、複数考えられる。 A.  取引所、セキュリティ会社共にハッキング を受けた B.  セキュリティ会社の提供ウォレットに脆弱 性があった C.  取引所のみがハッキングを受けて、セ キュリティ会社のマルチシグ確認がうまく 機能しなかった D.  取引所、あるいはセキュリティ会社共犯 の内部犯行
15. 15 2014年 D社 トランザクション展性をついた攻撃で出金を誤認させて 再出金を繰り返させた ߈ܸख ๏ Πϯγ σϯτ ݪҼ ඃ֐ͱࣄޙରԠ 不明（最大386BTCと 言われる) ഁ࢈ਃ੥ ʢͨͩ͜͠ΕҎ֎ʹ΋ ߈ܸΛड͚ͨՄೳੑ͕ ͋Δʣ ඃ֐ֹ ࣄޙର Ԡ ߈ܸ •  ビットコイントランザクションの特性 を利用して、出金完了していないよ うに誤認させ、再出金を促した •  トランザクション展性について次スラ イドで詳述 •  出金完了を認識する仕組み作り •  不備があった時に、一定の金額以 上の場合、手動チェックを入れるな どフールプルーフを入れるべき
16. 16 トランザクション展性とは、送金内容を変化させずにトランザク ションID（ハッシュ値）を変化させる性質 トランザクション展性の例 •  τϥϯβΫγϣϯ಺ʹ͸ɺૹۚऀͷॺ໊Λݕূ͢ΔscriptSigؚ͕·Ε͍ͯΔ •  ҙຯͷͳ͍σʔλΛೖΕͯ΋ɺॺ໊ݕূͷ݁Ռ͸มΘΒͣɺૹۚ಺༰΋มΘΒͳ͍ •  ͨͩ͠ɺτϥϯβΫγϣϯͷϋογϡ஋ΛٻΊΔݩʹscriptSigΛೖΕΔ࢓༷Ͱ͸txid͸ม ΘΔ ϏοτίΠϯʹ͓͚ΔτϥϯβΫγϣϯɺͦͷలੑͱӨڹʢ2014,੪౻ ݡ࣐ʣ http://member.wide.ad.jp/tr/wide-tr-ideon-bitcoin-transaction2014-00.pdf
17. 17 D者事例では、送金の内容を変えずに、トランザクションのハッシュ 値（txid）を変える事で出金が未完了だと誤認させた 攻撃のフロー ①  τϥϯβΫγϣϯΛ఻೻͢Δ஥հऀ͕ɺૹۚऀͷॺ໊Λݕূ͢ΔscriptSigʹɺҙຯͷͳ͍σʔλΛ ೖΕΔ ②  ॺ໊ݕূͷ݁Ռ͸มΘΒͣɺૹۚ಺༰΋มΘΒͳ͍͕ɺtxid͸มΘΔ ③  txid͕มԽͨ͠τϥϯβΫγϣϯΛड͚औͬͨϚΠφʔ͕ϚΠχϯά੒ޭ͢Δ ④  औҾॴ͕txidʹґଘ͢Δૹۚ֬ೝΛߦͳ͍ͬͯΔͱग़ۚະ׬ྃͩͱޡೝ͢Δ ⑤  ࠶ग़ۚΛ܁Γฦ͢ͱೋॏग़ۚͱͳΔ ① ② ② ③ ④ɺ⑤ ϏοτίΠϯʹ͓͚ΔτϥϯβΫγϣϯɺͦͷలੑͱӨڹʢ2014,੪౻ ݡ࣐ʣ http://member.wide.ad.jp/tr/wide-tr-ideon-bitcoin-transaction2014-00.pdf
18. 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
19. 19 システムを俯瞰するとインシデントのポイントが見え、事例からは 鍵保管、入出金誤認などが特にクリティカルな領域と考えられる ΠϯγσϯτͷϙΠϯτྫ 1. ೖग़ۚγεςϜ 1.  ग़ۚίʔυͷ੬ऑੑʢଟ਺ग़ ۚɾग़ۚઌͷॻ͖׵͑ʣ 2.  ग़ۚϩάͷઃఆ 3.  ސ٬༬ۚΞυϨεੜ੒࣌ʹ੬ऑ ੑ͸ͳ͍͔ 2.  ϗοτ΢ΥϨοτ 1.  อ؅ྖҬͷ҉߸Խ 2.  Ϛϧνγάઃఆͷ༗ແ 3.  Ϛϧνγά͸1Օॴʹ͓͍͍ͯ ͳ͍͔ 4.  ϗοτ΢ΥϨοτͷ࢒ߴൺ཰ ʢ࠷ѱ౪·Εͯ΋ϦΧόϦͰ͖ Δ͔ʣ 5.  ΞΫηεݖݶઃఆ etc… औҾॴγεςϜ ʢ಺෦αʔόʔ or Ϋϥ΢υʣ Ϣʔβʔ࢒ߴ؅ཧ ʢRDBͳͲʣ ΦϑϥΠϯ؀ڥ ίʔϧυ΢ΥϨοτ Blockch ain Node ೖग़ۚγεςϜ औҾγεςϜ ϗοτɾίʔϧυͷ ൿີ伴όοΫΞοϓ ① ② ③ ④ ϗοτ΢ΥϨοτ ③ Blockchain
20. 20 システムを俯瞰するとインシデントのポイントが見え、事例からは 鍵保管、入出金誤認などが特にクリティカルな領域と考えられる ΠϯγσϯτͷϙΠϯτྫ 3.  ίʔϧυ΢ΥϨοτɺϗοτɾίʔ ϧυͷൿີ伴όοΫΞοϓ 1.  ίʔϧυ΢ΥϨοτΛઃఆ͠ ͍ͯΔ͔ 2.  อ؅৔ॴ͕อޢ͞Ε͍ͯΔ͔ 3.  อ؅৔ॴͷ෺ཧతΞΫηεઃ ఆ 4.  อ؅৔ॴ͸҉߸Խ͞Ε͍ͯΔ ͔ 4.  ϒϩοΫνΣʔϯϊʔυ 1.  ΫϥΠΞϯτιϑτͰΞΫη εՄೳͳIP੍ݶ͸͍ͯ͠Δ͔ 2.  RPCͷΞΫηεύεϫʔυ͸ઃ ఆ͍ͯ͠Δ͔ɹetc… औҾॴγεςϜ ʢ಺෦αʔόʔ or Ϋϥ΢υʣ Ϣʔβʔ࢒ߴ؅ཧ ʢRDBͳͲʣ ΦϑϥΠϯ؀ڥ ίʔϧυ΢ΥϨοτ Blockch ain Node ೖग़ۚγεςϜ औҾγεςϜ ϗοτɾίʔϧυͷ ൿີ伴όοΫΞοϓ ① ② ③ ④ ϗοτ΢ΥϨοτ ③ Blockchain
21. 21 コールドウォレットは100％安全か？ ి࣓৴߸Ͱൿີ伴Λ౪Έग़͢BeatCoin https://www.youtube.com/watch?v=ddmHOvT866o
22. 22 カストディサービスの台頭により、コールドウォレット構築・保管 を預託する取引所も出てくると考えられる Coinbase Xapo Nomura
23. 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) ஥հऀ͕ೖΔࣄʹΑͬͯίετ͕૿େͯ͠͠·͏
24. 24 ハッキング事例から読み取るセキュリティポイント ü  ൿີ伴ͷอ؅ํ๏ɺೖग़ۚͷޡೝ͸ॏཁͳϙΠϯτ ü  ΦϖϨʔγϣϯϛεͰࢿ࢈͕ਧ͖ඈͿ͜ͱ΋͋ΔͷͰɺΦϖϨʔγϣϯϛεલఏ ͷӡ༻ΛઃܭʢAࣾͷΦϖϛεʣ ü  ͦ΋ͦ΋ϒϩοΫνΣʔϯ෦෼Ҏ֎Ͱ΋ී௨ʹγεςϜͷ੬ऑੑ਍அ΍ϖωτϨ ςετ͸࣮ࢪਪ঑ʢBࣾͷೖग़ۚ߈ܸʣ ü  ϋοΩϯάΛड͚ͨࡍͷϓϥϯΛࡦఆ͓ͯ͘͠ͱରԠ͕͠΍͍͢ɻิঈํ๏΍ؔ ܎ऀͷ࿈བྷઌɺτʔΫϯิঈͳͲ΋ࢹ໺͔ɻʢCࣾͷิঈํ๏ʣ ü  ͦͷଞɺϗοτ΢ΥϨοτ΁ͷอ؅ൺ཰ΛϦΧόϦՄೳֹʹઃఆ͓ͯ͘͜͠ͱ Ͱɺඃ֐Λ཈͑Δ͜ͱ͕Ͱ͖ΔʢશֹิঈͰ΋ཱͪ௚ΕΔέʔε͕͋Δʣ ü  ίʔϧυ΢ΥϨοτ͕100ˋ҆શͱ͸ࢥΘͳ͍ʢ಺෦ෆਖ਼ɺσόΠεܦ༝ͰͷϚ ϧ΢ΣΞײછͳͲʣ
25. 25 CryptoCurrency SecurityStandardから学べるブロッ クチェーンサービスのセキュリティ観点
26. 26 •  CryptoCurrency Certification Consortium(C4)という非営利団体が考案 •  C4のボードメンバーは、 •  Andreas M. Antonopoulos(Mastering Bitcoinの著者) •  Vitalik Buterin(Ethereum創始者) など •  ドラフトができたのが2015年、最後の更新 は2016年 •  現在も使いやすいところも多く、中央集権 性のある取引所には特に当てはまりやすい CryptoCurrency SecurityStandard（CCSS）では包括的なセキュリティ基 準の提案がされている https://cryptoconsortium.github.io/CCSS/
27. 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観点が掲載されており、鍵の生成から管理・破 棄までのライフサイクルをカバーしている
28. 28 •  Key / Seed Generation（鍵・シードの生成） ◦  秘密鍵やシード値がオペレーター自身で作成され たか ◦  秘密鍵の生成方法に脆弱性はないか ◦  鍵の生成方法がDRBG（決定論的乱数生成器）準 拠か ◦  生成時のランダム性エントロピーは十分か •  Wallet Creation（Walletの生成） ◦  トランザクションごとにユニークなアドレスを作成し ているか ◦  マルチシグを利用しているか ◦  鍵は冗長構成になっているか ◦  HD Walletを利用しているか ◦  鍵の保管場所は地理的に分散されているか（BCP 観点） ◦  鍵の保管は組織的に分散されているか（内部不正 対応） Cryptographic Asset Management （暗号資産の管理）では、秘密鍵生 成、管理、利用、破棄まで多くのチェック観点が示されている Cryptographic Asset Management ʢ҉߸ࢿ࢈ͷ؅ཧʣ 1/2 ・Key Storage（鍵の保管） ◦  暗号化されているか ◦  バックアップの秘密鍵はあるか ◦  バックアップの秘密鍵は物理的に安全な環境にあ るか ◦  バックアップの秘密鍵へのアクセスが制限されて いるか ◦  バックアップの秘密鍵は未開封シールで保護され ているか ◦  バックアップの秘密鍵は暗号化されているか
29. 29 • Key Usage（鍵の利用） •  鍵の利用時には複数の認証が設定されているか •  鍵の利用は信頼されたアクセス環境からのみに限 定されているか •  オペレーターの経歴チェックはしているか •  オペレーターの身元チェックはしているか •  オペレーターのバックグラウンドチェックはしている か •  署名前に送金内容をチェックしているか •  同じデバイスに複数の鍵を入れていないか •  署名時に入れる数値はDRBG準拠で生成されてい るか Cryptographic Asset Management （暗号資産の管理）では、秘密鍵生 成、管理、利用、破棄まで多くのチェック観点が示されている •  Key Compromise Protocol (KCP) （鍵の漏洩時 手順） •  漏洩時手順は作成されているか •  漏洩時手順は訓練とリハーサルされているか •  Keyholder Grant/Revoke Policies & Procedures（鍵保有者の権限付与/取消ポリシ ーと手続） •  権限付与/取消ポリシーは策定されているか •  信頼された経路で権限付与/取消はされるか Cryptographic Asset Management ʢ҉߸ࢿ࢈ͷ؅ཧʣ 2/2
30. 30 ◦  Security Audits / Pentests ʢηΩϡϦςΟ؂ࠪɾϖωτϨʔγϣϯςετʣ ◦  ֎෦ͷηΩϡϦςΟ؂͕ࠪʢఆظతʹʣ͞Ε͍ͯΔ͔ ◦  Data Sanitization Policy (DSP) ʢσʔλͷഁغϙϦγʔʣ ◦  σʔλͷഁغϙϦγʔ͕ࡦఆ͞Ε͍ͯΔ͔ ◦  σʔλഁغ࣌ʹ؂ࠪϩά͕࢒͍ͬͯΔ͔ ◦  Proof of Reserve (PoR) ʢ࢒ߴূ໌ʣ ◦  ࢒ߴূ໌ͷ؂ࠪ΋͘͠͸४ͣΔ΋ͷ͕࣮ࢪ͞Ε͍ͯΔ͔ ◦  Audit Logs ʢ؂ࠪূ੻ɺϩάʣ ◦  ΞϓϦέʔγϣϯͷ؂ࠪϩά͕͋Δ͔ ◦  ؂ࠪϩάͷόοΫΞοϓ͕͋Δ͔ Operations （オペレーション）についても言及している
31. 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 ʢ؂ࠪূ੻ɺϩάʣ
32. 32 CryptoCurrency SecurityStandard（CCSS）から読み取るセキュリティポ イント ü  ࠷ޙͷߋ৽͸2016೥͕ͩɺݱࡏ΋ར༻Ͱ͖Δ෦෼͸ଟ͍ ü  ͋Δఔ౓ͷ໢ཏײΛ͍࣋ͬͯΔͷͰɺηΩϡϦςΟΛߟ͑Δࡍͷࢀߟʹ ü  ஧࣮ʹै͏͜ͱ͕ݱ࣮తʹ೉͍͠؍఺͸ɺརศੑͱ֎ͯ͠͸͍͚ͳ͍ϙΠϯτͱ ͷόϥϯεΛݟͳ͕Βऔࣺબ୒ਪ঑ ü  ϗοτ΢ΥϨοτɺίʔϧυ΢ΥϨοτͷֹۚอ؅ൺ཰ͳͲ·Ͱ͸ݴٴ͍ͯ͠ͳ ͍ͷͰɺઐ໳ՈΛަ͑ͯ؍఺ͷ௥ՃͳͲ΋஫ҙ ü  ͜͜·Ͱ͘Δͱ݁ߏΞφϩά෦෼΋ॏཁʹͳΔ
33. 33 Ethereumスマートコントラクトのハッキング事 例からみるセキュリティポイント
34. 34 スマートコントラクトは、価値の移転をルールに従って起こす仕組 みである ޿͍ҙຯͰ͸ɺܖ໿ΛػցͰ࣮૷͢Δ࢓૊Έʢ˞ʣ
    ڱ͍ҙຯͰ͸ɺσδλϧʹදݱ͞ΕΔࢿ࢈Λ༧ΊఆΊΒΕͨϧʔϧʹैͬͯࣗಈతʹҠసͤ͞Δ࢓૊Έ
    Ethereumʹ͓͍ͯ͸… • ίʔυΛΞυϨεʹࡌͤͯϒϩ οΫνΣʔϯʹσϓϩΠ͢Δ • σϓϩΠ͞ΕͨίʔυΛϒϩο ΫνΣʔϯͱͯ͠ಈ͔͢ • ίʔυ͕ಈ͘͝ͱʹಈ͔͢ओମ ͷΨε͕ফඅ͞ΕΔ ੪౻
    
    ݡ࣐ࢯͷϒϩοΫνΣʔϯ࿈ଓߨٛ
    
    ୈճΑΓ
    IUUQTXXXESPQCPYDPNTSKCMSJIPHKJDK#D)TNBSUDPOUSBDUBQEG EM
    DEXͷྫ
35. 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ʣ લఏ
36. 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
37. Reentrancy Attackを防ぐためには、繰り返しに耐える処理を実装する 必要があった #Ϣʔβʔͷ࢒ߴா mapping (address => uint) private userBalances; #Ҿ͖ग़ؔ͠਺ function withdrawBalance() public { # Ҿ͖ग़͠Մೳֹۚͷऔಘ uint amountToWithdraw = userBalances[msg.sender]; #͜͜Λى఺ʹ߈ܸऀ͸FallbackΛ࣮ߦͯ͠Ҿ͖ग़͠ Λϧʔϓ࣮ߦ͢Δ require(msg.sender.call.value(amountToWithdraw)()); # Ϣʔβʔͷ࢒ߴாߋ৽Λߦ͏ userBalances[msg.sender] = 0; } Original DAOContract #Ϣʔβʔͷ࢒ߴா mapping (address => uint) private userBalances; #Ҿ͖ग़ؔ͠਺ function withdrawBalance() public { # Ҿ͖ग़͠Մೳֹۚͷऔಘ uint amountToWithdraw = userBalances[msg.sender]; # Ϣʔβʔͷ࢒ߴாߋ৽ΛɺҾ͖ग़͠લʹߦ͏ ͜ͱͰReentrancy߈ܸʹରԠ͢Δ userBalances[msg.sender] = 0; require(msg.sender.call.value(amountToWithdraw) ()); } Protected DAOContract 37
38. 38 Etherscanの攻撃トランザクション Beautychain Token(BEC)では、オーバーフローを利用した攻撃があり、 発行量以上の過剰な供給と引き出しが行われた https://etherscan.io/tx/ 0xad89ff16fd1ebe3a0a7cf4ed282302c06626c1af33221ebe0d3a470aba4a660f ڙڅྔ͕7000000000ͷ τʔΫϯʹରͯ͠ɺ 5789604461865809771 1785492504343953926 6349923328202820197 2879200395656481996 8τʔΫϯ͕2ͭͷΞυ ϨεʹҾ͖ग़͞Ε͍ͯ Δ
39. 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 トークンが引数のアドレスにそれぞれ 送られる
40. •  攻撃によるトークン供給量 (攻撃によるトークン供給量) / （単位補正※） =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
41. 攻撃を防ぐためにはオーバーフローを考慮した四則演算を行う必要 があった 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
42. 42 Ethereumスマートコントラクトのハッキング事例からみるセキュリテ ィポイント ü  ੬ऑੑͷ͋ΔίʔυΛΫϥοΩϯά͢Δ͜ͱͰෆਖ਼ͳࢿ࢈Ҡಈ͕Ͱ͖ͯ͠·͏έʔε ͕͋Δ ü  Ϣʔβʔͷൿີ伴Λ༬͔Βͳ͍ͱͯ͠΋ɺίʔυͷ҆શੑΛ୲อ͢Δඞཁ͕͋Δ ü  σϓϩΠͨ͠ίʔυ͸΄΅มߋͰ͖ͳ͍ͨΊɺࣦഊͰ͖ͳ͍ʢϒϩοΫνΣʔϯͷվ ͟ΜෆՄೳੑʣ ü  ίʔυ͸ϒϩοΫνΣʔϯ্ʹ͋Γɺ୭ʹͰ΋ݟΒΕͯ੬ऑੑΛ୳͠΍͍͢ʢϒϩο ΫνΣʔϯͷಁ໌ੑʣ ü  ಗ໊Ͱ௨՟͕खʹೖΔͨΊΫϥοΩϯάͷΠϯηϯςΟϒ΋ߴ͍ʢϒϩοΫνΣʔϯ ͷಗ໊ੑʣ
43. 43 スマートコントラクトの脆弱性を事前に発見 するために
44. 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 flow checking to detect a variety of security vulnerabilities. (READMEΑΓ) MythrilはEthereumスマートコントラクトのセキュリティ分析ツール。concolic analysisとテイ ント解析、制御フロー解析をセキュリティ脆弱性を発見するために利用している。
45. 45 例えばMythrilでOverflowAttackを受けたBECトークンのコントラクトを 解析すると、Integer OverflowのWarningが検知される
46. 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
47. 47 ü Mythrilの判断はコードを読む限り、EVM上で動くOPCODEから、脆弱性の可 能性があるものを幅広に出している ü False Positive / False Negativeもないとは言えなそうであり、Warningを見 て個別に確認する必要性がある ü そもそも未知の攻撃手法がある場合は検知不能 ü その他、現在oyenteやMAIANといった解析ツールもあり、複数ツールで試 行してみるのが良い Mythrilの判断基準は完全とまでは言えないものの、デプロイ前に診断 しておく事でセキュリティ向上に利用できる
48. 48 なお、Consensysによって公開されているsmart-contract-best-practices は、known attacksに攻撃事例が掲載されており、攻撃判定に役立つ
49. 49 本日はブロックチェーンサービスを運用する上で基本的なセキュリ ティポイントをご紹介しました 1.  औҾॴͷϋοΩϯάࣄྫ͔ΒηΩϡϦςΟͷϙΠϯτΛߟ͑Δ Ø 伴ͷอ؅ɺೖग़ۚ͸ΫϦςΟΧϧͳϙΠϯτ Ø γεςϜ၆ᛌ͢Δ͜ͱͰΠϯγσϯτͷϙΠϯτ͸ݟ͑Δ 2.  CryptoCurrency SecurityStandard͔Βֶ΂ΔϒϩοΫνΣʔϯαʔϏεͷ ηΩϡϦςΟ؍఺ Ø  伴ͷੜ੒ʙ࡟আ·ͰͷϥΠϑαΠΫϧɺΦϖϨʔγϣϯʹ͍ͭͯ໢ཏ ײ͕͋Δ Ø  νΣοΫϦετΛར༻͢Δ 3.  EthereumεϚʔτίϯτϥΫτͷϋοΩϯάࣄྫ͔ΒΈΔηΩϡϦςΟ ϙΠϯτ Ø σϓϩΠ͞Εͨίʔυ͸୭ʹͰ΋ݟΒΕͯ੬ऑੑΛ୳͠΍͍͢ Ø ࣄલʹݕ஌͢Δඞཁ͕͋Δ 4.  εϚʔτίϯτϥΫτͷ੬ऑੑΛࣄલʹൃݟ͢ΔͨΊʹ Ø ੬ऑੑ਍அπʔϧͷར༻ Ø աڈͷ߈ܸࣄྫͷऩू ·ͱΊ
50. 50 次回予告：9月26日（水）　セキュリティのイベント第２回をやりま す