Binanceの63億ドル規模のインシデント：何が起き、どうリスクを減らすか

Binanceの初期調査では、6月と9月に従業員の端末が侵害され、その後10月20日に社内AIツールを通じて侵入範囲が広がったとされています。攻撃者は同僚2人のコンピューターに到達し、コンテナーをデプロイするためのトークンを見つけました。10月29日にはそのトークンで悪意あるコードをデプロイし、ウォレット署名システムに到達して不正送金を開始しました。

攻撃者は署名サービスを利用して、EIP-7702による委任も作成しました。これは、攻撃者が制御するコードにEthereumウォレットの代理として動作する権限を与えるものです。この権限はBinanceの出金システムとは独立してブロックチェーン上に存在していました。出金を停止しても解除できず、Binanceはオンチェーンで別途取り消す必要がありました。

重要なのは、活動を止めることと、その活動を可能にする権限を取り除くことの違いです。端末の交換、デプロイ用認証情報の失効、別のシステム内の権限の取り消しは、それぞれ侵入の異なる部分に対処します。

ノートPC、デプロイシステム、機密性の高いサービスは、それぞれ異なる役割を担います。一つへのアクセスが自動的に次へのアクセスにつながると、リスクは高まります。盗まれたトークンでソフトウェアを置き換えられる場合、そのソフトウェアは従業員自身が直接持っていなかった権限で動作する可能性があります。

この連鎖をどこで断ち切るかを考えるには、次の四つの問いが役立ちます。

1. 認証情報の露出。 従業員1人の端末から、攻撃者は本番環境のどのアクセス権を取得できるでしょうか。
2. デプロイ権限。 そのアクセス権で動くコードを変更できるのは誰でしょうか。
3. サービス側の認可。 機密性の高いサービスは、そのコードからどの操作を受け入れるでしょうか。
4. アクセスの永続化。 元のアカウントを無効化しても、どのような新しい権限が残り得るでしょうか。

目標は、システム間で権限が引き継がれる範囲を制限し、侵入中に作成された追加のアクセス権を特定して取り消すことです。以下では、その目標を支える四つの対策を検討します。

対策1. ノートPCから露出し得る認証情報を減らす

認証情報が攻撃者に役立つのは、別のシステムがそれを権限の証明として受け入れるためです。従業員の端末に置く本番用認証情報を減らせば、ツール、リポジトリ、ブラウザーのセッションが侵害された際に盗まれるものを減らせます。

日常業務で従業員に必要なのは、多くの場合、サービスの再起動などの操作を要求する権限です。実行に用いる認証情報は、別の実行用IDに持たせることができます。露出を減らすには、不要なコピーの削除と、残る認証情報の管理を組み合わせます。

• 可能なところでは、日常的な直接アクセスを、範囲を限定した操作に置き換えます。
• 職務ごとにIDを分け、それぞれの権限範囲と有効期間を制限します。
• 認証情報、その所有者、失効方法を一覧で管理します。

これは、OWASPのシークレット管理ガイダンスにある、人がシークレットを扱う機会を減らし、各IDに必要なアクセス権だけを与える原則の適用です。ワークステーションが盗まれたり侵害されたりしても、露出する再利用可能な認証情報が減り、対応担当者は失効が必要な認証情報の所有者を把握できます。

対策2. デプロイ権限を本番環境の特権として扱う

シークレットが本人には見えなくても、その人がデプロイするコードには利用可能な場合があります。コードを変更できる人は、シークレットの読み取り、内部APIの呼び出し、アプリケーションのサービスアカウントとしての動作が可能かもしれません。そのため、デプロイ権限は、結果として動くワークロードの権限を踏まえて評価する必要があります。

OWASPのCI/CDセキュリティガイダンスは、リポジトリの変更、パイプライン設定、実行ホストを一つのセキュリティ課題の構成要素として扱っています。保護はデプロイ前のコードとデプロイ後の権限の両方を対象にします。

• 本番用コードのレビューを必須にし、自動化が実行するリポジトリのブランチを保護します。
• メインスクリプトだけでなく、タスク定義、依存関係、起動時の入力に対する変更も管理します。
• ワークロードには、その機能に必要な認証情報とネットワークアクセスだけを与えます。

この二つの対策群は連携する必要があります。リポジトリとデプロイの権限は、誰がコードを変更できるかを決めます。別途定めるID、ホスト、ネットワークのポリシーは、実行後にコードができることを制限します。シークレットの集中管理は露出を減らし、これらのポリシーはシークレットを利用するプログラムを制約します。

対策3. 呼び出し元だけでなく、操作を認可する

署名サービスは秘密鍵を隠したままでも、有害な署名要求を受け入れてしまうことがあります。データベースやクラウドAPIでも同様です。ワークロードの認証は呼び出し元を識別し、認可は何を実行してよいかを決めます。

OWASPはすべてのリクエストで認可を確認し、明示的に許可されていないアクセスを拒否することを推奨しています。受信側のサービスでは、許可された送金先と金額、データベース操作、インフラ変更など、操作と対象の両方を確認する必要があります。

