ブロックチェーンのセキュリティ問題に対応して、Beosin (成都聯南) チームはスマート コントラクトのセキュリティ脆弱性を毎週分析してシリアル化し、プログラマーがより安全で強固なコントラクトを作成して問題が発生する前に防止できるようにしたいと考えています。
要約
要約
前の本では、EOS ゲームが繰り返し攻撃され、乱数の抜け穴が繰り返し禁止されました。
この号のトピックス
この号のトピックス
DAppの偽造通貨は誤解を招く、伝達関数の検出漏れはずさん
今年人気の国内映画といえば、チョウ・ユンファ監督の『武双』が外せないが、劇中の偽米ドル紙幣の製造技術は驚くべきもので、残酷な「紙幣レベルの欺瞞」も推理している。 。
副題
基礎知識への道を開く
EOS スマート コントラクトのアーキテクチャ
EOS スマート コントラクトは一連のアクションで構成されており、各アクションは契約条項を表し、条項内の特定のルールを実装します。 EOS スマート コントラクトの実行は、作成、デプロイ、呼び出しの 3 つの部分に分かれています。
このうち、スマート コントラクトをデプロイするステップでは、各 EOS スマート コントラクトは、アクション要求を特定の処理関数にマッピングするために使用される apply() 関数を実装する必要があります。特定の実装の詳細は、EOSIO_ABI マクロにカプセル化されています。この設計により、開発者は基盤となるテクノロジに注意を払うことなく、ビジネス ロジックの開発のみに集中できるため、開発が簡素化されます。適用関数の例:
偽の EOS 転送攻撃
歴史上の出来事:
有名な EOSBet は 9 月 12 日に約 42,000 EOS を失い、これをきっかけに偽の EOS トークンを使用して攻撃するハッカーが急増し、続いて eoswindice と分散型取引所 newdex が続きましたが、これらはすべてハッカーに成り下がりました。
攻撃分析:
EOS チェーン上の共通トークンは、EOSIO によってデプロイされた eosio.token コントラクトによって生成される EOS トークンですが、eosio.token コードはオープンソースであり、どの eos アカウントでも eosio.token コントラクトを独自にデプロイし、これは EOS のトークンであり、図に示すように、価値のない偽の EOS が多数確認できます。
EOS の信頼性を識別するにはどうすればよいですか?お金探知機?もちろんそうではなく、トークンのフルネームが eosflare ブラウザに表示されます。本物の EOS と偽の EOS のフルネームには違いがあります。
写真から、1 つは EOS であり、その背後に他の説明はありません。もう 1 つは、refundwallet の偽 EOS (refundwallet) であることがわかります。
ブラウザではトランザクションの詳細を見て、トランザクションに使用されたEOSトークンが真であるか偽であるかを判断できますが、それがスマートコントラクトに配置されている場合はどうなるでしょうか?
たとえば、契約書の例は次のとおりです。
void transfer(const account_name& from,
const account_name& to,
const asset& quantity,
const string& memo)`
これはコールバックを受信するために使用される関数であり、偽の EOS が渡された場合、関数は真正性を区別する方法がありません。適用時に EOS が事前に検出されなかった場合、コントラクトは偽の EOS を受け取り、通常のビジネス ロジックを実行します。悪意のあるアカウントが EOS トークンを発行するコントラクトを展開すると、手ぶらの白いオオカミを実現し、偽の紙幣を本物のお金に交換することができます。
バグの修正：
EOSの発行者がeosioであることを検証するには、apply()に判定用のコード == eosio.token を追加する必要があります。
副題
バリアント 1: 伝達関数に対する直接呼び出し攻撃
脆弱性分析:
上記の脆弱性修復方法に従って適切な判断を追加した後、多くのプロジェクト関係者は安堵のため息をつきましたが、EOSBet事件の原因となった脆弱性コードはそう簡単には修正されませんでした。上記の apply を使用してコード呼び出しを検出する場合、検出条件が次の場合のみ、別のバイパス状況が発生するためです。
if( code == self || code==N(eosio.token) ||action == N(onerror))
この場合、この検出条件は、関数自身のアクションの呼び出しと、eosio.token からのアクションの呼び出しの 2 つの検出のみを処理します。検証なしの転送アクションの呼び出し元は、eosio.token またはその独自のコントラクトである必要があります。
これにより、契約口座に直接電話して送金することができます。
たとえば、ユーザー A は最初に 1 EOS をユーザー B に転送するために eosio.token を呼び出し、その後、eosio.token が転送レシートを送信してコントラクト B の転送関数を呼び出してビジネス ロジックを実行しました。これで、コントラクト B の転送関数は次のようになります。 toやvalueなどのパラメータを正しく設定することで、送金せずにBコントラクトのビジネスロジックを直接実行できます。したがって、EOSBet を攻撃した攻撃者は、eosio.token->transfer 関数を完全にバイパスし、正しいパラメータで eosbetdice11->transfer を直接呼び出し、EOS をコントラクトに転送せずにコントラクトのビジネス ロジックを実行しました。
バグの修正：
このタイプの攻撃に対する防御方法は、アクションとコードを同時に検出することです。
副題
if (code == N(eosio.token) && action == N(transfer))
{ }
バリアント 2 EOS 偽のレシート攻撃
歴史上の出来事:
9月14日の事件後、EOSBetも公式声明を発表し、コードのセキュリティを重視していると述べた。
しかし、わずか 1 か月後の 10 月 15 日、EOSBet は再びハッキングされ、140,000 EOS 近くを失いました。
脆弱性分析:
この脆弱性の理由は、スマート コントラクト処理ロジックの転送機能に to 判定が欠如していることです。to 判定が欠落している場合、コントラクトは転送を受け取ったのが自分自身であるかどうかを判断できず、実行を続ける可能性があります。攻撃者が 2 つのアカウント AB を持ち、c がゲーム コントラクト アカウントであると仮定すると、攻撃者はアカウント A を通じて eosio.token を呼び出して EOS をアカウント B に転送し、アカウント A または B にコントラクトをデプロイできます。そしてコールバック transfer で require_recipient(N(XXXXXX) を再度呼び出します); code==N(eosio.token)&&action==transfer の検証をバイパスできるように、転送通知をゲーム コントラクト C アカウントに送信します。ビジネスロジックを実行できるようになります。
バグの修正：
void transfer(const account_name& from,
const account_name& to,
const asset& quantity,
const string& memo) {
副題
return;
}
コードのセキュリティは白黒はっきりする
一連のセキュリティインシデントとコード修復の後、攻撃を受けたゲーム公式は、ついに一見信じられないような抜け穴を解決した。ブロックチェーンのセキュリティは非常に厳密で価値のあるテクノロジーであることがわかり、過去 2 年間の浮き沈みにより、ブロックチェーンのセキュリティは非常に重いテーマになっています。 「呉双」に「白か黒しか見えない人は常に敗者だ」という一文がありますが、この文はブロックチェーンの分野には当てはまりません。信じられないなら、この物語の主人公の結末を見てください。映画。
引用：
引用：
[1]: 偽EOS攻撃によるアップグレード再び：EOSCastがハッカー「偽EOS転送亜種」に攻撃され、6万EOS以上を失った；
[2]: BETがハッカーに襲われる一部始終、本物のハンマーが犯行現場と攻撃方法を復元；
[3]: ショック！ EOSBetが再び攻撃されました。損失は500万にも上った。これが攻撃方法ですか？；
IOS
Android