3 ポイント 投稿者 GN⁺ 5 시간 전 | 2件のコメント | WhatsAppで共有
  • GitHubでホスティングされていた数十件のオープンソースプロジェクトがハッカーに侵害され、パスワード窃取マルウェアがコードに注入されたことを受け、Microsoftは当該プロジェクトへのアクセスを遮断し、調査に着手
  • 影響を受けたプロジェクトの多くは、クラウドサービスAzureや、Claude Code、Gemini CLI、VS CodeなどのAI開発アプリでコーディングする際に使われるツールと関連
  • ユーザーがAIコーディングアプリで感染したツールを開くと、パスワードや機密性の高い認証情報が窃取される仕組み
  • GitHub上では少なくとも70件のプロジェクトが無効化されており、Microsoftは一部リポジトリを一時的に削除した後、確認を経て復元
  • 今回は人気のオープンソースコードを狙うサプライチェーン攻撃の最新事例であり、Microsoftのオープンソースプロジェクトが数週間の間に2度目の侵害を受けたとみられている

事件の概要とMicrosoftの対応

  • ハッカーがプロジェクトを侵害し、コードにパスワード窃取マルウェアを注入した形跡が確認され、MicrosoftはGitHub上の数十件のオープンソースプロジェクトへのアクセスを遮断し、侵害の経緯を調査中
  • 影響を受けたプロジェクトの多くは、Azureクラウドサービスや、Claude CodeGeminiのコマンドラインインターフェースVS CodeといったAI開発アプリのコーディングに使われるツールと関連
  • 影響を受けたツールを実際に何人がダウンロードしたかは、現時点ではすぐに確認できていない
  • Microsoftはリポジトリを取り下げた事実を認めており、これは404 Mediaが最初に報じた
    • Microsoftの広報担当Ben Hopeは「潜在的に悪意のあるコンテンツを調査している間、一部のリポジトリを一時的に削除した」と説明
    • 一部のリポジトリは確認後に復元されており、一方で一部は作業が進む間オフラインのままとなる可能性がある
    • 影響を受けたリポジトリからコンテンツをダウンロードした可能性がある少数の顧客に通知しており、追加対応が必要な事項が判明した場合は、既存のサポートチャネルを通じて直接連絡する予定
  • TechCrunchの問い合わせに対し、影響を受けた顧客の具体的な人数はすぐには示されなかった

マルウェアの動作方式

  • セキュリティ企業Cloudsmithと、コミュニティベースのマルウェア分析サイトOpenSourceMalwareは、このハッキングを最初に指摘した組織の一部
  • マルウェアは、ユーザーがAIコーディングアプリで感染したツールを開いた際に、パスワードやその他の機密性の高い認証情報を窃取するよう動作
  • Microsoftが所有するコードホスティングサイトGitHubでプロジェクトページにアクセスすると、少なくとも70件のプロジェクトが「無効化(disabled)」状態と表示
    • 表示メッセージ: 「GitHub利用規約違反により、GitHubスタッフによってこのリポジトリへのアクセスは無効化されています」

サプライチェーン攻撃という文脈

  • ここ数カ月続いている、広く使われるオープンソースプロジェクトを侵害し、そのコードをインストールした多数のユーザーにマルウェアを仕込む事例の最新ケース
  • こうしたハッキングは**「サプライチェーン」攻撃**と呼ばれ、多くのソフトウェア製品で広く使われていたり、特定の利用者層が使うコードを標的にする
    • こうした対象はクラウドシステムや大量の顧客データへのアクセス権を持つ場合があり、ハッカーにとって有利になり得る
  • オープンソースプロジェクトの単独開発者が標的になることは珍しくなく、その一部は開発者の信頼を得るための長期的な試みの一環でもある
  • ただし、このような攻撃を防御するためのリソースを持つMicrosoftのような大手テック企業が侵害されるのは異例