呼び出し元がすでに信頼されていても、要求された操作を評価するサービスであるべきです。自動化は作業の要求方法を管理し、受信側のサービスは受け入れる操作を管理します。

対策4. 侵入中に作成されたアクセス権を取り消す

攻撃者は正規のIDを使い、別の認証情報を追加したり、さらなる権限を付与したりすることがあります。MITRE ATT&CKではアカウント操作を、クラウド認証情報やSSH鍵の追加などによってアクセスを維持または拡大する手法として説明しています。元のセッションを無効化しても、それらの変更が取り消されるとは限りません。

Binanceのオンチェーン委任は、対応担当者が影響を受けたシステム自体の権限を調べる必要性を示しています。封じ込めは、最初の足がかりと、そこから作られた権限の両方を対象にします。

• 追加の認証情報を作成したり権限を付与したりできる自動化用IDを制限します。
• 新しく作成されたアカウント、セッション、委任を対応計画に含めます。
• タスクが停止しただけで封じ込め完了とせず、権限を実際に強制するシステムで失効を確認します。

これらの手順により、対応担当者は調査して取り消すべきIDと権限を明確にできます。また、封じ込めを検証可能にできます。影響を受けたサービスへの既知の経路が、本当に一つずつ閉じられたかを確認できるためです。

これらの対策は、従業員の端末、デプロイシステム、受信側のサービス、対応プロセスという異なる層で機能します。各層に責任者を置き、別の層が侵害されても制限が維持されることを確認する方法が必要です。

自動化管理プラットフォームは、従業員の要求から本番環境での実行までの部分に対応します。Semaphore UIでは、チームが定義済みタスクを準備し、実行または変更できる人を管理して、別のIDで実行できます。対象サービス内の認可や、他の場所で作成された権限の取り消しは、引き続き各システムと対応チームの責任です。

APIサービスを再起動する必要があるオンコールエンジニアを考えてみましょう。保守担当者は、対象ホストと再起動方法を固定したPlaybookとTask Templateを準備します。エンジニアは本番環境へのSSHセッションを開かずに、タスクを起動して結果を確認します。以下の二つの経路は同じ再起動を行いますが、実行用認証情報を持つ主体が異なります。

再起動のワークフローは、制限された実行用IDの作成、ユーザーが実行または変更できる内容の定義、実行環境の選定、結果の可視化という四つの手順で構築します。整備できたら、同じ考え方をデプロイにも広げられます。

盗まれたオペレーターセッションからも、そのアカウントに許可された操作は要求できます。許可された再起動でも、繰り返し実行されるとサービスを妨害する可能性があります。ステージング環境で実際に近いオペレーター用アカウントを使い、できることと悪用への対応の両方を検証します。

• タスクと入力の権限。 別のブランチ、インベントリ、引数を含め、実際のロールと起動時オプションを試します。
• 意図した操作の範囲外へのアクセス。 runnerのプロセスが到達できる範囲を含め、他のテンプレート、認証情報、本番システムへのアクセスを確認します。
• 検知と運用への影響。 結果の受信者、予期しない活動の調査担当者、繰り返し実行が許容できない障害を起こすかを確認します。
• 失効。 セッションとトークンの失効をテストし、実行用IDが別の場所で作成できる権限を特定します。

テスト用アカウントに残るアクセス権を記録し、操作の目的を超える経路を閉じます。演習を終える時点で、盗まれたセッションで何ができるか、その悪用をどう検知して封じ込めるかを把握している必要があります。

アクセス制御は、エンドポイント保護と、対応方法を理解しているチームと組み合わせて機能します。共有鍵や文書化されていない近道に戻らずに使えるよう、準備済みワークフローを十分便利にします。次の日常的な取り組みで支えましょう。

• 未知のインストーラーや面接課題は、企業の認証情報、ホストのマウント、内部ネットワークへのアクセスを持たない、使い捨ての隔離環境で実行します。
• 不審な活動を、責められる心配なく早期に報告できるようにします。明確な連絡先とインシデント対応経路を用意します。
• 職務の変化に応じてアクセス権を見直し、管理された緊急アクセス手順を維持し、インシデント前に失効の訓練を行います。

これらの取り組みは、予防、検知、復旧を日常業務に結び付けます。責任が変わってもアクセスモデルを正確に保ち、不審な事象が発生した際に、チームが慣れた手順で対応できるようにします。

中心となる教訓は、侵害された一つのIDが蓄積できる権限を制限することです。ノートPC上の認証情報の削減、レビュー済みの自動化、制限された実行ホスト、本番サービス内の認可は、それぞれ攻撃者が取れる経路を減らします。

Semaphoreは、準備済みタスク、実行と編集の権限分離、集中提供する認証情報、確認可能な実行記録を通じて、これらの対策の一部を反復可能なワークフローにします。オペレーターは業務に必要な操作を得て、保守担当者はその背後のコードと認証情報を引き続き管理します。

よく使う本番操作を一つ選び、タスクテンプレートを準備し、必要なオペレーター権限を割り当てます。置き換える直接接続を廃止する前に、得られたアクセス範囲をテストします。有効な進捗指標は、次に侵害されるアカウントで攻撃者ができることを、どれだけ少なくできたかです。