ハクソク

世界を動かす技術を、日本語で。

DuckDBのNPMパッケージ1.3.3および1.29.2がマルウェアに侵害される

258日前原文(github.com)

概要

DuckDBのNode.js向けnpm配布パッケージが マルウェア により改ざんされた事例 影響を受けたバージョンと対策の 詳細説明 フィッシング攻撃 による認証情報漏洩の経緯 即時対応および今後の再発防止策 ユーザーへの 注意喚起

DuckDB npmパッケージのマルウェア混入事案

  • DuckDB のNode.js向けnpmパッケージで マルウェア混入 が発覚
  • 攻撃者が4つのDuckDB関連パッケージに 悪意あるコード を混入し公開
    • 対象パッケージとバージョン
      • @duckdb/node-api@1.3.3
      • @duckdb/node-bindings@1.3.3
      • duckdb@1.3.3
      • @duckdb/duckdb-wasm@1.29.2
  • マルウェアは 暗号通貨取引の妨害 を目的としたコードを含有
  • 現時点の正式リリースは 1.3.2 であり、 1.4.0 は2025年9月10日リリース予定
  • 1.3.3系の正規リリース予定はなし ユーザーは誤って該当バージョンへ更新しないよう 要注意

対応と再発防止策

  • 発覚から4時間以内 に問題を検知
  • 以下の緊急対応を実施
    • 該当バージョンの非推奨化（deprecate）
    • npmサポートへ連絡し、該当バージョンの削除要請
    • 安全な新バージョン（1.3.4/1.30.0）を再リリース
  • 最新バージョンは 安全なもの へ差し替え済み
  • ユーザーへの謝罪 とともに、 内部プロセスの見直し を表明

インシデントの経緯と原因

  • 2024年9月8日（月）、DuckDBメンテナーが "...@npmjs.help" からのメールを受信
    • メール内リンクから npmjs.help ドメインの偽サイトへ誘導
    • 本物のnpmjs.comを模した フィッシングサイト でログイン
      • duckdb_admin アカウントでパスワード・2FA入力
      • サイトは本物そっくりで、ユーザープロファイルや設定も再現
    • 指示通りに 2FA再設定 を実施
      • 実際には本物のnpmサイトにも2FAが更新される仕組み
      • 攻撃者は 新しいAPIトークン を追加し、 悪意あるパッケージ公開 に利用
  • 自動入力が効かなかった点 が警告サインだったと後に判明
  • 古典的なフィッシング攻撃 により認証情報が漏洩

早期発見と被害最小化

  • 発覚後、 DuckDBLabsチーム が早朝7時に緊急対応会議を実施
  • NPMアカウントが乗っ取られなかった ことが幸い
  • 直ちに パスワード・トークン・APIキーのローテーション を実施

利用者への注意喚起

  • 1.3.3系 および @duckdb/duckdb-wasm@1.29.2 を 絶対に使用しない
  • パッケージのバージョン確認 を徹底
  • npm install時のバージョン指定 や 依存関係の見直し を推奨

今後の対策

  • 今回のインシデントを受け、 内部手順・セキュリティ対策の強化 を進行中
  • 再発防止 のための運用改善を継続
  • 利用者に対し、 引き続き注意と協力 を要請

Hackerたちの意見

今のところ、普通のフィッシングメールって感じだね。特に新しい要素も洗練されたところもないし、運営してる人たちが被害者に恵まれたみたい。まだ全貌は見えてない気がする。確認された著者が2人いるけど、他にも10人以上いるんじゃないかな？

└

今のところ、普通のフィッシングメールって感じだね。これが標準的なフィッシングメールじゃないってことは、基準が低すぎるってことだよね。1. メールの内容がnpmからのものみたいにトーンやフォーマットが整ってて、明らかなスペルミスや文法の間違いがない。普段より早く行動させるように仕向けて、典型的な疑念を引き起こさないようになってる。2. ランディングドメインやウェブサイトのコピーも本物に近いし、巨大なサブドメインもないし、不気味なログイン画面もない。AIがテクノロジーを変革するって話があるけど、これは生成AIがフィッシング業界を民主化する大きな影響を持つ角度だと思う。多くの著者が騙されてる可能性が高いってのには同意するし、まだ全体の影響は見えてないね。

└

おそらくここでの違いは、フィッシングメッセージが非常に信じやすかったことだね。普通はスペルミスや不自然な文法が多いけど、今回はドメインも信じられるものだった。彼らが運が良かったのは、> 振り返ってみると、ブラウザがログインを自動補完しなかったことが赤信号だったね。大きな赤信号だよ。ブラウザがサイトAのログイン情報を手動でサイトBに入力してることを検知して、「これフィッシングじゃないか？」って警告を出すべきなんじゃないかな？でも、チョークの著者がどうして騙されたのかはよくわからない。彼らは言ってたけど、> これはモバイルだったから、パスワードマネージャーのブラウザ拡張は使ってないんだよね。じゃあ、URLをチェックしないモバイルパスワードマネージャーってあるの？それがどう機能するのかはわからないな…

└

記事には被害者が2FAを使っていたって書いてあったけど、攻撃者はどうやってその2FAを知って、偽の2FAリクエストを送ったの？

npmのジャーは1週間か3週間は触らない方がいいかな。これからもっと多くのパッケージが影響を受けると思うし。

このウェブサイトはnpmjs.comのピクセルパーフェクトなコピーを含んでいました。これがどれほど重要なのかはよくわからないけど、君の脳はウェブサイトのピクセルパーフェクトなイメージを持ってないから、完璧なレプリカかどうかなんてわからないよね。パスワードマネージャーのシリコンバカにマッチングさせておけばいいんだから、そんなゲームで脳を疲れさせない方がいいよ。

└

私のパスワードマネージャーは別のアプリだから、いつも手動で認証情報をコピー＆ペーストしなきゃいけない。これがより安全だと思ってたけど、今は一つの攻撃ベクターを別のものに置き換えてるだけだって気づいたよ。

これはnpmのdebugやchalkパッケージが侵害されたことに関連してるのかな？ https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com...

└

同じフィッシングキャンペーンの標的になったみたいだね。

メールソフトには、リンクをクリックできないようにするオプションを追加するか、ユーザーがリンクを開く前にクリアなリンクを表示して（ドメインを強調表示して）くれるボックスを見せる機能が必要だと思う。今でもリダイレクトを使ってるから（リファラーヘッダーを避けるため？）半分はできてるよね。自動的にリダイレクトするんじゃなくて、リダイレクトページにリンクと「行く」ボタンを表示するようにすればいいのに。そうすれば、リンクにカーソルを合わせたときに本当のドメインが見えないっていうイライラも解消されるし。

└

正当なメールの中には、何らかのURL短縮サービスやトラッカーを通過するリンクがたくさんあるよね（Mailchimpみたいに）。人々は怪しいURLを無視するように積極的に条件付けされてる。

これは重要なインフラで、頻繁に危険にさらされてるよね。NPM（やそれに類似した）パッケージにマルウェアが混入する話は本当に多い。人々がフィッシングに100%引っかからないなんて期待できないし。ソフトウェアパッケージを公開する人たちは、少なくともある程度は技術的な人が多いから、パッケージ公開プラットフォームはお願いだからメールに署名を始めてほしい。GPGキーを公開して（技術的な実装はどうでもいい）、あなたのプラットフォームで何かを公開する人に送るすべてのメールに署名してほしい。出版社にこのことを教育して、どんなに説得力があっても署名のないメールは信用しないようにさせるべきだよ。それに、今の2FAのアプローチが十分じゃないのも明らかだよね。どう改善すればいいかは分からないけど、この例での行動は明らかに怪しい。ユーザーがログインして、2FA設定を変更して、すぐに新しいAPIトークンを追加して、それを使ってパッケージを公開するっていう流れ。認証情報を変更した後は、24時間は何も公開できない期間を設けるべきかも。その間に署名された通知メールをたくさん送るとか。もちろん、攻撃者がメールアドレスを変更したら意味ないけどね。

└

ほんとに！メールの中に自分で定義した簡単な単語を入れれば、そのメールが偽物かどうか分かるよ。

└

SPF/DKIMは送信者を認証してるけど、ユーザーがメールの送信元を確認しないと意味がないよね。でも、その場合GPGもあまり役に立たないかも。

└

メール（または他の「プッシュ」メッセージ）を信じないことが一番だと思う。メールやメッセージのリンクは絶対にクリックしないで。自分が以前にブックマークしたショートカットからサイトに行くか、URLを直接入力してね。最近、クレジットカードから詐欺警告のメールが来たんだけど、怪しい請求を確認するためのリンクが含まれてた。見た目は大丈夫そうで、メールには自分の名前と口座番号の最後の数字も載ってた。でも、結局はウェブサイトにログインしたんだ。フォローアップのためにカードに印刷されてた電話番号に電話したら、実際には正当なメールだったけど、ほんとに分からないよね。ほとんどの人は公開鍵署名を理解してないから、署名されたメールだけを信じるのは難しいし。もしこんなメールをユーザーに送ってるなら、リンクは含めない方がいいよ。その代わり、ウェブサイトやアプリで何をすればいいか指示を出してあげて。

└

人はフィッシングに100%引っかからないって期待できないよ。

  1. 本当に理解できない。
  2. もし人が問題の原因なら、何をやっても無駄だね。ハードウェアキー？問題ないよ、人間がそのハードウェアキーを使って悪意のある行動にサインするから。
