S3 Bucketsquatting หายไปแล้ว (ในที่สุด)

 (onecloudplease.com)
2 คะแนน โดย GN⁺ 2026-03-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • AWS เปิดตัว ฟีเจอร์ปกป้องเนมสเปซแบบอิงบัญชี ใหม่เพื่อแก้ปัญหา S3 bucketsquatting
  • เนมสเปซใหม่นี้มีรูปแบบเป็น <prefix>-<accountid>-<region>-an โดยมีเพียงบัญชีเดียวกันเท่านั้นที่สามารถสร้างบัคเก็ตชื่อนี้ได้
  • หากบัญชีอื่นพยายามใช้ชื่อเดียวกัน จะเกิดข้อผิดพลาด InvalidBucketNamespace และหากระบุรีจินไม่ถูกต้องก็จะได้ข้อผิดพลาดเดียวกัน
  • แนะนำให้ใช้เนมสเปซนี้ เป็นค่าเริ่มต้น และสามารถบังคับใช้ได้ผ่านนโยบายระดับองค์กร (SCP) ด้วยคีย์เงื่อนไข s3:x-amz-bucket-namespace
  • แม้จะไม่สามารถใช้ย้อนหลังกับบัคเก็ตเดิมได้ แต่ก็ให้การปกป้องที่แข็งแกร่งกับบัคเก็ตใหม่ และถือเป็น การปรับปรุงพื้นฐานด้านความปลอดภัยของ S3

ภาพรวมของปัญหา Bucketsquatting

  • Bucketsquatting (หรือ Bucketsniping) เป็นรูปแบบการโจมตีใน AWS S3 ที่อาศัยข้อเท็จจริงว่าชื่อบัคเก็ตต้องไม่ซ้ำกันทั้งระบบทั่วโลก
    • เมื่อบัคเก็ตถูกลบ ชื่อนั้นจะกลับมาใช้งานได้อีก ทำให้ผู้โจมตีสามารถลงทะเบียนบัคเก็ตใหม่ด้วยชื่อเดิมได้
    • ส่งผลให้เกิดความเสี่ยงต่อการเข้าถึงข้อมูลสำคัญหรือการหยุดชะงักของบริการ
  • องค์กรมักใช้ กฎการตั้งชื่อที่คาดเดาได้ เช่น myapp-us-east-1 ทำให้มีโอกาสถูกโจมตีสูง
  • แม้แต่ทีมภายใน AWS เองก็ได้รับผลกระทบจากปัญหานี้ และได้ร่วมมือกับทีมความปลอดภัยของ AWS มาราว 10 ปีเพื่อหาวิธีแก้ไข

การเปิดตัวเนมสเปซ S3 แบบใหม่

  • AWS ได้นำแนวคิด เนมสเปซรายบัญชี (account namespace) มาใช้เพื่อแก้ปัญหา
    • รูปแบบ: <prefix>-<accountid>-<region>-an
    • ตัวอย่าง: myapp-123456789012-us-west-2-an
  • เนมสเปซนี้จำกัดให้มีเพียงบัญชีนั้นเท่านั้นที่สามารถสร้างบัคเก็ตด้วยชื่อนี้ได้
    • หากบัญชีอื่นสร้างชื่อเดียวกัน จะเกิดข้อผิดพลาด InvalidBucketNamespace
    • หากรีจันในชื่อบัคเก็ตไม่ตรงกับรีจันจริง ก็จะได้ข้อผิดพลาดเดียวกัน
  • AWS แนะนำอย่างยิ่งให้ใช้เนมสเปซนี้ กับบัคเก็ตใหม่ทั้งหมดเป็นค่าเริ่มต้น
    • ต่างจากเนมสเปซเดิม (.mrap, --x-s3, -s3alias) เพราะครั้งนี้ถูกออกแบบมาเป็น เนมสเปซสำหรับผู้ใช้ทั่วไปเพื่อวัตถุประสงค์ด้านความปลอดภัย

การบังคับใช้นโยบายและการจัดการ

  • ผู้ดูแลความปลอดภัยสามารถใช้คีย์เงื่อนไข s3:x-amz-bucket-namespace เพื่อบังคับใช้การใช้เนมสเปซผ่าน นโยบายระดับองค์กร (SCP) ได้
  • จะไม่ถูกนำไปใช้โดยอัตโนมัติกับบัคเก็ตเดิมหรือเทมเพลตที่ไม่มีเนมสเปซ
    • หากต้องการปกป้องบัคเก็ตเดิม จำเป็นต้องสร้างบัคเก็ตใหม่ตามรูปแบบเนมสเปซใหม่นี้และย้ายข้อมูลไป
  • มาตรการนี้ทำให้ bucketsquatting แทบจะ “หายไป” แล้ว และมอบการปกป้องแบบสมบูรณ์ให้กับบัคเก็ตใหม่

