。2019年に私はEOSネットワークのメインネットをDDOS攻撃し、コンセンサスリソースモデルの欠陥を悪用して1か月間凍結させました。EOSは当時トップ7にランクされていました。(  、 ) 私の名前はデキサランです。私はハッカーで、業界で最大規模のコンセンサスレベル攻撃を設計し、実行しました EOSGOレポート コミュニティレポート 。（  ） 私はイーサリアムクラシックのコア開発チームの創設者の一人です Cointelegraphの記事 私は、POW チェーン業界の悩みの種であった 一連のルールである、  を設計しました。 51% 攻撃を解決する Nakamoto コンセンサスの修正案 編集者注: このストーリーは、記事の著者の意見を表しています。著者は HackerNoon のスタッフとは関係がなく、独自にこの記事を執筆しました。HackerNoon 編集チームは、記事の文法の正確さのみを検証しており、ここに含まれる主張を容認/非難するものではありません。#DYOR 事故 あるユーザーが、ezETH トークンをスマート コントラクトに送信したことにより、2,600 万ドル相当を失いました。これはユーザーのミスであると主張する記事や Twitter スレッドが複数あります。たとえば、  によるこのスレッドなどです。 CoinTelegraph 。外部所有のアドレスへの転送とスマートコントラクトへの転送は動作が異なります。 これは誤りです。同様のユーザーミスでは、Eth、NFT、またはERC-223トークンが失われることはありません ユーザーが間違ったアドレス（スマートコントラクトではない）や誰にも所有されていないアドレスにトークンを送信した場合、それはユーザーのミスになります。 ただし、この場合、ユーザーはスマート コントラクトにトークンを預けています。スマート コントラクトはこうしたミスを防ぐことになっており、確かにそれが可能です。たとえば、ユーザーが Ether (またはその他のネイティブ通貨)、NFT (ERC-721)、または トークンを、それらを受け取るように設計されていないスマート コントラクトに預けた場合、トークンは失われません。トランザクション エラーが発生し、トークンの転送は行われません。 ERC-223 エラー処理は、ソフトウェア セキュリティの最も基本的な原則の 1 つです。呼び出しエラーを適切に処理できないようなソフトウェアの設計は、ガバナンス機能の 修飾子が欠落しているのと同じであり、セキュリティ上の問題になります。 onlyOwner これはERC-20標準の問題です。エラー処理が不可能になるような設計になっています。そしてこれはセキュリティ上の問題です。ERC  。2023年に、  。 -20標準は安全ではありません ERC-20標準の作成者自身が、これが標準のセキュリティ上の問題であることを確認しました 私は2017年に と このことを報告しました。また、私は2017年にまさにこの問題を解決するためにERC-223標準を設計しました。ここに スレッドがあり、この標準が金銭の損失を防ぐことが強調されています。 ここ ここで オリジナルのEIP-223   セキュリティ企業や開発者が、ミスを犯したユーザーを責めるのは非常に簡単です。しかし、ユーザーのミスに対処できない安全でない標準を使用してアプリケーションを構築し、このような悲惨な損害をもたらした開発者の責任です。 歴史 私は、これがユーザーに経済的損害を与える可能性があることを強調し、Ethereum Foundation に報告しました。彼らは何もしませんでした。7 年間も。  2017 年にはこの問題により 16,000 ドルの損失が発生しました。  2018年には200万ドルが失われた 2023年に6000万ドル 2024年11月1日には90,000,000ドル（ezETH契約で失われた2500万ドルを除く）がありました。 今では1億1500万ドル 私のチームは、失われたトークンの量を計算するスクリプトを開発しました。     https://dexaran.github.io/erc20-losses   2017年に別のユーザーが13万ドルを失いました。   2020年に、あるユーザーが生涯の貯蓄を失いました。   2023年に、ユーザーは1回の取引で24万ドルを失いました。   その後、Poloniexのハッカーは250万ドルを失いました。  2017 年にこのセキュリティ問題のため ERC-20 標準の推進をやめるように要求しましたが、応答はありませんでした  。 https://github.com/ethereum/ethereum-org/issues/755 私はこの問題を、Ethereum で EIP を管理している EthereumCatHerders にエスカレートしました。  2023年に彼らは「当社はセキュリティ開示とは一切関係がなく、そのためのプロセスもありません」 。 と返答しました 説明: EIP と ERC は、誰でも Ethereum に提出できる提案です。これらは、開発者が Ethereum の動作に適用する標準または変更になることがあります。これらは、github リポジトリ内のテキスト ファイルです。 背景: Ethereum プロジェクトの開始から 10 年が経過した現在でも、EIP のセキュリティ開示に対処するプロセスが確立されていません。 私は、セキュリティ開示を可能にするために EIP の動作を変更する方法を提案していました:  https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265 私は ERC-20 に警告を追加し、EIP に問題を文書化することを提案しました。以下は彼らの電話です。彼らは、EIP-20 の脆弱性を明らかにする別の情報 EIP を作成する必要があると判断しました:  https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317 私はそうしました。その後、彼らは私の開示EIPを 。 拒否しました 私は、EthereumMagicians フォーラムで説明した、2024 年に EIP の「セキュリティに関する考慮事項」セクションでセキュリティ開示を再び許可するという当初のアイデアを復活させる提案を思いつきました。  EIP 編集者との議論はこちらです:  https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s その結果、EIP 編集者は投票するつもりだと私に伝えました:  https://github.com/ethcatherders/EIPIP/issues/349 私の提案は否決されました。EIP のセキュリティ開示に対処するプロセスはまだありません。ERC-20 の問題は修正されていません。問題として報告も文書化もされていないため、実装者は何度も同じ問題を再現し続けています。 不公平な監査人 私は個人的にこの問題を OpenZeppelin に報告し、修正を 3 回要求しました。  2018年 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729  2023年 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451 前の 2 つが却下された後、問題の重大性を示す方法で報告することに決め、OpenZeppelin 独自のルールに従って「重大なセキュリティ脆弱性」の基準に適合するため、バグ報奨金に提出しました   https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022  OpenZeppelin は「パッチ未適用の脆弱性の公開」を理由にこれを拒否しました (少なくとも、これがセキュリティ上の問題であることを確認しています)。  数日前の Devcon7 で、この問題に関して github で問題をクローズした OpenZeppelin の同じ人物に質問がありました:  https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406 報告されてから6年が経ち、ユーザーに1億1500万ドルの損失をもたらしました。 彼らの返答は真実ではありません。 未解決の問題を抱える代わりに、彼らは私が提起した 3 つの問題を閉じ、私が行った提案をすべて拒否しました。 結論 イーサリアム財団は、エコシステムのユーザーが 1 億 1,500 万ドルの損失を被ったこの問題を指摘するあらゆる試みを検閲しています。この問題は発表されず、開示は適切に処理されず、実装者は新しいコントラクトでこの問題を再現し続けています。 それを公表すれば、彼らの評判にあまりにも大きなダメージを与えると彼らは考えていると思います。  OpenZeppelin のような監査人もこの問題を公表していません。おそらく、監査した数百の ERC-20 契約にすでに「Secure」ラベルを付けているため、利益相反があるからでしょう。 開発者たちは「標準をそのまま実装しているだけです」と言っています。 この標準は EIP プロセスによって管理されていますが、EIP プロセスはセキュリティ開示に対処するために構築されたものではありません。  EIP プロセスを変更する必要があります。ERC-20 の問題は公開され、適切に文書化される必要があります。理想的には、新しい標準を実装する必要があります。ERC-20 に一連の「バンドエイド」を適用して損害を軽減することは、何もしないよりはましですが、それ自体で問題を解決することにはなりません。  「問題はウォレット レベルで解決できる」と言っている人は、セキュリティの専門知識に欠けています。ソフトウェア セキュリティには、 という原則があります。つまり、安全でないソフトウェアを作成し、ユーザーに影響を与えないように使用方法を全員に伝えて、損害は発生しないふりをすることはできません。金融業界ではそうではありません。たとえば、Web デザインでは、誰かが Web ページに適切なフォントをロードできないことが障害のコストとなるため、このアプローチは有効かもしれません。金融業界では、これは数百万ドルの損失につながります。 設計によるセキュリティ 人類文明の将来全体にわたって、すべてのウォレット開発者が常に必要な修正をすべて適切に実装することを保証することは絶対に不可能です。

Read My Stories

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Download free Tech Leaders Productivity Report!

トレーダーが ezETH トークンで 2,600 万ドルを失う: メディアはユーザーを非難、ハッカーは ERC-20 の欠陥を指摘

About Author

コメント

ラベル

この記事は

Related Stories

Telegram: クリプト島と本土を結ぶ橋

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

Telegram: クリプト島と本土を結ぶ橋

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

フォーラムからフィードへ: ソーシャルメディアアルゴリズムがデジタルインタラクションを形作る仕組み

クラウド移行を成功させるための完全ガイド: 戦略とベストプラクティス

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps