現場で診断をしていると、作業の途中でふと手が止まる瞬間があります。
ログや設定を追いながら、「この構成、少し気になるな」と感じるあの感覚です。
明確な脆弱性が見つかったわけでもなく、アラートが鳴っているわけでもない。
それでも、経験的に「このまま放っておくと、どこかでつながりそうだ」と思うことがあります。
Azure DevOps、SVN、Web サーバー。
どれも多くの企業で使われている、ごく一般的な仕組みです。
それぞれ単体で見れば、特別に危険な存在ではありませんし、日々の業務を支える重要な基盤でもあります。
ただ、少しずつ役割が重なり、境界が曖昧になっていくと、設計した覚えのない経路が、いつの間にか自然にできあがってしまうことがあります。
今回の事例も、そうした「つながり方」の話でした。
ゼロデイ脆弱性が使われたわけでもなければ、派手な攻撃手法が登場するわけでもありません。
むしろ、ひとつひとつの要素だけを見ると、「それ自体はよくある」「その設定自体は理解できる」そう言いたくなるものばかりです。
ただ、SVN に残っていた情報。
DevOps の権限設計。
CI/CD パイプラインの実行権限。
それぞれが少しずつ前提を共有しないまま積み重なり、結果として、気づいたときには SYSTEM 権限まで一直線につながっていました。
振り返ってみると、「どこかで止められたはずの場面」はいくつもあります。
ただ、それは事後だから言えることで、運用の最中に違和感なく使えてしまう構成ほど、見直されにくいのも事実です。
だからこそ、この手の事例は「怖い話」として消費して終わりにするものではないと感じています。
何も起きていない今の状態で、「この仕組みは、どこまでできてしまうのか」一度だけ、落ち着いて考えてみる。
現場で予防や診断の仕事をしていると、その一度の見直しが、結果を大きく変える場面を何度も見てきました。
TABLE OF CONTENTS
ポートスキャンから見えた最初の違和感
最初に確認したのは、対象ホストで待ち受けているサービスでした。
いつも通り、全体像を掴むところから始めています。
Web ポートが開いているのは想定の範囲内でしたが、それとは別に 3690/TCP（Subversion） が外部から到達できる状態になっているのが目に留まりました。
SVN が公開されている構成自体は、決して珍しいものではありません。
実際、運用の都合や過去の設計を引き継いだ結果として、そのまま使われ続けているケースもよく見かけます。
ただ、気になるのは「公開されているかどうか」よりも、そこから何が見えてしまうのか、という点です。
この時点では、まだ明確に問題が起きているわけではありません。
あくまで、「入口になり得る場所が一つ見えてきた」という段階です。
それでも、調査の流れとしては十分に引っかかるポイントでしたし、ここを起点に、もう少し丁寧に中を見ていく価値はあると感じました。
SVN に残っていた「運用の痕跡」
SVN リポジトリについては、特別なことはしていません。
まずは一般的な列挙から始めて、どこまで中身が見えるのかを確認していきます。
この時点では、「何かを見つけにいく」というより、見えてはいけないものが、見えていないかを確かめる感覚に近いです。
リポジトリ内のファイルを一つずつ確認していくと、過去の移行作業に関するメモや、環境を示す URL がそのまま残っていました。そこから devops.worker.htb を含む、いくつかのサブドメインが判明します。
ここまで来ると、調査というよりも、「書かれている通りに辿っているだけ」という感覚に近くなってきます。
実際、別のサブドメインにアクセスしてみると、そこからさらに追加のリンク情報が自然につながっていきました。
どの段階でも、強引な探索をしている感覚はありません。
用意されている情報を、順番に読んでいっただけです。
流れが変わったのは、コミット差分を確認したときでした。
PowerShell スクリプトの中に、認証情報がそのまま記述された箇所が残っているのが目に入りました。
移行作業や一時的な検証のために書かれたものだった可能性は高いと思います。
ただ、それが削除されないまま残り、しかも外部から参照できる状態になっていた、という点は無視できません。
この時点で、「偶然見えてしまった情報」ではなく、次の扉につながる情報として扱う必要があると感じました。
Azure DevOps の「正規機能」が攻撃経路になる瞬間
見つかった認証情報を使って Azure DevOps にアクセスしてみると、特に引っかかることもなく、通常のログインがそのまま成立しました。
アラートが出るわけでもなく、追加の確認を求められることもありません。
ここで行われている動きは、侵入というよりも、「用意された入口から、そのまま入っている」感覚に近いものでした。
ログイン後にプロジェクト一覧を確認すると、リポジトリにも問題なくアクセスできる状態でした。
まずは中身を把握するため、ローカル環境に clone します。
リポジトリの構成やファイルを確認したあと、新しいブランチを作成し、ファイルを一つ追加します。
このあたりの操作は、日常的な開発フローと何も変わりません。
そのまま Pull Request を作成し、内容を確認して承認します。
ここで改めて感じたのは、
レビュー体制が「仕組みとして」成立していない場合、この工程は誰にも止められないという点でした。
しばらく待つと、変更内容が Web サーバー側に反映されます。
CI/CD の流れとしては、極めて自然な結果です。
ただ、その「自然な反映」の先に、
Web シェルが設置された状態が出来上がっていました。
ここまで来ても、特別な操作をした感覚はありません。
DevOps の機能を、設計された通りに使っただけです。
それでも、組み合わせ次第で、ここまで到達してしまう。
その事実が、少し重く残りました。
パイプラインが持つ実行権限の重さ
Web シェル経由で OS 側の操作ができるようになり、次に確認したのは、実行環境の権限と、その周辺にどんな情報が残っているかでした。
ここから先は、Web の話というより、完全に OS の話になります。
リバースシェルを確立したあと、まずは取得できている権限やユーザー情報を一つずつ確認していきます。
この段階では、無理に先へ進むというより、「いま立っている場所がどこなのか」を把握することを優先しました。
確認を進める中で、SeImpersonatePrivilege が付与されていることが分かりました。
この権限自体は、珍しいものではありません。
ただ、サービスの動き方次第では、「次の段階へ進めてしまう余地」が生まれることもあります。
ここで一気に攻めに転じるというより、「他にも見えている情報はないか」をもう一度洗い直すことにしました。
さらに調査を進めていくと、別のユーザーに紐づく認証情報が見つかります。
試しに WinRM 経由でアクセスしてみると、こちらも問題なく成立しました。
このユーザーで改めて Azure DevOps を確認すると、先ほどとは異なるプロジェクトが見えてきます。
そこでは、Pipeline を操作できる権限が付与されていました。
Pipeline の作成画面を開くと、管理者に承認された Agent Pool がそのまま選択できる状態になっていました。
テンプレートとして PowerShell を選び、実行するスクリプトを指定します。
操作自体は、CI/CD の設定としてごく一般的なものです。
ただ、この Pipeline が どの権限で実行されるのかを考えると、
話は少し変わってきます。
Pipeline を保存して実行すると、その処理は SYSTEM 権限 で動作していました。
ここまで振り返ると、一つひとつの操作は、すべて用意された機能の範囲内でした。
それでも、情報と権限が整理されないまま積み重なると、
結果として、ここまで到達してしまいます。
「どこで踏み越えたのか」が分かりにくいこと自体が、この構成の一番の怖さだと感じました。
つながり方を一度、改めて見直す
この事例を振り返って、強く印象に残ったのは、特別な攻撃手法がほとんど使われていないという点でした。
外部から到達できる状態のまま運用されていた SVN。
リポジトリの中に残っていた、過去の作業の痕跡。
境界が整理されないまま使われていた Azure DevOps の権限。
そして、実行権限の強い Pipeline。
どれか一つだけを見れば、「それ自体はよくある」「便利だから使っている」そう言われる仕組みばかりです。
ただ、全体像を前提にした見直しがされないまま重なると、それぞれが自然につながり、いつの間にか、想定していないところまで到達してしまいます。
問題が起きていない今だからこそ、「この構成は、どこまでできてしまうのか」一度だけ、落ち着いて考えてみる。
現場で予防や診断をしていると、その一度の確認が、結果を大きく分ける場面に何度も出会います。
自社のセキュリティに不安を感じたら
投稿者プロフィール
-
Associate Red Team Engineer | Bug Bounty Hunter
スリランカ初のHackTheBox Offshore認定を取得したセキュリティエンジニアです。レッドチーム演習、ワイヤレスセキュリティ、マルウェア解析、リバースエンジニアリングを専門とし、Allianz、Crowdstrike、Nokia、WSO2、PayHere、HackerOneなどの大手プラットフォームで重要な脆弱性を発見してきました。複数のHall of Fameに名を連ねるほか、CVE（CVE-2024-34452, CVE-2024-48605）への貢献実績を持ち、世界的に高く評価されています。
主な保有資格：
● OSCP+（OffSec Certified Professional Plus）
● OSCP（Offensive Security Certified Professional）
● OSWP（Offensive Security Wireless Professional）
● HTB Offshore Penetration Tester（Level 3）
● Active Directory Penetration Testing Skill Path
