こんにちは、Orca Security 担当の尾谷です。

以前、こちらのブログ記事にて Attack Path を解説しました。
Attack Path は、Crown Jewel に向かう導線が描画されます。

Crown Jewel とは

Orca Security が提供する Crown Jewel と呼ばれる機能は、組織の最もビジネスに重要な資産をさします。

攻撃者は常にインターネットに面したポートを検索しています。
インターネットに面したポートを見つけた攻撃者は、まずそのエンドポイントの脆弱性が悪用できるか確認します。
攻撃者が侵入すると、大抵はターゲットのネットワーク内を横方向に移動します。大抵、ビジネスで最も重要な情報はプライベート環境に保存しますが、横移動によって攻撃者は情報に辿り着く可能性があります。
攻撃者がクラウンジュエルを見つけると、標的となった情報は最も脆弱な状態になります。攻撃者はおそらくここで止まり、通常は身代金を要求したり、サービス拒否を実行したり、組織の評判を著しく傷つけたりします。

Crown Jewel は以下の法則によって、Orca Security が自動で設定します。

管理者権限を持つ IAM ロール or IAM ユーザー
システム上の PII アラートと機密キーを含む仮想マシン
S3 バケットやデータベースなどのデータリソース (これには、PII アラートとシステム上の機密キーが含まれます。)
管理者権限または関数自体に機密キーを持つサーバーレス関数

Crown Jewel は手動で設定することもできます。

Auto Scaling インスタンスに Crown Jewel を手動設定した場合の挙動を確認するための前準備

前置きが長くなりましたが、Auto Scaling のノードとして稼働するインスタンスに手動で Crown Jewel を設定した場合、インスタンスがリプレースされると Crown Jewel はどうなるのでしょうか。
検証した結果をアウトプットさせていただきます。

また、非常に長いブログになりましたので結論から記載しますと

Crown Jewel は Auto Scaling Group に設定するので、インスタンスが入れ替わっても引き継がれたように見えます。

考え方

以下のように Auto Scaling フリートがあり、ASG 元の AMI ではなく特定の 1 インスタンスだけに Crown Jewel を手動で設定したとします。

すると、インスタンスが入れ替わった際に Crown Jewel はなくなるはずですよね。
ですが、ASG 自体に Crown Jewel を設定するので、インスタンスが入れ替わっても Crown Jewel がアタッチされたままに見えます。

EC2 を起動

早速やってみたいと思います。EC2 コンソールからインスタンスを起動します。

Graviton2 インスタンスで起動することにしました。
キーペアはなしにします。

ストレージは gp3 で暗号化を有効にしました。

アウトバウンド 443 ポートだけ開放したセキュリティグループをアタッチしました。

また、セッションマネージャーを接続するために IAM インスタンスプロフィールロールをアタッチしました。

i-01db23335356ac72c というインスタンスがデプロイされました。

このインスタンスに Elastic IP アドレスを割り当てました。

セッションマネージャー経由でインスタンスに接続ができたので、以下コマンドを投入して Web サーバーにしました。

dnf install -y httpd
systemctl start httpd
systemctl enable httpd

Apache のインストールが終わったので、Elastic IP を外して

セキュリティグループのアウトバウンドルールを削除しました。

これで、かなり強固なインスタンスが出来上がったと思います。

パブリック IP アドレスがアタッチされておらず、インターネットフェーシングしていない
キーペアを含まない
ストレージが暗号化されている
Graviton 2 (Nitro)
インバウンドは ALB からの 80 ポートのみを開放
アウトバウンドは無し

Elastic Load Balancing (Application)

続いて、Application Load Balancer (ALB) を起動します。
[ロードバランサーの作成] ボタンをクリックし、

Application Load Balancer の [作成] ボタンをクリックします。

ロードバランサー名を入力し、VPC や AZ などを指定して起動しました。
セキュリティグループはインバウンドポート 80 のみ開放しました。

EC2 インスタンス側でも、ALB からの 80 ポートからのみアクセスできるようにしました。

これで、EC2 自体にはインターネット越しにアクセスができない Web サイトができました。

Orca Security にてスキャン開始

構成図のような形で、環境が整いました。
インターネットに面したリソースは Application Load Balancer のみです。

Orca Security でスキャンしてみました。
Orca Security のコンソールから、Settings -> Accounts と進み、該当のアカウントをスキャンしました。手動スキャンがスタートしました。

