Google กลับลำ ปฏิเสธจ่ายรางวัลบั๊กช่องโหว่ร้ายแรงใน Config Connector หลังบอกนักวิจัยว่า 'Nice Catch'

Config Connector คืออะไร และมันพังตรงไหน

Config Connector คือ Kubernetes operator ที่ช่วยให้องค์กรต่างๆ จัดการทรัพยากร GCP เช่น พื้นที่จัดเก็บข้อมูลบนคลาวด์ ฐานข้อมูล และนโยบาย IAM ผ่านคำสั่งของ Kubernetes มันถูกออกแบบมาเพื่อรวมเครื่องมือเข้าด้วยกัน: คุณสามารถสร้าง อัปเดต และลบทรัพยากรคลาวด์ได้โดยใช้ kubectl ซึ่งเป็นเครื่องมือบรรทัดคำสั่งที่คุ้นเคยของ Kubernetes

O'Leary ค้นพบว่าวิธีการแบบรวมศูนย์นี้มาพร้อมกับผลข้างเคียงที่อันตราย ช่องโหว่นี้ทำให้ ผู้ใช้ Kubernetes namespace ใดๆ สามารถหลบเลี่ยงระบบควบคุม Identity and Access Management (IAM) ของ Google Cloud Platform ได้ นักพัฒนาที่มีสิทธิ์เข้าถึงขั้นพื้นฐานเพียงแค่ Kubernetes namespace เดียวสามารถใช้ประโยชน์จากสิ่งนี้เพื่อครอบครอง การควบคุมระดับผู้ดูแลระบบเต็มรูปแบบเหนือสภาพแวดล้อม GCP ทั้งองค์กร ซึ่งเท่ากับเป็นเจ้าของบัญชีคลาวด์ทั้งหมด O'Leary บอกกับ The Register ว่าการโจมตีนี้สามารถทำได้ภายในเวลาประมาณห้าวินาที โดยไม่ทิ้งร่องรอยการตรวจสอบใดๆ

กลไกทางเทคนิค: การยกระดับสิทธิ์ข้าม Namespace

แม้ Google จะไม่ได้เผยแพร่คำอธิบายทางเทคนิคโดยละเอียด แต่จากหลายแหล่งและรายงานของ O'Leary ระบุว่าช่องโหว่อยู่ที่การจัดการสิทธิ์ IAM ของ Config Connector ใน Kubernetes namespaces ต่างๆ

ในคลัสเตอร์ GKE แบบหลายผู้เช่า (multi-tenant) ที่กำหนดค่าอย่างถูกต้อง namespaces ที่แตกต่างกันควรถูกแยกออกจากกัน ผู้ใช้ใน namespace A ไม่ควรสามารถจัดการทรัพยากรใน namespace B หรือมอบสิทธิ์ GCP ที่สูงกว่าให้กับตนเองได้ การค้นพบของ O'Leary แสดงให้เห็นว่า ทรัพยากรประเภท IAM ของ Config Connector ไม่ได้บังคับใช้ขอบเขตระหว่าง namespace เหล่านี้ ด้วยการสร้างหรือแก้ไขทรัพยากรนโยบาย IAM ผ่าน Config Connector จากภายใน namespace เดียว ผู้ใช้ที่มีสิทธิ์ Kubernetes เพียงเล็กน้อยสามารถมอบสิทธิ์ roles/owner ให้กับตนเองในโปรเจ็กต์ GCP หรือทั้งองค์กรได้

นี่คือการละเมิดหลักการของสิทธิ์น้อยที่สุด (principle of least privilege) และเป็นการ bypass ชั้นการอนุญาต IAM ของ GCP โดยตรง มันไม่ใช่การกำหนดค่าที่ผิดพลาดที่ผู้ดูแลระบบสามารถแก้ไขได้ แต่มันคือข้อบกพร่องในระดับการออกแบบของวิธีการที่ Config Connector มอบหมายอำนาจ IAM

