วิธีค้นหา AWS Account ID ของ S3 bucket ใดก็ได้

 (tracebit.com)
2 คะแนน โดย GN⁺ 2024-02-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การค้นหา AWS Account ID ของ S3 bucket

  • ในปี 2021 Ben Bridts ได้เผยแพร่วิธีที่สร้างสรรค์ในการค้นหา AWS Account ID ของ S3 bucket ที่เปิดเผยสู่สาธารณะ
  • บทความนี้อธิบายเทคนิคสำหรับค้นหา Account ID ของทั้ง S3 bucket แบบส่วนตัวและแบบสาธารณะ

จาก S3 bucket ไปยัง AWS Account ID

  • แสดงเทคนิคในการค้นหา AWS Account ID ที่ไม่เคยทราบมาก่อนของ bucket ชื่อ bucket-alpha ผ่านผลลัพธ์จากเชลล์

เทคนิคนี้ทำงานอย่างไรกันแน่?

  • วิเคราะห์เหตุผลที่เทคนิคของ Ben ใช้งานได้ โดยเป็นการผสาน 3 องค์ประกอบหลัก:
    • ความสามารถในการใช้ IAM policy กับคำขอ
    • ความสามารถในการอนุมานได้ว่า IAM policy อนุญาตคำขอหรือไม่
    • ความสามารถในการใช้ wildcard match กับคีย์เงื่อนไข s3:ResourceAccount

วิธีแก้ปัญหา

  • พบวิธีแก้ปัญหาโดยใช้ VPC endpoint สำหรับ S3 และอาศัยความแตกต่างของพฤติกรรมเมื่อคำขอถูกปฏิเสธใน CloudTrail

ดูแบบทีละขั้นตอน

  • ขั้นตอนแบบทีละลำดับเมื่อคุณต้องการค้นหา Account ID ของ bucket bucket-alpha:
    • ระบุรีเจียนของ bucket
    • ดีพลอย VPC และ VPC endpoint ในรีเจียนเดียวกัน
    • เริ่มต้น EC2 instance ภายใน VPC และยืนยันว่าใช้ VPC endpoint สำหรับ S3
    • แก้ไขนโยบายของ VPC endpoint เพื่อระบุว่า Account ID ของ bucket เป้าหมายขึ้นต้นด้วย "0" หรือไม่
    • ส่งคำขอไปยัง bucket เป้าหมาย
    • ตรวจสอบว่าคำขอปรากฏใน CloudTrail หรือไม่
    • แก้ไขนโยบายของ VPC endpoint ตามผลลัพธ์เพื่อค้นหาข้อมูลของ Account ID เพิ่มเติม

ผลลัพธ์

  • มีการเขียนสคริปต์เพื่อทำกระบวนการนี้แบบอัตโนมัติ ทำให้สามารถค้นหา Account ID ของ bucket ได้อย่างน่าเชื่อถือ
  • ใช้ binary search กับแต่ละหลักเพื่อลดจำนวนครั้งของการทดสอบที่ต้องทำ

เพิ่มความเร็ว

  • มีการปรับนโยบายของ VPC endpoint เพื่อลดเวลาที่ต้องรอให้ผลของนโยบายมีผล และลดเวลาที่ต้องรอผลแต่ละรายการใน CloudTrail
  • ทำให้ลดเวลาที่ใช้ในการค้นหา Account ID ลงเหลือน้อยกว่า 10 นาที

ความเห็น

  • โพสต์บล็อกนี้เผยแพร่หลังจากได้หารือกับทีมความปลอดภัยของ AWS
  • มีการถกเถียงที่น่าสนใจว่า AWS Account ID ควรถูกมองว่าเป็นข้อมูลอ่อนไหวหรือไม่
  • เทคนิคนี้อาจนำไปใช้กับบริการอื่นนอกเหนือจาก S3 ได้ด้วย
  • เทคนิคเหล่านี้เป็นไปได้เพราะสามารถใช้เงื่อนไข StringLike กับ s3:ResourceAccount ได้
  • การที่เหตุการณ์ซึ่งถูกปฏิเสธโดยนโยบายของ VPC endpoint ถูกบันทึกลงใน CloudTrail อาจเป็นประโยชน์

คำขอบคุณ

  • เทคนิคต้นฉบับของ Ben Bridt เป็นแรงบันดาลใจให้กับงานนี้
  • ขอขอบคุณ Chris Farris สำหรับความช่วยเหลือและคำแนะนำ

ความเห็นของ GN⁺

  • เทคนิคนี้อาจมีประโยชน์มากในการทำ security audit ในสภาพแวดล้อมคลาวด์ โดยเฉพาะในการตรวจสอบความเป็นเจ้าของของ AWS S3 bucket
  • การถกเถียงเกี่ยวกับความอ่อนไหวของข้อมูลที่เทคนิคนี้เปิดเผย สะท้อนถึงบทสนทนาอย่างต่อเนื่องเรื่องความปลอดภัยของข้อมูลและความเป็นส่วนตัวระหว่างผู้ให้บริการคลาวด์กับผู้ใช้งาน
  • เครื่องมืออื่นที่มีความสามารถคล้ายกันคือ CloudTrail ซึ่งเป็นบริการของ AWS เอง ใช้สำหรับบันทึกและมอนิเตอร์กิจกรรมทั้งหมดที่เกิดขึ้นในสภาพแวดล้อม AWS ของผู้ใช้
  • ก่อนนำเทคนิคนี้มาใช้ ผู้ใช้ควรตรวจสอบให้แน่ใจว่าเทคนิคดังกล่าวสอดคล้องกับนโยบายของ AWS และแนวปฏิบัติด้านความปลอดภัยที่เหมาะสม
  • ประโยชน์ที่ได้จากการใช้เทคนิคนี้คือการทำ security audit อย่างมีประสิทธิภาพและการยืนยันความเป็นเจ้าของข้อมูลได้อย่างรวดเร็ว แต่ก็ควรพิจารณาความเสี่ยง เช่น การเปิดเผยข้อมูลส่วนบุคคลที่อาจเกิดขึ้นด้วย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-27