繰り返される侵害の兆候

  • Ars Technicaによれば、今回の件はここ数週間でMicrosoftのオープンソースプロジェクトが侵害された2件目の既知事例
  • 5月中旬には、開発者のアプリ構築を支援するMicrosoftのオープンソースプロジェクトDurable Taskがハッキングされたと、セキュリティ研究者が明らかにした
  • OpenSourceMalwareは今回の最新事案を、Durable Taskプロジェクトの**「再侵害(re-compromise)」**と表現
    • これは、Microsoftが最初の試みでハッカーを完全に排除できなかったか、あるいはまったく別の新たな侵害である可能性を示唆している

2件のコメント

 
brainer 1 시간 전

もしかして、パスワードを変更しても私にMSアカウントへのログイン試行がずっと来る理由はこれでしょうか?

 
GN⁺ 5 시간 전
Hacker Newsの意見
  • 純粋な推測と個人的な観察にすぎないが、昔ながらの RBACモデル はすでにほぼ破綻していて、今では完全に壊れたように見える。
    コーディングアシスタントとエンジニアが無関係な複数のプロジェクトを同時に触り、特に以前は時間がなくてできなかった実験まで行うようになって、企業内の サプライチェーンリスク が大きく高まったと思う。
    直接関係しているとまでは言わないが影響はあると感じるし、最近多くの場所で個人所有の機器で雑にAIコーディングをやれと開発者や管理者をけしかけているのも、そのうち問題になる気がする。
    最近のサプライチェーン事故のあいだに共通の流れがないとは信じがたく、こうした攻撃を専門にするハッカー集団がいるのも、見返りが大きいからだと思う。

    • はっきりさせておくと、元コメントが関係あると断定したわけではないが、これは AIやバイブコーディング とはまったく関係ない。
      昔から存在していた 開発者依存関係インストールのセキュリティ欠如 と、Shai Haludワームの延長線上にある。
      ハッカーは開発者をだまして何かをインストールさせるのが容易で、開発者の端末には認証情報、クラウドCLI、MCPのような機微な情報が多く、理想的な標的だと気づいたのだ。
    • うちの会社も似たようなものだ。「AIでできるだけ多くやらなければ取り残される」といった教義が広まっている。
      セキュリティは気にせず、群れの中で真っ先に走ろうとする、昔の IoT過熱 をそのまま繰り返している感じだ。
    • 総プロジェクト数に比べて人員が少なすぎると何年も主張してきたが、経営陣は大半のプロジェクトが休眠状態だから1人あたり多く抱えても大丈夫だと言っていた。
      結局こうなった。
    • ロールベースアクセス制御、つまり RBAC を別のものに置き換えるべきという意味なのか、それとも現在使われている特定のRBACモデルが破綻したという意味なのか気になる。
      個人的には名前が少し紛らわしいが、capabilityベースのセキュリティモデル が未来だと思う。
  • タイトルの表現からして偏っていて、本文もまるで オープンソースのせい であるかのように書いている。
    そのうえで、試みられたサプライチェーン攻撃の責任をMicrosoftに負わせるような書きぶりなのでなおさらおかしい。
    Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch. とあるが、オープンソースがもともとどう動くかをTechCrunchは説明していない。
    Microsoftを叩けるときは叩くのが好きだが、今回はMicrosoftが安全で正しい対応を取ったと思う。
    記事では、まるですべてがMicrosoftの責任で、侵害範囲を限定したことまで恥ずべきことのように書いている。
    steal passwords of AI developers という表現も、「AI開発者」なのか「AIを使う開発者」なのか、妙な含みを残している。
    サプライチェーン攻撃についての説明も、実際の意味ではなく結果と攻撃面の理由だけを述べていて、今回の報道は非常に良くないと思う。

    • TechCrunch は非常に不注意で、信頼しがたい。
      自分が実際に関わった内容を報じながら、検索最適化のために事実をでっち上げているのを見たことがあるし、訂正させる手段もなかった。
    • その文の何が問題なのかわからない。
      Microsoftには 組織的なセキュリティ問題 があり、GitHub Actionsを適切にロックダウンできず、マージリクエストがCI/CDを回避できる状態にしていたことが、それを助長または露呈させた。
      これはAI以前から存在していたMicrosoftの問題であり、議論の余地はない: https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewO...
      AI時代にはこの問題が風土病のように広がり、武器化されつつある。
    • それなら、事後分析をどう見ているのか気になる。
      実際に何が起きて、どう読めばいいというのか?
  • 関連がありそうな投稿
    https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
    https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
    https://news.ycombinator.com/item?id=48416155
    https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)

    • 感染したすべてのリポジトリでワームを修正または除去できる緩和ツールを作り、それについての記事も書いた
      月曜日に Hades キャンペーンが Composer、Go、Pip のサポートを追加した。それ以前は NPM と AI アシスタントエディタのみをサポートしていて、Ruby も一応あったが、最近 Rubygems を使っている人はほとんどいないように見える
      Microsoft でさえ見落としている点は、これがコードエコシステムのあらゆるプラットフォームで動作する最初のワームだということだ。開発者ホスト、サーバー、CI/CD ランナーのすべてで動き、それらのマシンがアクセスできるすべてのリポジトリにワームを広げる
      このワームに勝つには、すべてのコンピュータと AWS EC2、Google Cloud Platform、Azure、Kubernetes クラスターを同時に 100% 停止しなければならない。文字どおりインフラ全体を横断して広がる
      APT28 マルウェアでいつもそうであるように、キルスイッチはホスト言語を ru_RU.KOI8-R に設定すること、つまり LANG 環境変数の設定だ。そうすると伝播メカニズムが無効化される
      緩和ツール: https://github.com/cookiengineer/antimiasma
      ブログ記事: https://cookie.engineer/weblog/articles/malware-insights-mia...
  • 従来型の個人アクセストークンを雑に使った事例である可能性が高いと強く疑っている
    奇妙な openclaw デバイスから AI エージェントにトークンを渡すなら、細分化されたトークンを使うべきだ
    自分の GitHub アカウントはポリシーがまったく異なる 3 つの組織にまたがっているが、いまだに classic トークンが許可されているのは少し驚きだ
    少なくとも各組織ごとに手動で許可しなければならないようにすべきだ

    • AI エージェントは別個のセキュリティ主体であるべきで、必要なリポジトリや組織に対してのみ専用のアクセストークンを発行されるべきだと思う
      人間のアカウント向けに「鋳造された」アクセストークンを AI エージェントに渡すのは、新しい「パスワードをポストイットに書いておく」ようなものに感じる
    • その通りだが、細分化されたトークンの権限管理は悪夢に近い
      どの作業に何が正確に必要で適切なのかを判断するのは簡単ではない
      しかもソフトウェア開発者は、権限よりコードに集中することのほうが重要だと考えることが多く、権限は他人の責任だと見なすこともある
    • 原因が classic PAT なら、最近の GitHub リポジトリだけでなく、追加の非公開リポジトリも危険にさらされているということではないか?
    • 公開リポジトリのスクレイピングには低権限アカウントの classic トークンを使っている
      組織レベルの権限であれば自分の用途には十分うまく合いそうだ
  • 昨日、個人の Microsoft アカウントのパスワードをリセットしなければならなかった。ルーマニアからログイン試行があったという二要素認証アラートが来たためだ
    どうやってパスワードを知ったのかは分からない。自分が持っている Microsoft 製品は Xbox だけだ
    AI 以前から Microsoft はざるのように漏れている感じがしていたし、会社が Microsoft から離れてくれればいいのだが、すでに縛られている

    • 個人の Microsoft アカウントでパスワードレスログインを許可しない設定にするのはほぼ不可能だ
      そのため実際にはアカウントがその設定になっており、受け取った MFA リクエストも二要素認証ではなく、単にアカウントアクセスを試みたものだった可能性が高い
      自分もこうしたリクエストを 1 日に何度も受けており、スマートフォンで Microsoft Authenticator アプリを設定すると、顔、指紋、PIN などのロックがある場合は強制的にパスワードレス方式に切り替わることを知った
      回避するには、Authenticator アプリにアカウントを設定している間はそうしたロックをすべてオフにしなければならない
      Microsoft アカウントはあまり使わないので、今では Authenticator の代わりに別のメールで認証している
      こういう動作をすること自体が狂っているが、おそらく Microsoft 社内の誰かがパスワードレスログインの KPI を埋めようとしているのだと思う
    • 自分が働いていた一部の組織では、パスワードが正しいかどうかに関係なく多要素認証プロンプトが出るようにしていた。攻撃者の時間をさらに浪費させるのが目的だった
      Microsoft もそうなのかは確信がない
  • どうすればこれほど多くのリポジトリに難読化されたファイルを追加できるのか、誰か説明してほしい。コードレビューはまったくないのか?
    見出しも誤解を招く。setup は、リポジトリで作業する人たちが自動実行することになる設定を追加するもので、その人たちは VSCode、Cursor、Claude、Gemini を使っていなければならない
    Codex、opencode、ほかの実行ハーネスを使っている人たちは安全そうだ
    詳細: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...

    • 大手企業で働く親しい友人がいる。どの会社かは言えないが、S&P 500 企業だ
      かなり長く働いているのに、自分が担当しているプロジェクトが実際にどんなものか見たことがなく、リポジトリはクローンしてあり使用言語を知っているだけで、それ以上はわからない
      すべてがだいたい AI で継ぎはぎされている。そのプロジェクトは会社全体の製品の認証と認可システム
      本人いわく「一日中 Tab を押して、レビューには『意図した動作』と書く。レビューも全部 AI がやっていて人間は関与しない。CEO と CTO が本気でそうしろと言っている。何か壊れたら、実際のコードを見た人がいないから誰もどう動いているのかわからない。評価は自分たちが何をしたかではなく、使ったトークン数で決まる」そうだ
      今は多くの会社がこうなっている可能性があり、実際のコードレビューがないと思っても無理はない
    • 悪意あるコミットの多くは、作成者が github-actions と表示されている
      これは内部の GitHub CI/CD 側で認証していることを意味し、そうしたコミットが多すぎて、どんな自動化ツールでも干し草の山の中から毒を見つけ出すのは難しい
      だからこれは 2025年9月のGitHub セキュリティ侵害と関係している
      「5つのリポジトリの GitHub スターは合計 1,459 個で、そのうち mantine-datatable ひとつで 1,225 個を占める。スターは、どれだけ多くの開発者がソースをローカルにチェックアウトしたかの大まかな代理指標であり、この攻撃が狙っている集団だ。」
      「すべてのコミットは署名されておらず、身元は github-actions で、メッセージは chore: update dependencies [skip ci]、同じ6つのファイルという痕跡を残していた。5つのリポジトリを 49 秒でなめたのは人間のコミットではなく自動化だ。これは、以前の感染で書き込み権限のある GitHub トークンを収集し、そのトークンが届くすべてのリポジトリに永続化ペイロードを押し込む Shai-Hulud の自己伝播と一致する。」
      https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
      実際の動作: https://safedep.io/config-files-that-run-code/
      彼らとは関係ないが、今何が起きているのかについて、私が見つけた中ではいちばん簡潔で詳しい説明だ
    • 同僚が真顔で「いまやコードの大半を生成するのなら、そのコードを実際に全部読んでいるのは誰なんだ?」と聞いてきた
      小さな会社だが、人によっては 信託のように AI を信じたがる衝動がほとんど宗教的だと感じる
      私は自分が生成したコードの 90% 以上を、ジュニア開発者のコードレビューをするように読む
      いま新機能をかなり強めにバイブコーディングしているが、GitHub PR がまた動き始めたら徹底的に読むつもりだ
    • リポジトリに push できるアカウントが侵害されていたなら、PR レビューは不要だったはずだ
  • こういう人たちに Secure Boot のルート CA 証明書を任せているのか?

    • 2023 年のセキュリティレビューで不合格だったあの会社のことか? [0]
      「上で説明した欠陥は、それぞれ単独で見れば理解可能かもしれない。しかしそれらを合わせると、Microsoft の組織的統制とガバナンス、そしてセキュリティに関する企業文化の失敗を示している。」
      Microsoft の製品とサービスは至る所にある。世界で最も重要な技術企業の一つであり、あるいは最も重要かもしれない。この立場には最高水準の世界的責任が伴う。財務や市場投入の要因がサイバーセキュリティや Microsoft の顧客保護を弱めないよう、CEO から始まる責任あるセキュリティ中心の企業文化が必要だ。
      「残念ながら、このレビュー全体を通して委員会は、Microsoft が企業のセキュリティ投資と厳格なリスク管理の両方を低い優先順位に置いてきたことを示す一連の運用上・戦略上の意思決定を確認した。これらの決定は世界中の Microsoft 顧客に相当なコストと被害をもたらした。」
      「委員会は、Microsoft がセキュリティ文化を立て直さなければならないと確信している。」
      [0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...
    • Secure Boot の信頼のルートは通常 Microsoft 証明書ではなく OEM 証明書で、そちらのほうがもっと悪いかもしれない: https://www.binarly.io/blog/pkfail-untrusted-platform-keys-u...
      いずれにせよ、Microsoft 証明書を削除して自分の証明書を登録するのは自由だ
    • 「信頼」というより「強制的に受け入れさせられる」に近い
      今回の件も、Microsoft がきちんとセキュリティをやる会社というより、セキュリティ問題そのものだった前歴の延長にすぎない
    • Microsoft をセキュリティ面で信頼するのは愚かなことだ
      この 40 年、気にしていないことを何度も示してきた
  • 気づくのが遅かっただけかもしれないが、「コードの質が悪い」などの理由でAIを使いたくないとしても、セキュリティ監査にはAIを使うことをしばらく前から勧めてきた
    少なくとも、コード内の脆弱性をスキャンするツールは使うべき
    攻撃ベクターはデータを盗むプラグインだけではなく、使っているほぼすべてのソフトウェアの0-day脆弱性や、LLMを手にしたスクリプトキディがあなたのWebサービスを攻撃することまで含まれる
    ハッキングは増え続け、さらに悪化していくのだから、サイバーセキュリティ監査や監査ツールに投資しないところは考え直すべきだ

  • 誰も自分のマシンで npm installpip install を実行すべきではない
    適切なサンドボックス化(https://github.com/ashishb/amazing-sandbox)を継続的に使えば、この種の攻撃の被害範囲を大きく減らせる

    • Dockerバックエンドはコマンドをルートレスコンテナで実行するのか?
      コードをざっと見たが、それを確認できる箇所は見当たらなかった
    • Dockerは本格的なサンドボックス戦略ではない
    • npm installpip install を自分のマシンで行うなというなら、代わりに何を勧めるのか?
      サンドボックスの外ではインストールするな、という意味か?
    • これには検知コンポーネントもあるのか?
      開発をサンドボックス内で行うのは良いが、次の段階は本番デプロイだ
      サンドボックス内で悪意ある挙動が起きたかどうかをどうやって把握し、そのマルウェアをさらに配布しないようにできるのか?
  • MicrosoftのGitHubが、利用規約違反を理由にMicrosoft Azureと他のすべてのユーザーからのMicrosoftコードベースへのアクセスを停止したという事実が、あまりにもおかしい
    この組織図を本当に実感させてくれる: https://www.businessinsider.com/big-tech-org-charts-2011-6