警戒を：著名なRustaceanを狙った標的型攻撃
Rustのセキュリティチームは9月17日、説得力のあるビデオ通話から悪意あるクレートの公開へと進展した標的型キャンペーンが少なくとも1件確認されたことを受け、強い警告を発した。警戒を：著名なRustaceanを狙った標的型攻撃は、一般的なフィッシング注意喚起ではない。攻撃者は、Rustプロジェクトのメンバーや人気クレートの所有者に接触している。メンテナー1人が侵害されるだけで、数千もの下流開発環境が危険にさらされ得るためだ。
このキャンペーンでは、最初の接触を求人、コンサルティング案件、投資に関する話し合い、契約の機会などに見せかける。ビデオ通話中またはその後、標的は技術的な問題と称される状況に遭遇する。その解決策として、音声コーデックのインストール、コマンドの実行、あるいは攻撃者が管理するプロジェクトを開くことが提案される。
このソーシャルエンジニアリングは、過去に成功したようだ。8月20日、攻撃者は侵害したメンテナーアカウントを通じ、arrayref、internment、append-only-vecの悪意あるバージョンを公開した。そのコードはコンパイル中に実行され、通常の依存関係更新を、開発者のワークステーションや継続的インテグレーションシステムへ到達する経路へと変えた。
もはや中心的な対立は、単純に信頼できるコードと悪意あるコードの間にあるわけではない。個人的な信頼とパッケージの権限との対立である。こうした通話を受ける人々は、私的な侵害をソフトウェアサプライチェーンのインシデントへ変え得る公開権限を持っている。
著名なRustaceanを狙った標的型攻撃は、サプライチェーンへの警告となった
Rustプロジェクトがメンテナーに警告しているのは、攻撃者が個別のファイルやパスワードだけでなく、公開権限を狙っていると考えているためだ。
Adam Harveyは、crates.ioチームおよびRustセキュリティ対応ワーキンググループを代表し、標的型攻撃に関する警告を公開した。両チームは、継続中のキャンペーンがrust-langのメンバーと人気クレートの所有者を標的にしているとみている。
想定される目的は、デバイスやアカウントを侵害し、そのアクセスを使ってマルウェアを公開することだ。この評価は、私的なソーシャルエンジニアリングと公的な配布手段を結び付ける。開発者のワークステーション、ブラウザセッション、メールアカウント、またはcrates.io認証情報は、その両者をつなぐ橋になり得る。
報告されている手口は、魅力的な機会の提示から始まる。見知らぬ人物が、求人、プロジェクト、アドバイザー職、投資に関する会話、または契約を提案する。この誘いは返信する価値があるように十分調整されており、発信者はプロらしく見えるプロフィールで説明を補強する場合がある。
攻撃者は、もっともらしい企業アイデンティティやLinkedInの存在を作り出していると報じられている。これらの資産は、厳密なデューデリジェンスに耐える必要はない。一方的なメッセージから通話の予定が組まれるまでの短い期間、信頼できそうに見えればよい。
その後、通話中に人為的な障害が作られる。音声がうまく機能しない、コーデックが不足しているように見える、あるいはアクセスを復旧するにはコマンドが必要だとされる。別のパターンでは、コマンドをクリップボードに配置し、標的にターミナルへ貼り付けるよう促す。
この瞬間が重要なのは、コード実行がトラブルシューティングとして再定義されるからだ。標的は、未知のプログラムを意図してインストールしているわけではない。画面越しで相手が待つなか、よくある通信上の問題を解決していると信じている。
Rustの警告は、見知らぬ相手からの接触をより慎重に扱い、すでに信頼しているプラットフォームを利用するよう求めている。また、可能な限り標的側が会議を作成することを推奨している。これにより、やり取りから少なくとも1つの攻撃者管理コンポーネントを除ける。
メンテナーには、予期しない活動がないかアカウントを確認し、多要素認証が有効であることを確認するよう求められている。crates.ioへのアクセスについて懸念がある場合はサポートアドレスに連絡でき、より広範なインシデントはRustセキュリティチームへ報告できる。
これらの推奨事項は意図的にシンプルだ。このキャンペーンで危険なのは、難解なRustの脆弱性ではない。信じられる人間的なやり取りの後に行われる、一見ありふれた行動が、隠れた結果を伴うことにある。
この警告は、報告されたすべてのインシデントが単一の攻撃者によるものだとは主張していない。Rustのチームは、6月の試み、arrayrefの侵害、現在の活動が単一のキャンペーンなのかについて、まだ分からないと明言している。この不確実性は帰属判断を抑制すべきだが、差し迫ったリスクを下げるものではない。
だからこそ、警戒を：著名なRustaceanを狙った標的型攻撃は、その抑制的な表現以上の重みを持つ。この警告は、仮説上の脅威モデルではなく、実際の公開アカウント侵害を受けたものである。
arrayrefのインシデントは、侵害されたメンテナー1人が何を可能にするかを示した
arrayrefへの攻撃は、正規メンテナーアカウント1つの支配を、既存の3パッケージにわたる悪意あるリリースへと転換した。
8月20日7時15分UTC、Rustセキュリティ対応チームはproc-macro1が悪意あるものであるとの報告を受けた。調査員は、そのビルドスクリプトがリモートのペイロードをダウンロードすることを確認した。
ビルドスクリプトとは、Rustのパッケージマネージャー兼ビルドシステムであるCargoが、パッケージのコンパイル中に実行するコードである。正当なセットアップ作業を行うこともあるが、アプリケーションの起動前に実行される。そのため、マルウェアを隠す魅力的な場所となる。
チームは、新しいarrayrefリリースがproc-macro1に直接依存していることを発見した。最近のクリーンなリリースもyankされており、依存関係の解決が悪意あるバージョンへ向かう可能性があった。攻撃者は、同じメンテナーアカウントが管理するinternmentとappend-only-vecの2クレートでも同じパターンを繰り返した。
公式のarrayrefインシデント通知では、汚染された3つのリリースが特定された。arrayref 0.3.10は86分間、internment 0.8.7は90分間、append-only-vec 0.1.9は107分間利用可能な状態だった。
こうした時間はカレンダー上では短く見える。しかし、自動化された依存関係解決、開発者によるビルド、エディターツール、継続的インテグレーションジョブが新しいパッケージを取得するには十分に長い。
Rustチームは、悪意あるバージョンと関連する6つのクレートを削除した。攻撃者がyankしたクリーンなリリースを復元し、影響を受けたメンテナーアカウントをロックした。対応チームは、正規の作者が悪意を持って行動したとは考えていないと述べた。
むしろチームは、作者のコンピューターまたは認証情報が侵害された可能性が高いと評価した。この区別は重要だ。認知されたメンテナーが追加することを選ばなくても、よく知られたパッケージが攻撃者管理下のコードを含み得るという、評判の限界を示している。
セキュリティ研究者は、arrayrefの累計ダウンロード数を約2億4,500万回と見積もった。internmentは約1,440万回、append-only-vecは約450万回だった。累計数は影響を受けたインストール数と同義ではないが、なぜアカウント選定が重要なのかを示している。
攻撃者は、未知のパッケージを仕込み、採用を待つ必要がなかった。開発者がすでに受け入れていたプロジェクトの背後に、悪意ある依存関係を配置したのである。汚染された親パッケージは、それ以外の点では見慣れたものに見えた。
これらのクレートは技術的役割も異なっていた。arrayrefはスライスから固定長配列への参照を取得するためのマクロを提供する。internmentは、繰り返し現れる値を共有コピー1つとして保存するインターン処理を支援する。append-only-vecは、既存エントリを削除しない並行ベクターを提供する。
これらの機能のどれも、リモート実行ファイルのダウンロードを自然に連想させるものではない。その不一致は、新たな依存関係とビルド時の挙動を調べて初めて明らかになった。
したがって、このインシデントは、その後に届くあらゆる偽の機会の文脈を変えた。影響力の大きいメンテナーへの求人問い合わせは、もはや個人的なスパムとしてだけ評価できない。次のRustサプライチェーン攻撃の初手を意味する可能性がある。
偽の面接詐欺は、職業上の礼儀をコード実行へ変える
攻撃者は、メンテナーが機会を検討しようとする姿勢を悪用し、通常の協力行為によって攻撃者のコードが実行されるよう、やり取りを仕組む。
このキャンペーンで最も危険な部分は、マルウェアがcrates.ioに届く前に起きる。まず標的に関する調査から始まる。パッケージの所有権、プロジェクトの所属、カンファレンス出演、職業上の関心は、しばしば公開情報だ。
その情報は、攻撃者が関連性のある提案を作る助けになる。一般的なリクルーターのメッセージは無視されるかもしれない。しかし、メンテナーの仕事に言及する提案であれば、もっともらしい企業サイトやソーシャルプロフィールに支えられた場合、会話につながり得る。
Rust開発者Matt Mastracciが記録した6月のインシデントは、必要とされる準備を示している。偽造された投資担当者がアドバイザリー業務について彼に接触し、ビデオ会話を予定し、その後技術課題を送付した。
提供されたリポジトリは、通常のTypeScriptプロジェクトを含むように見えた。その指示では、受信者に型チェック、テスト、ビルドを実行するよう求めていた。Mastracciによる失敗した攻撃の分析では、TypeScriptに適用されたパッチ内に悪意あるコードが隠されていたことが判明した。
想定された開発コマンドを実行すれば、ペイロードが起動していたはずだ。リポジトリは、画像内に隠されたコンポーネントや分離されたプロセスを含む、複数層の隠蔽を用いていた。Mastracciは、その結果を、コマンド実行とファイルアクセスが可能なリモートアクセス型トロイの木馬と説明した。
彼はプロジェクトを実行前に調査したため、この事例でマシンが侵害されることはなかった。しかし、これは明白なフィッシング対策だけでは不十分な理由を示している。攻撃者は、粗雑な実行ファイルの添付を送ったわけではない。有害な行為は、標的が行うことを期待された作業の中に埋め込まれていた。
より新しいビデオ通話のパターンは、同じ圧力をライブでのやり取りに凝縮する。標的がトラブルシューティングする間、誰かが待っている。遅れは気まずくなり、会議を終えるより提案された解決策を試すほうが容易に感じられる。
クリップボードを使うパターンは、攻撃者にとって特に有用だ。ウェブサイトや通話参加者は、完全な効果を意味ある文脈で表示することなくコマンドを提供できる。それをシェルに貼り付けると、会話への信頼が直接オペレーティングシステムへ移される。
コーデックを装う手口も同様に機能する。音声問題は一般的であり、その説明はありふれたものに聞こえる。しかし、本物の会議プラットフォームなら、基本的な音声を機能させるために、見知らぬ相手独自のダウンロードを要求するはずがない。
最も安全な解釈は、見慣れない会議がすべて敵対的だということではない。会議環境は、それを手配した人物から自動的な技術的信頼を受け取るべきではない、ということだ。
既知のプラットフォーム上で通話を設定すれば、このバランスは変わる。本番用認証情報を一切含まない、使い捨てかつ隔離された環境内でのみ予期しないリポジトリを開くことも有効だ。どちらの対策も発信者の正当性を証明するものではないが、発信者の筋書きの価値を下げる。
この偽面接詐欺が狙うのは、crates.ioのパスワードだけではない。開発者のマシンには、GitHubセッション、クラウド認証情報、SSH鍵、署名用素材、ブラウザCookie、パッケージトークン、非公開ソースリポジトリへのアクセスが含まれている可能性がある。
攻撃者は、これらの資産のいずれも侵害の拡大に利用できる。最終的な悪意あるクレートは目に見える結果である一方、盗まれた組織の認証情報は見つからないまま残る可能性がある。
ここに、警戒を：著名なRustaceanを狙った標的型攻撃の根底にある核心的な逆転がある。攻撃者は主としてRustのメモリモデルを悪用しているのではない。Rustの共有インフラを維持する人々をめぐる職業上の信頼を悪用している。
ビルド時の実行は、小さなパッケージ変更を大規模な露出へ変える
悪意あるリリースが危険だったのは、下流の開発者がライブラリ関数を呼び出す前、ビルド中にCargoが攻撃者の依存関係を実行したためだ。
汚染されたクレートには、proc-macro1という依存関係が追加されていた。この名前は、広く使われている正規パッケージproc-macro2によく似ている。これは、信頼された依存関係と誤認されるような名前を攻撃者が選ぶタイポスクワッティングの手法だ。
悪意あるパッケージは、正規プロジェクトの見た目の多くを模倣していた。有害な動作はビルドスクリプトであるbuild.rsに埋め込まれていた。この分離により、親クレートは想定どおりのソースを保ちながら、依存関係の1行を通じてペイロードを導入できた。
技術的なパッケージ分析によると、このスクリプトはエンコードされた断片からネットワークアドレスを再構築し、通常の証明書検証を無効化していた。Linux、Windows、IntelベースのmacOS、Appleシリコン搭載macOS向けのペイロードを選択していた。
Unix系システムでは、このスクリプトは実行可能ファイルを/tmp/rust-setupに書き込み、完了を待たずに起動した。Windowsでは、PowerShellスクリプトを作成し、Visual Basicスクリプトを用いて隠しプロセスで起動した。
それ以外の点では、ビルドは正常に完了したように見えた可能性がある。これは重要だ。目に見える失敗は調査のきっかけになることが多い。通常どおりコンパイルされるパッケージは、開発者が推移的依存関係を調べる理由を減らす。
研究者らは、コピーされたパッケージがネットワークや暗号化のライブラリを含む追加のビルド依存関係を宣言していたことも確認した。小規模なマクロパッケージにインターネットへ接続する明確な理由がない場合、この種の追加は疑わしい。
別の分析では第2段階のマルウェアが復元され、より広範な機能が見つかった。報告された機能には、ホストのプロファイリング、ブラウザーデータの調査、永続化、コマンド実行、フォールバック通信手段などが含まれていた。
Wizのマルウェア調査は、北朝鮮の攻撃者に帰属されている別の活動とのインフラ重複を見つけた。この分析は、コマンドパス、ホスティング範囲、関連キャンペーンのパターンを結び付けている。
ただし、インフラの重複は決定的な帰属と同義ではない。サーバーは再利用、複製、貸与される場合があり、調査者を混乱させる目的で意図的に選ばれることもある。Rustプロジェクトも、特定された1グループが関連するすべての活動に責任を負うとは断定していない。
慎重な結論であっても深刻だ。この技術的な連鎖は、表面的なソースレビューをすり抜け、一般的な開発作業中に実行されるよう設計されていた。依存先プロジェクトをビルドするだけで十分だった。アプリケーション側でarrayref、internment、append-only-vecを呼び出す必要はなかった。
これにより、潜在的な被害者の範囲は本番デプロイメントを超えて広がる。ロックファイルを更新した開発者が影響を受ける可能性がある。プロジェクトの解析中にCargoを呼び出すCIランナー、自動依存関係更新ジョブ、エディターツールも同様だ。
ロックファイルは、ビルドで選択された依存関係の正確なバージョンを記録する。コミットされ、レビューされていれば、悪意あるバージョンの1つがプロジェクトに入り込んだかを明らかにできる。ただし、現在のロックファイルが正常でも、露出期間中に影響を受けたバージョンがいずれかのワークステーションで解決されなかったことの証明にはならない。
今回のRustサプライチェーン攻撃は、ダウンロード数の合計を慎重に解釈すべき理由も示している。過去のダウンロード数が数億回に上ることは、数億件の感染を意味しない。悪意あるバージョンが利用可能だった期間は短く、多くのプロジェクトは以前のリリースに固定されたままだった。
それでも、パッケージのインストールは自動化されているため、短期間のリリースでも機密性の高いシステムに到達し得る。リリースが公開されている毎分、人気の高さは攻撃者に数多くの独立した機会を与える。
したがって、コード経路とソーシャル経路は互いに作用を強め合う。メンテナーを標的にすることで公開権限を得る。ビルド時実行は、その権限を下流環境全体で即時のコード実行へと変換する。
帰属は依然として不確実だが、防御上の結論は変わらない
調査者は協調したキャンペーンを示す信頼できる兆候を得ているものの、利用可能な証拠は、すべてのRust関連インシデントが単一の実行主体によるものだとは証明していない。
9月の警告は、3つの観測を結び付けている。Rust開発者は6月に個別化された接触を受けた。arrayrefメンテナーのアカウントは8月に侵害された。新たな不審な接触は9月まで続いた。
手法にも認識しやすい構造がある。攻撃者はプロフェッショナルな身元を作り、魅力的な仕事を提案し、ライブでのやり取りを確立したうえで、標的をコード実行へ誘導する。狙われる被害者は、ほかの開発者に影響し得るアクセス権を持っている。
この一貫性は、キャンペーンという評価を支持する。しかし、単一の指揮系統、支援主体、マルウェアファミリーを立証するものではない。
Rustチームはこの隔たりを明示的に認めている。同チームの警告では、以前の標的化とarrayref攻撃がすべて同一キャンペーンの一部かどうかは分からないとしている。責任ある報道は、この留保を維持しなければならない。
DPRKとの関連についても同様の注意が必要だ。セキュリティ研究者らは、ソフトウェア開発者を狙った偽の採用プロセスを利用する北朝鮮のキャンペーンを文書化している。arrayrefマルウェアの一部のインフラと技術的パターンは、過去に帰属された活動と重なると報告されている。
これらの発見は仮説を有意義なものにするが、確実性には変わらない。公開警告を、Rustプロジェクトによる公式な帰属と解釈すべきではない。
もう1つの未解決の問題は、arrayrefメンテナーに対する最初の侵害だ。プロジェクトはメンテナーのデバイスまたは認証情報が侵害されたと考えているが、公開されたインシデント通知には完全なフォレンジックのタイムラインは示されていない。
そのため、盗まれたセッション、認証情報、ブラウザーデータ、エンドポイントへのアクセスについて、複数の可能性が残る。9月の投稿は、同様の攻撃を通じてアカウントが侵害されたとしているが、技術的な全手順を公開しているわけではない。
成功した被害者の数も不明だ。公開記録は悪意あるパッケージの公開を確認し、失敗に終わった接触を記録している。しかし、ソフトウェアをインストールしたメンテナー、コマンドを実行したメンテナー、不審な通話を非公開で報告したメンテナーが何人いたかは明らかにしていない。
下流での感染件数も公開されていない。研究者は悪意あるパッケージのバージョンを特定し、パッケージの普及度を推定できるが、それは限定された露出期間における実際の実行回数を測定することとは異なる。
こうした空白はインシデント対応に反映されるべきだ。チームは、プロジェクトが過去に影響を受けたクレートに依存しているという理由だけで感染を主張すべきではない。特定のマシンで影響バージョンが解決またはビルドされたかを判断すべきだ。
逆の誤りの方が危険である。悪意あるリリースがすぐに削除されたからといって、チームがこの事象を軽視すべきではない。ローカルキャッシュ、CIログ、ロックファイル履歴、エンドポイントテレメトリー、認証情報の利用状況には、現在のマニフェストでは見えなくなった兆候が残り得る。
影響を受けたバージョンをビルドした開発者は、該当環境が侵害された可能性があるものとして扱うべきだ。クレートを削除しても、すでに実行されたコードを元に戻すことはできない。そのマシンから利用可能だったシークレットは、別の信頼できるデバイスから無効化する必要がある場合がある。
このキャンペーンは、多要素認証がアカウントセキュリティを解決するという前提にも疑問を投げかける。MFAは多くの認証情報攻撃を減らすが、認証済みのワークステーションで実行されるマルウェアは、セッションを盗んだり既存のアクセスを通じて操作したりできる。
より強固なパッケージ認証は依然として重要だ。ハードウェアで保護された認証情報、最小限のトークンスコープ、短期間の公開権限、日常的なブラウジングとリリース作業の分離は、露出を減らし得る。どれもソーシャルエンジニアリングを無関係にするものではない。
実際のセキュリティ境界は、人、エンドポイント、アイデンティティシステム、レジストリにまたがっている。レジストリのログインだけを守っても、公開権限に至る代替経路が多すぎる。
これが、Be alert: targeted attacks on prominent Rustaceansにおける持続的な教訓だ。帰属が未解決のままであっても、防御側は確認済みの仕組みと実証された影響に基づいて行動できる。
メンテナーとエンジニアリングチームが次に注視すべきこと
次に決定的なシグナルとなるのは、追加のメンテナー報告、パッケージ公開管理の変更、そして新たな接触と既知のマルウェアインフラを結び付ける証拠だ。
まず、Rustクレートの所有者からさらなる開示があるかを注視すべきだ。同じ会議上の問題、企業アイデンティティ、クリップボード経由のコマンド、プロジェクトテンプレートを使う別々の報告があれば、協調作戦の根拠は強まる。
異なるマルウェアや無関係な目的を特定する報告は、単一キャンペーン説を弱める。それでも、複数のグループがオープンソースメンテナーを価値あるアクセス仲介者と見なしていることを示すだろう。
メンテナーは、不審なメール、会議リンク、ドメイン、プロフィール、リポジトリアドレス、タイムスタンプを保存すべきだ。こうした詳細は、個人が独自に帰属判断を下すことなく、対応者がインフラを比較する助けとなる。
次に、crates.ioやほかのレジストリが公開管理をどのように調整するかを注視すべきだ。アカウントロックとパッケージ削除はこのインシデントを限定したが、対応は悪意あるバージョンが現れた後だった。
将来の管理策は、異常なリリース行動に焦点を当てる可能性がある。パッケージが初めて依存関係を公開する、複数の安定バージョンをyankする、予期しないネットワーク対応のビルドコンポーネントを追加するといった行為は、レビュー可能なパターンとなる。
レジストリは介入とオープンソースメンテナーの独立性の均衡を取らなければならない。過度の摩擦は正当な緊急リリースを遅らせたり、すでに負担を抱えるボランティアにさらなる作業を課したりする可能性がある。
重要な基準は、新しい管理策が日常的な保守を手に負えないものにせず、高リスクな変更を阻止できるかどうかだ。これは公開の自律性とエコシステム封じ込めの間のトレードオフである。
第三に、ソーシャルな接触と復元されたマルウェアとの、より強固な技術的つながりを注視すべきだ。一致するドメイン、ペイロード証明書、コマンドパス、ソースアーティファクト、ホスティングインフラは、帰属をより明確にする。
既知の実行主体との関連が確認されれば、エコシステムを横断した検知の改善につながり得る。その関連が見つからなければ、こうした手法が複数のグループに広がっていることを示唆するだろう。
エンジニアリング組織は、それらの回答を待つ必要はない。誰がパッケージ公開権限を持つのか、リリース認証情報がどこに保管されているのか、そしてその認証情報が日常のブラウジングやビデオ通話と同じワークステーションを共有しているかを確認できる。
チームはまた、8月の露出期間中にどのビルドが実行されたかを把握すべきだ。悪意あるバージョンはarrayref 0.3.10、internment 0.8.7、append-only-vec 0.1.9だった。proc-macro1が現れた場合は、すべて調査に値する。
このレビューには、現在のリポジトリだけでなく、CIランナーとローカル開発キャッシュも含めるべきだ。過去の記録を無視すれば、クリーンアップされたロックファイルは以前の実行を隠してしまう可能性がある。
組織はさらに、予期しないアウトバウンド接続、新たな永続化メカニズム、異常なブラウザーアクセス、説明のつかない認証情報の使用に関するアラートを調査できる。実行が確認された場合は、認証情報のローテーションと、既知のクリーンなシステムからの再構築を開始すべきだ。
新しい機会を持ちかけられたメンテナーは、ソーシャルな検証と技術的な評価を分けるべきだ。独立したチャネルで企業を確認し、信頼できるサービスで会議を設定し、独自コーデックやコピーしたターミナルコマンドを拒否する。
予期しないリポジトリは、信頼されていないソフトウェアとして扱うべきだ。プロジェクトをビルド、テスト、起動するよう求める指示は、通常の面接課題として提示されていても、コード実行の要求である。
最終的な問いは、Rustが言語として安全であり続けるかどうかではない。メモリ安全性では、信頼されたビルドスクリプトがオペレーティングシステムの許す範囲で正確に動作することを防げない。
問題は、エコシステムが、その権限ゆえに高価値の標的となったメンテナーを守れるかどうかだ。警戒：著名なRustaceanを狙った標的型攻撃を受け、すべてのエンジニアリングチームは、次の攻撃者に先を越される前に該当する人物を特定すべきだ。公開権限を見直し、リリース認証情報を分離し、不審な働きかけを容易に報告できるようにしよう。
