注意深い！イーサリアムDeFiが認証を悪用、ウォレットが盗まれる恐れ

出典: Bitpie Security Lab 原題: Ethereum DeFi エコシステムにおける最大のセキュリティリスク

DeFi は非常に人気があり、Compound は非常に人気があり、業界はこのエコシステムに熱心に参加しているようです。革新、革命、そして中央集権化の終焉の日がもうすぐ来るようです。

オラクル、スマート コントラクト ウォレット、分散型融資、分散型取引、分散型などなど…

ブロックチェーン業界の多くの実践者は、DeFiの黄金の建物が基本的に完成したと楽観的に信じ始めています。

01

しかし、DeFiの晴れた空には、まだいくつかの不穏な暗雲が漂っています。

2020年4月18日、Uniswapはスマートコントラクトの脆弱性を露呈し、それが悪用されて数十万ドル相当の資産が盗まれました。

2020年4月19日、Lendf.meは同じ脆弱性により、プログラマー（ハッカーではない）によって数千万ドルの資産を盗まれました。

これら 2 つの事件は業界に波紋を呼び、特に Lendf.me の盗難は幅広い議論を引き起こしました。

「誰が責任を負うべきなのか？」

「地方分権化後は、問題が起きた時に誰に連絡すればいいのか分かりにくくなるようですね？」

「DeFiの後は、コインを失ったことによるすべての結果をユーザーが負担しなければならないということでしょうか？」

幸いなことに、Lendf.me を盗んだ人物はプロのハッカーではなく、ただの普通のプログラマーでした。彼は自分の居場所をよりうまく隠す方法を知らなかったのです。 IP が漏洩し、さらに所在が特定されたため、プログラマーは法的処罰を回避するために資産を返還するしか選択肢がありませんでした。

この点では、Lendf.me のプロジェクト所有者とユーザーは非常に幸運であると言えます。彼らは巨額の資産損失と長期にわたる法的手続きのリスクを回避した。業界の観点から言えば、お金が戻ってくるのは間違いなく良いことです。しかし、良いことは良いことであり、DeFi エコシステムにかかる暗雲はまだ消えていない。 DeFi の将来はまだ安全でしょうか?

02

スマートコントラクトのセキュリティに関しては、歴史上多くの事故が発生しています。この暗雲は常に存在しており、これは業界が今後も直面し続ける必要があるリスクと課題でもあります。

しかし、今日私たちが皆さんにお話ししたいのは、もう一つの暗雲についてです。セキュリティの観点から見ると、もう 1 つのダーク クラウドの複雑さははるかに低いですが、その影響はより広範囲に及び、DeFi に関わるほぼすべてのユーザーに影響を及ぼします。

その影響は明らかに深刻ですが、業界のユーザーや実務者からは無視されてきました。この暗雲は、ダモクレスの剣のように DeFi の上に垂れ込めています。あなたがそれを無視するかどうかに関わらず、それは常にそこにいて、あなたを静かに見守り、一口で飲み込む機会を待っています。

本日は、このダーククラウドについて体系的にご説明し、このダーククラウドが一般ユーザーにもたらす可能性のある資産セキュリティリスクを示す完全なスマートコントラクトの事例も紹介します。この記事を通じて、ユーザーは、イーサリアムの DeFi エコシステムに参加する場合、不注意な操作によってもたらされるリスクの多くはそれほど単純ではなく、関連するリスクが非常に大きく、上限がない可能性があることを明確に認識できると思います。

議論を始める前に、質問させてください。

100 万の Ethereum ベースの USDT を所有しており、そのうち 10,000 を中央集権型取引所に転送することにしたとします。何か問題が発生した場合（たとえば、取引所がハッキングされたり、取引所の所有者が逃げたりするなど）、リスクの限度はいくらですか？

答えは簡単です。リスクは入金した 10,000 USDT だけです。残りの990,000はすべてあなたのウォレットにあります。ハッカーも取引所の所有者もこのお金で何もすることができません。彼らが盗めるのは10,000ドルだけです。

さて、同じシナリオをDeFiに当てはめてみましょう。

あるいは、100 万 USDT を所有していて、そのうち 10,000 USDT を分散型 DeFi 契約に入金することにしたとします。何か問題が発生した場合（DeFi スマート コントラクト/プロジェクトがハッキングされたり、DeFi のボスが逃げ出したりした場合）、リスクの限度はいくらですか?

まだ10,000ですか？間違っている！現在のリスク制限は 100 万 USDT になる可能性があります。残りの 990,000 USDT がまだウォレット内に静かに眠っていて、これらの USDT をインターネットに接続せず絶対に安全なハードウェア コールド ウォレットに慎重に保管できたとしても、あなたの 100 万ドルの資産は一瞬にして消失してしまう可能性が非常に高いのです。

