Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

管理者権限の壁が、侵入の最後を折った

この記事は後半です。前半は Qiita にあります: 管理者権限エラーが「SSHはオン」に化けた理由――Cursor版Claude Code拡張の空振りを追う

Off を待っていた判定が、エラー文に負けた

画像: socket.dev より

Phorion の分析で核心はかなりはっきりした。攻撃側は systemsetup -getremotelogin の結果に Off が含まれるときだけ、sudo -n systemsetup -setremotelogin on を実行する作りだった。ところが macOS では、標準ユーザーでこのコマンドを叩くと、設定値ではなく「管理者アクセスが必要」というエラー文が返る。しかも終了コードは 0 のままなので、見た目だけだと成功失敗の判定がさらにややこしい。

結果として、攻撃コードは「SSH がオフだから有効化する」という分岐に入れない。権限不足で状態確認できなかっただけなのに、文字列判定のせいで「オフではない」と解釈してしまう。ここが macOS で空振りした直接の理由だ。しかも、この誤判定は単なる小さなバグではない。侵入の最後の一押し、つまり外から入ってくる口を開ける処理が飛ぶので、攻撃者の手元には鍵だけが残る。

鍵は置かれる、でも扉が閉じたままなら入れない

とはいえ、何も起きなかったわけではない。公式通知と Phorion の分析の両方で、攻撃者の SSH 公開鍵は authorized_keys に追記されている。さらに、永続化用の仕掛けやホスト情報の送信も行われたとされる。つまり、端末には「後で使うための材料」が残る。SSH がすでに有効だった端末、あるいは後から管理者が Remote Login を有効にした端末なら、その鍵はそのまま入口になる。

ここが少し嫌なところで、被害の大きさは「今回の実行時に SSH が立っていたか」に左右される。閉じていればリバーストンネルの先にある localhost:22 へ届かず、攻撃者はログインできない。開いていれば話は別だ。だから、空振りの Mac でも安心材料にはならない。鍵の残骸がある時点で、再点火の余地があるからだ。

何を残し、何を消すかは“今つながるか”では決まらない

Cursor 公式は、影響確認の手がかりをかなり具体的に出している。~/.ssh/authorized_keys に svc-telemetry があるかを見るだけでなく、改変された VSIX の SHA-256、攻撃者 IP 134.209.82.225、~/.config/.smt や ~/.config/.smtk、$TMPDIR/.stk_<10 hex>、macOS の com.apple.sysmond.plist など、複数の痕跡を並べている。これは、単発の接続有無よりも「設置された道具一式」を拾うための設計だ。

実務では、ここを雑に扱うと危ない。拡張を削除しただけで終えると、トンネル用のスクリプトや起動設定が生き残る可能性がある。さらに、端末から見える範囲の情報はすでに送られている前提で動くべきだ。ホスト名、ユーザー名、作業ディレクトリ、Git のメールアドレス、公開 IP まで収集されているので、資格情報の扱いも、端末の再利用も、通常より一段重く考えたほうがいい。

自分ならどう扱うか

この件を「たまたま macOS の判定バグで助かった話」として終えるのは危うい。私なら、まず authorized_keys の中身を見て、svc-telemetry の有無でなく公開鍵そのものの指紋まで確認する。次に、拡張の削除だけで済ませず、永続化の痕跡と関連プロセスを洗う。最後に、その端末から触れた資格情報を順に更新する。ローカルの SSH が止まっていても、そこに置かれた鍵が消えない限り、後で再び扉になる可能性があるからだ。

今回の macOS では、管理者権限がなかったことで“入口を開く処理”だけが失敗した。だが、攻撃の設計そのものはかなり実用的で、拡張機能が読み込まれた瞬間に動き、端末を静かに作業用の足場へ変える。だから、この件から学ぶべきなのは「Mac では助かった」ではなく、「拡張の更新一本で、開発端末の信頼境界は簡単に崩れる」という事実のほうだ。

同じ著者の記事

正式版Claude Code拡張に混入したSSHバックドア、その手口と見落とし

開発者向けの拡張機能は、便利なぶん一度入り込まれると厄介です。今回Phorionが報告したのは、Cursor Marketplaceに載っていた公式のClaude Code for VS Code拡張のバンドルにバックドアが仕込まれていた、という話でした。しかも影響はmacOSだけに限られず、LinuxやWindowsにもまたがります。単なる「悪い拡張があった」ではなく、IDEの権限でローカルファイルや開発環境にすぐ触れられる点が重い。だからこそ、今この件を整理しておく意味があります。 Phorionの説明によると、問題の拡張はCursor Marketplace上の「Claude Code for VS Code」拡張バンドルに含まれていました。対象として挙げられているのは Claude Code for VSCode 2.1.313 です。Cursorはこのリリースをマーケットプレイスから削除し、さらにNPMとVSCode版の2.1.313も各レジストリから引き下げたとされています。 仕組みはかなり露骨です。拡張の`extension.js`の先頭に、即時実行される関数が差し込まれ