スキャン開始から、

スキャン終了にステータスが変わりました。

Orca Security の Discovery から「i-01db23335356ac72c」を検索したところ、Risk Score は 4.3 と表示されていました。

EC2 インスタンスに VPC エンドポイントが設定されていないというアラートと、Systems Manager でサポートされていないというアラートを検知していました。
どちらも Medium でありますが、緊急ではありません。

また、Crown Jewel も設定されていませんでした。

Auto Scaling フリートを作成

では、この EC2 インスタンスから AMI を作成して Auto Scaling を設定していきます。

AMI を取得

アクション > イメージとテンプレート > イメージを作成を選択し、otani-test-image20230619 という名前で作成しました。

AutoScaling を作成

EC2 コンソールから Auto Scaling グループを開き [Auto Scaling グループを作成する] ボタンをクリックします。

任意の名前をつけて、[起動テンプレートを作成する] ボタンをクリックします。

任意の起動テンプレート名を設定して、

先ほど作成した AMI を指定しました。

インスタンスファミリーは t4g.nano で、秘密鍵は指定なしのままとしました。

Auto Scaling の画面に戻りますので、[次へ] をクイックします。
あとは、以下にて設定して作成しました。

サブネットは、パブリックサブネット (AZ-a と AZ-c) を指定
既存のロードバランサーにアタッチするを選択
先の手順で作成した ALB のターゲットグループを指定
希望するキャパシティは 1 のまま
最小キャパシティは 1 のまま
最大キャパシティは 1 のまま

すると、i-01db23335356ac72c とは別に、新しく i-00a073273c93030ed というインスタンスが起動してきました。

ヘルスチェックがエラーになるため、パスを /health.html から / へ変更し、成功コードを暫定的に 404 に変更しておきました。

また、ゴールデンイメージを生成したマスターインスタンスである i-01db23335356ac72c は停止しました。

ASG インスタンスが healthy になりました。

ここまで仕上がりました。

Orca Security にて 2 度目のスキャン

では、Orca Security に i-00a073273c93030ed を認識してもらうために再スキャンします。

再スキャンが完了しました。

Discovery にて、ASG ノードのインスタンス i-00a073273c93030ed を検索すると、表示されました。

もちろん、Crown Jewel は設定されていません。
※ この画像は最後にもう一度説明します。

Auto Scaling インスタンスに Crown Jewel を手動設定した場合の挙動

ようやく前準備が整いました。
Auto Scaling インスタンスに Crown Jewel を手動設定した場合の挙動に関しての検証を進めていきます。i-00a073273c93030ed に対して、Crown Jewel を手動で設定します。

その後、i-00a073273c93030ed をターミネートします。

すると、ASG ノードのインスタンスである i-07372a61f676416ea が自動起動してきました。

冒頭の構成図に戻りますが、Crown Jewel を設定した i-00a073273c93030ed が消滅したので、

入れ替わった i-07372a61f676416ea には Crown Jewel はなくなるはずです。

Orca Security にて 3 度目のスキャン

では、Orca Security に i-07372a61f676416ea を認識してもらうために再スキャンしました。

Discovery にて検索すると、Crown Jewel バッチがついた状態で表示されました。

これはすごい！魔法のようだと思いましたが、もう一度同じ検証を行なって原因が分かりました。

Crown Jewel が引き継がれたのではなく、Auto Scaling に Crown Jewel を設定していた

Auto Scaling のノードとして起動したインスタンスは、Auto Scaling グループとしてまとめられます。

Crown Jewel を設定した時の画像を再掲します。
Discovery にて、ASG ノードのインスタンス i-00a073273c93030ed を検索して、i-00a073273c93030ed の詳細ページを開いたつもりでいましたが、開いていたのは、Auto Scaling Group でした。

Orca はメタデータを読み込み、そのインスタンスがどういった形で起動しているのか把握していることが改めて証明できたかと思います。

まとめ

Auto Scaling インスタンスに Crown Jewel を手動で設定をしても意味がないかどうかを検証しました。
結論、Auto Scaling のノードとして起動したインスタンスには、Crown Jewel が設定できず、Auto Scaling Group 自体に Crown Jewel を設定するオペレーションになることがわかりました。

最後までお読みくださりありがとうございました。