なぜこのようなことが起こるのでしょうか?その理由は、Ethereum エコシステムの最も基本的な認証モデルにあります。

スマート コントラクトにアクセスすると、スマート コントラクトは「資産をより便利に操作する」ために承認を求める場合があります。この承認呼び出しはどのようになっているのでしょうか?

次に、チェーンからの承認トランザクションを見てみましょう。

出典: etherscan.io

この取引は非常に簡単です。実際、アドレス[0x3693]は、[Uniswap V2: Router 2]コントラクトがそのUSDTをすべて無制限に使用することを許可します。

では、これを行うことでどのようなメリットがあるのでしょうか?

この承認操作を完了すると、Uniswap はその後の呼び出しや訪問回数を減らして、資産を簡単に操作できるようになります。一部の契約では、Ethereum のマイニング手数料の交換にも役立ちます。つまり、マイニング手数料として ETH がない場合でも、この契約を呼び出すことができます。

この認証方法の利点は、実は利便性（主にプロジェクト関係者にとって）です。コインを送金するために財布を開く必要さえないのでとても便利です。

「何？ウォレットを開かずにコインを転送できるの？誰が私のコインを転送できるの？」

これが問題です。一度承認すると、契約はあなたの許可なくすべての資産を制御できるようになります。覚えておいてください、これは秘密鍵がどのように保存されるかとは関係ありません。秘密鍵をハードウェアのコールドウォレットに保存し、冷蔵庫で冷凍したとしても、この契約によりすべてのコインが消失する可能性があります。

さて、契約によってコインを転送できるとしても、スマート コントラクト コードがオープン ソースであり、第三者によって監査されていて、コインを転送するコードがない場合は、安全なのだろうか、と言う人もいるかもしれません。

実際、契約承認に関連するセキュリティは、それがオープンソースであるかどうか、または第三者によって監査されているかどうかとはほとんど関係ありません。現在、DeFi エコシステム内の複雑なスマート コントラクトのほとんど (基本的にすべて) は、コードをアップグレードできます。つまり、今日のコードではコインを転送できないかもしれませんが、明日は所有者が悪意を持ってコードを更新し、コインをすべて消去する可能性があります。

（ここで注意すべき点は、コントラクトコードのアップグレード後にコントラクトアドレスが変更されることです。そのため、オーナーがコインを転送したい場合は、再度承認する必要があります。ただし、各DeFiプロジェクトと各ウォレットソフトウェアでの承認操作はワンクリックで完了するため、コントラクトオーナーがコードのバージョンをいくつ変更しても、ユーザーは実際には注意を払いません。そのため、一般ユーザーは依然として同じリスクに直面しています。）

承認トランザクションの例を確認した後、契約のサンプル コードを確認しましょう。

https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/contracts/ExchangeDemo.sol

この例では、スマート コントラクトの脆弱性をシミュレートします。契約開発者が誤って ExchangeDemo 契約の転送メソッドのアクセス制御権限を public に設定したとします。この場合、契約を承認している限り、契約に対して転送操作を実行していなくても、他の人はウォレット内のすべてのトークンを直接転送できます。とても簡単です。

もちろん、現実の契約の脆弱性は複雑で、さまざまな形で現れる可能性がありますが、ここで指摘したいのは、契約に誤って第三者が承認者の資産を使用できるようにする脆弱性が含まれていた場合、契約自体が破壊されるだけでなく、契約を承認したすべての人の資産が盗まれるということです。

承認された資産を移転できる抜け穴をなぜ作らないのかと言う人もいるかもしれません。

これは理にかなっていますが、実際にはほとんど不可能です。イーサリアムの歴史上、数え切れないほどの脆弱性がこの点を証明してきましたが、そのほとんどは契約内の資産や契約の実行方法にのみ影響を与えるのに対し、認証関連の脆弱性は、それを承認したすべての人のすべての資産のセキュリティを危険にさらします。どれだけのリスクを負っているかお分かりいただけたでしょうか?

次のサンプルコードを続けましょう。

https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/contracts/ExchangeDemoV2.sol

この例では、契約開発者が ExchangeDemo 契約をアップグレードしました。アップグレード前のクレーム方式では、契約上のトークン残高の引き出ししかできませんでしたが、開発者はユーザーが承認したトークンを譲渡できるように修正しました。つまり、アップデート後、ユーザーが認証操作を実行すると、開発者は簡単にクレームメソッドを呼び出して、ユーザーのウォレット内のコインを転送できるようになります。とても簡単です。

上記の例の完全なテストケースとコードは以下にあります。

https://github.com/bitpie-wallet/erc20-approve-issue-demo/blob/master/test/ExchangeDemo.test.js

ウェブサイトでご覧いただけます。興味のある学生はぜひ試してみてください。

