Cobo Labs：暗号業界の1月の典型的なセキュリティ事件を振り返る

著者：Cobo Labs

この記事はCoboブロックチェーンセキュリティ研究チームによって提供されており、チームメンバーは著名なセキュリティラボ出身で、数年のネットワークセキュリティおよび脆弱性発掘の経験を持ち、GoogleやMicrosoftの高危険脆弱性の処理を支援し、GoogleやMicrosoftなどの企業から感謝を受けたことがあります。また、Microsoft MSRCの最も価値のあるセキュリティ研究者Topリストで優れた成績を収めています。チームは現在、スマートコントラクトのセキュリティ、DeFiのセキュリティなどに重点を置き、最前線のブロックチェーンセキュリティ技術を研究し共有しています。

クロスチェーンブリッジ Multichain 脆弱性

1月18日、著名なクロスチェーンブリッジMultichain（旧Anyswap）がWETH、PERI、OMT、WBNB、MATIC、AVAXの6種類のトークンに重大な影響を与える脆弱性を発見し修正しました。Multichain Routerに対して上記のトークンを承認したユーザーはすべて影響を受け、攻撃者は脆弱性を利用してユーザーが承認したトークンを直接転送することができます。19日の公式発表によると、一部のユーザーが承認を即座に取り消さなかったため、約445 WETHが攻撃者に盗まれました。

脆弱性はAnyswapV4RouterコントラクトのanySwapOutUnderlyingWithPermit関数に存在し、関数がTokenパラメータの合法性を検証していないため、攻撃者は偽造したTokenコントラクトを渡して本来の公式AnyswapV1ERC20 Tokenを置き換えることができます。

一方、WETHなどのトークンコントラクトはpermitメソッドを実装していませんが、fallback関数を実装しているため、その後permitを呼び出す際にrevertが発生せず、成功裏に実行され続けます。最終的に、攻撃者は被害者がAnyswapV4Routerコントラクトに承認したTokenを盗むことができます。

Cobo コメント

一般ユーザーは、Tokenの無限承認（ERC20 Infinite Approval）がもたらすリスクに特に注意する必要があります。承認は可能な限り使用するTokenの数量だけを承認し、デフォルトの無限承認を使用しないようにして、ガスを節約する代わりに元本を失わないようにしましょう。既存の無限承認は速やかに取り消し、アカウントの承認状況を確認するにはEtherscanのツール https://etherscan.io/tokenapprovalchecker を使用できます。

参考文献

https://github.com/W2Ning/AnyswapVulPoc

https://theblockbeats.info/news/28774

https://hackernoon.com/erc20-infinite-approval-a-battle-between-convenience-and-security-lk60350r

BSC上のDEX Crosswiseが攻撃を受ける

1月18日、BSC上のDEXプロジェクトCrosswiseが攻撃を受け、約30万ドルの損失を被り、CRSS Tokenの価格が急落しました。

問題は、MasterChefコントラクトのsetTrustedForwarder関数が正しく権限検証を行っていなかったことです。攻撃者がTrustedForwarderを変更すると、msg.senderを偽造することができ、MasterChefのオーナー権限を直接取得できます。その後、オーナー権限を利用してset関数を呼び出し、strategyを攻撃者の悪意のあるパラメータ0xccddce9f0e241a5ea0e76465c59e9f0c41727003に設定します。strategyを変更した後、少量のdepositで大量のCRSS Tokenを引き出して利益を得ることができます。

公式発表でもこの脆弱性があまりにも明白であり、開発者が意図的に行ったように見えると認めています。内部調査の結果、4人の開発者が解雇されました。現在、オンチェーンデータのスナップショットが行われ、今後再展開が行われる予定です。公式Gitでは全体のコード監査が開始されており、今後Certikと共同で監査を行う予定です。

Cobo コメント

今回の攻撃はMasterChefコントラクトを対象としており、実際にユーザーのLPやCRSSトークンを直接盗むことはありませんが、価格の急落はCRSSを保有するユーザーに実際の損失をもたらします。公式ドキュメントではプロジェクトの監査報告書を見つけることができず、この脆弱性はかなり明白です。もしセキュリティ会社による監査が行われていれば、高い確率で露呈していたでしょう。個人投資家にとって、監査を受けていないプロジェクトには慎重になる必要があります。

参考文献

https://twitter.com/peckshield/status/1483340900398895105

https://crosswise.medium.com/post-exploit-update-2a24c3370466

