過去1週間（2026/07/27 - 2026/08/02）において、以下の2件の注目すべきセキュリティインシデントが取り上げられており、合計で約$88Mの損失をもたらしました。
| 日付 | インシデント | 種別 | 推定損失 |
|---|---|---|---|
| 2026/07/29 | LULA | ビジネスロジックの欠陥 | ~$578K |
| 2026/07/30 | COLDCARD | エントロピー生成の欠陥 | ~1,370 BTC (~$88M)* |
* COLDCARDの損失は確認方法によって異なります。表示されている~1,370 BTC（~$88M）は、オンチェーンで公開検証可能な最小値です（coldcardwatch.com）。プライベートチャネルでの照合（Galaxy Research、73人の被害者との通信より）では、疑わしいものの未確認のドレインを含めると、約1,596 BTC、最大~2,055 BTC（~$130M）と、より高い数値が示されています。
選定理由
- LULA：AMMペアの残高を移動してリザーブの再同期を強制できる特権トークン関数が、価格操作によって繰り返し利用可能な流動性ドレインの手段となりました。
- COLDCARD：ウォレットファームウェアにおけるビルド・インテグレーションエラーにより、シード生成が決定論的なソフトウェアフォールバックに静かにルーティングされ、エントロピーの保証が損なわれた結果、シードの復元がオフライン探索で可能となり、大規模な資金損失へと発展しました。
Best Security Auditor for Web3
Validate design, code, and business logic before launch
今週のハイライト：COLDCARD
今週のハイライトとしてCOLDCARDを選んだのは、ウォレットのエントロピーバグが今期間で最大の損失をもたらしたためです。根本原因は、設定マクロが存在するかどうかを確認するだけで、有効になっているかどうかを確認しないビルドガードという、機能テストでは検出できない種類の静かなインテグレーションエラーであり、この教訓はオフチェーンのランダム性にオンチェーンのセキュリティが依存するあらゆるシステムに当てはまります。
Bitcoinハードウェアウォレットであるは、2021年に出荷したファームウェアにおいて、意図されたハードウェア乱数生成器（RNG）の代わりに決定論的なソフトウェアソースを使用してウォレットシードを生成していました [1][2]。この欠陥は2026年7月末まで大規模には悪用されませんでしたが、7月30日から開始したオンチェーンの波で影響を受けたウォレットが一斉に流出しました。公式に確認された損失は少なくとも1,370 BTC（8月5日時点の価格$64,099で~$88M）[3]に上り、プライベートチャネルの報告では約1,596 BTC [4] まで上昇しています。根本原因は、シード生成を意図されたハードウェアRNGではなくソフトウェアフォールバックにルーティングしたビルド・設定エラーでした。影響を受けたデバイスでは、シードの復元が暗号的に実行不可能な問題からオフライン探索へと変わってしまいました。
背景
COLDCARDはBitcoinハードウェアウォレットです。ウォレットの秘密鍵とアドレスはすべて単一の秘密値（シード）から派生するため、セルフカストディウォレットのセキュリティはそのシードの2つの特性に依存しています。シードが秘密に保たれることと、生成時に予測不可能であることです。ハードウェアウォレットは主に前者を保護するために存在しており、このインシデントは後者の失敗です。BIP-39シードフレーズは人間が読める形式ですが、予測不可能性の要件の根底にあるセキュリティ特性は、その生成に使用されたランダムバイトのエントロピーです。それらのバイトが再現可能であれば、シードも再現可能になります。直感的に言えば、サイコロを振って暗証番号を決める金庫のようなものです。サイコロが偏っていれば、錠前がどれほど強固でも、その偏りを知る者には金庫は開け放たれています。
ウォレットにとって「偏ったサイコロ」とは、弱い乱数生成器を意味します。ハードウェアウォレットは、セキュアマイクロコントローラ上のハードウェア真乱数生成器（TRNG）からシードエントロピーを得ることが期待されています。ソフトウェアの擬似乱数生成器（PRNG）は決定論的であり、内部状態と呼び出し履歴が分かれば出力を完全に再現できるからです。生成器の出力が予測可能であれば、候補範囲を列挙し、アドレス・xpub・公開鍵などの公開ウォレットデータと照合することができ、シードの復元が暗号的に実行不可能な問題からオフライン探索へと変わってしまいます。
COLDCARDのファームウェアは2つの独立したRNGサーフェスを持っていました。MicroPythonはウォレットの暗号ライブラリが期待するグローバルなrng_get()シンボルを公開するSTM32プラットフォームレイヤーを同梱しており、COLDCARDも独自のボードローカルなハードウェアRNGラッパーを維持していました。両サーフェスともハードウェアエントロピーを提供することを意図しており、ウォレットの暗号ライブラリはファームウェアのビルド時に解決される単一のグローバルRNGシンボルを通じてそのどちらかに到達します。
脆弱性分析
根本原因は、MICROPY_HW_ENABLE_RNG設定マクロに関するビルド・インテグレーションエラーでした。COLDCARDの製品ボード設定はこのマクロを0に設定していました。これはファームウェアがMicroPythonのハードウェアRNG実装ではなく、独自のボードローカルなハードウェアRNGラッパーを使用する意図があったためです。しかし、ウォレット生成パスはngu.random.bytes(32)に移行されており、暗号ライブラリのSTM32パスは最終的にMicroPythonによって解決されるグローバルなrng_get()シンボルに依存していました。
問題の連鎖は以下の通りでした：
generate_seed()
-> ngu.random.bytes(32)
-> libngu CHIP_TRNG_32()
-> rng_get()
-> MicroPython STM32 RNGモジュール
-> MICROPY_HW_ENABLE_RNG == 0 のためYasmarangソフトウェアフォールバックボード設定はMicroPythonのハードウェアRNGブランチを無効化していました：
// We have our own version of this code.
#define MICROPY_HW_ENABLE_RNG (0)暗号ライブラリは依然としてマクロをハードウェアRNGの十分な証明として扱っていました [5]。rng_get()を呼び出す前にマクロが存在するかどうかのみを確認していたためです：
extern uint32_t rng_get(void);
#define CHIP_TRNG_32() rng_get()
#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endifこのガードは危険なケースを見落としています。0として定義されたマクロは依然として定義されているため、#ifndefチェックをパスしてビルドが成功します。MicroPythonはマクロの値によってRNG実装を選択するのであって存在の有無ではないため、MICROPY_HW_ENABLE_RNG == 0によりrng_get()はCOLDCARDのボードローカルラッパーではなくソフトウェアフォールバックブランチにルーティングされました [6]：
#if MICROPY_HW_ENABLE_RNG
// STM32ハードウェアRNG
#else
// Yasmarangソフトウェアフォールバック
#endif影響はデバイスの世代によって異なります。Mk2/Mk3ファームウェアv4.0.0-v4.1.9については、Blockの分析 [7] によるとngu.randomに暗号エントロピーが追加されておらず、フォールバック状態と呼び出し履歴が判明すればウォレット生成が決定論的になる可能性があります（Coinkiteのアドバイザリー [2] はMk2/Mk3の範囲をv4.0.1-v4.1.9とやや狭く定めています）。Mk4/Q/Mk5については、セキュアエレメントの素材がハッシュ化されていましたが、ngu.random.reseed()には4バイトのみが渡されており、セキュアな再シードが単一の32ビット状態ワードに制限され、ユーザーが期待するウォレットエントロピーよりはるかに有効な探索空間が少なくなっています。最終的な32ランダムバイトをハッシュ化しても結果のエントロピーを増やすことはできず、すでに制限された候補セットを変換するだけです。
攻撃分析
スマートコントラクトのエクスプロイトとは異なり、このインシデントには追跡すべき単一のオンチェーン攻撃トランザクションはありません。オフラインのシード復元問題に続くオンチェーンスイープでした。前提条件は、影響を受けたユーザーが脆弱なngu.random.bytes(32)パスを通じてウォレットシードを生成していたことであり、そのシード素材が完全なハードウェアエントロピーではなく再現可能なソフトウェアフォールバック状態に依存していたことです。2つ目の推測される前提条件は、影響を受けたウォレットがシードのみから導出可能であったことです。強固でユニークなBIP-39パスフレーズは、RNGの欠陥が触れていないPBKDF2を通じて独立したユーザー提供のエントロピーを混入させるため、そのようなウォレットは純粋なシード列挙の範囲外に置かれます。スイープの規模から、影響を受けたほとんどのユーザーはそのようなパスフレーズを設定していなかったことが示唆されます。その後、復元はおそらく3つのステップで進められました：
- 攻撃者はデバイスのメタデータ、ブートタイミング、RTC/SysTickの仮定、および妥当なRNG呼び出し履歴を使用して候補RNG状態を制約または列挙しました。
- 各候補状態について、攻撃者は候補ウォレットシードを導出し、アドレス・xpub・生成された公開鍵などの公開ウォレットデータと照合してオフラインで確認しました。
- 候補が実際のウォレットと一致した場合、攻撃者はシードを復元し、秘密鍵を再構築して関連するBTCを流出させました。
オンチェーンでは、盗難は7月30日から始まるアドレススイープの急増として現れました。独立したオンチェーンヒューリスティック追跡 [3] は、4,580件の確認済みアドレスから少なくとも1,370 BTC（8月5日のBTC価格$64,099で約$88M）が流出した複数のドレイン波を特定しており、これは合計ではなく確認済みの最小値です。一方、プライベートチャネル [4]（73人の被害者との通信で確認）では、疑わしいものの未確認のドレインを加えると約1,596 BTCから2,055 BTC（~$130M）に上るとしています。
結論
COLDCARDインシデントはエントロピー生成の失敗でした。セキュリティクリティカルなシード生成APIが、設定マクロが有効かどうかではなく存在するかどうかを確認するビルドガードのために、意図されたハードウェアRNGではなく決定論的なソフトウェアPRNGフォールバックに静かに解決されていました。影響を受けたデバイスでは、これによりシードの復元が暗号的に実行不可能な問題からオフライン探索へと変わり、結果として1,370 BTC以上が複数の波にわたって流出しました [3]（プライベートチャネルの集計では約1,596〜2,055 BTC [4] と報告されています）。
中核的なエンジニアリング上の失敗は、出荷されたファームウェアが最もセキュリティクリティカルなAPIが実際に意図されたハードウェアRNGに到達していることを証明していなかったことです。3つのプラクティスがこれを検出できたはずです。暗号エントロピーのビルドガードはマクロの存在と値の両方を確認する必要があること、エントロピーフォールバックはソフトウェアPRNGに静かに代替するのではなくフェイルクローズする必要があること、最終ファームウェアイメージの検証はコードがコンパイルされるだけでなく、シンボルの出所とエンドツーエンドのエントロピーフローをカバーする必要があることです。影響を受けたシードはその場で修正できません。資金は修正済みファームウェアで作成されたウォレットに移動すべきであり、強固でユニークなパスフレーズはシードを修復することなく即時のリスクを軽減します [2]。
この失敗モードは強調する価値があります。この種のランダム性バグは、生成された各シードが個別には有効であるため、機能テストには見えません。欠陥は単一の出力にあるのではなく、それらを生成したソースにあります。そのソースが予測可能で再現可能であるため、シードは集合的に小さく列挙可能な範囲に収まります。オフチェーンの鍵生成コンポーネントには、ファーストクラスのセキュリティ精査が求められます。
参考文献
- [1] BlockSec Phalconによる、COLDCARDウォレットのドレインがシード生成のランダム性の弱さに起因するとのアラート
- [2] Coinkite、エントロピー問題の技術的詳細解説
- [3] coldcardwatch.com、Coldcard Sweep Watch：オンチェーンドレインアドレスの追跡と手法
- [4] Galaxy Research、COLDCARDハック損失推定（被害者報告により~1,596 BTC確認）
- [5] libngu、STM32 RNGパスはグローバルな
rng_get()を参照し、#ifndef MICROPY_HW_ENABLE_RNGのみでガード - [6] Coldcard MicroPython、ハードウェアRNGが無効化されている場合
rng_get()はYasmarangにフォールバック - [7] Block Engineering、COLDCARDファームウェアにおける予測可能なRNGフォールバックと32ビット再シード
今週のその他のインシデント
LULA
BNBチェーン上のBEP-20トークンであるLULAは、2026年7月29日にトークンコントラクトのビジネスロジックの欠陥により約$578Kの損失を被りました。攻撃者が到達可能なパスが特権的なrecycle()関数をトリガーし、RentalコントラクトがPancakeSwap V2ペアから直接LULAを転送し、sync()を呼び出してペアのリザーブを操作された残高に更新することを可能にしました。攻撃者はrecycle()を繰り返しトリガーしてペアのLULAリザーブをほぼゼロに近づけ、少量のLULAを送ってほぼすべてのUSDTと交換しました [1]。
背景
LULAはBNBチェーン上のBEP-20トークンであり、レンタルベースのチームリワードメカニズムを持っています。適格なアドレスはRentalコントラクトに保留中のチームリワードを蓄積し、claimTeamReward()を通じてそれを請求します。請求フロー中、Rentalコントラクトはリワード配布のためにLULAを取得するためにトークンのrecycle()関数を呼び出します。recycle()は任意のユーザーが呼び出せるわけではなく、Rentalコントラクトのみが実行を承認されています。
claimTeamReward()エントリポイントには「EOAのみ」チェックが含まれています。msg.sender == tx.originである外部所有アカウントからの直接呼び出しをサポートし、委任コードのプレフィックスを検査することでEIP-7702委任呼び出しもサポートしています。
自動マーケットメーカー（AMM）では、ペアは保存されたリザーブからスワップの価格を算出し、そのリザーブはペアのsync()関数によって更新され、現在のトークン残高に設定されます。リザーブは通常、スワップや流動性イベントに伴って移動するため、本物の取引を追跡しますが、ペアのトークン残高は直接転送によっても変更でき、sync()は操作されたものであっても存在する残高をそのまま保存されたリザーブにコピーします。
脆弱性分析
根本原因は、LULA.recycle()がRentalコントラクトにPancakeSwap V2ペアから直接LULAを転送し、sync()を呼び出してペアのリザーブを操作された残高に更新することを許可していたことです [1]。
sync()はリザーブをペアに残っているLULA残高に設定するため、この特権パスはUSDT側に影響を与えることなくペアのLULAリザーブを任意に低くすることができます。LULAリザーブがほぼゼロになると、ペアは少量のLULAをほぼすべてのUSDTに相当する価格で算出します。
攻撃分析
以下の分析はトランザクション 0xa219ab9...411d7c に基づいています。
- ステップ1：攻撃者は~197.05M USDTを蓄積することで操作の資金を調達しました。資金はMoolah/Lista、Aave V3、Venus、PancakeSwap V3、PancakeSwap Vault、Uniswap V4 PoolManager、Uniswap V3などの複数のフラッシュローンおよびボロースソースから調達されました。
- ステップ2：攻撃者はPancakeSwap V2ルーターを通じて~197.05M USDTを使用し、大規模な
USDT -> LULAスワップを実行しました。これによりペアのLULAリザーブが約8M LULAから24,022 LULAに急減し、USDT側は約197.64M USDTに増加しました。 - ステップ3：攻撃者は複数のEIP-7702ウォレットを通じてリワードパスを起動しました。各ウォレットはRentalコントラクトの
claimTeamReward()を呼び出し、それがLULA.recycle()をトリガーして、ペアのLULAリザーブを24,022 LULAから0.004 LULAに縮小させながら、ペアには依然として非常に大量のUSDT側が残りました。 - ステップ4：攻撃者はルーターを通じて最終的なPancakeSwap V2スワップをルーティングし、わずか~4,749 LULAをペアに送り、~197.64M USDTを受け取りました。
- ステップ5：攻撃者はすべてのフラッシュローンを返済し、約$578Kの利益を得ました。
結論
BNBチェーン上のLULAトークンは、トークンコントラクトのビジネスロジックの欠陥により約$578Kのエクスプロイトを受けました。攻撃者が到達可能なパスが特権的なrecycle()関数をトリガーし、RentalコントラクトがPancakeSwap V2ペアから直接LULAを転送し、sync()を呼び出してペアのリザーブを操作された残高に再同期させることが可能でした。攻撃者はこれを繰り返しトリガーしてペアの価格を歪め、少量のLULAをほぼすべてのUSDTと交換しました。
トークンコントラクトは、AMMペアの残高を移動してリザーブの再同期を強制できる特権パスを公開すべきではありません。そうすることでそのパスに到達できる者に価格制御を渡すことになるからです。AMM ペアと統合するトークンは、ペアのリザーブを真の市場主導の残高変化に縛り付ける必要があり、価格設定のためにプールリザーブを読み取るロジックは、リザーブを権威あるものではなく操作可能なものとして扱う必要があります。