ExchangeDemo V1 および V2 のスマート コントラクト サンプルから、権限の乱用により、ユーザーがコントラクトに資産を転送していないか、転送した資産が少量であっても、コントラクトに権限のある転送に関連する脆弱性がある場合、すべての権限のあるユーザーのウォレット内の資産が危険にさらされることがわかります。抜け穴がない場合でも、契約開発者はコードを更新した後、承認されたユーザーのウォレット内のすべての資産を奪う権限を持ちます。

ここでさらに一歩進むことができます。無制限の権限を求める契約の目的は、明らかにあなたの資産の操作を容易にすることです。契約自体の機能は、もちろん、資産の操作に関係します。取引、融資、財務管理など、資産を操作する必要があります。

したがって、契約自体には、少なくとも通貨送金操作に関連するインターフェースが含まれます。もちろん、これらの通貨送金操作は機能します。たとえば、抵当目的で 50,000 USDT が契約アドレスに預け入れられるか、償還目的で 1,000 USDT が契約アドレスに預け入れられます。ここで問題となるのは、コントラクト自体にそのようなインターフェースがあるため、コントラクトの所有者が (コントラクト コードの記述方法に応じて) ユーザーの許可なく同じ呼び出しを引き続き使用して、コントラクトにさらに多くの資産を預け入れることができる可能性があることです。つまり、コードがアップグレードされていない場合や関連する脆弱性がない場合でも、特に Ethereum のマイニング料金を支払ってくれるコントラクトの場合、この可能性は依然として存在し、呼び出しの開始レビューさえもコントラクト所有者の責任になる可能性があることを意味します。

つまり、スマートコントラクトに、あなたの承認後に 1,000 元を契約アドレスに送金する方法がある場合、当然、同じ方法を使用して 1 万元、10 万元、または 100 万元を送金することもできます。契約アドレスまたはその他の関連アドレスに転送した後、契約所有者は実際にこれらの資産を持ち去る権限を持ちます。

ここで指摘しておくべきことは、0x のような契約ではこの点に関していくつかの予防措置が講じられているということです。インターフェイスを呼び出すときにユーザーの署名を検証します。つまり、少なくとも呼び出し操作がユーザーによって開始されたことを確認できます。しかし、これは実際には契約コードの記述方法によって異なります。契約コードは、ユーザーの署名または契約所有者の署名を検証できます。もちろん、何も検証しないこともできます。コントラクト メソッドは、ユーザーまたはコントラクト所有者によって呼び出されることもできます。異なる書き込み方法により、ウォレット内のコインを管理する役割が異なります。怖くないですか？

スマートコントラクトの所有者が悪事を働かなければ、この問題は起こらない、そう言う人もいるかもしれません。

ここで一つ説明しなければならないことがあります。

分散化で最初にやらなければならないことは、第三者の信頼の必要性を排除することです。分散型プロジェクトで契約所有者を信頼する必要がある場合、分散化の意味は何でしょうか?

さらに、もっと重要なのは、当初は、契約所有者の資産への影響は、取引のために dex に送金した通貨や、財務管理のために分散型貸付契約に送金した通貨など、スマート コントラクトに参加した部分に限定されていると考えていたことです。契約所有者は預けた資産の一部にしか影響を与えられないと考えていました。これで、契約所有者がこの部分だけでなく他の部分にも影響を与えることができることがおわかりいただけたと思います。彼はあなたのウォレットに残っている資産にも影響を与える可能性があります。あなたの財布が熱くても冷たくても、それは問題ではありません。すべて私のものになります。

そして、契約所有者が道徳的に完璧な人物であると仮定したとしても、スマートコントラクトがますます複雑になるにつれて、脆弱性のリスクが増加することが知られています。これまでの理解では、抜け穴が発生した場合、主な資産リスクは依然として契約内にあり、攻撃者はせいぜい契約内にあるすべてのコインを奪い取ることができると考える人がほとんどでしょう。しかし、この記事の例は、契約の脆弱性が承認された転送に関連している場合、リスクが拡大するという事実を物語っています。これまでに契約を承認したすべてのアドレスが消去されます。攻撃者は、どのアドレスが認証操作を実行したかをスキャンし、それらのアドレス上のコインを 1 つずつ転送するだけで済みます。

さらに重要なことは、スマート コントラクト開発者がオーナー キーを安全に保持する方法に対する要求も高くなることです。ある日、オーナーキーを紛失した場合、契約内のコインだけでなく、承認されたすべてのユーザーのウォレット内のすべての資産が失われます。誰がこれを買う余裕があるでしょうか?

03

