クラウドサービスの利用でエンジニアスペックに合わせたスピーディなサービス展開が可能になった一方、責任分解モデルの誤解や組織内の縦割り管理の不整合や不備により、クラウド特有の脆弱性に無策となり深刻な問題を引き起こす原因となっています。この記事ではその中でもいくつかの例を挙げ、クラウド設計・設定の脆弱性を全社的に取り組むための啓蒙と見識の提供に繋がればと記事に起こすことにしました。
それでは早速紹介していきます。
Subdomain takeovers
Subdomain takeoversとはCDN（Content Delivery Network）やWebホストなどをクラウドサービスなどで利用した際に設定したサブドメインのDNS設定がサービスの利用終了後も残ったままになっていることを悪用し、ドメイン名の管理権限を持たない第三者が、そのサブドメインの乗っ取り（takeovers）する攻撃手法です。
CDNの設定の更新忘れとドロップキャッチ(ドメインの所有のリリース直後に意図的にドメインを取得する行為)が組み合わさるケースが多く、次いでクラウドベンダーのサービスの変更管理漏れで発生します。ブランドの誘引力を悪用され過去ドメインがマルウェア配布サイトとなり被害を拡大されたり、フィッシングサイトを設定されたりといった被害シナリオが想定されます。
AWSでは
*.elasticbeanstalk.com←こっち忘れられがちなので注意
*.s3.amazonaws.com
対応はシンプルに不要なCNAMEレコードを削除なのだが、発生する原因は組織内での管理の問題に起因することが多い印象です。
リソースを削除したらDNS設定、特にCNAMEを更新できる管理体制を平時から運用する
AWS COGNITO MISCONFIGURATION
数多ある設定不備の中で認証機能で活用されるCognitoはターゲットとして優先度が高いと言えます。さらにALB認証などに対応した結果社内SSOとも連携している可能性もあり益々重要性が増しています。
悪用シナリオ：想定外のサインアップ
企業向けのサービスなどでサインアップ機能はオープンにせず、契約に基づいて提供者側でアカウント発行するサービスを運用しているケースを想定します。
この場合利用者に提供を意図していないサインアップ機能を利用して登録することは不正行為と言えます。また以下に示すようにバイパスされれば機能の悪用の連鎖により」深刻な問題につながります。具体的に確認してみましょう。
まず下準備として通常ログインのリクエスト・レスポンスからClientIDが抽出します。
次にヘッダーにX-Amz-Target：AWSCognitoIdentityService.SignUpとしてリクエストをAPIリファレンスのSignUpを見ながらRequired: Yesの最小構成からテストしてみます。（Burp SuiteのRepeater機能を利用するとテストが捗ります）
２００ OKが返ってきた場合、指定したメールにきているConfirmationCodeを使用してAPIリファレンスのConfirmSignUpを確認してリクエストを送信します。
これで不正な登録はできましたがアプリケーションへのアクセスにはグループの所属が必要なので現時点でログインしてもエラーになります。アプリで利用できないからここまでではなくリソースへのアクセス権限から活路を開きます。
今度はAmazon Cognito Federated IdentitiesのAPIであるGetCredentialsForIdentityを利用します。
X-Amz-TargetヘッダーをAWSCognitoIdentityService.GetCredentialsForIdentityとした上でリクエストするとCredentialsがレスポンスされます。
この情報でAWS CLIにAWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,AWS_SESSION_TOKENを設定(export)します。
＄aws sts get-caller-identityで確認し有効になっていることが確認できたらアクセス可能なリソースを確認します。
s３などあたりをつけてaws s3 lsとしてみてもいいですしaws_service_enum.pyなどを利用して隈なく確認する手もあります。脆弱性診断では時間都合もあるのでaws_service_enum.pyなどで効率化することを推奨します。
運用よくAWS Lambdaにアクセス権がある場合はaws lambda list-functionsでroleを確認していきましょう権限変更系のロールが付与されていれば権限昇格の可能性がありバックドアを環境に仕込み永続化まで実現できてしまいます。
悪用シナリオ：水平認証のバイパス
2022年6月3日検証なしにメールアドレスが更新されることを防止する機能がデフォルトで実装されました。
裏を返せば2022年6月3日以前に構築されたユーザプールには謂わゆる水平認証のバイパスの脆弱性の可能性があることになります。
具体的にはサインアップ時はメールアドレスにOTPを送信し検証するがメールアドレス変更のAPIにはその検証がないため乗っ取りが可能ということです。
CognitoはHTTPSリクエスト上ではX-Amz-Targetヘッダーによって使用するAPIを指定します。
AWSCognitoIdentityService.SignUpであればサインアップ、AWSCognitoIdentityService.GetIdであればIDの取得といった感じです。
ログインリクエスト時のレスポンスに含まれるAccessTokenを利用します。get-user Cognito APIを確認してみましょう。
AccessTokenを利用してAWS CLIからupdate-user-attributesをリクエストしてメールアドレス変更を試みます。
$aws cognito-idp update-user-attributes --access-token "example_access_token" --user-attributes Name="email",Value="example_new_email"GetIdに紐づくメールアドレスで識別している場合や、ドメインごとの遷移の割り振りをしている場合、アクセス権限の侵害につながる可能性があります。
なお2022年6月3日以降では検証コードがON（email_verified 属性がTrue に設定）となり
aws cognito-idp verify-user-attribute --access-token "example_access_token" --attribute-name "email" --code "verification_code"と任意のアドレス変更は現実的ではなくなりました。対策をする場合他にも同じような入口がないか俯瞰してみる視点が大切です。
email_verified 属性がTrue に設定しましょう
SSRF（Server Side Request Forgery）for IMDS v２
インスタンスに関する情報であるインスタンスメタデータをInstance Meta Data Service(IMDS)を通じて取得することができます。IMDS v1の場合GETメソッドで取得可能だったため、Capital Oneの1億人を超える個人情報流出など大きな情報漏洩の原因にもなりました。
これはApache Modsecurityの設定不備でSSRF攻撃を検出されなかった（AWS WAFでは検知可能）ことも大きな要因です。
IMDS v２では以下のようなリクエスト仕様に修正されました
curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"IMDS v２となりPUTメソッドになったので安心かというと攻撃される可能性はあるため油断はしないようにしましょう。
JIRAのSSRF（CVE-2019-8451）と組み合わせるとhttpmethodとheadersで(ターゲットのURL)?url=http://169.254.169.254/latest/meta-data/profile&httpmethod-put&&X-aws-ec2-metadata-token-ttl-seconds%3d21600でGETリクエストするとトークンをレスポンスしてしまいます。
OpenSocial対応なるものでPUTにした対策が無意味になっていますねwキーをURLエンコードを 2 回してhttp://169.254.169.254/latest/user-dataにPOSTリクエストすると資格情報が得られてしまいます。
※Burpsuite Collaboratorなどでチェックすると利用サービスの特定が楽です
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery#ssrf-url-for-aws-bucket
Security Token Serivce（STS）の悪用
IAMポリシー履歴の悪用
基本的にユーザアカウントに直接ポリシーは適用せず、グループにアタッチし、ユーザは参加させる形式ポリシーも過去も含め役割に逸脱しているポリシー（分割前の部署のポリシーなど）は適用せず新規に作成することを推奨します。紹介のケースではSetDefaultPolicyVersionの権限が悪用されるシナリオを想定します。
まずは$ aws iam list-attached-user-policies –user-name XXXXX –profile XXXXXでアタッチされているポリシーを確認する
次に得られたポリシーで$ aws iam list-policy-versions –policy-arn arn:aws:iam::XXXXX:policy/XXXXX –profile XXXXXで過去バージョンを確認する
SetDefaultPolicyVersionがあるか確認する
そして$ aws iam get-policy-version –policy-arn arn:aws:iam::XXXXX:policy/cXXXXX –version-id XXXXX –profile XXXXXでそのバージョンの中身を確認する
ここで最も良さげ（目的の権限がある。または高権限）のバージョンを探す
最後に$ aws iam set-default-policy-version –policy-arn arn:aws:iam::XXXXX:policy/XXXXX –version-id XXXXX –profile XXXXXでバージョンを適用すると権限昇格の実現につながる可能性があります。
S3の公開による情報漏洩
S3のダッシュボードでの警告やAWS Configによるアラートにより数自体は少なくなりましたが被害はまだまだ存在するのでこちらも紹介します。S3に保存された機微情報(アップロードしたドキュメント)、個人情報（顔写真は個人情報に当たります）の流出などの被害につながります。実際、米Verizon、1400万人の顧客情報、ダウジョーンズ、400万人の個人情報と枚挙にいとまがありません。
S3で静的コンテンツのWebサーバとして機能させる場合もCloud Front経由以外を受け付けないOAIの設定は必須と言えます。
他にもAWSから見ればユーザ責任という設定ミスは数多あります。クラウドサービスを全社的で使っていく方針であれば、部署の垣根をなくし、暗黙知をなくし常にミスがありうることを想定し検知し対応できる仕組み作りが大切かと存じます。
以上です。参考になれば幸いです。