https://bscscan.com/address/0x70873211cb64c1d4ec027ea63a399a7d07c4085b#code

https://github.com/crosswise-finance/crosswise-code-review-1.1

Rari #90、すなわちFloat Protocol Poolがオラクル操作攻撃を受ける

1月15日、RariCapitalの90号プール、すなわちFloat Protocolプールがオラクル操作攻撃を受けました。

このプールはUniswap V3 FLOAT/USDC取引ペアの価格を使用していますが、攻撃が発生する数日前にFLOAT/USDCプールの流動性が低下（約\$550kしか残っていない）し、低流動性が攻撃者にオラクル操作攻撃を行う機会を与えました。

攻撃者は47 ETH（約\$120k相当）を使用してプール内でUSDCをFLOATに交換し、FLOATの価格を引き上げました。その後、FLOATをRari #90プールに担保として預け入れ、他の資産を借りて利益を得ました。攻撃手法は2021年11月に発生したRari #23プールVesper Lend Beta攻撃と一致しています。

Cobo コメント

ChainLinkオラクル価格を使用できない小規模なトークンに対して、DeFiコントラクトでは通常DEXを価格設定に使用します。現在、UniswapV2/V3の遅延価格設定はフラッシュローン攻撃に対抗できますが、実際の大資産操作には対抗できません。一方、TWAP時間加重メカニズムは操作の難易度をある程度高めることができますが、緩和するだけで根絶することはできません。

開発者の観点からは、コントラクトに一定のリスク管理コードを追加して悪意のある価格設定をチェックすることを検討できます。一般ユーザーにとっては、関連する流動性プールに注意し、価格操作リスクに警戒する必要があります。

参考文献

https://twitter.com/FloatProtocol/status/1482184042850263042

https://medium.com/vesperfinance/on-the-vesper-lend-beta-rari-fuse-pool-23-exploit-9043ccd40ac9

DefiDollarが潜在的な攻撃を発見

1月8日、DefiDollar Finance（@defidollar）がDUSDコントラクト内に潜在的な脆弱性を発見したとツイートし、コントラクトは停止され、すべての資金は安全であると報告しました。この脆弱性はブロックチェーン監視システムによって自動的に発見されたとされています。その考え方は、チェーン上のTornado.Cashから新しいアドレスに転送され、コントラクトが展開される行動を監視することです（これは多くの実際の攻撃における典型的な初期準備行動です）。

コントラクトと関連する取引の分析を通じて潜在的な攻撃行動を発見し、問題が発見された場合には関連プロジェクトに即座に通知して予防措置を講じます。すでにForta上で類似のエージェントが実装されています。

Cobo コメント

プロジェクトチームは、チェーン上の新しいコントラクトやメモリプール内の取引を監視することで、疑わしいコントラクトや取引に対して静的分析やシミュレーション実行を行い、自身のプロジェクトに関連するコントラクト内の資産に悪影響を及ぼすかどうかを確認することを検討できます。

ブロックチェーン攻防の進化に伴い、類似の監視警告システムがますます成熟していくことが予想されますが、攻撃者も監視を回避するための新たな攻撃手法を見つけ出すでしょう。伝統的なセキュリティにおける攻防の持続的な対抗の状況は、ブロックチェーンセキュリティにおいても繰り返されるでしょう。

参考文献

https://twitter.com/AndreCronjeTech/status/1479778350084333574

https://connect.forta.network/agent/0x2fbec7dcd4eebf34c5b94d899109057eea3642a2400b7143e64873d453b7ba61

Rariプール#19攻撃失敗

著名なブロックチェーンセキュリティホワイトハット@samczsunがRari #19（Index Coop Pool）に対する警告ツイートを発表しましたが、その後攻撃は実際には発生しませんでした。

攻撃手法は前述のFloat Protocol Rari #90オラクル攻撃と類似しています。攻撃者はUniswap V3で約300 ETHをBEDに交換し、価格を操作しました。Uniswap V2/V3オラクルは2番目のブロックで価格を更新するため、攻撃者は1回の取引内で価格を操作することができず、フラッシュローン攻撃に対抗できました。

実際の大資金を使用して操作する場合、攻撃者は少なくとも2番目のブロックまで待つ必要があり、価格の反応を見ることができます。TWAPの存在により、通常攻撃者はさらに数分待つ必要があり、価格がより明確になるまで待つ必要があります。今回の攻撃でも、攻撃者は確かにそうしました。

