ビットコインユーザーなら抑えておきたい！ビルドシステムへの攻撃とその対策

2019年6月8日から9日にかけて、アムステルダムでBreaking Bitcoinというカンファレンスが行われました。

本コラムは、公開された動画や書きおこしをもとに、その発表内容を追いかけ、ビットコインのセキュリティに関する取り組みの最先端を知ろうという試みです。発表内容を日本語で、かつ実際の事例などを交えて解説することで、少しでも皆様がビットコインの仕組みや最新の研究について詳しくなるための一助になれることを願います。

今回は、Carl Dong氏の講演について見てみましょう。

ユーザーが知っておきたい攻撃者の手法とその対策

ビットコインを盗むとき、ひとつの簡単な方法は、ユーザーがビットコインのウォレットをダウンロードするとき、それを悪意のあるファイルにすりかえてしまうことです。ダウンロードが完了し、ユーザーが実行すると、悪意のあるファイルが実行され、ビットコインを勝手に転送したり、パスワードを盗み出したり、ということが可能です。

もちろん、技術的に可能という意味であり、それほど簡単なわけではありませんが、ここではどういった方法で身を守れるかを考えます。

攻撃はビルドやコンパイル時に狙われる

ファイルをダウンロードした際にユーザーは、悪意のある攻撃を受け、ビルドしたファイルが書き換えられている可能性があります。

ビルドとは、簡単に言えば、コードを実行可能にすることです。たくさんのコードの断片をつなぎあわせ、ひとつひとつの小さな部品を組み合わせるような形なので、ビルドと呼ばれています。ビルドシステムとは、そのビルドを行うための環境と思っていただければよいでしょう。

プログラマーはコーディング、つまり意味のある文字列をコンピュータに打ち込み、プログラム（ソースコード）を書きます。ですが、そのプログラムはそのままでは動きません。ソースコードをコンパイラで処理してビルドすることで、実行可能なバイナリ形式、つまりファイルに変換して公開することになります。（例えばWindowsなら.exe）

コンパイラで処理をすることから、ビルドすることをコンパイルする、という言い方もします。差異はありますが、どちらもほとんど同じ意味と思っていただいてよいでしょう。

ファイル変換を行う不正攻撃に対する対策

途中でファイルが書き換えられることへの対策としては、例えば bitcoincore.orgでは実行可能なファイルと一緒にシグネチャ（著名）が付属されているので、このシグネチャを使うことで、発信元が提供しているオリジナルのファイルがダウンロードできた、ということを確認することができます。シグネチャも同時にダウンロードすると、やはり改ざんできてしまうので、事前にシグネチャだけダウンロードしておくことが推奨されます。

このシグネチャで確認したときに異常が出た場合は、ネットワークの途中でファイルが書き換えられた場合に検知することができます。必ずすべての人が、この手順を実行する必要がある、というわけではありません。攻撃では高度な技術が使われますし、シグネチャによる確認にもちょっとした知識が必要だからです。

個人的には、より簡単な仕組みで書き換えを検知できるようになるべきだ、と思っています。 とはいえ、現時点では他に良い仕組みもなく、多くの資金を持っている方であれば、ひとつでも多くの対策を施すべきでしょう。

しかし、もっと疑り深くて知識を持っている人は、実際に書かれたソースコードと、実行可能形式のファイルを比較したいと思うことでしょう。なぜなら、Githubなどで確認できるソースコード自体には問題が無くても、ユーザーから見えないところで悪意のあるコードが挿入され、その後でコンパイルされている可能性を否定できないからです。

そういった場合には、Gitianが使えます。ソースコードが同一だった場合、全く同じ出力になる仕組みです。つまり、Githubからソースコードを持ってきてコンパイルし、ダウンロードしたファイルと比較することで、一致すれば配布されているファイルが正当なものと確認できます。

実際、途中で生成されるgitian assertファイルをアップロードしたgitian.sigs.gitが存在しています。ビットコインは、gitian assertファイルで確認が可能な、数あるプロジェクトのうちの一つと言えます。

プログラマーにとってはさらにこんな悪夢が

では次に、こんな例を考えてみましょう。 ニックは非常に簡単なプログラムを修正しています。先輩が書いたシンプルなもので、単純なメッセージを表示するだけのものです。プログラムを確認して、コンパイルし、実行をしました。

すると、入れた覚えのない、悪意のあるメッセージが表示されました。ニックはソースコードを読み、一か所、おかしな場所を修正しました。これで大丈夫だと何度もコードを読んで確信し、コンパイル後に実行します。

でも、また同じメッセージが表示されます。何度も読み返しても、おかしなところはありません。

ニックが何日もかけて調査した結果、原因は使っているツールにあることを特定しました。 コンパイルするたび、とあるツールがコードを挿入していたのです。これでは、ソースコードをいくら読んでも意味はありません。

最終的に、ニックはツールも含めてOSをセットアップしなおしました。その後は正常に動作するようになりました。

ここで注目すべき点は、ソースコードだけを完璧に監視あるいは監査できたとしても、必ずしも十分ではない、ということです。

しかし、各個人や組織がコンパイルを行う環境まで厳密に管理させることはできません。正しく管理しているつもりでも、マルウェアやスパイウェアが混入する事例があるのです。

さらに、ユーザーに悪意のあるファイルをダウンロードさせるだけでなく、自動アップデートでマルウェアを配布するという手口も多くなってきています。

例えば、2017年にはCCleanerというツールの自動アップデートにマルウェアが入り込みました。最近では今年に入って、ASUSというコンピュータメーカーの自動更新システムが乗っ取られ、マルウェアが配信されるという事件もありました。影響を受けたユーザーは推定で100万人に及ぶという試算もあります。

モバイル端末ですら例外ではありません。iPhoneの脆弱性を複数組み合わせて攻撃していた事例も確認されており、完璧に安全な環境というものは存在しない、ということを強く意識させられます。

ツールを守るための解決策

対策のひとつは、gitianに頼らず、ツールをパッケージマネージャで管理することです。完璧ではありませんが、十分有効な対策と言えるでしょう。

パッケージマネージャとは、様々なツールを簡単にインストールしたり削除したりする機能を持つ管理ツールと呼ぶべきものです。講演では開発中のguixを提案しており、これによって信頼できるツールや特定のバージョンを入れやすくし、かつ悪意が混じりにくいようにできる、という点を述べています。

guixが使えると、どのOSでも同じように動作するので、全く同じ結果が得られる「再現可能なビルド」が実現できるようになります。

現在guixのブートストラップバイナリは232MBで、これはdebianというディストリビューションの数分の一です。しかし現在のmesのバージョンでは、gccを信頼可能なバイナリとして扱うことで削除し、131MBにまで縮小できました。

仮想通貨で使われていたモジュールに悪意あるコードが挿入された事例もあるので、今後もguixが活発に開発を続けることに期待したいですね。

まとめ

以上、今回はCarl Dong氏の講演をまとめました。

なお、記事中の表現については講演資料を筆者なりに読み解きつつ、前後で独自の解説を加えておりますが、なにぶん新しい技術に関する内容ですので、もしも間違いなどございましたらお気軽にご指摘くださいませ。（特に技術的な指摘は大歓迎です）