ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること
47.1K Views
March 04, 23
スライド概要
今や、ウェブセキュリティの知識は、書籍、ネットの記事、動画教材、AIなど多様な方法で得ることができますが、その内容の多くは、過去の記事や書籍の内容の劣化コピーであり、セキュリティの基礎を学ぶ重要性は増していると考えます。本講演では、下記の3つの切り口により、セキュリティのリアルを体現することの重要性についてお話します。
・ChatGPTの生成するコードはセキュアなの?
・検索やAIによる情報収集による問題
・CapitalOne事件に学ぶDevSecOpsの落とし穴
Forkwellのエンジニア文化祭 2023での講演資料です
https://forkwell.connpass.com/event/272596/
関連スライド
SPAセキュリティ超入門
徳丸 浩
806.8K
各ページのテキスト
ウェブセキュリティの知識は普及しているか、 徳丸本の著者が憂慮していること 徳丸 浩 徳丸浩のウェブセキュリティ講座
本日お伝えしたいこと • ChatGPTの生成するコードはセキュアなの? • 検索やAIによる情報収集による問題 • CapitalOne事件に学ぶDevSecOpsの落とし穴 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 2
徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – – – – EGセキュアソリューションズ株式会社取締役CTO https://www.eg-secure.co.jp/ 独立行政法人情報処理推進機構 非常勤研究員 https://www.ipa.go.jp/security/ 著書「体系的に学ぶ 安全なWebアプリケーションの作り方（第2版）」(2018年6月) YouTubeチャンネル「徳丸浩のウェブセキュリティ講座」 https://j.mp/web-sec-study – 技術士（情報工学部門） 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 3
情報収集どうやっていますか? • • • • • 書籍を読む Googleで検索する（ググれカスとか言いますものね） 最近だとAIに質問する? AIだと、プログラム作ってくれたりしますよね ChatGPTに作ってもらおう 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 4
ChatGPTの生成するコードはセキュアなの? SPAで改行混じりのテキスト表示する例 ～改行を<br>タグに変換する～ 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 5
なぜ改行を<br>タグに変換するのか • HTMLのテキスト上は改行は空白として扱われる <p>AAA BBB</p> AAA BBB と表示される • 改行するには、改行文字を<br>タグに変換する <p>AAA<br>BBB</p> AAA BBB 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 6
ChatGPTにVue.js版を作ってもらおう 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 7
8
改行をbr要素に変換する Vue.js 版（ChatGPT）
<template>
<div>
<p v-html="formattedText"></p>
</div>
</template>
v-htmlで<br>タグを有効化
<script>
export default {
data() {
return {
text: 'This is a sample text.¥nThis text contains a line break.',
};
},
computed: {
formattedText() {
return this.text.replace(/¥n/g, '<br>');
},
改行を<br>タグに変換
},
};
</script>
9
実行結果：ちゃんと改行されている 10
XSSは大丈夫か? 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 11
改行をbr要素に変換する Vue.js 版（ChatGPT）
<template>
<div>
<p v-html="formattedText"></p>
</div>
</template>
v-html大丈夫か?
<script>
export default {
data() {
return {
text: 'This is a sample text.¥nThis text contains a line break.',
};
'<svg onload=alert(1) />' を追加してみましょう
},
computed: {
formattedText() {
return this.text.replace(/¥n/g, '<br>');
},
},
};
</script>
12
実行結果：ちゃんとXSS攻撃できる （ちゃんと?） 13
改行をbr要素に変換する Vue.js 版のXSS対策版（ChatGPT）
<template>
<div>
<p v-text="formattedText"></p>
</div>
</template>
v-textに変更
<script>
export default {
data() {
return {
text: 'This is a sample text.¥nThis text contains a line break.',
};
},
computed: {
formattedText() {
return this.text.replace(/¥n/g, '<br>');
},
},
};
</script>
14
実行結果：改行が <br> という文字列（タグではない）になる 15
改行をbr要素に変換する Vue.js 版（ChatGPT）
<template>
<div>
<p v-text="formattedText"></p>
</div>
</template>
<script>
export default {
data() {
return {
text: 'This is a sample text.¥nThis text contains a line break.',
};
},
computed: {
formattedText() {
return this.text.replace(/¥n/g, ' ').replace(/¥r/g, ' ');
},
},
改行を 等と変換
};
（どこから探してきた?）
</script>
16
実行結果：改行が という文字列になる 17
ええい、自分でやるよ 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 18
改行をbr要素に変換する Vue.js XSS対策版
<template>
<div>
<template v-for="(value, key) in stringList" :key="key">
v-for
で配列を<br/>を
{{ value }}<br />
付与しながら表示
</template>
</div>
</template>
<script>
export default {
data() {
return {
text: 'This is a sample text.¥nThis text contains a line break.<svg onload=alert(1) />',
}
},
computed: {
stringList() {
return this.text.split(/¥r?¥n/g)
文字列を改行区切りで配列に
}
},
}
</script>
© 2023 Hiroshi Tokumaru
19
実行結果：タグではなく文字列として表示される 改行されている 文字列として表示 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 20
ちなむと、Reactなら大丈夫でした 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 21
改行をbr要素に変換する React版（ChatGPT）
import React from 'react';
const App = () => {
const text = 'こんにちは¥n世界.<svg onload=alert(1) />';
const lines = text.split('¥n').map((line, i) => (
<React.Fragment key={i}>
{line}
<br />
</React.Fragment>
));
return <div>{lines}</div>;
};
export default App;
徳丸浩のウェブセキュリティ講座
22
実行結果：タグではなく文字列として表示される OK👌 徳丸浩のウェブセキュリティ講座 23
JSXを活用して改行表示
const lines = text.split('¥n').map((line, i) => (
<React.Fragment key={i}>
{line}
<br />
</React.Fragment>
));
文字列 ABC¥nDEF
配列 ABC
配列 "ABC"
return <div>{lines}</div>;
¥n
DEF
<br key=0/>
"DEF"
DOM span
ABC
br
DEF
徳丸浩のウェブセキュリティ講座
© 2023 Hiroshi Tokumaru
24
いったんまとめ • AIによるプログラム生成が話題になっているが、常に高品質のコード が生成されるわけではない • 脆弱性があるコードが生成される場合も一定割合存在する – GitHub Copilotに対する研究もある https://i.blackhat.com/USA-22/Wednesday/US-22-Pearce-In-Need-Of-Pair-Review.pdf 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 25
検索やAIによる情報収集の問題 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 26
情報収集どうやっていますか?（再） • • • • 書籍を読む Googleで検索する（ググれカスとか言いますものね） 最近だとAIに質問する? 今度はBing Chat AIに質問してみましょう 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 27
Bing Chatに「SSRFについて詳しく教えて」もらった この記事を見てみます © 2023 Hiroshi Tokumaru 徳丸浩のウェブセキュリティ講座 28
記事の冒頭と目次 徳丸浩のウェブセキュリティ講座 https://cybersecurity-jp.com/column/33568 より引用 29
SSRF攻撃とは（件の記事） SSRF攻撃とは通常の方法ではアクセスできないサーバーに対して攻撃を仕掛ける手法の一つです。 攻撃者はインターネット上に公開サーバーには直接アクセスできます。しかし内部サーバーへはアク セスできません。しかし公開サーバーから内部サーバーへのアクセスはできる状態を仮定します。 この時、攻撃者は公開サーバーに対して攻撃コマンドを送信することで、公開サーバーを経由して内 部サーバーに対して攻撃をしかけることができます。この時、公開サーバーからのコマンドは正規コ マンドとして処理されます。これがSSRF攻撃の概要です。 徳丸浩のウェブセキュリティ講座 https://cybersecurity-jp.com/column/33568 より引用 30
SSRF攻撃とは（徳丸のブログ記事より） SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃 の様子を示します。 攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー （192.168.0.5）はファイアウォールで隔離されているため外部から直接アクセスできません。しかし、 公開サーバーから内部のサーバーにはアクセスできる想定です。 攻撃者は *何らかの方法で* 公開サーバーから内部のサーバーにリクエストを送信することにより、内 部のサーバーを攻撃できる場合があります。これがSSRF攻撃です。 徳丸浩のウェブセキュリティ講座 https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html より引用 31
件の記事と徳丸のブログ記事を比較してみる SSRF攻撃とは通常の方法ではアクセスできないサー バーに対して攻撃を仕掛ける手法の一つです。 攻撃者はインターネット上に公開サーバーには直接ア クセスできます。しかし内部サーバーへはアクセスで きません。しかし公開サーバーから内部サーバーへの アクセスはできる状態を仮定します。 この時、攻撃者は公開サーバーに対して攻撃コマンド を送信することで、公開サーバーを経由して内部サー バーに対して攻撃をしかけることができます。この時、 公開サーバーからのコマンドは正規コマンドとして処 理されます。これがSSRF攻撃の概要です。 https://cybersecurity-jp.com/column/33568 より引用 SSRF攻撃とは、攻撃者から直接到達できないサーバー に対する攻撃手法の一種です。下図にSSRF攻撃の様子 を示します。 攻撃者からは、公開サーバーにはアクセスできますが、 内部のサーバーはファイアウォールで隔離されている ため外部から直接アクセスできません。しかし、公開 サーバーから内部のサーバーにはアクセスできる想定 です。 攻撃者は *何らかの方法で* 公開サーバーから内部の サーバーにリクエストを送信することにより、内部の サーバーを攻撃できる場合があります。これがSSRF攻 撃です。 https://blog.tokumaru.org/2018/12/introduction-to-ssrfserver-side-request-forgery.html より引用 32
SSRF攻撃の仕組み 徳丸浩のウェブセキュリティ講座 https://cybersecurity-jp.com/column/33568 より引用 33
元ネタがあった 1980年代からSSRFがセキュリティ問題である、と指摘されていたと考えている理由はUNIXのリモート シェルの仕様と注意事項にあります。現在のUNIX系OSにはそもそもリモートシェル系のコマンド（r コマンドと呼ばれるrshなど）はインストールされていない物が多いと思います。そこでrコマンドと は何か、簡単に説明します。 rコマンドの代表であるrshは名前の通り、リモートからシェルコマンドを実行する仕組みです。rshな どのrコマンドはホームディレクトリの.rhostファイルに実行を許可するホストとユーザー名を定義し てリモートコマンド実行を許可します。 ATTACKER1とSERVER1、SERVER2があり、SERVER1が攻撃対象だとします。 ATTACKER1 -> SERVER2 -> SERVER1 リモートシェルの仕組みを利用するとSERVER1が信頼するSERVER2にアクセスできれば、攻撃元とな るATTACKER1から攻撃対象となるSERVER1に攻撃可能になります。 リクエストフォージェリ – SSRFとCSRF – yohgaki's blog https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用 徳丸浩のウェブセキュリティ講座 34
件の記事と大垣さんのブログ記事を比較してみる SSRFと似た攻撃としてCSRFがあります。 CSRFは攻撃用のWebページを準備し、攻 撃用のURLを設定します。攻撃者はWeb サイトの訪問者に対して罠ページにアク セスさせて、攻撃用のURLをクリックさ せます。攻撃用URLをクリックしたユー ザーは正規のユーザーであると認識され るため、正しいリクエストとして処理さ れてしまいます。 https://cybersecurity-jp.com/column/33568 より引用 徳丸浩のウェブセキュリティ講座 1. 罠（攻撃用）のWebページを用意し、 攻撃用のURLを配置する 2. 攻撃目標のWebサイトの正規ユー ザーに罠ページにアクセスさせ、攻 撃用URLをクリックさせる 3. 攻撃目標のWebサイトに攻撃用URLが、 正規ユーザーとして送られる 4. 攻撃目標のWebサイトは正規ユー ザーからのリクエストなので正しい リクエストとして処理する https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用 35
CSRFとSSRFの違い(?) 徳丸浩のウェブセキュリティ講座 https://cybersecurity-jp.com/column/33568 より引用 36
CSRFとSSRFの比較表 https://cybersecurity-jp.com/column/33568 より引用 • SSRF サーバーが持つ権限・認証を利用して不正な命令を実行 • CSRF クライアントが持つ権限・認証を利用して不正な命令を実行 https://blog.ohgaki.net/request-forgery-ssrf-and-csrf より引用 徳丸浩のウェブセキュリティ講座 37
SSRFの対策 ファイアウォール ファイアウォールの設定により、攻撃者が接続先となる攻撃対象を指定しても、接続できないように 制限する方法が有効です。少なくともローカルホストに対するアクセスについては厳しく制限する必 要があります。注意点として、SSRF攻撃ではない正常のアクセスについて制限してしまうと、本来の 目的が果たせなくなってしまいます。 プロキシ ブラウザにプロキシを設定して全てのアクセスをプロキシ経由にする方法です。そしてプロキシにお いてアクセス制御を行います。プロキシを設定する方法の注意点として、ブラウザが全ての通信をプ ロキシ経由にするとは限らない点があげられます。さらにループバックアドレスへの通信については、 デフォルトでプロキシ経由にならないことにも気を付ける必要があります。 インターセプト Puppeteerのようにリクエストのインターセプト機能を持つツールを使用している場合には、リクエス トの送信先などを制御することができます。しかしこの方法では全ての通信をインターセプトできる わけではありません。 徳丸浩のウェブセキュリティ講座 https://cybersecurity-jp.com/column/33568 より引用 38
元ネタがあった（MBSD寺田さんの記事） ファイアウォール まずはファイアウォール（FW）による対策です。FWにも種類がありますが、少なくともローカルホ ストへのアクセス制限については、それができるホスト型のものを使用する必要があります。… プロキシ ブラウザにプロキシ（HTTP/Socks）を設定して全てのアクセスをプロキシに転送します。そして、プ ロキシ側（プロキシ自体の設定、またはプロキシを置くNW/サーバの設定）でアクセスを制御する方 式です。… プロキシ方式の問題は、そもそもの話としてブラウザが全ての通信をプロキシ経由にするわけではな いということです。少なくともWebRTCの通信についてはプロキシ経由になりません。またループ バックアドレス宛の通信がデフォルトではプロキシ経由にならない点に注意が必要です。 インターセプト Puppeteerはリクエストのインターセプト機能を提供しており、これを使うとリクエストの送信先など を制御できます。やられサイトの最終版ではこれを使っていますが、プロキシと同様に全ての通信が インターセプトできるわけではないという問題があります。… 徳丸浩のウェブセキュリティ講座 https://www.mbsd.jp/blog/20190605.html より引用 39
件の記事と寺田さんのブログ記事を比較してみる ファイアウォール ファイアウォールの設定により、攻撃者が接続先となる攻撃 対象を指定しても、接続できないように制限する方法が有効 です。少なくともローカルホストに対するアクセスについて は厳しく制限する必要があります。 プロキシ ブラウザにプロキシを設定して全てのアクセスをプロキシ経 由にする方法です。そしてプロキシにおいてアクセス制御を 行います。プロキシを設定する方法の注意点として、ブラウ ザが全ての通信をプロキシ経由にするとは限らない点があげ られます。さらにループバックアドレスへの通信については、 デフォルトでプロキシ経由にならないことにも気を付ける必 要があります。 インターセプト Puppeteerのようにリクエストのインターセプト機能を持つ ツールを使用している場合には、リクエストの送信先などを 制御することができます。しかしこの方法では全ての通信を インターセプトできるわけではありません。 https://cybersecurity-jp.com/column/33568 より引用 ファイアウォール まずはファイアウォール（FW）による対策です。FWにも種 類がありますが、少なくともローカルホストへのアクセス制 限については、それができるホスト型のものを使用する必要 があります。 プロキシ ブラウザにプロキシ（HTTP/Socks）を設定して全てのアクセ スをプロキシに転送します。そして、プロキシ側（プロキシ 自体の設定、またはプロキシを置くNW/サーバの設定）でア クセスを制御する方式です。… プロキシ方式の問題は、そもそもの話としてブラウザが全て の通信をプロキシ経由にするわけではないということです。 少なくともWebRTCの通信についてはプロキシ経由になりま せん。またループバックアドレス宛の通信がデフォルトでは プロキシ経由にならない点に注意が必要です。 インターセプト Puppeteerはリクエストのインターセプト機能を提供しており、 これを使うとリクエストの送信先などを制御できます。やら れサイトの最終版ではこれを使っていますが、プロキシと同 様に全ての通信がインターセプトできるわけではないという 問題があります。… https://www.mbsd.jp/blog/20190605.html より引用 40
寺田さんのブログ記事はヘッドレスブラウザを使う場合のもの 徳丸浩のウェブセキュリティ講座 https://www.mbsd.jp/blog/20190605.html より引用 41
記事の構成はこう 徳丸浩の日記より転 載・改変 大垣さんのブログよ り転載・改変 piyologより転載・改変 大垣さんのブログよ り転載・改変 独自の作文? MBSD寺田さんの日記 より転載・改変 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 42
キメラのように、既存記事を組み合わせて新しい記事をつくる 大垣さんの ブログ記事 徳丸浩の日記 piyolog MBSD寺田さん のブログ記事 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 43
ネット上のセキュリティ記事の現状と対策 • SEO技術の発展により、量産型のセキュリティ解説記事が検索上位に ある – 今回はSSRFで説明したが、SQLインジェクションやクロスサイトスクリプティ ングでも同様の傾向となる • 資金とSEOの動機のある企業が記事を量産している • もはや、「ググって上位の記事を参照する」方法では、質の高い記事 を見つけることはできない • Bing AI Chatも検索上位を参照するので同様の傾向が見られる • 今後は AI を使ったSEO目的の記事が量産され、上記が加速するのでは ないか? • インターネット検索やAIを使う場合でも、セキュリティの基礎的な知 識がないと、真贋を見分けられない 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 44
CapitalOne事件に学ぶDevSecOpsの落とし穴 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 45
SSRF攻撃の被害事例はありますか? CapitalOneの事例に注目します 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 46
SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog 2019年7月29日、米金融大手 Capital Oneは不正アクセスにより1億人を超える個人情報が流出したと発表しまし た。WAFの設定ミスに起因して、Server Side Request Forgery（SSRF）攻撃を許したことにより情報を盗まれたと 見られています。ここでは関連する情報をまとめます。 Capital Oneによる公式発表 • • Information on the Capital One Cyber Incident（米国向け） Information on the Capital One Cyber Incident（カナダ向け） • Frequently Asked Questions （１）影響範囲 影響が及んだ人数の内訳は以下の通り。 米国 約1億人 カナダ 約600万人 発表時点でCapital Oneは流出した情報が外部へ出回ることや、詐欺への使用は確認していない。 クレジットカード番号、ログイン情報は侵害されていない。 徳丸浩のウェブセキュリティ講座 https://piyolog.hatenadiary.jp/entry/2019/08/06/062154 より引用 47
原因はWAF設定ミス ※ 問題が生じたWAFはApache Modsecurityを採用していた。AWS WAFではなく、Capital Oneが独自構築したもの 徳丸浩のウェブセキュリティ講座 https://piyolog.hatenadiary.jp/entry/2019/08/06/062154 より引用 48
事件の概要 • WAF用に構築したリバースプロキシが、オープンリバースプロキシと なっていた • その結果、SSRF脆弱性が生じていた • SSRF攻撃により、AWS IAMのクレデンシャルが漏洩、S3に保存してい た個人情報等が漏洩した ※ 1億人超の個人情報が漏洩した Capital Oneの事件（2019年7月29日発表）をモデルにしています 参考: SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた https://piyolog.hatenadiary.jp/entry/2019/08/06/062154 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 49
mod_securityによるWAFの概要 Apache+mod_security リバースプロキシとして構成 Webサーバー EC2 AWS 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 50
Apacheでリバースプロキシとmod_securityを導入する例 # 以下はAmazon Linux上のでの操作 # Apacheとmod_security、CRS（ルール）をインストール $ sudo yum install httpd mod_security mod_security_crs $ sudo vi /etc/httpd/conf.d/reverseproxy.conf これは絶対だめ ProxyRequests On <VirtualHost *:443> ServerName capital.example.com ProxyPass / http://172.31.XXX.XXX/ ProxyPassReverse / http://172.31.XXX.XXX/ </VirtualHost> $ sudo systemctl restart httpd 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru ウェブサーバー
警告 サーバを安全にするまで ProxyRequests は有効にしないで ください。 オープンプロキシサーバはあなた自身のネット ワークにとっても、 インターネット全体にとっても危険です 徳丸浩のウェブセキュリティ講座 https://httpd.apache.org/docs/2.4/ja/mod/mod_proxy.html より引用
攻撃の模様 ⚫ WAFの設定ミスを悪用したSSRF攻撃 ⚫ HostヘッダにIMDSエントリを指定 ⚫ 設定ミスの詳細は明らかにされていない ⚫ 1億人を超える被害者が出た Apache+mod_security 169.254.169.254 リバースプロキシとして構成 （IMDSのエンドポイント） SSRF攻撃により ISRM-WAF-Role にアクセス ISRM-WAF-Role EC2 S3 徳丸浩のウェブセキュリティ講座 AWS Amazon S3 © 2023 Hiroshi Tokumaru 個人情報などを保管 53
EC2 IMDS(IMDSv1)とは • Instance MetaData Service • Amazon EC2 の仮想エンドポイント http://169.254.169.254/ • アクセス元の設定情報 （Instance MetaData）を返す • 外部からはIMDSにはアクセス できないので設定情報はもれない …はず • PUBLIC IPv4を取得する例 EC2インスタンス IMDS 169.254.169.254 インスタンスの 設定情報 仮想的な エンドポイント EC2 $ curl http://169.254.169.254/latest/meta-data/public-ipv4 18.217.170.163$ 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 54
なぜ攻撃を受けたか • S3ストレージに大量の個人情報を保存 • S3ストレージのアクセス権がWAFのインスタンスに付与され ていた • WAFがオープンPROXYになっていた（予想） • IMDSが無効化されていなかった 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 55
Capital OneはDevSecOpsの先駆的企業だった（2018年5月の記事） Capital One で DevOps について話すとき、DevOps の一般的な定義については話し ません。私たちが話すのは、DevOpsの目標、すなわち高品質で動作するソフトウェ アをより速く提供することです。DevOps を定義して DevOps とは何かを問う代わり に、DevOps が私たちにとって重要である理由に焦点を当てます。私たちは「高品質 で機能するソフトウェアをより速く提供する」を分解し、この文の中で私たちにとっ て重要な単語やフレーズに焦点を当てます。 • 高品質とは、セキュリティ上の欠陥がないこと、コンプライアンスに準拠してい ること、欠陥が最小限であることなどを意味します。 • エンドツーエンドで機能するということは、すべての関係者にとって実際に機能 し、テストされ、すべての依存関係が満たされていることを意味します。 • Faster（より速く）とは、品質を犠牲にすることなく、できるだけ速くという意味 です。 https://medium.com/capital-one-tech/focusing-on-the-devops-pipeline-topo-pal-833d15edf0bd より引用 徳丸浩のウェブセキュリティ講座 56
Capital One: Building Security Into DevOps (Qualys; 2018年) 技術変革の実績を考えると、Capital One が DevSecOps を採用し、自動化されたセキュリ ティ チェックを DevOps パイプラインに組み込んでいることは驚くべきことではありません。 この取り組みにより、仮想マシン イメージとコンテナーの脆弱性と構成ミスを評価するプロ セスが劇的に加速されました。 CAPITAL ONE が QUALYS を選んだ理由: • Qualys API を使用すると、その機能を DevOps ツールと統合して、コードのセキュリティ とコンプライアンスのスキャンを自動化できます • Qualys は、Amazon Machine Image (AMI) と Docker コンテナの両方で、脆弱性と設定ミ スの評価を提供します • Qualys を使用すると、DevOps チームが独自のスキャンを実行できるため、AMI とコンテ ナのセキュリティ認証プロセスが迅速化され、セキュリティ チームがより高いレベルのタ スクに集中できるようになります • ライブ インスタンスに Qualys Cloud Agent をシードすると、本番環境の継続的かつ即時 のセキュリティおよびコンプライアンス評価が可能になり、より高い精度が得られます。 https://www.qualys.com/customers/success-stories/capital-one-building-security-devops/ 徳丸浩のウェブセキュリティ講座 57
58
WAFに対する脆弱性診断ではSSRF脆弱性は見抜けなかったか? • Nessusなら • 使っていたツールでは検出されなかった可能性 • 検出はしたが軽視した可能性 • …詳細は不明だが、SSRF攻撃により情報が漏洩し、それを脆弱性検査 で対策できていなかったことは事実 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 59
AWS設定監査では脆弱性を見抜けなかったか? • 設定監査の基準としてよく用いられる CIS Controls にはIMDSに関する 監査項目はない • CIS Controlsには権限に関する項目はあるが、極端なケースのみ対象 – 1.16 Ensure IAM policies that allow full "*:*" administrative privileges are not attached (Automated) • AWS 基礎セキュリティのベストプラクティスにはIMDSの項目がある – EC2 instances should use Instance Metadata Service Version 2 (IMDSv2) • 当時SSRFおよびIMDSに関する情報はそれほど知られていなかった – 徳丸浩の日記（2018年12月5日）では言及していた – Capital Oneの社員が弊日記を読んでくれていれば（無理） 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 60
いったんまとめ • Capital One事件の概要を説明（一部推測） • SSRF攻撃によりIMDS経由でS3ストレージのクレデンシャルを取得 • Capital Oneのだめだったポイント – WAFがOpen Proxyになっていた（決定的な要因） – WAFに多数の不要なクレデンシャルが付与されていた – S3ストレージに1億件超の個人情報を保管していた • CapitalOneはDevSecOpsの先駆的な企業なのに攻撃を受けた – 印象論にはなるが、ツールに頼りっぱなしで、セキュリティの生の状態を人が ちゃんとチェックしていなかったのでは? 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 61
DevSecOps、SDLC、シフトレフト… • DevSecOps – DevSecOpsとは、開発（Development）、セキュリティ（Security）、運用 （Operation）を指し、ソフトウェア開発ライフサイクルのすべてのフェーズで セキュリティを自動化し、統合する手法 • SDLC（Secure Development Life Cycle） – SDLCとはセキュア開発ライフサイクルの略で、開発プロセスの全工程にセキュ リティ関連の活動を組み込むことで、製品のセキュリティ品質を向上させる • シフトレフト(Shift Left) – シフトレフトとは、開発プロセスの可能な限り早期の段階にセキュリティ施策 を実施すること。開発ライフサイクルが高速になり、迅速かつ頻繁にアプリ ケーションをリリースすることができる 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 62
総まとめ • DevSecOps、SDLC、シフトレフトなど、セキュア開発の手法が提案さ れている • 開発の全工程でセキュリティを担保するという考え方自体は、古くか ら指摘されていたもの • 上流工程で「実際に何をするのか」はあまり語られていない • CapitalOne事件はDevSecOpsの手痛い失敗例として研究されるべきだ が、そのような言及はほとんどない – ツールを導入しただけで満足していませんか? • AIの発達が著しいが、AIまかせはCapitalOne事件の再来にならないか? • 開発者がセキュリティの知識を身に着け、実践する時が来ていると考 えます 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 63
徳丸の過去資料の紹介 • オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法 – 架空のQRコード決済サービス「オニギリペイ」のセキュリティ事故を題材と して、開発の全行程でのセキュリティ施策の重要性を解く – https://www.docswell.com/s/ockeghem/KWM4RZ-phpconf2019 – https://atmarkit.itmedia.co.jp/ait/articles/2001/28/news003.html • SPAセキュリティ超入門 – https://www.docswell.com/s/ockeghem/K2PPNK-phpconf2022 • SPAセキュリティ入門 – https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security • フレームワークで脆弱性対策されているのに現実のアプリケー ションに脆弱性が減らないワケ – https://pr.forkwell.com/event/security-study-01/ 徳丸浩のウェブセキュリティ講座 © 2023 Hiroshi Tokumaru 64