しかし、困ったことに、2番目のブロックで疑わしいアービトラージボットが存在し、このアドレスはすぐに大量のBEDをETHに交換し、元の価格の安定を維持しました。これにより、攻撃者は攻撃を続行できず、スワップのガス、手数料、大口取引のスリッページの損失を負うことになりました。

Cobo コメント

Uniswap V2/V3オラクルはフラッシュローン攻撃に対抗できますが、大資金の操作に直接対抗することはできません。したがって、流動性が少ない取引ペアには、オラクル価格が操作されるリスクが依然として存在します。

攻撃者の観点から見ると、Uniswap V2/V3オラクル操作攻撃を行うには高い攻撃コストが必要であり、操作対象のプールの目標トークンの大部分を市場で保有している必要があります。そうでなければ、他の目標トークンを持つ大口がアービトラージを行い、最終的に攻撃者は損失を被ることになります。

参考文献

https://twitter.com/samczsun/status/1486243806739587076

OpenSeaフロントエンド脆弱性

@PeckShieldがOpenSeaにフロントエンドの問題がある可能性があると発表し、ユーザーがこの問題を利用して347 ETHを獲得したと報告しました。この脆弱性は@yakirrotemが公開した問題に関連している可能性があります。

OpenSeaの取引構造は次のとおりです：

• 売り手がリスティングを開始（価格を提示）し、この時ユーザーは提示データに署名し、設定された価格でNFTを販売することに同意します。

• この署名データはOpenSeaのオフチェーンデータベースに保存され、買い手がOpenSeaでそのNFTを購入する際、OpenSeaはこの署名データをオンチェーンで検証し、成功すればNFTの転送が完了します。OpenSeaは一部の手数料を受け取ります。

• 売却前に、売り手は以前のリスティングをキャンセルすることもでき、キャンセルされたリスティングはオンチェーンでの検証時に失敗し、販売されません。

ここに存在する問題は、OpenSeaが元のリスティングをキャンセルせずに再度リスティングを開始することを許可していることです（現在この問題は修正されています）。この時、OpenSeaのUI上では売り手の古い提示は表示されませんが、実際には古いリスティングは依然として存在し、有効です。

攻撃者はhttps://orders.rarible.comで古いリスティングを確認できます。OpenSeaのリスティングには取引Nonceメカニズムがないため、古いリスティングは依然として有効です。攻撃者は古いリスティングを通じてNFTを直接購入し、新しい価格で販売することができます。NFTには激しい価格変動があるため、この方法で巨額のアービトラージを実現できます。

https://etherscan.io/token/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d?a=9991#inventoryがその一例です：1月24日、BAYCのNFTはOpenSeaで0.77 ETHで購入され、その後84.2 ETHで販売されました。

Cobo コメント

一般ユーザーはhttps://orders.rarible.comにログインして自分に古いリスティングがあるかどうかを確認し、直ちにキャンセル処理を行うことをお勧めします。より安全で確実な方法は、NFTを新しいアドレスに移転することです。

参考文献

https://twitter.com/PeckShieldAlert/status/1485547426467364864

https://twitter.com/yakirrotem/status/1485559864948629512

Metamaskが個人IPを漏洩する脆弱性

@alxlpscがmediumでMetamaskに深刻なプライバシー漏洩問題があることを公開しました。この脆弱性は主にMetaMaskがNFT画像のURLを自動的に読み込むことを利用しています。基本的な攻撃の考え方は、攻撃者がNFTのURIを自分が制御できるサーバーのURLに設定することです。

そしてNFTをターゲットアカウントに転送します；ユーザーがMetamaskにログインすると、Metamaskはアカウントが所有するNFTを自動的にスキャンし、攻撃者のサーバーへのHTTPリクエストを発起します；攻撃者はアクセスログから被害者のIP情報を取得できます。

Cobo コメント

ブロックチェーンの匿名性は主にチェーン上のアドレスとチェーン外のアイデンティティの分離から来ています。チェーン上のアドレスを通じてチェーン外のアイデンティティを確認できる場合、ブロックチェーンのシナリオでは深刻な危害となります。伝統的なセキュリティではホストIPの漏洩は特に深刻な問題とは見なされないことが多いですが（フィッシングSMSやメールで簡単に実現可能なため）、匿名性を主張するブロックチェーンの世界ではプライバシーの重要性が一段と高まります。このように、セキュリティシナリオの違いによって脆弱性のレベルが異なる状況が、ブロックチェーンという比較的新しい分野で今後も続々と現れることでしょう。

