AWSセキュリティ学習環境構築ツールCloudGoatの初期設定

僕のようなAWSセキュリティに興味がある人にうってつけのツールCloudGoatを見つけたので環境構築をやってみました。

CloudGoatとは

Rhino Security Labs社が開発したセキュリティ学習用の脆弱性があるAWS環境構築ツールです。
用意されているシナリオを進めていくことでクラウドサイバーセキュリティスキルを磨くことができます。

各シナリオは、
攻撃者として環境調査をおこない脆弱性を特定するところから始まります。
脆弱性の特定ができたらそれを悪用しサービスの情報を盗むことが目標です。

詳細は以下の公式GitHubに載っています。 github.com

クラメソ様も記事を書いておりますのでこちらも参考までに dev.classmethod.jp

※注意事項
実際に試す際は個人のアカウントをお勧めします。
意図的に脆弱なAWSリソースを作成する必要がありますので、
機密性の高いAWSリソースと一緒に配置は絶対にしないでください

また、一部のシナリオではFree-Tierをこえるリソースが作成されます。
利用後は必ず不要なリソース削除を忘れないようにしてください！

CloudGoatの初期設定

CloudGoatをやる場合の必要条件

• 対象OSはLinux or MacOSです。 ※Windowsはサポートされていません！
  • 引数タブ補完にはbash 4.2+を利用する
• Python3.6 以上がインストールされていること
• Terraform 0.12がインストールされていること
• AWS CLIがインストールされていること
• リソースを作成および削除するのに十分な権限を持つAWSアカウントであること

環境構築

VPCとNW設定は省略します。デフォルトVPCを使う場合は以下を参考にしていただければと思います。 chikoblog.hatenablog.jp

IAM user作成

CloudGoatからAWSリソースを作成するためのIAM userを作成します。

CloudGoatという名称のIAM userを作成し、
AdministratorAccess（AWS管理ポリシー）権限を付与します。

ES2の設定

必要条件をもとに僕は先ほどIAM userを作成したAWSアカウントに
以下の内容で作業用EC2を作成しました。

インスタンスタイプ:t2.micro
OS:Amazon Linux 2

初期作業

yum updateでパッケージをアップデートをします。

$ sudo yum update

$ aws configure --profile CloudGoat
AWS Access Key ID [None]: CloudGoatのアクセスキー
AWS Secret Access Key [None]: CloudGoatのシークレットキー
Default region name [None]: 
Default output format [None]: 

Python3.6 以上のインストール

Python がインストールされているかどうかを確認します。

$ python3 --version
bash: python3: コマンドが見つかりません

上記のようにインストールされていなければPython をインストールします。

$ sudo yum install python3

次のコマンドを実行して、Python が正しくインストールされたことを確認します。

# python3 --version
Python 3.7.4

Terraformのインストール

ダウンロードしたいバージョンを確認します。
Terraform 0.12が必要です。 releases.hashicorp.com

必要なバージョンのzipファイルをダウンロードします。

$ wget  https://releases.hashicorp.com/terraform/0.12.20/terraform_0.12.20_linux_amd64.zip

ダウンロードしたzipファイルを解凍します。

$ unzip terraform_0.12.20_linux_amd64

/usr/binに解凍したファイルを移動します。

$ sudo mv terraform /usr/bin

最後にTerraformが動くかの確認をおこないます。

$ terraform -v
Terraform v0.12.20

クイックスタートの実施

CloudGoatをインストールするのに必要条件を満たしたら次のコマンドを実行します。

$ git clone https://github.com/RhinoSecurityLabs/cloudgoat.git ./CloudGoat

※Gitがインストールされていなければ以下のコマンドでインストールしてください。

$ sudo yum install git-all

正しくgit cloneできたか確認し、CloudGoatディレクトリに移動します。

$ ls
CloudGoat

$ cd CloudGoat/

Pythonの必要パッケージをpip3でインストールします。

$ sudo pip3 install -r ./core/python/requirements.txt

git cloneで持ってきたcloudgoat.pyに実行権限を付与します。

$ chmod u+x cloudgoat.py

デフォルトプロファイルの作成をおこないます。
使用するAWSプロファイルのCloudGoatを選択します。

$ ./cloudgoat.py config profile
No configuration file was found at /home/ec2-user/CloudGoat/config.yml
Would you like to create this file with a default profile name now? [y/n]: y
Enter the name of your default AWS profile: CloudGoat
A default profile name of "CloudGoat" has been saved.

whitelist.txtファイルの設定をおこないます。
yを選択するとifconfig.coにネットワーク要求を自動的おこない、
その結果をwhitelist.txtに書き込みます。

$ ./cloudgoat.py config whitelist --auto
No whitelist.txt file was found at /home/ec2-user/CloudGoat/whitelist.txt
CloudGoat can automatically make a network request, using curl, to ifconfig.co to find your IP address, and then create the whitelist file with the result.
Would you like to continue? [y/n]: y

whitelist.txt created with IP address xxx.xxx.xxx.xxx/xx

これで以下のように./cloudgoat.py createの後にシナリオ名を入力する事でCludoGoatを開始できます。