ความเห็นจาก Hacker News

  • ความสามารถในการใช้การจับคู่แบบไวลด์การ์ดกับคีย์เงื่อนไข s3:ResourceAccount ของ AWS

    • สิ่งที่น่าแปลกของฟีเจอร์นี้คือ ไม่มีเหตุผลที่สมควรในการอนุญาตหรือปฏิเสธสิทธิ์โดยอิงจากการจับคู่บัญชีแบบบางส่วน AWS account ID อาจมีความอ่อนไหวคล้ายกับที่อยู่ IP แต่เพื่อให้งานเดินหน้าได้ ก็ต้องมีใครสักคนรู้มัน

  • AWS account ID == ที่อยู่ IP ของคุณ อาจอ่อนไหวได้ แต่เพื่อให้งานสำเร็จ ก็ต้องมีใครสักคนรู้มัน

    • ตัวอย่าง: ผู้เขียนต้องการใช้การตั้งค่า privatelink ซึ่งโดยทั่วไปปลอดภัยกว่าการเปิดพอร์ต sftp เพื่อทำงานร่วมกับบุคคลที่สามซึ่งต้องเชื่อมต่อกันตามขั้นตอนต่อต้านการฟอกเงิน แต่บริษัทนั้นปฏิเสธด้วยเหตุผลด้านความปลอดภัยเพราะต้องการซ่อน account ID สุดท้ายทีมของผู้เขียนจึงต้อง whitelist ช่วง public IP ที่พวกเขาใช้ไว้ที่พอร์ต 22
    • ข้อคิดของเรื่อง: การซ่อน ID อาจดูฉลาด แต่ถ้าไม่มีที่อยู่ให้คนอื่นติดต่อคุณได้ ก็ทำธุรกิจจริงไม่ได้

  • โดยทั่วไปคุณคงไม่เผยแพร่ account ID ต่อสาธารณะ แต่ก็ควรคาดไว้ว่าในจุดหนึ่งบางส่วนจะถูกเปิดเผย

    • เมื่อ third-party vendor และแพลตฟอร์ม SaaS เปลี่ยนไปใช้การเชื่อมต่อแบบที่นิยม role assumption มากกว่า IAM user และ access key นั้น account ID ของบัญชีที่ใช้เป็นจุดเชื่อมต่อจะเป็นที่รับรู้โดยอีกฝ่าย และพวกเขาเองก็มี dependency และช่องโหว่ของตน

  • AWS resource สาธารณะอื่น ๆ ที่มี global namespace ก็เปิดเผย AWS account ID ได้เช่นกัน

    • สำหรับคนที่สนใจ ผู้เขียนโพสต์โค้ดนั้นออนไลน์ไว้ที่นี่: find-s3-account

  • ที่เกี่ยวข้อง: AWS key ID (ไม่ใช่ส่วน secret key) มี account ID อยู่ในนั้น โดยมีการเลื่อนบิตไปหนึ่งตำแหน่ง

    • key ID นี้รวมอยู่ใน URL ของลิงก์ presigned สำหรับ S3 ดังนั้นคุณอาจกำลังเปิดเผย account ID อยู่แล้ว

  • เป็นการค้นพบที่น่าสนใจ แต่พอเห็นชื่อเรื่องแล้วคาดว่าจะมีวิธีที่ง่ายกว่านี้

    • อยากให้ AWS มีวิธีง่าย ๆ ที่ให้ถามด้วยสิทธิ์ผู้ดูแลได้ว่า "resource X อยู่ที่ไหน" โดยเฉพาะฟังก์ชันที่บอกได้เร็ว ๆ ว่า S3 bucket บางตัวอยู่ในบัญชีไหน เรื่องนี้มักเกี่ยวกับ legacy bucket ที่มีอยู่ก่อนจะถูกนิยามไว้ในโค้ด เมื่อมี AWS account จำนวนมาก การตามหา resource ในบัญชีที่ไม่ทราบและ region ที่เป็นไปได้นั้นค่อนข้างยุ่งยาก

  • สถานการณ์ที่การแฮ็กจริงทำให้นึกถึงภาพจำหรือความเข้าใจผิดแบบเก่าว่า "แฮ็กรหัสผ่านทีละตัวอักษร" นั้นเจ๋งเสมอ

  • เวกเตอร์การโจมตีที่น่ากังวลกว่าคือ ตอนนี้สามารถใช้หมายเลขบัญชีเพื่อลองเพิ่ม principal ของอีกบัญชีหนึ่งเข้า allowlist ในนโยบายของบัญชีตัวเองได้

    • หาก principal นั้นไม่มีอยู่ในอีกบัญชีหนึ่ง จะเกิดข้อผิดพลาดว่าไม่พบ role/user ซึ่งสามารถใช้หาหลักฐานของ principal ที่มีอยู่จริงในอีกบัญชีได้

  • ทำไมเรื่องนี้จึงสำคัญ? อย่างหนึ่งที่ชัดเจนคือ หากรู้ production bucket ก็อาจค้นหา development bucket ขององค์กรเดียวกันได้ ซึ่งเป็นพฤติกรรมที่ไม่คาดคิด