参考文献

https://medium.com/@alxlpsc/critical-privacy-vulnerability-getting-exposed-by-metamask-693c63c2ce94

wxBTRFLY 脆弱性の開示と修正

@immunefiのホワイトハットハッカーがwxBTRFLY Tokenコントラクトに深刻な脆弱性が存在することを発見しました。コントラクト内のtransferFrom関数はrecipientの承認を正しく更新せず、msg.senderの承認を誤って更新します。

脆弱性自体は深刻ですが、その原因は複雑ではなく（開発者の誤記のようなものです）、興味深いのは公式の修正方法です。コントラクト自体がアップグレードをサポートしていないため、コントラクトコードを直接更新することはできません；コントラクトは一時停止をサポートしていないため、スナップショット + 移行の方法でユーザー資産を移転することもできません。最終的に公式の措置は、自ら攻撃取引を発動し、脆弱性の影響を受けたすべてのユーザーの資産をマルチシグウォレットに移転することでした。後に新しいTokenコントラクトが展開された後に再配分される予定です。

Cobo コメント

ERC20 Tokenは比較的成熟したコードテンプレートを持っており、wxBTRFLYはtransferFromを再実装する際に問題が発生しました。この問題は、十分な単体テストがあれば簡単に発見できたはずで、プロジェクトチームは開発過程で十分なテストプロセスが欠けていた可能性があります。

参考文献

https://discord.com/invite/rpkPDR7pVV

https://twitter.com/redactedcartel/status/1482497468713611266?s=20

https://etherscan.io/tx/0xf0e4ccb4f88716fa5182da280abdb9ea10ec1c61cfc5bbe87e10bdde07c229d6

Qubit クロスチェーンブリッジが攻撃を受ける

1月28日、BSC上のDeFiプラットフォームQubit FinanceのクロスチェーンブリッジQBridgeが攻撃を受け、約8000万ドルの損失を被りました。

クロスチェーンブリッジの一般的な実装形式は、ソースチェーンのコントラクトに資産を担保し、イベントをemitすることです。リスニングノードがイベントをキャッチし、ターゲットチェーンのクロスチェーンブリッジコントラクトに呼び出しを行い、同量の資産をmintします。ソースチェーン上でイベントが発生すれば、クロスチェーンブリッジシステムはクロスチェーン資産の移転が必要であると認識します。

しかし、ソースチェーン上のクロスチェーンブリッジコントラクトコードに問題がある場合、資産がクロスチェーンブリッジコントラクトに担保されていないにもかかわらず、イベントがemitされる状況が発生し、脆弱性が生じ、ターゲットチェーンのTokenの誤った増発を引き起こす可能性があります。

QBridgeにはこのような問題が存在します。QBridgeはETHとERC20 Tokenの2種類の資産の担保をサポートしています。EthereumのETHはネイティブトークンであり、ERC20 Tokenは2つの別々のコードで処理されます。ソースチェーンでTokenを担保する際、depositメソッドが呼び出され、担保時にはETHはdepositETHメソッドを呼び出すべきです。

QBridgeはゼロアドレスをETHの識別子として使用しています。しかし、実装時に十分な検証が行われておらず、コントラクトがETHを処理する際に依然としてdepositメソッドを使用してしまい、ETHをコントラクトアドレスがゼロアドレスのTokenとして処理してしまいます。転送時にtransferFromを使用すると、ゼロアドレスに対してコントラクト呼び出しを行うことになります。

Ethereumの基盤設計では、EOAアドレスに対してコントラクト呼び出しを行うと、デフォルトで成功し、revertしません。これらの条件が組み合わさると、最終的には攻撃者がソースチェーンで何の資産も担保していなくても、ターゲットチェーンで大量のqXETHをmintし、利益を得ることができる状況が生まれます。

Cobo コメント

現在、ブロックチェーン業界ではマルチチェーンが共存しており、クロスチェーンブリッジは重要なインフラとなっています。クロスチェーンブリッジは、オンチェーンとオフチェーンの協調を行う必要があるため、全体の複雑さが通常のdappよりも高く、問題が発生しやすいです。また、クロスチェーンブリッジ上には通常大量の資産が担保されているため、不正に移転できれば大きな利益を得ることができます。各クロスチェーンブリッジシステムは、最近1、2ヶ月の間に攻撃者の重点目標となっているようです。