./cloudgoat.py create cloud_breach_s3

終わりに

今後はCloudGoatの各シナリオをやっていき、
その記事を書いていこうかと思ってます。

その前の初期設定や環境設定に僕は詰まってしまったので、
記事を書かせていただきました。

脆弱性があるAWS環境構築を作ってしまうので
ある程度悪用を防ぐ手段を現在考え中です。

みなさまもCloudGoatをやる際はくれぐれも注意してお勉強いただければと思います。

flaws.cloudでAWS環境にSSRF攻撃をやってみた Level 3

この記事は下記のブログの続きです！

chikoblog.hatenablog.jp

まだ、このシリーズの読んでいなければ先にLevel 1の記事をご覧ください。
chikoblog.hatenablog.jp

※この記事はflaws.cloudのやり方が載ってます。今後flaws.cloudにチャレンジ予定の方はネタバレになってしまいます。

Level 3

トップページはこんな感じです。

今回の問題は以下の通りです。
「The next level is fairly similar, with a slight twist. Time to find your first AWS key! I bet you'll find something that will let you list what other buckets are.」
Level 3もLevel 2にかなり似ているがまた捻りを加えて、最初のAWSキーを見つけにくくなっている？ようです。
また、他のバケットが何であるかをリストできるものを見つかるでしょう...
※上記、僕なりの翻訳です。英語能力が不足しています...

現状、AWSキーが見つかることしかわかりません！

とりあえず進めてみる

いつもの流れでLevel 3のドメイン
level3-9afd3927f195e10225021a578e6f78df.flaws.cloudに対して
digコマンドを実行してみる。

$ dig any level3-9afd3927f195e10225021a578e6f78df.flaws.cloud +short
52.218.228.122

いつも通りAレコードが取れました。
いつもnslookupを使っているので今回は趣向を変えてdig -xで
先ほど手に入れたAレコードを引いてみる。

$ dig -x 52.218.208.187 +short
s3-website-us-west-2.amazonaws.com.

もう当たり前のようにS3バケットのPTRレコードがわかりました。

今までの問題同様に先ほど手に入れたPTRレコード
s3-website-us-west-2.amazonaws.com.と Level 3のドメインで
S3バケットの名前を特定するため以下のURLでブラウザアクセスする。
http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud.s3-website-us-west-2.amazonaws.com

これでS3バケット名がLevel 3のドメイン名だとわかりました！
ここまでの流れはflaws.cloudの基本手順なのでしょうか…

ちなみにlevel3-9afd3927f195e10225021a578e6f78df.flaws.cloud.s3-website-us-west-2.amazonaws.comの
s3-website-us-west-2.amazonaws.comの部分はS3バケットをWEBサイトホスティング設定する際の
WEBサイトエンドポイントなのでこれを除いたlevel3-9afd3927f195e10225021a578e6f78df.flaws.cloudがこのS3バケットの名前です。

S3バケットの情報を見るためaws s3 lsコマンドを実行する。

$ aws s3 ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/
                           PRE .git/
2017-02-27 09:14:33     123637 authenticated_users.png
2017-02-27 09:14:34       1552 hint1.html
2017-02-27 09:14:34       1426 hint2.html
2017-02-27 09:14:35       1247 hint3.html
2017-02-27 09:14:33       1035 hint4.html
2017-02-27 11:05:16       1703 index.html
2017-02-27 09:14:33         26 robots.txt

今回はPRE .git/があるのでgitを使っていることがわかります。
S3バケット名を確認した際にアクセスしたURLのs3-website-us-west-2.amazonaws.comの部分を
以下のURLのようにs3.amazonaws.comへ変更してサイトのXML情報を確認してみます。
http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud.s3.amazonaws.com

.git/配下に色々ファイルがあるようなので、gitで管理されているのが確定しました。 今回の問題はgit管理下に目星いファイルがありそうです。

ここまでの手順でS3のバケットポリシーはEveryoneであることは間違いなさそうなので、一先ずaws s3 syncでS3バケットをローカルに同期できるか確認してみます。

aws s3 sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ . 

dev.classmethod.jp

同期出来ているかの確認をします。

$ ls -la
drwxr-xr-x  10 chiko  staff     320  1 19 18:17 .
drwxr-xr-x+ 32 chiko  staff    1024  1 19 18:16 ..
drwxr-xr-x  12 chiko  staff     384  1 19 18:17 .git
-rw-r--r--   1 chiko  staff  123637  2 27  2017 authenticated_users.png
-rw-r--r--   1 chiko  staff    1552  2 27  2017 hint1.html
-rw-r--r--   1 chiko  staff    1426  2 27  2017 hint2.html
-rw-r--r--   1 chiko  staff    1247  2 27  2017 hint3.html
-rw-r--r--   1 chiko  staff    1035  2 27  2017 hint4.html
-rw-r--r--   1 chiko  staff    1703  2 27  2017 index.html
-rw-r--r--   1 chiko  staff      26  2 27  2017 robots.txt

無事に同期ができているようです。
次にやる事として思いつくのはgitの情報を見れるかですかね、
とりあえず、git logでコミット履歴が見れるか確認します。