เส้นเวลา: จาก 'Nice Catch!' สู่ 'ที่ตั้งใจให้เป็น'

ตามรายงานพิเศษของ The Register เมื่อวันที่ 18 มิถุนายน 2026 และแหล่งข้อมูลอื่นๆ เส้นเวลาเป็นดังนี้:

• ปลายเดือนมีนาคม / ต้นเดือนเมษายน 2026 (โดยประมาณ): O'Leary ค้นพบช่องโหว่และส่งรายงานโดยละเอียดไปยัง Cloud Vulnerability Reward Program (Cloud VRP) ของ Google รายงานดังกล่าวรวมถึงหลักฐานแนวคิด (proof of concept) ที่แสดงให้เห็นว่าผู้โจมตีสามารถยกระดับจากผู้ใช้ namespace ไปเป็นเจ้าขององค์กร GCP ได้อย่างไร
• การตรวจสอบเบื้องต้น: ทีม Bug Bounty ของ Google ตรวจสอบรายงาน จัดหมวดหมู่เป็นช่องโหว่ที่มีลำดับความสำคัญสูงและความรุนแรงสูง และตัวแทนของ Google ได้ตอบกลับเป็นการส่วนตัวด้วยคำว่า 'Nice catch!'
• ~พฤษภาคม/มิถุนายน 2026: โดยไม่ออกแพตช์แก้ไข Google กลับคำตัดสิน บริษัทปิดรายงาน โดยประกาศว่าพฤติกรรมดังกล่าว 'เป็นไปตามที่ตั้งใจ' ('working as intended') ซึ่งหมายความว่าไม่เข้าข่ายเป็นช่องโหว่ภายใต้กฎของ Cloud VRP และไม่มีการจ่ายรางวัลใดๆ
• ณ วันที่ 18 มิถุนายน 2026: ช่องโหว่ยังคงไม่ได้รับการแก้ไข อย่างไรก็ตาม รายงานบั๊กของ O'Leary ยังคงถูกทำเครื่องหมายว่า 'ลำดับความสำคัญสูง' และ 'ได้รับการยอมรับ' ในระบบติดตามของ Google ซึ่งเป็นความขัดแย้งที่เห็นได้ชัด เคสดังกล่าวเปิดค้างไว้เกือบสามเดือนแล้ว

ทำไม Google ถึงปฏิเสธรางวัล?

Google ยังไม่ได้อธิบายต่อสาธารณะถึงการกลับคำตัดสินนี้ แต่มีหลายปัจจัยที่อาจมีส่วนเกี่ยวข้อง โดยพิจารณาจากกฎของ Cloud VRP และบริบทที่กว้างขึ้นของการเปลี่ยนแปลงโปรแกรมของ Google ในปี 2026

กฎอย่างเป็นทางการของ Cloud VRP ระบุว่า: 'รายงานช่องโหว่ของ Google Cloud ที่ทดสอบกับทรัพยากรที่เป็นของลูกค้านั้นไม่มีสิทธิ์ได้รับรางวัล' ขอบเขตของโปรแกรมจำกัดไว้อย่างชัดเจนที่ช่องโหว่ในโครงสร้างพื้นฐานและบริการที่เป็นของ Google ไม่ใช่ในส่วนประกอบที่ลูกค้าสามารถกำหนดค่าได้ หาก Google ถือว่าพฤติกรรมของ Config Connector เป็นเรื่องของการกำหนดค่าของลูกค้ามากกว่าช่องโหว่ของผลิตภัณฑ์ ในทางเทคนิคแล้ว Google สามารถปฏิเสธรางวัลภายใต้ภาษานี้ได้ แม้ว่าพฤติกรรมดังกล่าวจะ bypass การควบคุม IAM ที่คาดหวังไว้ก็ตาม

