好奇心の足跡

飽きっぽくすぐ他のことをしてしまうので、忘れないため・形にして頭に残すための備忘録。

Security-JAWS #16 参加レポート

2020年2月14日に開催された、Security-JAWS 【第16回】 勉強会に参加してきました。Security-JAWSAWS + Security をコンセプトに立ち上げられた勉強会。今回で参加は4回目?5回目?くらい。
今回もとても濃い内容のものが多く、twitterではまとめきれなかった&長くなってしまったので参加レポート。

s-jaws.doorkeeper.jp

ハッシュタグ#secjaws #secjaws16 #jawsug

登壇資料、まだ拾えていないものがあるので随時更新予定。
今回も感想多めになってしまった…💦

§1. Amazon DetectiveなどAWS re:Inventで発表されたセキュリティサービス紹介

by アマゾンウェブサービスジャパン株式会社 桐山 隼人さん

re:Inventで発表されたセキュリティサービス、セキュリティに絞っても全部紹介するには全然時間が足りないので、今日は絞って、駆け足での紹介。

★スライドは見つけたら追加予定。

桐山さん:「好きな家電は時短家電、好きな飲物はマウントレーニアです!」(マウントレーニアは今回森永さんからの差し入れ。)

誰でも簡単に使えるものを作ると、メカニズムが複雑になる。セキュリティも時短家電も一緒。
その複雑についていける専門性・技術を身につけ続けて担保していけるのか?という話から、そこでAWSのマネージドサービスですよ。という流れ。個人的にはこの問いかけとても心に刺さった。

確かにマネージドサービス便利だし、複数人での開発現場となると人のローテーションは必ず見越しておくべきで、そこで担当になる人が毎回ある程度の専門性・技術を持っているとは限らない。もちろん採用の際にそこを重視した採用はするだろうけども、人は千差万別・十人十色。いい人に必ず巡り会える保証はないわけで、なるべく担当者の知識・スキルにサービスの存続が依存しないほうが良い。
なので、そこの敷居をグッと下げてくれるマネージドサービスは素晴らしいと思っているし、大好き。たとえ高い技術を持っていたとしても、諸々の手間を省いてやりたいことに注力できるし。
なんだけど、1エンジニアとしては「使えればOK」だけではなく、どういう仕組で動いているのかある程度は理解しておきたいところ。予想外のことに対処したり、ちょっと怪しい挙動みたいなのを検知する能力は下地がないとできない。…なんてことを思いながら、聞いていたのでした。おっと長くなった。

本日紹介されたメインの機能は「Amazon Detective」。Amazon Detectiveは、Cloud Trail, VPC Flow Logs, Guard Duty 辺りのログを拾って分析してくれる。まだPreviewなので、使うのには申請が必要&今は混んでいるようでちょっと待つ必要あり。

いつもアメリカからログインしているアカウントが、シドニーからログインしているぞ!みたいなのをMapで表示してくれる。これ緯度・経度だけだと正直「どれくらい近いの?」となるので結構ありがたい。大体都市名くらいは表示してくれるのだけども。
成功したAPIコールと失敗したAPIコールも、手間を掛けずに勝手にグラフ化してくれるのは嬉しい。ここから攻撃に気づけたり、システムの不具合に気づけたりするので。

途中で行われたアンケート、「GuardDuty使ってる人〜?」では、挙手の感じだと7~8割かな。さすがセキュリティJAWS、めっちゃおる!と感動したけど、最近では使うのが当たり前になってきたのかな。

他にも駆け足で沢山サービスが紹介されましたが、時間がなかったのであとはスライド見ておいてね、とのこと。

新サービスとして紹介されていたのは

あたりかなぁ。聞くので精一杯だった。

こちらも参考に。さすがクラスメソッドさんやでぇ…。 re:Invent 2019セキュリティ関連情報まとめ #reinvent | Developers.IO

新しい発表だけでも盛り沢山!自分たちのサービス・組織に合ったAWSマネージドサービスを利用して、システムの構築・運用の手間を省いていきたいですね。

AWS re:Invent動画はこちら

§2. 様々なAWS Securityベストプラクティスのまとめ

by トヨタ・リサーチ・インスティテュート・アドバンスト・デベロップメント株式会社 Cyber&Vehicle Security シニアディレクター 高橋 威裕さん

AWS(に限らない部分も多かった)のセキュリティベストプラクティス、情報が沢山、やることもたくさんありすぎるけど、どうやって情報収集して実務に落とし込むか?という内容の発表。

★スライドは見つけたら追加予定。