$ git log
commit b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526 (HEAD -> master)
Author: 0xdabbad00 
Date:   Sun Sep 17 09:10:43 2017 -0600

    Oops, accidentally added something I shouldn't have

commit f52ec03b227ea6094b04e43f475fb0126edb5a61
Author: 0xdabbad00 
Date:   Sun Sep 17 09:10:07 2017 -0600

    first commit

techacademy.jp

コミット情報が手に入ればあとはgit checkoutで
コミット時のgitリポジトリがどうなっているか確認できます。

一つ前のfirst commit時に移動するため、
f52ec03b227ea6094b04e43f475fb0126edb5a61にgit checkoutします。

$ git checkout f52ec03b227ea6094b04e43f475fb0126edb5a61
Note: checking out 'f52ec03b227ea6094b04e43f475fb0126edb5a61'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b 

HEAD is now at f52ec03 first commit

「detached HEAD状態です。」といってきますがgit branchで確認すると
git checkoutできているので問題なさそうですね。

$ git branch
* (HEAD detached at f52ec03)
  master

過去のコミット時のgitリポジトリの内容確認をおこないます。

$ ls -la
drwxr-xr-x  12 chiko  staff     384  1 19 18:43 .
drwxr-xr-x+ 32 chiko  staff    1024  1 19 18:16 ..
drwxr-xr-x  12 chiko  staff     384  1 19 18:43 .git
-rw-r--r--   1 chiko  staff      91  1 19 18:43 access_keys.txt
-rw-r--r--   1 chiko  staff  123637  2 27  2017 authenticated_users.png
-rw-r--r--   1 chiko  staff    1552  2 27  2017 hint1.html
-rw-r--r--   1 chiko  staff    1426  2 27  2017 hint2.html
-rw-r--r--   1 chiko  staff    1247  2 27  2017 hint3.html
-rw-r--r--   1 chiko  staff    1035  2 27  2017 hint4.html
-rw-r--r--   1 chiko  staff    1703  2 27  2017 index.html
-rw-r--r--   1 chiko  staff      26  2 27  2017 robots.txt

やばいものが置いてあります。
access_keys.txtが明らかに気になるのでとりあえず中身を開きます。

$ cat access_keys.txt
access_key AKIAJ366LIPB4IJKT7SA
secret_access_key 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

access_keyとsecret_access_keyを手に入れてしまったので、
その情報をもとにaws configure --profileでプロファイルを作成する。

$ aws configure --profile testchiko
AWS Access Key ID [None]: AKIAJ366LIPB4IJKT7SA
AWS Secret Access Key [None]: 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
Default region name [None]: us-west-2
Default output format [None]:

作成したプロファイルでAWSアカウント内の全てS3バケットを確認します。

$ aws --profile testchiko s3 ls
2017-02-19 04:41:52 2f4e53154c0a7fd086a04a12a452c2a4caed8da0.flaws.cloud
2017-05-30 01:34:53 config-bucket-975426262029
2018-07-08 01:09:49 flaws-logs
2017-02-19 04:40:54 flaws.cloud
2017-02-24 14:15:42 level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
2017-02-27 03:29:03 level3-9afd3927f195e10225021a578e6f78df.flaws.cloud
2017-02-27 03:49:31 level4-1156739cfb264ced6de514971a4bef68.flaws.cloud
2017-02-27 04:49:03 level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud
2017-02-27 04:48:40 level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud
2017-02-27 05:07:13 theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud

次の問題はLevel 4なので、以下のURLでブラウザアクセスします。
http://level4-1156739cfb264ced6de514971a4bef68.flaws.cloud/

これでLevel 3クリアとなります！

やってみた感想

今回の問題は、AWSキーが漏洩してしまうという現実だとかなりヤバメな問題でした。
わかりきっている事ですが、自分のAWSキーが漏洩するとS3バケット以外の情報も
全て取られてしまうので、実業務ではあってはいけない事ですね。。。

自分や会社のAWSキーが仮に漏洩または公開されている場所に置き忘れた可能性がある場合は、そのAWSキーを無効にする事ぐらいしか対策はなさそうですね。

とにかくAWSキーの管理はしっかりおこなっていくのが大事ですね、
月に1度はAWSキーを変更する運用を考えてもいいかもしれません。

また、flaws.cloudにも記載があったのですが、
「Another interesting issue this level has exhibited, although not that worrisome, is that you can't restrict the ability to list only certain buckets in AWS, 」
AWSの特定のバケットのみをリストする機能を制限できないと記載があります。

今もそうのでしょうか？今度調べてみようかと思います。
以下のサイトの方法で上手く制御できればいいのですが。。。 aws.amazon.com

そもそもS3バケット名がバレてしまう事もまずいので対策は必須です。

S3バケット名はすべてのユーザにわたって一意である必要があるため、
会社名のような簡単に特定可能な文字をS3バケット名に入れる事や
secretなどの明らかに大切なファイルを置いていますよというのがわかる名前でS3バケットを作成してしまうと、
今回のように誰かが技術的にS3バケットの存在を特定する可能性があります。