ความเป็นไปได้อีกประการหนึ่ง: กฎของ Cloud VRP ระบุว่าโปรแกรมครอบคลุม 'ข้อบกพร่องด้านการตรวจสอบสิทธิ์หรือการอนุญาต' ในรายการที่อยู่ในขอบเขต ซึ่งควรครอบคลุมถึงสิ่งที่ O'Leary ค้นพบ แต่ Google เคยโต้แย้งในบริบทอื่นๆ ว่าการยกระดับสิทธิ์บางอย่างไม่ใช่บั๊ก หากต้องใช้สิทธิ์เฉพาะในการกระตุ้นให้เกิด ซึ่งเป็นจุดยืนที่ถูกวิพากษ์วิจารณ์จากนักวิจัย ในกรณีของ O'Leary สิทธิ์เริ่มต้นที่จำเป็น (การเข้าถึงทรัพยากร Config Connector ระดับ namespace) มีเพียงเล็กน้อยและมักจะมอบให้กับนักพัฒนา ทำให้การยกระดับสิทธิ์นั้นทั้งเป็นจริงและอันตราย

ปัจจัยที่สามเกี่ยวข้องกับการ ยกเครื่อง Vulnerability Reward Program ปี 2026 ของ Google สำหรับ Chrome และ Android ในช่วงปลายเดือนเมษายนและต้นเดือนพฤษภาคม 2026 Google ประกาศว่าจะลดการจ่ายเงินสำหรับ Chrome และปรับโครงสร้างรางวัล โดยอ้างถึงรายงานคุณภาพต่ำที่สร้างโดย AI จำนวนมากที่เพิ่มขึ้น บริษัทระบุว่ากำลัง 'ลดจำนวนรางวัลและโบนัสบางส่วนใน Android และ Chrome' เพื่อมุ่งเน้นที่ 'คุณภาพและผลกระทบในโลกแห่งความเป็นจริงมากกว่าปริมาณ' แม้ว่ากรณีของ O'Leary จะอยู่ภายใต้ Cloud VRP ที่แยกต่างหาก ไม่ใช่โปรแกรม Chrome หรือ Android แต่จุดยืนของบริษัทในการรัดเข็มขัดการจ่ายเงินอาจมีอิทธิพลต่อการตัดสินใจ โดยเฉพาะอย่างยิ่งหาก Google มองว่าปัญหา Config Connector เป็นตัวเลือกในการออกแบบมากกว่าบั๊ก

กระแสตีกลับจากนักวิจัยที่เพิ่มขึ้น

เหตุการณ์นี้จุดชนวนให้เกิดการวิพากษ์วิจารณ์จากชุมชนนักวิจัยด้านความปลอดภัย โดยบางคนโต้แย้งว่า Google ใช้คำบรรยายเรื่องการส่งรายงานโดย AI เป็นข้ออ้างในการปฏิเสธช่องโหว่ที่ถูกค้นพบด้วยตนเองอย่างถูกต้องตามกฎหมาย บทวิจารณ์ของ PC Perspective เรียกการตัดสินใจนี้ว่า 'ขี้เหนียวกับ Bug Bounties' และชี้ให้เห็นถึงความแตกต่างระหว่างคำชมในตอนแรกของ Google กับการปฏิเสธในท้ายที่สุด Cyber News Live เน้นย้ำว่าช่องโหว่นี้อาจทำให้เกิดการยึดระบบได้ภายในห้าวินาทีโดยไม่ทิ้งร่องรอยใดๆ

กรณีนี้ยังเกิดขึ้นในช่วงเวลาเดียวกับที่ Google เพิ่มรางวัลสูงสุด สำหรับบั๊ก Android บางประเภทพร้อมกัน โดยสูงถึง 1.5 ล้านดอลลาร์สหรัฐสำหรับการโจมตีแบบ zero-click ที่เจาะจง Titan M แนวทางสองมาตรฐานนี้ การให้รางวัลกับการหาช่องโหว่ระดับฮาร์ดแวร์อย่างงาม ในขณะที่ปฏิเสธแม้กระทั่งการยอมรับสำหรับการ bypass IAM บนคลาวด์ที่รุนแรง ได้เติมเต็มการรับรู้ว่าโปรแกรม Bug Bounty ของ Google กำลังจัดสรรงบประมาณอย่างมีกลยุทธ์มากกว่าการประเมินความเสี่ยงอย่างตรงไปตรงมา