AWSのセキュリティベストプラクティス、公式のホワイトペーパーや動画、著名なユーザーによる記事や動画など沢山出ている。全部読んで/見て実践するのは大変。嬉しい意味で情報が膨大…!

紹介されていた主なAWS公式リファレンス

一般的なセキュリティの考え方と流れ

セキュリティチームの目標は、事故につながらない仕組みづくり。
一般的なセキュリティの考え方は下記。

  • 侵入を前提に、被害の範囲を最小限に抑えるデザイン
  • 最小限の権限を与える
  • ユーザとパスワードの仕組みはもはやアンチパターン → 2FA
  • 多重防御の考え方
  • 脅威モデルを作成し、脅威と対応策を明確にする

そして、下記の流れで対策をしていく。

  1. 攻撃手法を理解
  2. 自分たちのサービスの脅威モデルを作成
  3. 脅威ごとの優先度を決定
  4. 脅威に対応するベストプラクティスを実践
  5. 定期的に脅威モデルを更新

まずは攻撃について理解しましょう。とのことで、よくある攻撃例を紹介。

  1. 認証を要求しないリソースへのインターネットからのアクセス
  2. 公開repositoryにAPIキーなどをソースコードに含めて公開
  3. RCE(Remote Code Execution)によち、IAM Roleの権限を抜かれて悪用される

他、

  • 大事な情報の入ったAMIをPublicに公開
  • rootやIAM userのパスワード使いまわし
  • 組織を離れた人がAWSコンソールにアクセスできる状態

など、よくある事故・攻撃例を紹介していただきました。

「セキュリティはそんな難しい事から始める必要はなく、自分たちの出来る範囲からやっていけば良い」。これは特にオフボーディングの時に感じるそう。
ものを作る時(開発・設計・実装・テスト…)は結構セキュリティを意識すること増えてきたと思うけど、関係者のオフボーディングについてはなかなか整理するタイミングがなかったりして野放しになりがちわかる。たとえ離任者に悪意がなかったとしても、そのアカウントや鍵が新しい脅威となりうるので、オフボーディングこそしっかり対策したい所。…最近離任した身としては耳が痛い。やりきったつもりでも、ちょいちょい残ってしまっている…。

次は脅威モデルの話。脅威モデルは各サービス、組織によって必ず異なるものなのでGeneralなものは作れない。これは自分たちで作る必要がある。
上で紹介した脅威だけでなく、管理端末のマルウェア感染・ADがハッキングに遭う、CI/CDを変更できる人の端末が感染、などなど、いろんな脅威が想定できる。

脅威の洗い出しをやっていると、本当に「まだある」「こんなにある」「もうやめて」っていう気持ちになる。でも攻撃する側も、対策のスキをついたり、新しい攻撃手法を日々研究してるので、脅威は日々増える一方…。ちゅらい。

ベストプラクティスの探し方

ベストプラクティスの探し方(ロング版)

  • 正しい基礎知識を得る
  • 攻撃者の一般的な手口を理解する
  • ファーストパーティーが提供するレファレンスとなるマテリアルを理解する
    • ホワイトペーパー
    • re:Invent / re:Inforce などをよく見る
  • 著名なAWSセキュリティの専門家の直近2年分くらいのコンテンツをレビューする

ベストプラクティスの探し方(ショート版)

きっちりセキュリティのプロセスを実践している例で、とても参考になったし、参考にしたい発表でした。
ショート版でさえなかなかやれていないなぁ…。

§3. 事業会社情シスとしてのセキュリティの取り組み(CCoE立ち上げと今後の展望)

by 森永乳業株式会社 経営戦略本部 IT改革推進部 アシスタントマネージャー 石井 俊光さん

★スライドは見つけたら追加予定。

CCoEを設立して、クラウド(AWS)化を進めた話と、セキュリティの取り組みの話。

守りのIT・攻めのITという話が。守りの部分は、3年間で約60%のコスト削減ができそう。3ヶ月書けてテストし、現在AWS化の真っ最中とのこと。
攻めのITに関しては、今後少子高齢化により、生産人口が激減することを取り上げていらっしゃった。ということで、投資・人材(スキル)・人材(量)も課題。

情シスのセキュリティの現状。

  • 経営との距離が遠い
  • 新規予算がつきにくい
  • 人材の不足
  • ローテーション・教育

SANS(セキュリティのトレーニング)に行きたい、という話をした所、「数十万円をおまえに投資すべきか…」と言われるなど。なかなか予算はつきにくいですよね。

他、「AWSのマルチアカウントでのルールぎめ・統制」「社内調整チーム」というワードに大きくうなずくなどしていました。

§4. IAMどうしましょ

by 株式会社FOLIO 鈴木 研吾(@ken5scal) さん