S3バケットの名前の管理も考えていかなければいけません。

最後に

1つの問題を解くことでこれだけのセキュリティリスクを学べるのは助かります。
皆様も是非チャレンジしてみては如何でしょうか？

Level 4は以下の記事へ

chikoblog.hatenablog.jp

flaws.cloudでAWS環境にSSRF攻撃をやってみた Level 2

この記事は下記のブログの続きですので、まだ読んでいなければ先にLevel 1の記事をご覧ください。
そちらの記事にSSRFの説明も記載してありますので、
SSRFとはなんぞや？って方は読んでいただければふわっと理解できるかと思います！

chikoblog.hatenablog.jp

※この記事はflaws.cloudのやり方が載ってます。今後flaws.cloudにチャレンジ予定の方はネタバレになってしまいます。

Level 2

トップページはこんな感じです。

一番下に問題が記載されてます。
「The next level is fairly similar, with a slight twist. You're going to need your own AWS account for this. You just need the free tier.」
Level 1と似ているが少しひねりを入れているみたいなことが書いてありますね。
また、Level 2からは個人のAWSアカウントが必要になるようです。

とりあえず進めてみる

似ているということだからLevel 1と同様に
Level 2のドメインlevel2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloudに対してdig anyを実行してみる。

$ dig any level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud +short
52.218.218.98

Level 1とは違いNSレコードの情報は抜けないみたいです。
Aレコードは抜けましたので、手に入れたAレコードでnslookupを実行する。

$ nslookup 52.218.193.211
211.193.218.52.in-addr.arpa     name = s3-website-us-west-2.amazonaws.com.

Authoritative answers can be found from:

S3バケットのPTRレコードがわかりましたね、ここまではLevel 1と大差ないです。

Level 1と同様に先ほど手に入れたPTRレコードs3-website-us-west-2.amazonaws.com.と
Level 2のドメインでS3バケットの名前を特定するため以下のURLでブラウザアクセスする。
http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud.s3-website-us-west-2.amazonaws.com

これもLevel 1 と同様にLevel 2のドメインがS3バケット名になっていました。
Level 1同様にaws s3 lsコマンドを実行する。

$ aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

やっとLevel 1との違いが出てきました。
どうやら、アクセス拒否されてます。ここまでガバガバだったのに…

AWS ListObjectsV2の公式サイトを見ると
ListObjectsV2を使用するには、s3:ListBucketアクションを実行するアクセス許可が必要なようです。
アクセス許可が必要ってことはaws s3 lsコマンドに--profileオプションをつけて、
アカウントを指定して実行したらエラーは出ないというなのか？

とりあえず、問題の最初に個人のAWSアカウントが必要と書いていあったので、
aws s3 lsコマンドに--profileオプションをつけて実行してみました。

>aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/ --profile アカウント名
2017-02-27 02:02:15      80751 everyone.png
2017-03-03 03:47:17       1433 hint1.html
2017-02-27 02:04:39       1035 hint2.html
2017-02-27 02:02:14       2786 index.html
2017-02-27 02:02:14         26 robots.txt
2017-02-27 02:02:15       1051 secret-e4443fc.html

情報が抜き取れました。
あとは明らかに怪しいsecret-e4443fc.htmlを開いてみます。

以下のURLをブラウザでアクセスする。
http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud.s3-website-us-west-2.amazonaws.com/secret-e4443fc.html

Level 2クリアしました。
Level 1をクリアした後だと何か物足りなさはあります。

やってみた感想

Level 2はLevel 1の問題を代用されています。
Level 1をクリアした人だと比較的簡単に突破ができますね。

なので、ここではLevel 1とLevel 2をやって学んだこと、
僕なりの対策をまとめていきます。

学んだ教訓

AWS環境では、静的ファイルのホストに使用するなど、
あらゆる種類のアクセス許可と機能を備えたS3バケットを設定できます。

S3バケットの権限をあまりにもゆるい設定をおこなってしまうと、
この問題のように意図しないを情報を外部に渡してしまうケースが出てきてしまいます。
Webサーバのディレクトリ一覧を許可しないように設定をしばければいけないですね。

調べてみると、S3バケットをEveryoneへのアクセス許可を設定するのと同様に、
誤ってAny Authenticated AWS Userへのアクセス許可を設定してしまっているケースが多いようです。
実際にこの設定はAWSアカウントを持っている人を意味するのに、
「これは自分のAWSアカウントのユーザ」だけだと誤解して設定しまうことがあるようです。

S3バケットの設定は注意して設定した方が良いですね。

設定の間違いを避ける為に

デフォルトでは、S3バケットは作成時はプライベートで安全な設定になっています。

Level 1とLevel 2の問題はWebページとしてアクセスできるようにするため、
Static Website Hostingをオンにして、
バケットポリシーをすべてのs3：GetObject権限を許可されているようです。

これは、Webページとしてバケットを公開する場合は問題はない設定です。
しかし、この問題はあえてバケットポリシーへEveryoneを追加してList権限を持つように変更しているようです。

以下製作者の参考画像

