VPNゲートウェイが侵害されたとき、実際に何が露出するのか

VPNゲートウェイは、保護するトンネルの終端に位置する。つまり、その暗号化を通過させるのではなく終端する。攻撃者がホストを掌握すれば、トンネルは外から見れば健全なままに見える一方で、中間にあるマシンはもはや信頼できない。有用な問いは、すべてが復号されるかどうかではない。そのホストが何を見られたか、どこまで到達できたか、どの秘密が実際にそこに保存されていたかである。この三つの答えは大きく異なり、対応もそれに応じて変わる。

ゲートウェイはトンネルを終端するため、内側が見える

VPNにおける暗号化はホップごとに行われ、ゲートウェイはそのホップである。外側の層を剥がし、ポリシーを適用し、内側のパケットを転送するため、運ばれるすべてのパケットはある時点でそのホストのメモリ上に読める形で存在する。これは設計であり欠陥ではない。だからこそゲートウェイの侵害は、トンネルの暗号技術の侵害とは別の出来事である。

攻撃者がまず得るのは位置である。運ばれる通信を観察し、転送を変え、バックエンドの代わりに応答する能力だ。次に何を得るかはホスト次第であり、ここで人々は過大評価する。ゲートウェイへのアクセスだけではブラウザのTLSセッション鍵は渡らない。それらはゲートウェイ上に決して存在しなかったからだ。

同じ大きさではない三つの露出

問いを、運ばれる通信、到達可能なシステム、保存された秘密に分け、それぞれに個別に答える。

真ん中の行こそが見落とされる。ゲートウェイは通常、プライベートネットワークへのルートと、バックエンドがすでに信頼する送信元アドレスを持つ。したがって興味深い問いは、それらのバックエンドがそのアドレスから何を許可するかである。狭いクライアントアクセス・ポリシーは良い統制だが、ホスト上の攻撃者は通常のクライアントが使うインターフェースに限定されない。

下の行はインシデントがどれだけ続くかを決める。サーバー鍵とCA鍵では影響範囲がまったく異なり、ローカル管理者アカウントと読み取り専用の監視トークンも同様である。

トンネル内のHTTPSもHTTPSのまま

アプリケーションのTLSはVPNゲートウェイではなくアプリケーションで終端するため、侵害されたゲートウェイはそれらのフローについて暗号文しか観察できない。これは攻撃者が得るものに対する現実的な限界であり、はっきり述べる価値がある。逆の主張はパニックと誤った判断を広げるからだ。二つの条件がこれを崩す。信頼された証明書を持つ検査コンポーネントが経路上にあれば、ゲートウェイは設計上平文を見られる。アプリケーションのエンドポイント自体が侵害されていれば、トンネルは無関係である。

したがって、彼らが何を見たかという答えは条件付きであり、判決として発表するのではなく条件として書き留めるべきである。

再び信頼する前に何を変えるべきか

ホストを再構築することは必要であり、めったに十分ではない。管理アカウント、デプロイ資格情報、署名鍵を依然として持つ攻撃者は、ホストを好きなように戻せる。復旧は、侵害されたマシンに依存しない管理経路から始めなければならない。

何をローテーションするかを決める前に、そこに何があったかを棚卸しする。鍵、サービスアカウント、APIトークン、ローカルユーザー、スケジュールされたジョブ、信頼関係、デプロイパイプラインはすべて候補であり、それぞれに確認すべき所有者がいる。

ss -lntup
getent passwd
crontab -l
ip route show table all

その一覧は、ホストが何を提供し、どこまで到達できたかを見る最速の方法である。 まず証拠を保全する。対応責任者のプロセスに従うこと。再構築は調査に必要なものをまさに破壊するからだ。NIST SP 800-61 第3版は、準備、検知、対応、復旧を再起動手順ではなく一つのリスクプロセスの一部として扱っている。

次の被害を安くする境界

必要になる前に四つの境界を築く価値がある。ゲートウェイを経由して認証しない独立した復旧経路を保つ。署名権限を通信を提供するホストから分離する。ゲートウェイが到達できる範囲を制限し、侵害されたゲートウェイが自動的に侵害された管理ネットワークにならないようにする。そして各資格情報の所有者を記録し、ローテーションが考古学プロジェクトではなく一本の電話で済むようにする。

これらのどれも侵害を防がない。侵害を境界づけ、悪い一週間と悪い四半期の差を生む。