Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Is Serverless Safe? ~Hacking AWS Lambda~
Search
Yutaka Hiroyama
December 05, 2023
Technology
1
350
Is Serverless Safe? ~Hacking AWS Lambda~
I spoke this content at Cyber-sec+ vol.2 Dec.5 2023.
Yutaka Hiroyama
December 05, 2023
Tweet
Share
More Decks by Yutaka Hiroyama
See All by Yutaka Hiroyama
Is Serverless Safe? ~Hacking AWS Lambda~
pict3
0
140
PagerDutyを活用したインシデント管理の自動化とメリット
pict3
0
480
WafCharm運用のベストプラクティスを考えてみた
pict3
0
1.3k
AWSからのメール読んでいますか?
pict3
0
1.9k
PCI DSS運用でラクをする/make_it_easy_for_pci-dss_operation_on_cloud
pict3
0
260
AWSでのPCI DSS運用でラクをする/make_it_easy_for_pci-dss_operation_on_aws
pict3
1
2.4k
運用情報共有会資料
pict3
0
160
AWS運用における「セキュリティ」の不安を一掃! cloudpackのセキュリティサービスで安心運用を実現
pict3
0
140
Other Decks in Technology
See All in Technology
オブザーバビリティプラットフォーム開発におけるオブザーバビリティとの向き合い / Hatena Engineer Seminar #34 オブザーバビリティの実現と運用編
arthur1
0
200
隙間時間で爆速開発! Claude Code × Vibe Coding で作るマニュアル自動生成サービス
akitomonam
2
240
AI によるドキュメント処理を加速するためのOCR 結果の永続化と再利用戦略
tomoaki25
0
240
完璧を目指さない小さく始める信頼性向上
kakehashi
PRO
0
130
VLMサービスを用いた請求書データ化検証 / SaaSxML_Session_1
sansan_randd
0
150
帳票構造化タスクにおけるLLMファインチューニングの性能評価
yosukeyoshida
1
200
Kiroから考える AIコーディングツールの潮流
s4yuba
2
550
Tableau API連携の罠!?脱スプシを夢見たはずが、逆に依存を深めた話
cuebic9bic
2
160
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
1.2k
ファインディにおける Dataform ブランチ戦略
hiracky16
0
230
마라톤 끝의 단거리 스퍼트: 2025년의 AI
inureyes
PRO
1
210
人と生成AIの協調意思決定/Co‑decision making by people and generative AI
moriyuya
0
220
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Balancing Empowerment & Direction
lara
1
510
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Automating Front-end Workflow
addyosmani
1370
200k
KATA
mclloyd
31
14k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Transcript
サーバーレスは 安全なのか? Hacking AWS Lambda
自己紹介 •氏名:廣山 豊 •所属:アイレット株式会社 クラウドインテグレーション事業部副事業部長 兼 内部統制推進室室長 •役割:情報管理責任者 兼 PCI DSS管理責任者
兼 AWS Well Architected Lead 兼 品質管理責任者 •AWS Top Engineers - 2019 ~ <初回から継続中> •AWS, 情報処理安全確保支援士、 その他多数の認定資格を保有
はじめに
このLambdaファンクションで、他の人のデータを盗める? import json import yaml def Handler(event, context):
data = yaml.load(event[“body”]["Data"]) store_data(data) return { "statusCode" : 200, "body" : “OK!!” } import json import yaml def Handler(event, context): data = yaml.load(event[“body”]["Data"]) # store_data(data) return { "statusCode" : 200, "body" : “OK!!” }
注意事項 https://unit42.paloaltonetworks.com/gaining-persistency-vulnerable-lambdas/ 攻撃手段については、上記で公開されている範囲内でお話しします。 悪用への活用や、無断での第三者環境での試用は絶対にしないでください!
ハッキング
AWS Lambda の仕組み 以下の3点が、今回のお話の肝となります。 • コールドスタート時に、コンテナが生成される • bootstrap (ランタイム)はユーザーが記載するコード(ハンドラ)と同じコンテナ環境に存在する •
ランタイム はハンドラの呼び出しとレスポンスの返却をループ処理で繰り返す 引用) https://aws.amazon.com/jp/blogs/compute/the-serverless-lamp-stack-part-3-replacing-the-web-server/ https://medium.com/build-succeeded/deconstructing-aws-lambda-functions-d1597dd054cd
今回解説するハッキングの概要 ハンドラから bootstrap を差し替えることで実現。 OS コマンドインジェクションの脆弱性をつく。 データを盗み出すよう改竄した bootstrap を送り込み、YAML読み込み時にプロセスを
差し替えることで永続化させる。 この bootstrap は、ハンドラ呼び出し直前に、TCPにてデータを指定のIPアドレス宛に 送信する。
ハッキング構成 差し替える
bootstrap の改ざん手順 ざっくりとした手順は以下。 1. 正規の bootstrap をベースに加工した bootstrap を用意する 2.
加工した bootstrap を、既存の bootstrap と差し替えるスクリプトを用意する 3. 攻撃対象の Lambda に対し、1, 2 のスクリプトを展開させるような YAML データを 付属の上、呼び出す 正規の bootstrap の振る舞いも続けるため、利用者および Lambda の保守担当者は 気づきにくい。 成功すれば、そのコンテナ環境に次回以降くるリクエストに付随するデータを搾取可能。
加工した bootstrap のサンプルの抜粋 ハンドラ呼び出しの直前に POST で悪意ある 攻撃者宛にデータを送信
プロセスを差し替えるスクリプトのサンプル
Lambdaに送りつける YAML データ生成のサンプル 先の2つのサンプルを差し込んで、上記の偽装 YAML を生成し、Lambda ファンクション を invoke する。
盗み出したデータのキャプチャ Base64でデコードすることで データを取得可能
ホワイトハッカー視点での分析
攻撃に対して PyYAML の脆弱性 (CVE-2017-18342) をついた、OS コマンドインジェクション。 5.1 未満のバージョンに存在。 CVSS で
9.8 のヤバいやつ。 引用) https://nvd.nist.gov/vuln/detail/CVE-2017-18342
問題となる箇所 PyYaml ver 5.1 で作った Layer
問題箇所のコード import json import yaml def Handler(event, context):
data = yaml.load(event[“body”]["Data"]) # store_data(data) return { "statusCode" : 200, "body" : “OK!!” }
防御 Shift Left(スキャン、ネットワーク制限、暗号化) Shield Right(WAF、エージェント、VPC FlowLog、GuardDuty) 引用) https://sysdig.com/blog/cnapp-runtime-insights-shift-left-shield-right/
防御 Shift Left も重要! 予めできることはやっておきましょう!
Amazon CodeGuru の検出例 しっかり検出!
AWS WAF防御例 「os.execv」 という文字列を検知 左記のルールを設定した WAFをAPI Gatewayにアタッチ した上で攻撃を行なったログ
AWS Lambda における責任共有モデル IaaSとサーバーレス 引用) https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/the-shared-responsibility-model.html
AWS Lambda における責任共有モデル IaaSとサーバーレス
Wrap-up
AWS Lambdaは危険なのか? No! OS コマンドインジェクションは、IaaS やオンプレでも有効。むしろ攻撃を成功させやす い。 コールドスタートによって自動的にコンテナを再生成(攻撃を無効化)できる AWS Lamba
の方が安全。
まとめ • (IaaS やオンプレよりは攻撃難易度は上がるものの) たとえ FaaS であっても脆弱性対策は必要 • セキュリティ面を考慮するには、仕組みを知ったほうがいい •
脆弱性をなくすことと(Shift Left)、攻撃を検知・防御すること(Shield Right)両面で 行う