Everyoneはインターネット上の全員を意味していて、Listのアクセス許可があるため、
http：//flaws.cloud.s3.amazonaws.com/にアクセスするだけでファイルをListすることもできるようになってしまいます。

設定するときは上記した内容をしなければファイルをListされることはなさそうです。

S3バケットのバケットポリシーがAny Authenticated AWS Userを設定するのもあまり良くないです。
上記した通り、「これは自分のAWSアカウントのユーザ」のみだと勘違いしていると
Level 2の問題のようにaws s3 lsコマンドに--profileオプションで情報が取られてしまうケースがあります。

終わりに

やはりセキュリティ意識は持っていないと大切な情報が抜かれてしまうのは怖いですね。
こういった問題を1度解いてみるとそういえばこの設定情報が抜かれる可能性があると
気づけるようになるのでおすすめです。

皆様も是非チャレンジしてみては如何でしょうか？

Level 3は以下の記事へ chikoblog.hatenablog.jp

VS Codeでtextlintを導入してみた

ブログを書き始めてからtypoが多く困っていたので紹介されたtextlintを導入してみたのでついでにブログを書きました。

efcl.info

textlintとは

textlintはnode.js製で、主にMarkdown形式のドキュメントに対して特定の文法や言葉遣いをチェックできるツールです。

チェックできる範囲は特定のルールで指定でき、自分がチェックしたい内容のルールを設定すればその内容で文章のチェックが可能となります。
主なるルールは以下のようなものがあります。

• textlint-rule-max-ten (一文に利用できる"、"の数をチェックする)
• textlint-rule-no-mix-dearu-desumasu (ですます」調と「である」調の混在をチェックする)
• textlint-rule-no-dropping-the-ra (ら抜き言葉のチェック)
• textlint-rule-ja-hiragana-hojodoushi (ひらがなにした方が良い補助動詞)
• textlint-rule-no-doubled-conjunction (同じ接続詞が連続して出現していないか)

などなど、上記はほんの一部です。詳細は以下のGitHubをご確認ください。 github.com

node.js とnpmをインストールする

上気した通りtextlintはnode.js製ですので、利用するにはnodeとnpmをインストールする必要があります。

VS Codeのターミナルで以下のコマンドを実行し導入されているかを確認します。

node -v
npm -v

インストールされていないようでしたら以下のサイトを参考にインストールします。

qiita.com

qiita.com

textlintの設定

必要なルールのインストール

導入したいルールのパッケージをVS Codeのターミナルでnpm installコマンドを実行しインストールします。

今回は下記のパッケージをインストールしました。

github.com

このルールは技術文書向けのtextlintルールプリセットなので、
これ1つ追加するだけである程度チェック項目の網羅ができます。

インストールコマンド

>npm install --save-dev textlint  textlint-rule-preset-ja-technical-writing

npm installがエラってしまった場合は以下を参考にしてください。

sugimotonote.com

ルールの適応

インストールしたルールの適応設定をおこなっていきます。

まず、設定ファイルの「.textlintrc」の作成をおこないます。
VS Codeのターミナルで以下のコマンドを実行します。

> cd 設定ファイルを保存したいディレクトリorファイルへ移動
> npx textlint --init
> ls -a
 .textlintrc

「.textlintrc」ファイルの初期設定はこんな感じで何も書いてなかったです。

>vim .textlintrc