speakerdeck.com

ということで、ken5scalさん。前半は森永さんの話のことを考えていたらぼーっと聞き流してしまった…!前回登壇予定だったのに忘れててごめんなさい、だけは聞いてた :D

IAMなにもわからんから始まり、これに終わりました。盛りだくさんの内容、知見の共有でした。完全にこれ。エンジニアの言う「完全に理解した」「なにもわからない」「チョットデキル」って本当はこういう意味?「わかる」の声多数 - Togetter
今日は、IAMについて話すと言うよりは相談のスタンスとのこと。
現時点でスライドが公開されているので、感想を中心に。

RootアカウントへのMFA設定・パスワードポリシーの設定は、当たり前教。ほか、前提としてIAMユーザー(人間)はそもそも使わないこと、マルチアカウント・Organization構成であるとしてのお話でした。

IAM Policy vs Resource Policy

まずは、IAM Policy vs Resource Policy の話。
基本は両方OKなときにアクセス出来る。被ってる領域はどう使い分けるか?
-> ANDなので両方定義しないといけない。基本方針はIAM Policy側に寄せるのが個人見解。

最初は、IAMは入り口なので、各種リソースに依存させたくないので、リソースで縛るべきと思っていた。が、思想的に「Identityへの認可」という意味でIAM側に設定したほうが正しそう。また、Tagを使った詳細な制御がIAMからしかできないこと、リソースごとの制限が運用的に大変なことから、IAM側に寄せるべきと思うように。

-> わかる。良さそう。

Permission Boundary

次は Permission Boundary について。AWSのPolicy Typesは下記。

  • Resource-based policy
  • Identity-based policy
  • Permissions Boundary

この中の最後のやつ。割と使い道がわからないので、基本的に使わないことにしている。他のでいいじゃん、という認識。

Tag-based access

次は Tag-based access。これは便利なものだと思っている、とのこと。Tag-basedはリソースでは全許可だけどタグでアクセスを制限、みたいに出来る。データによってsensitive,confidentialみたいな設定ができる。descriptionも設定できるのでdomain知識も書ける。
ただ、ABACやっていきたい気持ちはあるが、ABACそのものというよりもタグは運用が重要&手間がかかる。タグのルールを決めたり、タグ警察を作ったりして運用する?
※タグのような属性ベースのアクセスコントロールABACと言う。

実際、タグが便利すぎて、何でもタグでやりたくなってしまう感はある…。

AWS SSO vs AWS IAM (Role)

AWS SSO vs AWS IAMの話。Roleを切り替えるのは面倒。SSOのほうがCLIでもシュッと切り替えてアクセスできるので便利という認識。Roleだと各アカウントに対してポリシーを決めて設定しないといけないが、SSOはそれが一元化できるのが良い。ただInfraStructureAsCodeやってると、そこまでアドバンテージではないかも。今の所IAM Roleのほうが良さそう。

職場ではroleメインで使っており、SSOで切り替えする運用は、ちょうど私が抜けるときに検討していたので未経験だった。結局どっちが良いんじゃろ?というのは気になっていたので、結論が出ていなくても話が聞けてよかった。

GCP周りのPermissionが、個人的にはもっとカオスで「なにで!なにを!しばれば!!いいの!!!」「かんり!したいんですけど!権限!!!」状態なので、こっちの知見共有もしたい。あ、今GCP全然触ってないで自分は全く語れないんですけど。。。

§5. SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

by EGセキュアソリューションズ株式会社 徳丸 浩(@ockeghem)さん

www.slideshare.net

CapitalOneの事故を例に、何をどう悪用されたのかを解説。

IMDS(v1)とは

EC2 IMDS(IMDSv1)は、Instance Meta Data Serviceの略。EC2の仮想エンドポイント http://169.254.169.254/。アクセス元の設定情報を返してくれる。
外部からはアクセスできないので設定情報がもれないはず。…?

Capital One事例紹介と攻撃再現

Capital Oneの話はpiyokangoさんのブログ参照。
SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog

WAFの設定ミスに起因して、Server Side Request Forgery(SSRF)攻撃を許したことにより情報を盗まれたと見られています

とのこと。
設定ミスの詳細やシステム構成などは明らかにされていないが、状況を再現してみた。(スライドp7)

予想では、WAFがオープンプロキシになっていたのではとのこと。Hostヘッダに169.254.169.254を指定してGETクエリを投げることにより、リクエストを受けたWAF(Apache + mode secueity)がオープンプロキシとしてIMDSのエンドポイントにアクセス、攻撃者に情報を返してしまう。IAM Roleのクレデンシャルも。そこで付与されていたRoleを用いてS3を参照された、というシナリオ。

