8月3日、Solanaブロックチェーンのホットウォレットがハッキングを受け、大規模に資産が窃盗される事件が起きました。
https://www.coindesk.com/markets/2022/08/03/phantom-wallet-exploit-drains-millions-in-sol-tokens/
SolanaはWalk to earnのSTEPNで初期チェーンとして採用されるなど、Web3界隈で注目度の高いプロジェクト。そんなこともあり、ハッキングニュースであふれかえる昨今にあっても、特に注目度の高いニュースになっています。
8月3日夜の時点ではまだ事件の全容は見えてきていないのですが、上記の記事によると次の状況なようです。
- Phantom, Slope, TrustWalletといったホットウォレットから資産が抜かれる被害が発生している
- 現在も攻撃は進行中で、すでに8000以上のウォレットが侵害されている
- ユーザーの秘密鍵によるトランザクションへの電子署名が実施されている
そして、サプライチェーン攻撃の可能性がある、としていますね。
さて本コラムでは、今回のように秘密鍵へのアクセスが実現されてしまう攻撃にはどんなものがあるかを見てみようと思います。
実装にミスがあるケース
ウォレットは暗号技術の固まりです。
暗号処理では、256ビット（10進数だと78桁）といった極端に大きな数字を扱ったり、乱数を扱うのが当たり前の世界です。
ところが、コンピュータ言語の標準機能ではこれらを扱うのは荷が重かったりします。
そこで、各ウォレットを開発する側の人達は、なんとかして暗号処理・ウォレット処理を実現するコードを手に入れないといけません。
- 自前で実装する
- オープンソースな暗号・ウォレットライブラリを利用する
といった選択肢があります。
新しいブロックチェーンを作っちゃおうぜ、といったチームだと自前実装を行う事になります。
ある程度こなれたビットコインのような世界では、誰かが作ってくれたライブラリを利用することができますね。
さて、冒頭のSolanaのケースですと、ホットウォレットが利用している乱数生成部分に問題があった、なんて指摘もちらほらでてきました。
乱数が正しくつくられないとウォレットは正しく機能しません。アドレスから秘密鍵を推定する攻撃に繋がったりします。
怖いのは乱数を利用したタイミングではおかしいことに気付いておらず、生成したアドレスをがっつり利用しちゃってた場合ですね。
今回はその疑いがある、ということですね。
乱数を正しい乱数として生成するのって意外と難しい問題で、ソフトウェア開発者が気楽に作るといとも簡単に偏りが生じます。
出力を見ただけでは偏りに気づけないところが問題をややこしくしています。
数字の列をみて、これは真に乱数だ！なんてどうやって言い切れるでしょうか。
是非、乱数の生成については片山さんがハンズオンをコラムにしてますので試してみてください。でてきた数字列をみて、これは真に乱数かな？なんて考えてみましょう。
2021年8月18日
秘密鍵はどのように生成されているのか？
こんにちは。AndGoのハードウェア担当の片山です。 突然ですが，日本の小学校の教室には写真のようなロッカーがあります。実は皆さんの暗号資産はこのようなロッカーの中に入っているのと同じです。鍵がかけられていないので，資産が入っている場所さえわかれば簡単に盗み出すことができてしまいます。 え！？っと思った方も多いでしょうが，小学校のロッカーとの違いはロッカーの個数です。小学校のロッカーは30個程度しかないので，全数探索することができてしまいます。一方でビットコインの場合はロッカーの個数が2の256乗個あります。10進数で77桁の数字となります。もし世界の全人類が貴方のビットコインが入っている…
AndGoハードウェア担当
昨今では、こうした基礎な部分を自前で実装するのは危ない、すぐバグが入り込む、という認識がソフトウェアエンジニアな人々に広がりました。
オープンソースで公開され沢山の人が利用しているライブラリこそが検証されているのだから積極的に利用すべきだ、と推奨されています。
確かにその通りではあるのですが、皆さんDon’t trust, verifyの精神を忘れがちです。
みんなが使っているんだから安心、となっちゃうんですね。
今回のSolanaの件がそんな状況なのかはまだ分かりませんが、推移を見守りたいと思います。
ウォレットを構成するライブラリにマルウェアが仕掛けられたケース
2018年11月、BitPayという会社によるCopayウォレットが攻撃を受けたことが発覚しました。
いまどきのソフトウェアは沢山のオープンソースに依存しています。Copayもそうで、NodeJSというプラットフォーム上のライブラリを利用しています。
そんなオープンソースなライブラリは一個人が開発しメンテナンスしていることが多いです。そのため、ちょっとやる気がなくなったとかで新機能の追加ばかりか、メンテナンス（見つかった脆弱性を修正する作業）が滞ることも多々あります。
それでは困りますので、ライブラリの利用者コミュニティからボランティアが登場し、メンテナンス作業を手伝う世界感が確立していたりします。
コーディング作業を手伝う人は、Pull Requestとよばれるコード修正案をGitHub上で投げます。ライブラリの著者は、その中身を見て問題がなければマスターソースに取り込みます。
Copayへの攻撃は、Copayが利用しているライブラリが更に利用している親ライブラリにマルウェアを仕込むPull Requestが投げられる形で行われました。
Pull Requestは全力トラスト！と取り込んでしまった、という事件でした。
そもそもオープンソースの作者は、下流のどんなソフトウェアで利用されているかなんて把握していないのが普通です。
下流への影響まで鑑みて内容を吟味するのは構造的にも難しかったかもしれません。
ソフトウェアではありますが、立派なサプライチェーン攻撃ですね。
車やハードウェアウォレットなどのものづくりの世界では部品表（Bill Of Materials, BOM）をつくるのが常識になっています。
サプライチェーンを可視化することで弱いポイントがないか対策しよう、ということですね。
昨今ではソフトウェアの世界でも同様の運動がはじまっています。
例えば2022年1月19日、米国バイデン大統領が「国家のサイバーセキュリティ向上に関する大統領令」を発表し、その中でソフトウェアのサプライチェーンセキュリティの強化、について言及しています。
https://crds.jst.go.jp/dw/20220411/2022041131489/
各製品のソフトウェア部品表（SBOM）を購入者に直接または公開Webサイトで提供すること、を要求しています。
さて、はたしてこれで十分な対策になるのでしょうか。
ソフトウェアのソースコードにはそもそもどんなライブラリに依存するか、という情報は記述されていました。そうじゃないと動かないからです。
足りなかったのは、やはりDon’t trust, verifyの精神な気がします。
部品表を作る事だけに躍起になり、verifyが相変わらずおそろかになってしまう。
これだけは避けたいところです。
もう一歩踏み込んで、「verify」な部分まで電子署名等の技術でまきとりたいですね。
あれ、どこかで聞いた話。
Web5のVerifiable Credentialなんて相性よいのではないでしょうか。
【2022/6/16】Jack Dorsey率いるTBDが提唱する"Web5"はどういう構想？
ジャック・ドーシーらが提唱する「Web5.0」とは
豊かな知識とともに。
加藤 規新
夏休みの自由研究として考えてみてはいかがでしょう。
まとめ
ここ数ヶ月だけでもブロックチェーン系プロジェクトへの攻撃が重なるのを鑑みるに、いくらエルサルバドルでビットコインが法定通貨になったんだ！といったところで、ビットコインから始まったCrypto Currencyというパラダイムはまだ壮大な社会実験フェーズにあるといえます。
このことをしっかりと心にとどめつつ、触れて楽しむ、の心意気が大事そうです。
個人として対応出来ることは、正しい知識・リテラシーを育てることかと思います。
機械仕掛けな世界が広がった分、残り続けるトラストポイントへの信用度はより高まっています。その辺をしっかりDon’t trust, verify できるようになりたいですね。
次の記事
読者になる
一緒に新しい世界を探求していきましょう。
ディスカッション