スマートコントラクトとは
・ブロックチェーンであらかじめ設定されたルールに従って、トランザクション（取引）などを自動的に実行するプログラムです。
・主の開発言語は Solidity（Ethereum）
スマートコントラクトセキュリティ
・ブロックチェーン自体は安全だが、アプリケーションはそうではない。
・仮想通貨を扱っているため、脆弱性によって多くの財産の損失になる可能性がある。
・言語の特性上、デプロイすると修正できなくなるので。より気を付ける必要がある。
・コードを公開する場合が多い、多くの人がソースを見えることができる。
過去事例
TheDAO事件 リエントラント攻撃 約 52億円 損失
ParityWallet事件 アクセス修飾子脆弱性 約 3000万ドル 損失
EOS.WIN事件 ランダム数予測攻撃 約 10万ドル 損失
本編を読む前、見たほうがよい予備知識
Solidity言語 勉強サイト CryptoZombies
ブロックチェーンとは
スマートコントラクトとは何ですか？
本編
警告
本文で展示しているサンプルコードは、あくまでセキュリティを理解するため、勉強用のサンプルです。
悪用などしないでください。
よくある攻撃手段と事例（一部）
リエントラント攻撃
本来であれば、関数を一度実行すると中断することなく上から下まで実行されます。
脆弱性を利用して、関数の実行が途中で中断し、任意の処理を差し込めるようになります。
任意の処理なので、同じ関数をもう一度実行可能です。
その場合、実行中断中にもう一度頭から再実行されることになります。
サービス拒否攻撃
脆弱性を利用して、スマートコントラクトを機能させなくする攻撃手段。
ランダム数予測攻撃
ランダム数生成アルゴリズムを知った上で、ランダム数の結果を予測する
アクセス修飾子脆弱性
正しくないアクセス修飾子を利用する原因で外部から送金などの関数実行される
リエントラント攻撃
今回例になるスマコン
銀行みたい、入金出金の機能。１回は１Ether以上の入出金制限、ロジック自体問題なさそうですか....
今回攻撃用のスマコン
注目のところは「fallback」関数
説明
fallback関数は このスマコンが Receive 時呼び出しする
-
etherを入金し、bankのwithdraw関数を呼び出しする（出金操作）
-
Bankスマコンのwithdraw関数を実行
-
出金する人が1 ether以上持つことを確認し、出金操作を実行する
-
Attackスマコンのfallback関数を呼び出し、bankスマコンのwithdrawを呼び出し
-
withdrawを再呼び出し、残高を減らす処理が実行されなかった。
AttackスマコンはBankスマコンで持っている1 Etherが減っていないため、Bankスマコンの残高が無くなるまで出金することができる。
攻撃前:
Bank: 10 ether
Attack : 1 ether
攻撃後:
Bank: 0 ether
Attack : 11 ether
リエントラント攻撃 - 結果
損失：
直接の財産損失
対策：
・検査 -> 有効 -> 実行の手順で書く （今回の修正例）
・send、callではなくtransfer関数を使う （gasが足りなくなって、リエントラントができなくなる）
サービス拒否攻撃
今回例になるスマコン
シンプルのオークション機能
現在価格より上回る場合は最高入札者になる。
今回攻撃用のスマコン
注目のところは「Receive」関数がないこと
つまり「受け取る」ことができません
説明
攻撃用スマコンを使って、Auctionスマコンのbid関数を呼び出し
１回目は最高入札者がいないため正常実行。
攻撃スマコンもう一回使って、Auctionスマコンのbid関数を呼び出し
攻撃スマコンは返金を Receive(受け取る) ことができませんので、payableのところまで実行するとサービス拒否になる。
ここまで、このスマコンはもう使うことができない（攻撃者より上回ることができない）
サービス拒否攻撃 - 結果
損失：
・スマコンが使えなくなります。
・スマコン内の残高が取れなくなる事例もあります。
対策：
・今回の例限りなく、いろんなところで発生する可能性があります(ガス代設定していない外部呼び出し、配列長さ長すぎるなどなど色々な原因)
・今回の例は、払い戻しの処理を別関数にして、解決できます。（ただし払い戻しの処理はまだ別のところで呼び出しする必要がある）
サービス拒否攻撃 ー 対策修正例
・bidから払い戻しの処理を外す
・withdrawという払い戻しの別関数追加
・アプリ側で適切なタイミングでwithdrawを呼び出し、前の最高入札者へ払い戻し
ランダム数予測攻撃
今回例になるスマコン
数字を予測するゲーム、奇数の場合当たると判定、偶数なら当たらないと判定。
ブロック難易度＋タイムスタンプのハッシュ値でランダム数生成する、一見ランダム性があって、安全な感じですか...
今回攻撃用のスマコン
ランダム数を先に予測し、勝つ結果だけguess関数を呼び出し、二つのスマコンとも同じブロックで実行されるので、取れたブロック難易度とタイムスタンプは同じになる。
これによって、事前予測ができるようになる。
説明
ブロック難易度＋タイムスタンプのハッシュ値でランダム数生成、ランダム性はありますか、実際は予測される可能性がある
サービス拒否攻撃 - 結果
損失
・ロジックによって、スマコン内の残高が取られる可能性があります
対策
・より安全なランダム数生成方法を使う
・ランダム数生成のサービスなどを使う
アクセス修飾子脆弱性
今回例になるスマコン
関数内の処理は省略します。
問題のところは簡単で、_transferのところ、本来privateの方が正しいのだが、publicになっている。これによって外部から呼び出しができ、お金が取られる。
アクセス修飾子脆弱性
損失
Transferなど、本来外部呼び出ししちゃいけない関数を呼び出しされて。財産の損失になる。
対策
正しいアクセス修飾子を使うこと