下記が攻撃を受けてしまった原因

  • 個人情報がS3に置かれていた
  • S3へのアクセス権がWAFのインスタンスに、しかも全てのS3にアクセスできる権限が付与されていた
  • WAFがオープンプロキシになっていた(予想)
  • IMDSが無効化されていなかった

以降、Capital One仕様の脆弱なWAFの作り方。
CapitalOneでは、上述の通り、Apache + mod_security の構成でWAFを構成していた。この際、reverseproxy.confProxyRequests Onにし、p10のように設定していると、リバースプロキシのつもりがオープンプロキシになってしまう💣

Apacheのページにも、「警告:サーバを安全にするまで ProxyRequests は有効にしないでください。オープンプロキシサーバはあなた自身のネットワークにとっても、インターネット全体にとっても危険です。」とただし書きがあるくらい :)

こうやって構築したオープンプロキシ(事例ではWAF)を通じてIMDSにアクセス。単にIPアドレスを指定してアクセスするとmod_securityにブロックされてHost header is a numeric IP addressと怒られてしまうが、適当なホスト名に169.254.169.254を設定すれば突破できちゃう。

ここでIMDSから設定されているIAMのRole情報も取得できちゃうので、AWS-CLIをインストールしてクレデンシャルを設定すれば、このクレデンシャルの権限内でやりたい放題。

こないだの「とある診断員とSecurity-JAWS #01」でやったflawsとかなり重なる部分もあり、とても面白かった!「なんか攻撃されちゃうらしい」だけじゃなくて、攻撃の仕組みを理解したり、実際に手を動かしてみると理解が10000倍深まる。ん、言い過ぎ?

IMDS(v2)とは

  • v2へのアクセスは、事前に取得したtoken必須
    • tokenはPUTで取得
    • tokenはリクエスト時に有効期限を設定できる
    • tokenはヘッダに入れてリクエス
  • v1を無効化出来る(デフォルトでは併用可)
  • メタデータサービス自体を無効化出来る
  • EC2立ち上げの際にv2飲みに設定することを強制可
  • X-Forwarded-Forヘッダがあるリクエストにtokenを発行しない
  • メタデータレスポンスのTTLを短くし、複数ホストを経由した取得を防止できる

公式のブログではここで紹介されています。
EC2 インスタンスメタデータサービスの拡張により、オープンなファイアウォール、リバースプロキシ、SSRFの脆弱性に対する防御を強化しました | Amazon Web Services ブログ

ブックマークアプリのプレビュー機能のSSRF脆弱性

突如「第二部」として始まった「派手なブックマーク」という仮想アプリの話。発音が大事。「はてなブックマークのような」ってめっちゃ言ってたしスライドにも書いてあるけど。
正直「え、今から第二部行くの!?」って思っちゃいましたね。盛り盛り。

アプリケーションに脆弱性のあるアプリ「派手なブックマーク」、プレビュー機能でSSRFをして見る話。IMDSv1だと、先程のと同じくmod_securityが検知してブロックしてくれるが、IPアドレスをホスト名にすると突破可能。

ではIMDSv2だと攻撃できないのか?
...それ、Gopherでできるよ!古のプロトコルGopherでHTTPをエミュレート出来るので、これでPUTメソッドとカスタムヘッダを実現。→なんとTokenがとれてしまった!
URLのスキームをバリデーションしても、リダイレクタによる攻撃により回避できてしまう。

対策としては

  • ネットワーク的な保護
    • AWSのドキュメントで推奨されているiptablesの設定例を紹介(※環境依存なので注意)
  • そもそもIMDS使わないなら無効化する

というわけで、IMDSはv2にしたから安全!というわけではない。という話でした。多層防御大事。

QA中に「なんでこのような設定になってしまったのか?(うろ覚え)」という質問に対して、徳丸さんがよくおっしゃっている「コピペ文化危険」というお話。「IAMわからん」「ググる」「なんかあった」「コピペった」「動いた」→「オッケー!」みたいな事がまぁよくあるのでは。StackOverFlowにも、こういった回答にイイね!がたくさんついてたりするので注意。今回の徳丸さんの資料にも「環境によって違うので注意」と言った但し書きが入っているページがありましたね。

ところで徳丸さんにサインしてもらおう♡とミーハー心丸出しで徳丸本(第2版)を持っていこうとしたんですけど、あまりにも鈍器だったので秒で諦めました。

参考リンク

今回もめちゃめちゃ早かったクラスメソッド臼田さんの記事。しかもほとんど全部書いてある。すごすぎ。