papoo.work

Northflankで何が起きたのか、そしてなぜ「すぐに鍵を替えて」が繰り返されたのか

Northflankのステータスページには、サービス障害の案内に加えて、かなり切迫したSecurity incidentの更新が並びました。単なる遅延や一時停止の話ではなく、利用者が保存していたAI API keysや環境変数が不正利用された可能性を前提に、すぐに全秘密情報を回転させるよう呼びかけているのが特徴です。しかも、対象は一部の機能ではなく、platform全体の複数コンポーネントにMajor outageが付く状態でした。クラウド基盤を使う人にとっては、「止まった」以上に「保管していた認証情報が危ないかもしれない」という点が重いニュースです。 Northflankのステータスページでは、まず「Experiencing partial outage」として一部障害が示されたあと、Security incidentが「Identified」、さらに「Major outage」へと整理されていました。更新は2026年10月30日UTCの同じ日に何度も行われ、最初の時点では「Users have reported unauthorised use of AI API keys sup

papoo.work

AzureのAPI Connectionsに潜んでいた“横取り”の連鎖

Microsoft AzureのLogic AppsにあるAPI Connectionsについて、またひとつ深刻な脆弱性の話が出てきました。しかもこれは単発の欠陥ではなく、同じ設計の弱さから何度も別の抜け道が見つかった、という筋書きです。元記事の著者は、最終的に5件のcriticalな権限昇格脆弱性を報告し、合計で20万ドルを得たと書いています。単なるバグ報告ではなく、クラウドの“つなぎ方”そのものがどれだけ危ういかを示す話として読むべきだと思います。 元記事の中心は、Azure Logic AppsのAPI Connectionsがどう動いているかです。Logic Appからの呼び出しは、共有のAzure API Management（APIM）を経由し、そこでOpenAPI定義を確認したうえで、接続先サービス向けの認証情報に“交換”されてからバックエンドへ届く、と説明されています。つまり、見かけ上はLogic AppがAPIを呼んでいるようでも、実際にはAPI Connectionに設定されたトークンやキーでKey VaultやAzure SQL、さらにはJiraやSalesfor

papoo.work

AIは税務の「答え」だけでなく、「何を調べるべきか」まで担えるのか

税務の仕事は、計算を合わせれば終わり、という世界ではありません。依頼の書き方が曖昧だったり、資料どうしが食い違っていたり、そもそも依頼者が重要な論点に気づいていなかったりするからです。Surge AI はその厄介さをそのままベンチマーク化した「DAYJOB: Tax」を公開しました。狙いは、AIエージェントが税法の知識を持っているかではなく、実務で本当に必要な判断と注意力を持てるかを試すことにあります。この記事は、その設計思想と、実際の結果がなかなか厳しいことを伝えています。 Surge AI の「DAYJOB: Tax」は、AIエージェントを専門的な税務作業に当てはめて評価するベンチマークです。対象は 50 の環境で、合計 1,789 個のファイルが使われています。元記事によれば、AIは依頼文だけでなく、散らかった記録や矛盾する証拠を読み解きながら、税務申告書、作業用ワークペーパー、技術レビュー、顧客向けアドバイスなどを仕上げる必要があります。 ここで重視されているのは、単なる計算精度ではありません。必要な論点を自分で見つけること、どの証拠を信じるか決めること、情報が足りないときにそ

papoo.work

Mistral Large 4の重みが公開された意味

Mistralが、フラッグシップモデル「Mistral Large 4（Le Chonk）」のweightsをopen weightとして公開した。単なる“モデルの発表”ではなく、開発者や企業が自前で扱える形に踏み込んだ点が大きい。しかもこのモデルは、コード生成やcybersecurity、reasoningの効率まで押し上げたとされる。Mistralが「sovereign AI」を掲げる会社だということを考えると、今回の発表は技術面だけでなく、AIの持ち方そのものをどうするかという話にもつながっている。 Mistralは、Mistral Large 4（Le Chonk）のweightsを公開したと発表した。このモデルは1 trillion parametersのnatively multimodal modelで、もともと今月初めにpublic previewとして出されていたものだ。今回の公開は、その後にreinforcement learningをさらに回したうえでのアップデート版にあたる。Mistralによれば、コード、defensive cybersecurity、reas

papoo.work

Qwenputerの中身をほどく

