$5000 from Raydium Bug Bounty Program ～バグハントがブルーオーシャンだと思った話～ part2/2
前書き
パート１では私がバグバウンティプログラムに参加した顛末を物語成分多めに紹介させていただきました。
DefiでなくともIT業界全般に共通する話も多く、バグの詳細にはあまり触れてこなかったため、既に高いスキルを持つ方には少し退屈な話だったかもしれません。
そういった方々にとっても有益な情報を提供できるよう、パート２では努めてまいりたいと思います。
具体的には、「Defiにおけるバグバウンティプログラムの実態調査」といったものになればよいかと考えます。
私もまだ、この世界の表面をさっと走査しただけであり、専門的なことをご紹介することはできませんが、私がいくつか目を通した記事や論文の中でよく目にしたトピックや頻出問題と呼べそうなもの、または有益に感じたリンク、フォローしておくべきスポットなどをまとめてみます。
バグバウンティプログラムへより効率的にコミットするためのガイドラインとなることを願っていますが、既にディープな情報収集能力に長けた方達がほとんどかと思われますので、有益な記事などを見つけた際は是非ツイートなどで紹介していただければ私も助かります。
プラットフォーム
さて、Defiにおけるバグバウンティプログラムに参加する際に候補となるプラットフォームには以下が挙げられます。
おそらくDefiを対象にバグバウンティプログラムに参加する際は、3.のImmunefiが唯一の選択肢になるかと思います。順番に概要を説明していき、その理由をお伝えします。
１．HackerOne
Defiに係らない最も有名なバグバウンティプラットフォームが、BugCrowdと並んでこちらのプラットフォームになります。
有名どころではありますが、Defiという分野に限るとそこまでプロジェクトの選択肢が豊富にあるというわけではありません。
こちらから "smart contract"のタグが付けられたものでヒットした結果は3件でした。どれも誰もが知るようなプロジェクトですが、報酬の上限にかなりのバラつきがあるのがわかります。
キーワード検索で"crypto"でも検索してみます。こちらの検索数は14件に増えました。
他にメジャーなところでは、Coinbase、Crypto.comも参加しているようで主に中央取引所や交換所が多いですが、"smart contract"で検索したよりもがくっと報酬が下がっています。(*なおCoinbaseだけBaseチェーン等も対象なのか上限$1Mでぶっちぎっており、Crypto.comは$80k)
この差は主に、バグハントの対象となるプロトコルそのものの違いに依るものでしょう。資本力はCEXの方が大きいはずですが、これらの企業は主にAPIやWebサイト自体の脆弱性に焦点を置いており、それらはAPIエンドポイントの不備、SQLインジェクションなどといったWebアプリケーションを提供している企業全般にいえるものです。
つまり、他の仮想通貨に関連のない企業が提案する報酬の相場に則しています。
一方、スマートコントラクトというプロトコルは、Defi内に限られており、且つ新しい技術であるため専門的な人材が足りていません。
また最も大きな理由が、資金が直接的にリスクにさらされているといった側面もあり、報酬は他のIT企業の提案するよりもずっと大きくなります。でなければ、見つけた脆弱性を利用してExploitする方が割に合ってしまうといった状況が簡単に成立してしまうため、抑止力として提案する報酬も破格になる傾向があります。
それでも後でお見せするImmunefiにラインナップされた報酬の相場観と比較しても、MagicEdenやChainlinkはその知名度に比べて、かなり割安な印象を受けてしまいます。他の非Defiプロジェクト相場に引っ張られている感は否めませんが、スマートコントラクトに則した業界スタンダードな報酬を定義するためのポリシーの準備が、プラットフォーム側でできていないといった背景もあるのかもしれません。
またラインナップが非Defi企業主流のために、検索でDefiに絞りにくいといった欠点もあります。
２．bugcrowd
次にbugcrowdですが、"smart contract"で検索したヒット結果はありませんでした。"crypto"では9件で、知名度のある企業は主に以下になります。
ここで天下のBinanceが登場しますが、HackerOneで述べたこととまったく同じことがあてはまるので特に言うことはありません。次に移ります。
３．Immunefi
大体の相場観をつかんでいただいたところで、パート２主役の登場です。
提携しているプロジェクトは314とあります。
しかもそのほとんどがスマートコントラクトを対象としており、先に紹介したプラットフォームのそれとは一線を画しています。
なるべく多くのプロジェクトが入るよう縮小したので、見にくいかもしれませんが、見覚えのあるプロジェクトもそうでないものもあるかと思います。
しかし体感的には、見知っている＝TVLが大きい＝リスクに晒されている資産も大きい＝報酬も高いといった図式が大まかに成り立っているかと思います。
名前の聞いたことのないようなプロジェクトであっても、最高$100kの報酬を設けていたり、資産が一か所に集まるような性質を持つプロトコル(ステーキングやブリッジ *e.g. Lido/Wormhole/Multichain)は高額なようですし、主要なブロックチェーンは軒並み名を連ねています。
検索フィルターも、レンディング・DEX・Perpとタイプ別に絞ったり、Polygon限定といったチェーン指定や、プログラミング言語別にしたりもできますので、ご自身で検索してみてください。
大体の報酬の相場をつかんでいただいたところで、トップページからプラットフォーム全体の集計を見てみます。
すでに支払われた報酬の累計$70M以上
準備金$139M
バグハントで守ることのできた資産の試算$250B
また、ホワイトハット達の獲得報酬のリーダーボードを眺めてみるとえらい景気がいいです。
リーダーボードは上位20名までの掲載なので、正確な分布や中央値などはわかりませんが、その20名の報酬を合計すると$56Mほどだったので、すでに支払われた報酬累計$70Mから差し引くと、$14M程度が残りの中堅ホワイトハッカーたちに分配されていると考えられます。
それ以上は何もデータがないので(Discord8000人とかその程度のもの)、レポートを提出した人数とか知りたいですけど、まぁオンチェーンデータとかあるわけもないし探してみた感じでは見つかりませんでした。
リーダーボードで見える分にはすごいですが、かなりハイランカーに寡占されてはいるでしょう。と言ってもひとつバグを見つけて、いきなり1位を取るなんてこともあり得なくもなくはない(しかも原資ゼロで！)わけですし、あんまり見ても意味ないような気もします。
一応、Immunefiの集計した生態調査にも目を通しましたが、ホワイトハットの54%が20~29歳だとか、男性率95.5%とか、何をモチベーションにやってるのだとか、特に知りたくもなかったそういったものが主でした。
といったわけで、わざわざ解説するまでもなくDefiで特にスマートコントラクトをターゲットにしたバグハンティングをやるなら、現状Immunefi一択になるでしょう。
４．直接交渉
すべてのプロトコルが上述のプラットフォームと提携しているわけではありません。そもそもコントラクトのプログラムを公開していないプロジェクトも多いわけで、していてもバグの報告を受け付ける窓口すらなかったりします。
実際に行うとなると、私のように偶然バグに遭遇してデバッグしてたら見つけてしまった、といったような受動的なバグハントになるパターンがほとんどかと思います。
実際、私はRaydiumがドキュメントにバグバウンティプログラムを掲載していなかったら報告なんてしていなかったと思います。
報酬がもらえるかもという期待もありましたが、それ以前にすごくめんどくさいです。
そしてほとんどの人がそうだと思います。
中には悪用する人だっています。
どうこうしてくださいと私から言えることも言うつもりもありませんが、そういったときのためにImmunefiのガイドラインにあらかじめ目を通しておいて損はないとは思います。
少なくとも、いざ報告しようといった段で私のようにあたふたしないで済みます。
頻出問題
Vulnerabilities and Attack Vectors
https://immunefi.com/reports/
さて、ようやくここから本題に入るようなものですが、規約や報酬体系、PoCの要件をすべて把握したところで、当たり前ですがバグを見つけないことには何の意味もありません。
片っ端からコードを読むといった作業は遅かれ早かれ必要ですが、その前にある程度のパターンや傾向を網羅しておくことは、コードのどこを注視すべきかといった目を養うのに必要です。
Immunefiには過去のエクスプロイトの事例などを分析した記事やフォーラムなどの優良なコンテンツが揃っています。
特に、他のホワイトハットが行ったバグハントの分析レポートが、Discordにいくつも挙げられているのは大きいでしょう。これらは事前に修正されたバグであり、ここでしか読めません。エクスプロイトに繋がったものは、取り沙汰されることで多くの人の目に触れますが、人知れず何百万ドルもの資産を救った事例も、我々が思うより数多く存在します。
そういったわけで、これらを脆弱性のタイプごとに分類してまとめたものでも書こうかなと思っていたのですが、まだ圧倒的に知識が足りてません。
上述リンクのものを上回ることすら、ちょっと今の段階では厳しいなと自分に絶望しました。
ですので、ここでは私がこれから行う予定のアプローチを紹介できたらなと思います。
ImmunefiのMediumは超絶優秀です。ここを上から読んでいくだけで、何か自分にもできるかもと思えてきます。
ただリンクが結構とっちらかっているので、パターンやキーワード毎に仕分けしたまとめリンク集を作るのが一番有意義かなぁと思ったので、色々なところで記事や論文を読んでから作ろうかなと思います。
今はまだ10個くらいしか記事・論文併せて読んでないので、それが100個くらいになったらまた後日記事にします。今はこれで勘弁してください。笑
以下はいちお、草案として。
例えば有名なNomadハックの記事。
こういうのってちゃんと細部まで読まないと、どの脆弱性タイプが突かれたかっていうのは分からない＆深部まで読み解く理解力を要します。
例えば、今の私の理解力で、この記事からキーワードを抽出するなら「ブリッジ//プロキシアップグレード//マークルツリー//メッセージハッシュ」になるかなと思います。
一方、BSCトークンハブ(Binanceブリッジ)ハックの記事。
こちらを読んでみると、「ブリッジ//マークルツリー//LAVL検証//リレイヤー」といったキーワードが抽出できるかなと思います。
ここでもマークルツリーが出てきました。
私自身ブリッジの実際の実装など一切知りませんが、マークルツリーを細部まで理解していないと、この脆弱性を発見することは不可能だということだけは理解できます。(ちなみにマークルツリーはWLや、Txの重複確認など色々な場面で使います)
一方でバグの原因となった箇所は、前者ではプロキシアップグレード、後者ではLAVL検証となり、これらはまったく類似性がありません。
さらにもうひとつ記事をピックアップしてみましょう。
こちらはBeanstalkプロトコルで見つかった脆弱性で、先に述べた２つとは異なり、事前に報告されて$181,850の報酬が支払われました。実際にどういった報告によって、この報酬が支払われたか知ることができるので、たいへん興味深い記事です。(他にも読みたい方は、ぜひDiscordへ。報酬の発生した事後レポートがたくさんアップされています)
この記事からキーワードを抽出すると、「ステーブルコイン//プロキシコントラクト//外部関数呼び出し//論理エラー」となるでしょうか。
Nomad事案と同じようにプロキシコントラクトがここで共通していますが、今回は脆弱性の原因といったわけではなく、これを使用して外部送金する際に許容量のチェックがなかったことによるものです。
直接の原因は内部にありましたが、こちらもプロキシというコントラクトが関わっているので、その実装をよく理解することが求められているということがわかりました。
これらのことから、どこが何と共通しているかといったことが見えてくるので、先述したように多くの記事に目を通す網羅作業がまず私に必要なことかと思います。そしてひとつひとつの解像度も上げていかなければなりません。(solidityもEVMもナニモワカラン)
またこれらのまとめリンクを作るのは、自分の学習にも役立つのでこれからコミットしていきたいものです。(私が主に棲むSolanaでも、こうした資料があれば学習が捗るのですが、残念ながらほとんど見かけない)
どのプロジェクトを選ぶべきか
ここからはあくまで私の妄想や仮定も多分に含んだ考察です。
さて、Immunefiでアカウントを作成し、いざバグハントを開始するとしましょう。どのプロジェクト、プロトコルに注力すべきかといった選択問題が非常に重要になってくるのは明確です。
賞金が多いものから狙っていく、または開発力に不安がありそうなプロジェクトや、賞金・知名度の低さから逆に競合が少なそうなどといった見立てで選ぶといった戦略も悪くはないでしょう。
報酬の大小は資産への直接的なリスクの大きさにより、危険度毎にカテゴライズされているので、影響の大きそうな関数(e.g. emergencyWithdraw()など)だけピックアップして精査するのもアリでしょう。
これにはおそらく正解などないでしょうが、私から提案できるやり方のひとつに、ひとつのプロジェクトに絞るのではなく、ひとつのプロトコルタイプに絞って並列にやるのも良いやり方ではないかと考えます。
例えば”レンディング”というタイプに絞り、そのタイプに合致するプロジェクトを横並びにしてそれぞれを突き合わせていく、といったものです。
これには、borrow()といった貸し出しの関数であれば、どのレンディング・プロジェクトにも必ず存在すると予想できるため、そうした共通する関数がある場合、その差異も把握しやすいからです。
また、その時にはバグが見つからなかったとしても、新しいレンディングプロトコルがリストアップされたときに、効率的にコードをレビューできます。
これは汎用性のあるEVMベースのプロトコルに特に言えるもので、残念ながら私の愛するRustではあまり使えませんが、それでも実際私はスワップの実装、特に集中流動性には強かったために効果を発揮しました。
今後の行動指針
おそらく私の今後の行動指針としては、それまでどこに自分のリソースを割くかといったことに悩んでいたのもあって、バグハント面白そうなので挑戦してみたいと思っています。
何も成果が得られなかったとしても、そのプロトコルのコードを徹底的に読むことになるので、副産物として仕様にのっとったエッジなども見つかる可能性が高いですし、もしかしたら何かプロトコルを作ってやろうという気になるかもしれません。
何より、原資が全く必要ないというのはかなり大きいです。
私はこれまで、主に２つのBotをSolanaで運用していました。
１つ目はAtomic arbitrage botと呼ばれるもので、今運用しているものをもう一段アップグレードするにはどうしても運用コストがかかってしまうために尻込みしていました。それとコストをかけたところで、まともに戦えるようになるかは未知数なところが多く、おそらくバグハンティング以上に競争が激しい世界です。
２つ目はAutomated management liquidity botで(たぶんこの呼称でいいと思う)、 SolanaであればKamino Financeが提供しているLiquidity vaultみたいなものを、自分でスマートコントラクトを作ってひとりで使うみたいな感じです。
Kaminoが提供しているプールと被ると、資金が流動性プールに集まってきておいしくないので、それ以外のペアを使っています。
基本的にこういったリバランス系の流動性提供は、集まった資金が大きくなればなるほど枚数当たりの利率が落ちるので、最高効率でやるのがいいです。逆に言えば、ロットを増やせば増やすほど原本割れするリスクが高まるので、これ以上増やす魅力を現状感じていません。
最初はヘッジをかけてやってたんですが、トークンが半分の価格に落ちても、トークン枚数は2倍近くまで増えて対のUSDCの方はせいぜい2～3割くらいしか持っていかれないことが確認できたので、あんまやる意味ないと思って今は外してやってます。もちろんあまりに勢いよく急落したら損失はでるんですが、上述のロット限界もあるので最悪そうなってもすでに十分元は取れているのでいいかなといった感じです。
そんなわけで、１つ目のBotも2つ目のBotもちょうど限界を感じていたので、自前のPCも新調したことだし過去にやっていたReinforcement learning(強化学習)Botの学習でも再開しようかなと思っていたところなんですが、今回の件が飛び込んできて良い刺激になりました。
Solidity及びGo言語も、これまであまり勉強するモチベーションが湧かなかったのですが、脆弱系記事を読み漁るために、急にそういった必要性が出てきたのも良い点です。
自分にとっては新しい風が吹き込んできたようなものなので、今回の件は本当にありがたかったです。
この記事は、私が感じるのことができたこの新しい風を少しでも皆さんと共有できればといいなと考えています。
それにBot運用系の話は、言うメリットがまず一切ないので普通は黙っていた方がいいのですが、バグハンティング系だとこれまでのうっぷんを晴らすかのように色々語れるのは自分にとってはデカいです。(ついでにポロリしました)
バグハンティング系で情報を発信する風潮を作ることは、デメリットよりメリットの方がはるかに大きいと思うので、賛同していただける方は是非そちらからも発信してみてください。
これからしばらくは圧倒的に”読む”ことに自分のリソースを割くことになるので、またその後アップデートが完了した自分で何かお届けできればと思います。
それではその時まで。
この記事が気に入ったらサポートをしてみませんか？