[レポート]Splunkでサーバーサイドリクエストフォージェリを検知する (sponsored by Splunk) #PRT325 #reinvent

Webアプリなどの脆弱性をつくSSRF(サイバーサイドリクエストフォージェリ)。SSRFとはどのような攻撃なのか、またそれを検知しシステムを守っていくにはどうしたらいいかを学ぶ、re:Invent 2022 のパートナーセッション
2022.12.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

セッション

スピーカー:Tom Smith
セッションレベル:300 - Advanced
カテゴリ:Security, Data Protection

はじめに

AWSの年に一度の祭典 re:Invent 2022に参加しております。 現地オフラインで Detecting SSRF events on AWS using Splunk (sponsored by Splunk) というセッションに参加してきました。

セッションの概要は以下となります。

概要

2019 年、有名な金融機関に対する侵入により、1 億人を超える顧客の個人データが失われました。 許可されていないユーザーは、サーバー側のリクエスト フォージェリ (SSRF) を実行し、グループがアクセスできるようにしました。 このセッションでは、ハイレベルな SSRF の基礎、AWS と Splunk の統合、そして最後に Stream、Splunk Enterprise Security、Splunk Enterprise を使用して、発生したそのようなイベントの兆候を検出する方法について説明します。 このプレゼンテーションは、AWS パートナーである Splunk によって提供されます。

内容

サーバーリクエストフォージェリ(SSRF)とは

(補足)
SSRFを一言で説明すると、外部から到達できない領域にあるサーバーなどに対して、プログラムコードの脆弱性を悪用して、リクエストを送る攻撃手法となります。
ではセッション内容について見ていきましょう。

  • 攻撃を行われた場合に AWS のサービスでは確認できなかったもの Splunk では見ることができたものがあった
  • 過去の SSRF の攻撃の例として、金融機関から1億人分の個人情報が盗まれた
  • 攻撃の痕跡を見つけていくにあたって、Mitre Att&ck を活用して攻撃のフェーズを識別
  • この事例を再現した疑似攻撃では発見、権限の昇格、永続化、データの取り出しからなる戦術に分類

SSRF の疑似攻撃

発見

  • コードに脆弱性を持つWebサイトに curl コマンドで悪意のあるコードを渡す
  • Amazon EC2 instance metadata から資格情報が返される

権限の昇格

  • Python で書かれた Lambda 関数を作成して AWS アカウントへの管理者権限を取得

永続化

  • 新しいユーザーの作成とポリシーのアタッチ
  • 最初に取得した管理者ユーザーへ変更があった場合でも、侵害された環境を永続させる

データの取り出し

  • S3 バケットをパブリックに公開

攻撃に使ったツール

  • W3AF、Kali Linux、DigitalOcean、PACU
  • Digital Ocean のみが14ドルの費用がかかるだけ

AWS では何を確認することができたか

  • 永続化のアカウント作成時には AWS では正常な操作としてのみログに記録されるのみでそれ以上のものは何もない
  • GuardDuty は S3 バケットの公開アクセスに関する設定変更を検出したがそのトークンのユーザー名は表示してくれない

Splunk へのデータ取り込みの構成

  • AWS のデータの取り込みは Data Manager で取り込みたいものを選択しアカウントを入力するだけ

  • データの流れは CloudWatch events、Amazon EventBridge、Amazon Kinesis Data Firehose を連携させて送られてくる

  • AWS 以外のデータの取り込み Apache ログや Azure、GCP のようなものは GDI を利用することができます

Splunk では何を確認することができるか

  • GuardDuty の検知では 12:35 4/9/2022 だった

  • Splunk で確認すると最初の侵入のためのコマンドが実行されたのは 10:44 4/9/2022 だった
  • 侵入開始からS3バケットの公開設定まで2時間くらいが経っていたことが分かる

  • リクエストされた uri path でフィルタしてみると全て3分おきに実行されています
  • セッションを維持するために繰り返し実行している

  • Splunk を使って分析できるようにする
    • メタデータを追跡するためのルールの作成
    • 169.254.169.254 へのURLリダイレクト通信
    • /security-credentials/ の大量のヒット
    • 短時間でのLambda関数の作成/削除
    • ES の ネットワークトラフィックアナライザーやプロトコルアナライザーを使ってVPCフローログを分析

  • Splunk ではログを取得したらすぐに分析できるようになっている
  • 都市ごとの新しいログインを可視化したりリスクスコアが高いものを表示してくれる

  • SOAR を連携させると、自動でユーザーアカウントを無効にしたりすることが可能です

まとめ

このセッションでは、AWS上でのサーバーサイドリクエストフォージェリの疑似攻撃を行い、Splunkを使って攻撃者行動を追跡していく方法について学ぶことができる内容になっていました。 AWSをはじめマイクロサービスのように様々なシステムから出力されるログ・イベントを一元に管理して、柔軟な検索を実現する SIEM を導入するのも有効なアプローチだと感じました。