> この記事は後半です。前半は Qiita にあります: [Qwen3.5の中にCPUを埋め込んだ話を、RAMの作り方からほどく](https://qiita.com/homhom44/items/af9e77faf75ef402b866) *画像: divagr.com より* *画像: divagr.com より* 前半では、Qwen3.5-4B の前段に 32-bit RISC-V CPU を焼き込み、Gated DeltaNet の状態を RAM として使う、という骨格を見た。外部ツールは呼ばず、トークン列の流れの中で計算機が回る。ここで気になるのは、CPU と Qwen の役割分担が曖昧にならないのか、という点だ。 説明を追うと、境界はかなりはっきりしている。CPU 側は計算に必要な命令列を処理し、結果をトークンとして返す。Qwen 側はその出力を普通の文章として読み取り、続きの応答を作る。モデルの前にある 11 層の chip layer が命令の実行系で、その後ろの 32 層が通常の Qwen3.5 だ。つまり「LLM が賢くなって CPU を理解した」のではなく、LLM

papoo.work

Anthropicがスタンフォード教授の本を使っていた件、何が問われているのか

スタンフォード大学の教授たちの本が、AnthropicのAI「Claude」の学習に無断で使われていた――そんな裁判の話が、大学の学生新聞という形で報じられた。単なる著作権トラブルではなく、AI企業が学習データをどう集めるべきか、そもそも「学習」はどこまで許されるのかを突きつける内容だ。しかも争点は、過去の違法な取得と、正規に買った本を使うことを法律上どう分けるかにも及んでいる。AIの進化を支える材料の多くが本や記事だと考えると、これは業界全体の足元を揺らす話でもある。 記事によると、米AI企業Anthropicは、スタンフォード大学の10人超の教授の著作を違法に収集し、Claudeの学習に使っていたと連邦判事が判断した。報道では、少なくとも教授 Tobias Wolff、Abraham Verghese、Chang-Rae Lee、Daniel Mason、Hayagreeva Rao、Myra Strober の本が、許可なく使われていたとされる。問題になったのは、いわゆる“shadow libraries”と呼ばれる違法配布サイトで、LibGenやPiLiMiのような場所から本を

papoo.work

macOSのgit・curl・python3がまだ危ない理由

AppleのmacOSに入っている開発者向けツールが、すでに失効が問題になっている証明書をまだ信頼している――そんな話を、元記事はかなり強い口調で伝えている。対象は git、curl、python3 で、見落としというより、修正が遅れたうえに一度ユーザーが手で回避した状態まで台無しになった、というのが焦点だ。単なる設定ミスに見えて、実際にはHTTPS通信の中身を差し替えられる危険がある。開発者だけの話にとどまらず、CIや供給網にも響くので、今取り上げる意味がある。 元記事が扱っているのは、eMudhra の認証局コンプロマイズ、つまり証明書を発行する側の一部が侵害された件だ。Appleはこの件について17th October に通知を受けたとされているが、28th October の時点でも、macOS に同梱される開発者向けツールはまだその「compromised certificates」を信頼していたという。対象として挙げられているのは git、curl、python3 だ。しかも問題は、単に修正が遅れているだけではない。26th October に出た macOS 27.2 で

papoo.work

Gemini 4 Carbonが示した、Googleの「次の最前線」

Googleが公開した「Gemini 4 Carbon」は、同社の生成AIモデル群の中でも最前線を担うと位置づけられた新モデルだ。単に賢いだけではなく、サイバーセキュリティと長時間にわたる複雑な作業への対応を強く打ち出しているのが特徴である。しかも、前モデルの発表からまだ2週間しかたっていない段階で次を出してきたため、Googleがこの分野をどれだけ速く前へ進めようとしているかがよく見える。性能競争の話にとどまらず、実運用への慎重な出し方も含めて、かなり意味のある発表だと思う。 Googleは、Gemini 4 Carbonを「next frontier model」と呼び、これまでで最強のモデルだと説明している。特徴としてまず挙げているのは、state-of-the-art cybersecurity、つまり最先端レベルのサイバーセキュリティ性能と、long horizon capabilities、長い時間軸で複雑な作業をやり切る能力だ。公開文によると、Carbonは最近更新されたArtificial Analysis Intelligence Index v5.0で59点を取り、

papoo.work

512通りで開く鍵の正体を追う

> この記事は後半です。前半は Qiita にあります: [AES-256のはずが9ビットで足りる——MuPDFの暗号化PDFが軽く破られる背景](https://qiita.com/homhom44/items/ca06efe53f9cc6d0f270) *画像: en.wikipedia.org より* 前半で見た通り、問題の出発点は `drand48` 系の 48 ビット LCG でした。仕様上は 48 ビット状態を持ちますが、MuPDF では seed に Unix 時刻の秒が使われ、状態の低 16 ビットは固定値 0x330e です。つまり、時刻で揺れるのは上位 32 ビットだけです。 ところが、鍵生成ではこの状態をそのまま使わず、`lrand48()` で順に byte を抜いていました。LCG の掛け算と足し算では、上位ビットの揺れは下位へまったく伝わりません。MuPDF は `lrand48()` の戻り値を 1 バイトに切り詰めて使っていたので、鍵に入るのは状態のビット 17〜24 だけで、ビット 25 以上は鍵に効きません。そこに固定部分を差し引くと、時刻の 32

papoo.work