สิ่งนีหมายถึงอะไรสำหรับองค์กรที่ใช้ Config Connector

องค์กรที่ใช้งาน Config Connector ในคลัสเตอร์ GKE แบบหลายผู้เช่าหรือแบบ shared ควรมองว่านี่เป็นความเสี่ยงเร่งด่วนที่ยังไม่ได้รับการแก้ไข หากไม่มีแพตช์อย่างเป็นทางการจาก Google มาตรการบรรเทาผลกระทบต่อไปนี้สามารถลดความเสี่ยงได้:

• จำกัดการสร้างทรัพยากร iam* ในระดับ namespace โดยใช้นโยบาย RBAC ของ Kubernetes อย่าให้สิทธิ์ create, update หรือ Delete สำหรับทรัพยากรที่กำหนดเอง IAMPolicy, IAMPolicyMember หรือ IAMPartialPolicy แก่ namespaces ที่ไม่น่าเชื่อถือ
• ใช้ Config Connector แบบ Namespace-mode พร้อมกับบัญชีบริการ (service account) ที่มีสิทธิ์ต่ำแยกกันในแต่ละ namespace เอกสารของ Google รองรับการกำหนดค่านี้ซึ่งช่วยจำกัดขอบเขตความเสียหาย
• ตรวจสอบการเปลี่ยนแปลง IAM ของ GCP ที่มาจาก Config Connector เปิดใช้งานบันทึกการตรวจสอบ (audit logs) และตั้งค่าการแจ้งเตือนสำหรับการเรียก setIamPolicy ใดๆ ที่มาจากคลัสเตอร์ GKE ของคุณ
• พิจารณาปิดการใช้งาน Config Connector ในสภาพแวดล้อมที่ต้องการการแยกผู้เช่าหลายราย จนกว่า Google จะแก้ไขช่องโหว่

เอกสารอย่างเป็นทางการของ Google เกี่ยวกับการรักษาความปลอดภัยการเข้าถึงทรัพยากรด้วย IAM อธิบายถึงการกำหนดค่าที่แนะนำ แต่ไม่ได้กล่าวถึง vector การ bypass ข้าม namespace ซึ่งเป็นหัวใจของรายงานของ O'Leary องค์กรต่างๆ ควรถือว่าการปรับใช้ Config Connector ของตนอาจมีความเสี่ยง

ประเด็นสำคัญ

• ช่องโหว่การยกระดับสิทธิ์ใน Config Connector ของ Google (CVSS 10.0) ทำให้ผู้ใช้ Kubernetes namespace ใดๆ ก็สามารถครอบครองโปรเจ็กต์ GCP ได้อย่างสมบูรณ์
• ทีม Bug Bounty ของ Google ยอมรับรายงานเบื้องต้นว่าเป็นลำดับความสำคัญสูง จากนั้นกลับลำ ประกาศว่า 'ตั้งใจให้เป็นแบบนี้' และปฏิเสธรางวัล
• เกือบสามเดือนหลังจากรายงานครั้งแรก ช่องโหว่ยังไม่ได้รับการแก้ไข และไม่มีกำหนดการแก้ไขจาก Google
• เหตุการณ์นี้เกิดขึ้นท่ามกลางการเปลี่ยนแปลงโปรแกรมปี 2026 ในวงกว้างของ Google ซึ่งลดการจ่ายเงินสำหรับ Chrome ในขณะที่เพิ่มรางวัลสำหรับ Android ทำให้ความสัมพันธ์ของบริษัทกับนักวิจัยด้านความปลอดภัยซับซ้อนยิ่งขึ้น