{
  "filters": {},
  "rules": {}
}`

なので、先ほど入れたルールを適用します。

>vim .textlintrc

{
  "filters": {},
  "rules": {
+   "preset-ja-technical-writing": true,
  }
}

VS Codeの設定

VS Code で textlint を実行するために VS Code の拡張機能「vscode-textlint - Visual Studio Marketplace」をインストールしてVS Codeの再起動。 marketplace.visualstudio.com

これでtextlint が有効になります。

こんな感じで指摘がされます。

やってみて

ブログ以外にも社内の手順書や議事録などにも使えるのですごい便利です。
レビューしていただく方の負担も減りますので、
typoが多いなぁと思う方は是非導入してみてはいかがでしょうか。

flaws.cloudでAWS環境にSSRF攻撃をやってみた Level 1

※この記事はflaws.cloudのやり方が載ってます。今後flaws.cloudにチャレンジ予定の方はネタバレになってしまいます。

EC2インスタンスメタデータサービスv2のリリースでも上がっている
flaws.cloudを使ってSSRF攻撃について個人的に調査してまとめてみました！

以下参考記事
クラメソ様のEC2インスタンスメタデータサービスv2のリリースの記事 dev.classmethod.jp

SSRF攻撃についてpiyokango様がまとめている記事 piyolog.hatenadiary.jp

そもそもSSRF攻撃って？

SSRF攻撃をすごく簡単に説明すると

通常のWEBサイトとかのイメージだとWEBにアクセスしてくるユーザは WEBサーバやその他外部公開用のサーバにアクセスしてWEBのページを見ることが可能です。

SSRFの脆弱性がある場合、
攻撃者は公開サーバ(WEBとか)など踏み台に利用して FW(Firewall)などで隔離されている内部サーバ(DBとか)へ攻撃をおこなうことができたりします。

画像はあくまで例で最終的な攻撃目標はいろいろあり、 最近問題になっているのがクラウドサービスのインスタンスやメタデータを取得できるAPIのエンドポイントを狙ってきたりします。

AWS環境で簡単なSSRF攻撃を実践してみた！

調べてもいまいちわからん！

一先ず、AWSのセキュリティ学習ができるflaws.cloudでSSRFについて出題されているみたいなので実際にやってみた

トップページはこんな感じ

※ヒント無しで右往左往しながらやってみました！

Level 1

This level is buckets of fun. See if you can find the first sub-domain.

最初のサブドメイン…？を見つければよさそうですね

最初の説明に「範囲はすべてが単一のAWSアカウントで実行され、すべての課題はflaws.cloudのサブドメインです。」と
記載があったので「flaws.cloud」に対してdigコマンド(もちろんオプションはany)を実行してみる

$ dig any flaws.cloud +short
ns-1890.awsdns-44.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
ns-966.awsdns-56.net.
ns-1061.awsdns-04.org.
ns-1890.awsdns-44.co.uk.
ns-448.awsdns-56.com.
52.218.225.10

Aレコード情報とNSレコード情報を入手！NSを見る限りRoute53を利用していることがわかる digで手に入れたAレコードのIPをnslookupで引いてみる
(ちなみに52.218.225.10をブラウザアクセスするとS3の公式ページに飛びます。おしゃれ)

$ nslookup 52.218.225.10
10.225.218.52.in-addr.arpa      name = s3-website-us-west-2.amazonaws.com.

Authoritative answers can be found from:

お、S3のPTRレコードがわかりましたね
ダメもとでブラウザアクセス！

でさーね…
この「flaws.cloud」はおそらくs3で静的ウェブサイト公開をおこなっているんじゃないか？

AWS S3の公式サイト を見ると、S3バケットをWEBサイトホスティングように設定する際のWEBサイトエンドポイントの一般的な 2 つの形式は次のとおりになるようだ

bucket-name.s3-website-region.amazonaws.com

bucket-name.s3-website.region.amazonaws.com

まさかとは思うが、バケットの名前「flaws.cloud」じゃないよね？
「http://flaws.cloud.s3-website-us-west-2.amazonaws.com」をブラウザアクセス

S3バケットが外部からアクセス可能であれば、
S3バケットの中身を確認できるのではないか？

AWSコンソールに接続しなくてもS3バケットの中身を確認する方法...
S3のバケット名がわかっているのであれば、すぐに思いついたのはAWS CLIでS3 lsなのでとりあえず実行してみる。

$ aws s3 ls  s3://flaws.cloud/ 
2017-03-14 03:00:38       2575 hint1.html
2017-03-03 04:05:17       1707 hint2.html
2017-03-03 04:05:11       1101 hint3.html
2018-07-10 16:47:16       3082 index.html
2018-07-10 16:47:16      15979 logo.png
2017-02-27 01:59:28         46 robots.txt
2017-02-27 01:59:30       1051 secret-dd02c7c.html

お、情報抜き取れますね！
正しくない公開範囲だとこうなるのか…と思いつつS3バケットの中身を確認し怪しげな「secret-dd02c7c.html」を見てみた URLはこんな感じに「http://flaws.cloud.s3-website-us-west-2.amazonaws.com/secret-dd02c7c.html」

Congrats! You found the secret file!
どうやらLevel1クリアしたようです！

やってみた感想

長くなりそうでしたので今回の記事はLevel1だけにしましたが、 セキュリティをしっかり考えておかなければ「flaws.cloud」のようにWEBサイトページから様々な情報が抜き取られることがわかりました！

Level1を例にすると「flaws.cloud」(公開されている場所)からS3バケットの情報(本来は非公開？)が抜き取られてしまっています。

SSRFはおっかないですね

AWSの環境設計の際もセキュリティ意識はしっかり持っておかなければ予想外のところから攻撃されてしまいますね…
EC2インスタンスメタデータサービスv2はしっかり学習しておかなければ！

Level2は以下の記事へ chikoblog.hatenablog.jp

Micro Hardening：Enterprise Editionを受講してきました！

この記事は，マイナビ Advent Calendar 2019 12日目の記事となります.

※本記事は講師の方にネタバレにならない程度なら記事にしていいと言われているのでふんわりとした内容となっています。

Micro Hardening：Enterprise Editionとは

「様々な攻撃からECサイトを45分間守りきれ！最大の売上を上げろ！」をコンセプトにしたセキュリティトレーニングです！

どんなことをやるのか

• 与えられたECサイトのサーバを様々な攻撃から守り、制限時間内に最大の売上を目指してサイトを運用をする。
• サイトの監視と防御に集中することで、攻撃対処の実践経験を効率的にトレーニングする事ができる。
• ECサイト（サーバ）を与えられ、1日で演習を4セット経験する事ができます。各セットは全て 同じ攻撃シナリオで行われるため、セット毎に振り返りができ、何を見落としたか？自分の取った行動や対策が有効だったか？さまざま な角度から確認検証ができ、さらに復習⇒定着まで、極めて短時間に密度の濃いスキルアップを行えます。

まぁすべて以下のサイトに書いてあります笑 www.gsx.co.jp

受けてみた感想

同じ会社のアプリが得意な人1名、そのほかインフラ屋さん3名の計4名でトレーニングに参加しました！

当日の役割分担はざっくりこんな感じです！

①ログを監視する人
②サーバの設定の確認・変更をする人
③ セキュリティの設定をする人
④Chikoなんかいろいろしてる

ネタバレにならない程度に図にするとこんな感じ

ゴリラが様々な攻撃をしてECサイトを壊しに来ますので
それを防御していくのがこのトレーニングでやることです。

上記した通り4セット経験する事ができ、すべて同じ攻撃です。
45分がたつと作業していたサーバはなくなり作業前のサーバに戻るループものみたい設定でトレーニングが進みます。

First Attack

まず、おのおのが環境の理解に努めました、
どんなアプリを使っているのか？必要なログはどこにあるかのか？
必要なログはそもそも取れているか？などなど…

私はループものなので
次回の対策のために役に立てばと思いどんな攻撃があったかメモするようにしておきました。

Fast Attackはこんな感じで何もできないうちに終わってしまいました…

Second Attack

環境の理解も少しだけできたので、
どんな脆弱性があるとかどんな攻撃を受けているかがわかるものが出てきました。

それの対処とセキュリティの強化を図りました。

そのなかでこんなやり取りがありました。

踏み台からSQLインジェクションされてるんですが…

踏み台からも攻撃受けてるなら踏み台のセキュリティも見ないとですね

ちょっと待ってください...chikoさん…何か知ってます？

いつのやつですか？

5分くらい前ですね

……それ…僕です…

この辺りからのチームの役割分担
①ログを監視する人
②サーバの設定の確認・変更をする人
③セキュリティの設定をする人
④ECサイトに攻撃をする人(本来不要) ← Chikoが独断で行う

Second Attackはチームメンバーを裏切る形で終わり迎えました。

Third Attack

脆弱性とその対応もまとまり、より良いセキュリティ設定が可能になりました。
チームメンバーもやることが固まり、作業もスムーズに対応することが可能となりました。

いつものような珍事(身内からの攻撃)もありましたが
ほとんどの攻撃は防げるようになっていました。

僕もただただ攻撃していただけではないので、
いろいろな脆弱性の発見もできチームに貢献してThird Attackは終了しました。

この後、講師の解説がありどんな攻撃がされているかがわかりLast Attackへ移ります。

Last Attack

もうここまでくればどんな攻撃がいつ来るかもわかっているので
対応の優先度を決めすべての攻撃を防ぎまくるだけです。

なので、ここまでくると終盤やることがなくなってしまったりしましたね。

最後は僕も何も攻撃できず少々寂しい気持ちになってしまいました。

結果はほぼ満点でこのトレーニングを終わることができました！

まとめ

チームで作業をおこなうので
いつ何を作業したかの連携は非常に大切なトレーニングでした。

私みたいなことをやるとチームが混乱してしまいますのでやめましょう。
SQLインジェクションダメ!絶対!

基本中の基本である以下のようなことが大切だと再度気づかせてくれるいいトレーニングでした。

• 作業の記録
• 作業内容の共有
• オペミス時の復旧手順
• サービス稼働状況の監視・調査
• ログの監視・調査
• 脆弱性を放置しない
• SQLインジェクションしない…

興味がある方は是非参加してみてはどうでしょうか？
セキュリティ意識高まりますぞ！

デフォルトVPCを使う場合に最低限注意しないといけないこと

この記事は，マイナビ Advent Calendar 2019 5日目の記事となります。

そもそもVPCって？

インフラに詳しくない人からするとよくわからないのではないかと思いまして
軽い説明からさせていただきます！

VPCとは

Amazon Virtual Private Cloudが正式名称 VPCは略称
簡単に説明すると仮想のユーザー専用プライベートなクラウド環境を提供するサービスで
ネットワーク設定を簡単にカスタマイズすることができます。

具体的に何が設定できるの？

ざっくり書くと以下のようなネットワーク・セキュリティ設定が可能です。

• ネットワーク設定
  • IPの割り当て
  • サブネット設定
    • 外部ネットワーク
    • 内部ネットワーク
  • ルーティング
  • etc…
• セキュリティ周り
  • ネットワークアクセスコントロール
  • アクセス制御
    • IPアドレス
    • プロトコル
  • etc…

これらの設定をおこなうことで
インターネット向けシステムやオンプレミス向けシステム、
インターネット兼オンプレス向けシステムなど使い分けることが可能です。

デフォルトVPCとは

AWSアカウントを作成するとAWSの各リージョンごとにデフォルトVPCが備え付けられています。
最初からデフォルトVPCは使用できる状態になっているため、
面倒なVPCの作成、設定はその他必要なNWリソースの作成、設定をおこなう必要がなく
すぐにEC2インスタンスを利用できますよ～ってものです。

インフラの設定よくわからんけどこれ使えばEC2とかRDS建てれんじゃん！
ってなった方も少なくないかと思います(身近にも何名かいました…)

では、デフォルトVPCはどんな設定になっているのかを確認しておこう

デフォルトVPCとそれに紐づいているリソースとその設定をまとめてみた

AWSの公式サイトを見るとこんな設定になっている

• サイズ /16 の IPv4 CIDR ブロック (172.31.0.0/16) の VPC を作成され最大65,536 個のプライベート IPv4 アドレスを使えます。
• 各AZに、サイズ /20 のデフォルトサブネットを作成 (サブネットあたり最大 4,096 個のアドレスが作成され、その中のいくつかは Amazon が使用するように予約されているよう)
• インターネットゲートウェイを作成して、デフォルトVPCに接続
• デフォルトのセキュリティグループを作成し、デフォルトVPCに紐付ける
• デフォルトのネットワークアクセスコントロールリスト (ACL) を作成し、デフォルトVPC に紐づける
• デフォルト VPC を備えた AWS アカウントに、デフォルトの DHCP オプションセットを紐づける

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/default-vpc.html

ざっくり図にするとこんな感じです。

なんかやばそうな気がしませんか？

デフォルトVPCを使う場合に注意しないといけないこと

前置きが長くなり申し訳ないです…

図を見ていただくとわかるかと思いますが、
デフォルトVPCをそのまま使う場合は
少なくとも以下の2つの設定は変更したほうが良いかと思います。
①セキュリティ設定
②サブネットをプライベートとパブリックに分ける

①セキュリティ設定

デフォルトVPCの主なセキュリティ設定は
セキュリティグループとネットワークACLです。

セキュリティグループとネットワークACLの比較
次の表は、セキュリティグループとネットワークACLの基本的な違いをまとめたものです。

セキュリティグループ	ネットワークACL
インスタンスレベル	サブネットレベル
ルールの許可のみがサポートされます	ルールの許可と拒否がサポートされます
ステートフル:ルールに関係なく、返されたトラフィックが自動的に許可されます	ステートレス:返されたトラフィックがルールによって明示的に許可されます
トラフィックを許可するかどうかを決める前に、すべてのルールを評価します	トラフィックを許可するかどうかを決めるときに、順番にルールを処理します
インスタンスの起動時に誰かがセキュリティグループを指定した場合、または後でセキュリティグループをインスタンスに関連付けた場合にのみ、インスタンスに適用されます。	関連付けられているサブネット内のすべてのインスタンスに自動的に適用されます(そのため、セキュリティグループのルールの許容範囲が広すぎる場合は、保護レイヤーを追加する必要があります)。

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Security.html

デフォルトVPCのセキュリティ設定

デフォルトのネットワークアクセスコントロールリスト (ACL) の設定

デフォルトのセキュリティグループの設定

ノーガードなんですよね（　＾ω＾）・・・

このままだと攻撃者の格好の的ですので
ある程度、ルールの設定をする必要があります。

最低でもセキュリティグループのインバウンドが0.0.0.0/0となっているのは絶対変更する。
登録するルールは必要最低限に絞ることをお勧めします。
開発環境だから個人で利用しているAWS勉強用だからといってインバウンドの設定を
0.0.0.0/0にしてしまうと攻撃の被害にあったりしちゃいますよ～
(できればフロントとなるALBのみが0.0.0.0/0を受けて、そこからの通信だけEC2に許可とかしてほしいのですが…)

WEBなら必要なHTTPやHTTPSの通信だけ許可するなど
必要のないプロトコルは全部塞いじゃいましょう
例 こんな感じ

この辺りは最低限注意したほうが絶対いいです！

②サブネットをプライベートとパブリックに分ける

WEBとDBを分ける際はサブネットも別するようにしてください！

デフォルトVPCを利用する場合、
備え付けのサブネットは各AZに一つずつしかないです。
そのまま利用するとなると、Webサーバ、APサーバ、DBは全てを
同じサブネットに配置ことになります。

DBがパブリックからアクセスされることはあまりよろしくないです。
せめて、サブネットをプライベートとパブリック分けて利用するようにしてください。

パブリックサブネットに配置するのは各種LBサービスと踏み台サーバのみとしてください。
Webサーバ、APサーバ、DBは全てプライベートサブネットに配置することがAWSべスプラです。

まとめ

だらだらとまとまりのない記事で申し訳ないです…

デフォルトVPCは便利なのですが、
そのまま使うとリスクは存在してしまします。

なので、EC2を配置する前にセキュリティ部分の設定は必須となってしまします。
以下のURLにベストプラクティスがまとまっておりますので一度読んでおくことを強くお勧めします！
https://d1.awsstatic.com/whitepapers/ja_JP/Security/AWS_Security_Best_Practices.pdf

私的な主観ですが、デフォルトVPCは個人の検証用途なら使ってもいいが、
決してサービス環境は避けたほうが良いと思います。

ただ、一からVPCを作るのが難しい人もいるかと思いますので、
あとでこの記事に簡単なテンプレートを載せておきます。(急ぎます)
何かのお役に立てば幸いです。