採用選考で「この課題をローカルで動かしてみてください」と言われたら、たいていのエンジニアは普通に動かします。npm install して、run して、動いたスクショを送る。私もそこで身構える発想は薄かったです。今回話題になっているのは、その「普通にやってしまう作業」そのものを突く手口です。
この記事の結論
採用選考の技術課題としてコードを渡し、求職者に実行させることで開発環境の認証情報を盗む手口が報告されています。狙われるのはクラウドのアクセスキー、SSH鍵、仮想通貨ウォレット、ブラウザ保存情報など。管理者権限がなくてもユーザー権限だけで成立するため、身に覚えのない課題は仮想マシンなどの隔離環境で開くのが基本の防ぎ方になります。
元になっているのは、codedge.deが公開した就職面接を使ってシステムを侵害する手口についての記事です。調査によると、求職者へ技術課題としてコードを渡し、実行させることで開発環境の認証情報を抜き取る流れが報告されています。個別の攻撃コードや通信先の解析までは当ブログで追えていないため、この記事では手口の性質と、受け取った側の守り方に絞って整理します。
コード課題型フィッシングの概要
流れはかなり単純です。LinkedInなどの求人経路で接触があり、面接や選考の一環として「技術課題」が渡されます。中身はリポジトリのURLだったり、ZIPで送られてくるプロジェクト一式だったりします。求職者はそれを自分のPCで動かし、その時点で仕込まれた処理が走ります。
狙われるのは、開発者のPCに当たり前のように置いてあるものです。クラウドサービスへログインするための鍵（AWSのアクセスキーなど）、サーバーへ接続するためのSSH鍵、仮想通貨ウォレット、そしてブラウザが保存しているログイン情報。開発機は便利さのために鍵を平文で置きがちなので、一台抜かれると被害範囲が本人のPCだけで終わりません。
リモート採用が普通になって、面接相手の実在確認が難しくなった影響も大きいと思います。会社名とロゴがあるページ、それらしい求人票、丁寧な担当者。この三点が揃うと、コードを疑う理由がほぼなくなります。
メールのリンク型フィッシングとの違い
従来のフィッシングは「偽ログイン画面にパスワードを入力させる」形でした。だから対策も分かりやすくて、URLを見る、公式アプリから入り直す、多要素認証を入れる、で大半が防げます。
コード課題型はそこが違います。入力させないのです。ユーザーは何も打ち込まず、ただビルドして実行するだけ。パスワードを盗む必要がなく、すでに端末に保存されている認証情報をそのまま読み出します。多要素認証は「ログイン時の本人確認」なので、鍵ファイルやセッション情報を直接コピーされる経路には効きにくい。ここがややこしいところで、普段のセキュリティ意識が高い人ほど「自分は入力していないから大丈夫」と感じてしまいます。
管理者権限がなくても成立するのはなぜか
管理者権限（システム全体を変更できる強い権限）が必要な攻撃なら、UACの確認画面やsudoのパスワード入力で一度は立ち止まれます。ところがこの手口は、そこを通りません。
理由は単純で、盗みたいファイルが全部ユーザー権限で読める場所にあるからです。ホームディレクトリ配下のクラウド設定、SSH鍵の置き場、ブラウザのプロファイル。どれも本人が日常的に読み書きしているので、本人と同じ権限で動くプログラムなら素通りできます。ウイルス対策ソフトも、正規の開発ツールがホーム配下のファイルを読む動きを毎回止めるわけではありません。
個人的にはここが一番効きました。「権限を上げていないから安全」という感覚が、開発機にはほぼ通用しないという話なので。
実行前に見るサイン
これらは単独で黒判定するものではなく、重なったときに手を止める材料として見ています。
- 課題の実行を急かす。「今日中に動作確認を」「期限が明日まで」など。
- 依存パッケージの取得元が公式レジストリ以外に向いている、あるいは見慣れないURLが設定ファイルに書かれている。
- 「必ずローカルで動かして」「Dockerではなく直接実行して」と、環境を指定してくる。
- コード内に長い難読化された文字列や、実行時に外部から追加スクリプトを取ってくる処理がある。
- 連絡が個人アカウントのみで、企業ドメインのメールが一度も出てこない。
- リポジトリが新規作成で、コミット履歴がほぼ空。あるいは本家のフォークだがブランチだけ更新されている。
実行環境を指定してくる点は、判断材料として分かりやすい方だと思います。まともな選考で「隔離環境は使わないでほしい」と言う理由が、ちょっと思いつきません。
隔離環境の選び方
「隔離環境で開く」は正論ですが、選択肢によって手間も守れる範囲も違います。比較として並べます。
| 方式 | 準備の手間 | 隔離の強さ | つまずきやすい点 |
|---|---|---|---|
| Dev Container（VS Codeのコンテナ開発） | 軽い | 中 | ホストのフォルダやSSH設定を共持っている初期設定が既定で有効なことがある |
| ローカル仮想マシン（VirtualBox / Hyper-Vなど） | 中 | 高 | 共有フォルダとクリップボード共有を切り忘れる |
| 使い捨てのクラウド仮想マシン | 中 | 高 | その環境に紐づくクラウド権限を強くしすぎる |
| 予備の実機（オフライン） | 重い | 最も高い | 再利用時に初期化を省いてしまう |
選ぶ基準としては、普段からコンテナを触っている人ならDev Containerが一番着手しやすいです。ただ、素性の分からないコードを開く目的なら仮想マシンを推したいところで、理由は隔離の強さより「戻せること」にあります。スナップショット（その時点の状態を丸ごと保存する機能）を取っておけば、実行後に何が起きても数十秒で実行前へ戻せます。ネットワークもホストオンリーに切り替えれば、外部への通信自体を止められます。使い捨てのクラウド側で開くなら、そのアカウントに本番の権限を持たせないことが前提になります。
環境を用意するときの現実的な確認
仮想マシンを一台持つと、選考課題に限らず「よく分からないツールをとりあえず動かす」用途で使い回せます。一般的な目安として、ゲストOSへ割り当てる分とホスト側の作業分を別々に確保できるメモリ量と、スナップショットを何枚か保存できるストレージの空きがあると運用が楽です。手持ちの機材で足りないときは、外付けSSDへ仮想ディスクを逃がすのが安上がりでした。この辺りは環境次第なので、自分のPCの空き容量を先に見た方が早いです。
すでに実行してしまった場合の順番
実行後に気づいたときの一般的な対応順
1. まずネットワークを切る（Wi-Fiオフ、LANケーブルを抜く）。
2. クラウドのアクセスキーを無効化し、新しい鍵へ差し替える。
3. SSH鍵を作り直し、サーバー側の公開鍵を入れ替える。
4. ブラウザに保存されたパスワードを変更し、ログインセッションを全端末で失効させる。
5. 仮想通貨ウォレットは新しいウォレットを作り直して資産を移す。シードフレーズの再利用はしない。
6. 会社支給の端末なら、自分で消す前に情報システム部門へ連絡する。ログが調査に必要になります。
順番に意味があります。先に端末を初期化してしまうと、鍵の失効が終わる前に手元の情報も消え、何が漏れたか分からなくなります。通信を止める、鍵を無効化する、その後で端末を作り直す、という流れです。
よくある疑問
Q. 課題を隔離環境で動かしたいと伝えると、選考で不利になりませんか？
A. 実務でも検証環境と本番を分けるのは普通の作法なので、変わった申し出ではありません。むしろ「そのまま実行してほしい」と押し返された場合、その反応自体が判断材料になります。
Q. GitHubでスターが多いリポジトリなら安全ですか？
A. スター数は本家への評価であって、渡されたフォークや特定ブランチの中身までは保証しません。URLが本家と同じか、履歴が不自然に浅くないかを見る方が実用的です。
Q. macOSやLinuxなら被害は小さいですか？
A. クラウドの認証情報もSSH鍵もブラウザのプロファイルも、OSを問わずユーザー権限で読める場所にあります。OSの種類より、その端末にどれだけ強い鍵を置いているかで被害範囲が変わります。
次に確認するなら、自分のPCのホームディレクトリに置きっぱなしのクラウド認証情報を一度棚卸しするところからだと思います。使っていない鍵が残っていることは、案外あります。手口そのものをもう少し詳しく知りたい方は、上でリンクしたcodedge.deの元記事に目を通してみてください。
当ブログでは、AI関連ツールやローカル環境の運用まわりも扱っています。他の記事もよければトップページから覗いてみてください。
あわせて読みたい関連記事
おすすめ Googleドキュメントを装った偽招待状、なぜ研究者まで騙されたのか
本物そっくりの体裁で技術者の信頼を突き、実行させることで侵害する手口という点で、就職課題型フィッシングと構造がよく似ています。研究者ですら見破れなかった事例は、今回の「求人経路なら疑わない」心理と重なります。
買う前にあわせて確認したい記事
スペックや価格だけで決める前に、必要な環境や選び方も確認しておくと失敗しにくくなります。
コメント