└
  • パスキー * サインされたパッケージは、まずは人気のある上位数千のパッケージに対してそれを強制することで、ユニークな新規ユーザーログインセッションを検出するための基本的な衛生管理が助けになると思う。
└

メールは「npmjs dot help」ドメインから送信されたよ。あなたが間違ってるとは言わないけど、基本的なデューデリジェンスがあれば防げたはず。もしメールでなくても、メンテイナーはテキストや他の手段で妥協される可能性があったかも。今の大きなプロジェクトのメンテイナーは、スタックオーバーフローから持ってきたような小さなパッケージをインポートしたり自動更新したりしなければ、こういう問題を避けられるよ。

└

パッケージ公開プラットフォームは、メールに署名を始めてくれませんか？ フィッシング解決になるとは思えないし、さらに問題を増やすだけじゃないかとも思うけど（メールが署名されてたら、リンクを盲目的にクリックする？）、もし公開鍵暗号を提案するなら、NPMはパッケージ発行者が署名されたパッケージだけをリリースするか選べるようにして、消費者は署名されたパッケージだけに依存するか決められるようにすればいいと思う。攻撃者にとっては、ターゲットが発行者アカウントを妥協することからキーを手に入れることに移るけど、それは不可能だよね…プライベートキーはSSM/HSMから出ないから。 どんなに説得力があっても、署名されていないメールを信じないようにさせるべきだ。重要なショップにとって、今やメールのセキュリティは基本中の基本だよ。

こういう重要なインフラプロジェクトでは、リリースには異なるメンテナーから少なくとも3つの署名が必要にすべきだと思う。実際、これが一般的な慣習じゃないのが驚きだよ。

2週間で少なくとも3回目の大規模な妥協だね。 （前のコメント: https://news.ycombinator.com/item?id=45172225） （その前: https://news.ycombinator.com/item?id=45039764） フィッシングのことは忘れて、これは赤いヘリングだよ。実際の解決策はコード署名とアーティファクト署名だ。プライベートキーをローカルマシンに保管して、コードやアーティファクトに署名するんだ。それをプッシュする。パッケージはエンドユーザーがあなたの公開鍵で検証する。たとえNPMアカウントが乗っ取られても、攻撃者はあなたのプライベートキーを持ってないから、あなたとして有効なパッケージを公開できない。でも、これらのプラットフォームはコードとアーティファクトの署名を強制していないし、ツールもその署名を検証していないから、攻撃者は自分の毒パッケージをアップロードする方法を見つけるだけで、みんなやられちゃう。開発者のデスクトップからエンドユーザーまで、信頼のバリデーションチェーンが必要だよ。エンドユーザーが自分に渡されたコードが開発者のプライベートキーで署名されていることを検証できなければ、信頼できない。これは多くのシステムですでに実装されてる。今日からGitHubや1Passwordを使ってすべてのコミットに署名して、必要なときだけローカルでプライベートキーの解除を許可すればいい。そうすれば、パッケージも署名する必要があって、公開鍵は複数の経路やミラーを通じて配布されるべきだし、ツールは署名を検証する必要がある。Linuxディストリビューションはこれをやってるし、Macのパッケージもそうだ。でも、すべてのパッケージマネージャーで実装されているわけじゃない。Npmや他のパッケージツールにもこれを要求させる必要がある。コード署名が実装されたら、次に必要なのは1) 異常な活動を検出するサインインヒューリスティックで、ユーザーに通知するか完全に止めること、2) 必須の2FA（ハードウェアトークンを使ったパスキーのオプション付き）。これがフィッシングに対抗する助けになるけど、安全なソフトウェア供給チェーンの代わりにはならない。

公開にはnpmから送信されたメール確認リンクをクリックすることが必要かもしれない。

└

すべて無意味なパフォーマンスだよ。人々はやりたいことをするために摩擦を減らしたいだけで、増やしたくないんだ。メール確認リンクをクリックするような摩擦ポイントは自動化しちゃうよ。

ちょっと背景を説明すると、DuckDBチームはセキュリティプラクティスを一切無視してる。ノートパソコンにDuckDBをインストールする唯一の方法は、curl https://install.duckdb.org | shを実行すること。CLIを標準パッケージとして提供するようにお願いしたけど、無視された。ここがスレッドだよ: https://github.com/duckdb/duckdb/issues/17091 見ての通り、これは「人間の要因」による単なるミスじゃなくて、DuckDBの管理が一貫してユーザーを危険にさらしてる。

└

本気の質問なんだけど、curl https://trusted-site.com | shってなんでセキュリティリスクなの？基本的には、httpsがちゃんと機能してるかどうかに完全に依存してるんじゃないの？標準のパッケージリポジトリもhttpsに頼ってるよね？つまり、公式サイトに行って、推奨されてるコマンドをコピーしてシェルにペーストするのと何が違うの？どっちにしても、結局そのドメインの信頼性に頼ってるってことだよね？