イーサリアムエコシステムにおける権限の乱用は非常に深刻なレベルに達しているため、ほぼすべての DeFi 契約が制限なく無制限の権限を求めていると言っても過言ではありません。この場合、モルモットとしてさまざまな DeFi プロジェクトを実験してみることは何ら問題ありません。しかし、あなたが負うリスクは、DeFi に参加するために使用するコインだけではなく、あなたの資産すべてであると言ったら、どう感じるでしょうか?

ブロックチェーン業界では、イーサリアムエコシステムにおける権限の乱用に関していくつかの声が上がっていますが、実際のところ、それは十分ではありません。開発者、実践者、ユーザー、その他のグループを問わず、99.9% の人々はそれについて何も知りません。権限の乱用がほとんどすべてです。この状況を変える時が来ました。

ここでは、（無制限の）権限を悪用するプロジェクトの例をいくつか挙げます。

複合

ユニスワップ

カイバー

メーカー

0x

バランサー

DX

イーサデルタ

IDEX

imToken トークンロン

上記のリストの最初のいくつかのプロジェクト、たとえば Compound、Uniswap、Kyber などは、現在の DeFi の世界で最も注目されているスター プロジェクトですが、これらのプロジェクトはすべて、ユーザーが無制限の権限を付与してユーザーの資産を完全に制御できるようにすることを選択しています。つまり、上記のプロジェクトを使用している限り、ウォレット内のコインはいつでもこの記事で述べたリスクに直面する可能性があり、これは実に残念なことです。

無制限の権限を持つアドレスの一部をスクリーニングしたところ、そのほとんどにまだ資産があることがわかりました。彼らの多くは、数百万ドル、数千万ドル、あるいは数億ドル相当の資産を保有しています。これらのアドレスの所有者は、実際には知らないうちに資産の管理権を他人に譲渡しています。

上記の契約では、認証コードを調整し、オンデマンド認証に変更する必要があります。たとえば、1,000 USDT のみを交換する必要がある場合、1,000 USDT のみが承認されます。追加の許可は無許可行為となります。

これらの契約を使用するユーザーは、DeFi 契約の使用行動も変更し、資産のセキュリティを保護するために、DeFi に参加しないコインをどのアプリケーションにも承認されない別のアドレスに置く必要があります。

Ethereum エコシステムは急速に進化しているため、Bitpie に Ethereum セキュリティ センターを設計しました。 Ethereum システムに切り替えると、Ethereum セキュリティ センターに契約承認検出機能が開発されていることがわかります。 Bitpie のアドレスに認証の不正使用がないかどうかを確認するだけでなく、外部アドレスの現在の認証ステータスも確認できます。不正使用された承認については、承認回復操作を実行することもできます。

Bitpie の契約検出機能に関しては、使い方をガイドする特別な記事を書く予定です。あなたの住所は安全ですか?試してみればわかります。

権限の乱用が広まっているという点について言えば、Bitpie はこれに関してどのような対応をしているのでしょうか?

Bitpie ウォレットでよく使用されるバッチ転送機能を例にとると、私たちのアプローチは限定的な承認です。つまり、100 USDT を 50 のアドレスに転送する必要がある場合、Bitpie は 100 USDT のみを承認し、追加の承認は生成しません。

例えば、Bitpie の USDT マイニング手数料の支払い機能では、契約認証を一切使用しませんでした。承認を使用して実装する方が明らかに簡単ですが、私たちはそうしませんでした。実際、プロジェクト側はユーザーの権利と利益を最優先に考え、ユーザーのリスクを増大させるような行為には抵抗すべきであるのはこのためです。

04

この暗雲の下にあるセキュリティを考慮すると、一般ユーザーはDeFiに参加する際にどのような予防策を講じるべきでしょうか?

1. Bitpie などのウォレットに用意されている承認スキャン機能を定期的に使用して、どの契約が承認（無制限の承認）を取得しているかを確認します。

2.複数のイーサリアムアドレスを使用して、コイン保管アドレスとDeFi参加アドレスを分離し、DeFi活動にのみ使用するコインをDeFiアドレスに入れます。このようにして、たとえ空が暗くても、コイン保管アドレス内のコインは安全です。

3. リスクを軽減するために、一部のアプリケーションの承認を取り消します。少なくとも、どのアプリケーションがあなたの許可なくウォレット内のコインを直接転送できるかを知っておく必要があります。

4. プロジェクト関係者に、認可を乱用せず、要求に応じて認可してユーザーのセキュリティリスクを軽減するよう求めます。

05

分散型金融は未来を象徴しており、ブロックチェーン技術の非常に重要な応用シナリオでもあります。

しかし、私たちを結びつけているのは、決して驚異的な概念でも、深遠で難解な規範でも、高度な技術でもなく、常に私有財産は神聖で侵すことのできないものであるという信念なのです。

雲が晴れて太陽が輝くまで、私たちを動かし続けることができるのは、それだけです。