แนวทางของผู้ให้บริการคลาวด์รายอื่น

  • Google Cloud Storage (GCS) ใช้ เนมสเปซแบบตรวจสอบชื่อโดเมน อยู่แล้ว
    • บัคเก็ตที่ใช้รูปแบบโดเมนอย่าง myapp.com สามารถสร้างได้โดยเจ้าของโดเมนเท่านั้น
    • แต่บัคเก็ตที่ไม่ใช่รูปแบบโดเมนก็ยังมีโอกาสเกิด bucketsquatting ได้
  • Azure Blob Storage ใช้โครงสร้างแบบ ชื่อบัญชีสตอเรจ + ชื่อคอนเทนเนอร์
    • ด้วยข้อจำกัดความยาวสูงสุด 24 ตัวอักษร ทำให้เนมสเปซแคบกว่า และอาจเสี่ยงต่อปัญหาเดียวกันมากกว่า

บทสรุป (tl;dr)

  • AWS S3 เปิดตัว เนมสเปซบัญชี-รีจันแบบใหม่
  • เนมสเปซนี้ช่วย ป้องกันการโจมตีแบบ bucketsquatting และแนะนำให้ใช้อย่างยิ่งเมื่อสร้างบัคเก็ตใหม่
  • บัคเก็ตเดิมจะไม่ได้รับการปกป้องโดยอัตโนมัติ ดังนั้นหากจำเป็นควรเสริมการป้องกันด้วย การย้ายข้อมูล

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

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

 
GN⁺ 2026-03-14
ความคิดเห็นจาก Hacker News

  • เมื่อไม่นานมานี้เพิ่งรู้ว่า ไม่สามารถนำอีเมลของผู้ใช้ root กลับมาใช้ซ้ำได้ แม้จะลบบัญชี AWS ไปแล้วก็ตาม
    มีคนในองค์กรของเราสร้างผู้ใช้ root ของบัญชีที่ปิดไปแล้วด้วยอีเมลหลักของบริษัท จากนั้นก็สร้างบัญชีใหม่ด้วยอีเมลอื่น ซึ่งตอนนี้เลยช่วงเวลากู้คืนหลังการลบไปแล้ว
    ผลคืออีเมลนั้นถูกผูกกับบัญชี root ที่ถูกลบอย่างถาวร ทำให้ ไม่สามารถล็อกอินแบบ SSO ผ่าน IdP ภายนอกได้อีก
    ติดต่อทีมซัพพอร์ต AWS แล้ว แต่แทบไม่ได้รับความช่วยเหลือ

    • ช่วงหลังตอนช่วยงานซัพพอร์ตลูกค้า เคยเจอกรณีที่ MFA ของบัญชี root ยังผูกอยู่กับโทรศัพท์ของวิศวกรหลักคนก่อน ที่ลาออกไปแล้ว
      รหัสผ่านมีการบันทึกไว้ในเอกสาร แต่ไม่มีทางปิด MFA ได้ จึงติดต่อทั้ง AWS support และผู้ดูแลบัญชีแล้วก็ยังแก้ไม่ได้
      สุดท้ายเลยยังเข้าใช้บัญชี root ไม่ได้ และอาจต้องย้ายสภาพแวดล้อมที่ซับซ้อนทั้งหมดไปยังบัญชีใหม่
    • ถ้าผู้ให้บริการอีเมลรองรับ ก็สามารถใช้ plus addressing ได้
      AWS มองว่าอีเมลที่มีเครื่องหมายบวกเป็นคนละที่อยู่อีเมลกัน
    • ไม่ควรใช้บัญชี root กับการใช้งานของคนจริง ๆ แต่ควรทำเป็น บัญชีพิเศษสำหรับกรณีฉุกเฉิน และเก็บข้อมูลรับรองไว้ให้ปลอดภัย
      ควรใช้เฉพาะเวลาที่เกิดปัญหาร้ายแรงจริง ๆ เท่านั้น
    • ยิ่งรู้สึกว่าความปลอดภัยนี่เปราะบางแค่ไหน
      สุดท้ายถ้ามีมิจฉาชีพคนไหนหลอกทีมซัพพอร์ตลูกค้าจนได้ คะแนนประเมิน 10/10 ทุกอย่างก็อาจพังได้หมด
    • ถ้าเป็นวิธีที่แมปอีเมลของ IdP เข้ากับ role ก็สงสัยว่าคำว่า “ถูกผูกกับบัญชี root ที่ถูกลบอย่างถาวร” หมายความว่าอย่างไร
      อยากรู้ว่ากลไกไหนที่ทำให้ใช้งานไม่ได้จริง

  • ดูเหมือนผู้เขียนจะเข้าใจแนวคิด account name ของ Azure Blob Storage ผิด
    จริง ๆ แล้วมันอยู่ในระดับเดียวกับชื่อบัคเก็ตของ S3 และต้องไม่ซ้ำกันทั่วโลก จึงยังเป็นความยุ่งยากใหญ่เหมือนเดิม
    โดยเฉพาะที่จำกัดความยาวชื่อไว้ 24 ตัวอักษรยิ่งน่าอึดอัด
    อยากให้ Microsoft เพิ่ม namespace แยกตามลูกค้า แบบเดียวกับ AWS

    • ราว 10 ปีก่อน ทีม S3 ก็รับรู้ปัญหานี้อยู่แล้ว
      แต่เปลี่ยนไม่ได้เพราะข้อจำกัดจากการออกแบบยุคแรก
      ส่วนตัวไม่เข้าใจว่าทำไมถึงยังไม่ทำ S3 v2 API
      ถ้ามี API ใหม่ก็น่าจะค่อย ๆ ย้ายระบบได้ แต่สุดท้ายทั้งลูกค้าและวิศวกรกลับต้องทนกับความเจ็บปวดที่ไม่จำเป็น
    • ตอนใช้ Azure ครั้งแรก พอเห็นว่าทรัพยากรต่าง ๆ ไม่ได้ถูกทำ namespace ตามบัญชี ก็รู้สึกว่าเป็น การออกแบบที่ประหลาด มาก
    • ผู้เขียนตัวจริงเข้ามาคอมเมนต์เองว่าตนได้อัปเดตบทความตามคำติชมแล้ว
    • ข้อจำกัดเรื่องชื่อไม่ได้มีแค่ 24 ตัวอักษร แต่ยัง ห้ามใช้ยัติภังค์ ขีดล่าง และจุด ด้วย
      ทำให้ใช้ได้แค่ตัวเลขกับตัวพิมพ์เล็ก ซึ่งลำบากมาก
      อยากให้อนุญาตอย่างน้อยเครื่องหมายขีดแบบ S3 หรือ GCS
    • การที่ชื่อบัญชีสตอเรจใช้แม้แต่ยัติภังค์ก็ไม่ได้ ถือเป็น การออกแบบที่แย่มาก
      ทรัพยากรอื่นอย่าง container registry ก็เป็นแบบเดียวกัน

  • ชื่อแพ็กเกจ ชื่อบัคเก็ต ชื่อบัญชี GitHub ฯลฯ อาจใช้รูปแบบแบบ Discord คือ @ชื่อ-สุ่ม4หลัก ก็น่าจะดี
    แบบนี้จะทำให้พื้นที่ชื่อเป็นประชาธิปไตยขึ้น และป้องกัน การสควอตหรือการโจมตีจากการนำชื่อกลับมาใช้ซ้ำ ได้
    ถ้าบัญชีถูกลบ ก็ทิ้งชื่อเต็มนั้นไปเลยได้อย่างเรียบร้อย

    • แต่ Discord ยกเลิกรูปแบบนี้ไปเมื่อ 2 ปีก่อน และ เปลี่ยนไปใช้ระบบชื่อที่ต้องไม่ซ้ำกันทั่วโลก
      เหตุผลมีอธิบายไว้ในประกาศอย่างเป็นทางการ ว่า
      ผู้ใช้ลำบากเพราะต้องจำเลข 4 หลัก และยังต้องแยกพิมพ์เล็กพิมพ์ใหญ่อีก
    • ส่วนตัวคิดว่าระบบ UUID + petname ดีกว่า
      โดยเฉพาะในแอปแชต ควรใช้ ID ภายใน ส่วนผู้ใช้ก็ใช้แค่นามแฝง จะดูสะอาดกว่า
      สำหรับบัคเก็ตนั้น ชื่อที่คนอ่านเข้าใจง่ายสำคัญกว่า จึงมองว่าการใช้ โดเมนของตัวเอง น่าจะดีกว่า
    • ใช้กับบัคเก็ตอาจโอเค แต่สำหรับการป้องกัน package hijacking รหัส 4 หลักแทบไม่ช่วยอะไร
      กลับยิ่งเพิ่ม ความเสี่ยงจากการพิมพ์ผิด เสียมากกว่า
    • อยากให้ใช้ ชื่อแบบอิงการยืนยันโดเมน (@example.com) ได้ทุกที่ไปเลย
    • ตอนทำเครื่องมือภายใน ฉันให้ผู้ใช้มี internal ID แบบทึบแสง แล้วให้เปลี่ยนชื่อได้อย่างอิสระ
      ในชุมชนออนไลน์ การมีชื่อซ้ำกันเป็นเรื่องธรรมดาอยู่แล้ว
      เลยสงสัยว่าทำไมต้องบังคับให้ชื่อไม่ซ้ำกันทั่วโลกด้วย

  • ขอบคุณ Ian Mckay ผู้เขียน
    ที่ AWS เพิ่ม namespace ระดับบัญชีและรีเจียน อย่างเป็นทางการถือเป็นการเปลี่ยนแปลงที่ดี
    ถ้าเครื่องมือ IaC อย่าง Terraform นำกฎนี้ไปใช้เป็นค่าเริ่มต้นด้วยจะยิ่งดี
    ตอนนี้ Terraform ก็ใส่ suffix แฮชแบบสุ่ม ท้ายชื่อบัคเก็ตเพื่อเลี่ยงการชนกันอยู่แล้ว
    มีรายละเอียดใน บล็อกทางการของ AWS เช่นกัน

  • การโจมตีแบบ bucket squatting ที่เกิดเมื่อผู้ให้บริการคลาวด์ใช้ ชื่อบัคเก็ตที่คาดเดาได้ เป็นพื้นที่ scratch ภายใน เป็นเรื่องที่น่าสนใจ
    ใน AWS การโจมตีจริงทำได้ยากเพราะมีแฮช แต่ GCP เพิ่งเจอปัญหาแบบนี้ไม่นานมานี้
    ดูเพิ่มเติมได้จาก: DC32 AWS bucket squatting talk,
    ช่องโหว่ GCP: CVE-2026-1727

    • งานพูดนั้นน่าประทับใจมาก
      พอเห็นว่าชื่อบัคเก็ตคาดเดาได้ก็รู้สึกถึงความเสี่ยงทันที
      ถ้าเป็นการผสมกันของ bucket squatting + public bucket + ปัญหา TOCTOU ของ CloudFormation
      ก็อาจเพียงพอที่จะ deploy ทรัพยากรเข้าไปในบัญชีของคนอื่นได้เลย
      น่าแปลกใจที่ทีมความปลอดภัยของ AWS ไม่เจอเรื่องนี้เร็วกว่านี้

  • ชื่อ DNS ก็มีปัญหาคล้ายกัน
    ถ้าไม่ต่ออายุโดเมน ก็จะมีคนมาจดทะเบียนใหม่ได้
    และใครสักคนอาจตั้งค่า MX record เพื่อ ดักอีเมลรีเซ็ตรหัสผ่าน เป็นต้น

    • บางครั้งก็ใช้วิธีนี้เพื่อกู้คืนทรัพย์สินอย่าง legacy IPv4 block ได้เหมือนกัน

  • บัคเก็ตของ AWS ยังให้ฟีเจอร์พิเศษเฉพาะกรณีที่ ชื่อเหมือนกับ hostname เท่านั้น
    เอกสารที่เกี่ยวข้อง: Virtual Hosting in S3

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

  • เคยสงสัยว่าการเปิดเผย account ID จะเสี่ยงด้านความปลอดภัยหรือไม่

    • AWS ระบุอย่างเป็นทางการว่า account ID ไม่ใช่ข้อมูลลับ
      ตามเอกสารทางการ
      ควรจัดการอย่างระมัดระวัง แต่ไม่ถือเป็นข้อมูลอ่อนไหว
    • ในความเห็นส่วนตัว มันเหมือนกับอีเมล คือเป็น ตัวระบุ ไม่ใช่วิธีการยืนยันตัวตน
      ถ้าไม่ได้เปิดเผยพร่ำเพรื่อเกินไปก็ไม่น่ามีปัญหา
    • ในแง่ hygiene อาจไม่ดีนัก แต่ แค่มี account ID อย่างเดียวโจมตีไม่ได้
      เพราะในกฎ IAM ฝั่งผู้โจมตีใช้ * ได้อยู่แล้ว ดังนั้นสิ่งสำคัญจริง ๆ คือการตั้งค่านโยบายของฝั่งป้องกัน
    • ถ้าแชร์ S3 signed URL ก็จะมี Access Key ID รวมอยู่ในนั้น
      และถอด base32 แล้วจะ ดึง Account ID ออกมาได้
      อ้างอิง: บทวิเคราะห์ที่เกี่ยวข้อง

  • การที่ S3 ใช้ ชื่อบัคเก็ตเพียงอย่างเดียวเป็น access key ถือเป็นหนึ่งในการตัดสินใจด้านการออกแบบที่น่าหงุดหงิดที่สุด