- นักวิจัยด้านความปลอดภัยพบว่าสามารถเข้าถึงข้อมูลอ่อนไหวของนักขับ F1 ได้ผ่าน ช่องโหว่ในเว็บไซต์จัดประเภทนักขับของ FIA
- ระบบดังกล่าวทำงานแยกจาก FIA Super Licence และเป็นพอร์ทัลที่ให้นักขับยื่นขอหรือขอต่ออายุระดับของตนเอง (Bronze/Silver/Gold/Platinum)
- นักวิจัยใช้ ช่องโหว่ mass assignment ในคำขอ HTTP PUT เพื่อยกระดับสิทธิ์เป็นผู้ดูแลระบบและเข้าถึงแดชบอร์ดภายใน
- ด้วยวิธีนี้ พวกเขาสามารถดูข้อมูลของนักขับทั้งหมดได้ รวมถึง หนังสือเดินทาง, อีเมล, หมายเลขโทรศัพท์, password hash, เรซูเม่ และ PII
- กรณีนี้เป็นตัวอย่างสำคัญที่แสดงให้เห็นว่า ความสำคัญของการจัดการความปลอดภัยเพิ่มสูงขึ้นตามการเปลี่ยนผ่านสู่ดิจิทัลของอุตสาหกรรมกีฬา
พื้นหลัง: จุดตัดระหว่าง F1 และความมั่นคงปลอดภัยไซเบอร์
- ในช่วงไม่กี่ปีที่ผ่านมา จากการเพิ่มขึ้นของ สตาร์ทอัพด้านความปลอดภัยและการลงทุนจากเวนเจอร์แคปิทัล ทำให้อีเวนต์ด้านเครือข่ายสำคัญมีแนวโน้มจัดขึ้นโดยมี F1 Grand Prix เป็นศูนย์กลาง
- CrowdStrike, Darktrace และรายอื่น ๆ ลงทุนหลายล้านดอลลาร์ในฐานะผู้สนับสนุนทีม
- Bitdefender ทำข้อตกลง ความร่วมมือด้านไซเบอร์ซีเคียวริตี้ อย่างเป็นทางการเพื่อดูแลความปลอดภัยให้ทีมแข่ง
- นักวิจัย Gal Nagli, Sam Curry และ Ian Carroll เข้าร่วมงานลักษณะนี้และพยายาม ค้นหาช่องโหว่ด้านความปลอดภัยในเว็บไซต์สนับสนุนที่เกี่ยวข้องกับ F1
- บล็อกนี้เป็น ตอนแรกของซีรีส์ 3 ตอน และกล่าวถึงช่องโหว่แรกที่พบในระบบที่เกี่ยวข้องกับ F1
ภาพรวมของระบบจัดประเภทนักขับของ FIA
- นักขับ F1 ต้องมี FIA Super Licence ซึ่งออกให้ทุกปีผ่านสมาคมมอเตอร์สปอร์ตของแต่ละประเทศ (ASN)
- ต้องผ่านข้อกำหนดด้าน คะแนน, อายุ, การตรวจทางการแพทย์ และการสอบข้อเขียน ตามที่กำหนด
- FIA ยังมี ระบบ Driver Categorisation (drivercategorisation.fia.com) แยกต่างหากเพื่อจัดการระดับของนักขับ (Bronze~Platinum)
- พอร์ทัลนี้รองรับ การลงทะเบียนด้วยตนเองแบบสาธารณะ และผู้สมัครต้องอัปโหลดใบสมัครระดับของตนพร้อม เอกสารยืนยันตัวตนและประวัติอาชีพ
- ผู้ถือ Super Licence จะได้รับระดับ Platinum โดยอัตโนมัติ
กระบวนการค้นพบช่องโหว่
- หลังจากสร้างบัญชีแล้ว นักวิจัยสังเกต คำขอ HTTP PUT ที่ใช้แก้ไขโปรไฟล์
- ตัวคำขอเองเรียบง่าย แต่ใน JSON ตอบกลับมี ฟิลด์เพิ่มเติม เช่น roles, birthDate, status รวมอยู่ด้วย
- จากการวิเคราะห์โค้ด JavaScript พวกเขาพบว่าเว็บไซต์มีหลายบทบาท เช่น นักขับ, เจ้าหน้าที่ FIA, ผู้ดูแลระบบ (admin)
- นักวิจัยจึงทดลองส่งคำขอ PUT ที่มีบทบาทผู้ดูแลระบบรวมอยู่ด้วย เพื่อทดสอบว่า ฟิลด์ roles สามารถถูกอัปเดตได้โดยไม่มีการตรวจสอบฝั่งเซิร์ฟเวอร์หรือไม่
การได้สิทธิ์ผู้ดูแลระบบ
- ตัวอย่างคำขอมีดังนี้
"roles": [{"id": 1, "description": "ADMIN role", "name": "ADMIN"}]
- เซิร์ฟเวอร์ประมวลผลคำขอดังกล่าวตามปกติ และใน JSON ตอบกลับก็แสดงว่า ได้รับบทบาท ADMIN แล้ว
- เมื่อล็อกอินใหม่หลังการยืนยันตัวตนอีกครั้ง ก็พบว่า แดชบอร์ดสำหรับผู้ดูแลระบบของ FIA ปรากฏขึ้น และสามารถเข้าถึง ฟังก์ชันฝั่งเซิร์ฟเวอร์ทั้งหมด เช่น การจัดประเภทนักขับ การจัดการพนักงาน และการแก้ไขเทมเพลตอีเมล
ความเป็นไปได้ในการเข้าถึงข้อมูลอ่อนไหว
- เมื่อเปิดดูโปรไฟล์นักขับด้วยสิทธิ์ผู้ดูแลระบบ พบว่ามีการเปิดเผยข้อมูลดังต่อไปนี้
- password hash, อีเมล, หมายเลขโทรศัพท์, สำเนาหนังสือเดินทาง, เรซูเม่ และข้อมูลระบุตัวตนส่วนบุคคล (PII)
- ความเห็นภายในเกี่ยวกับการประเมินนักขับ และบันทึกการตัดสินใจของคณะกรรมการ
- นักวิจัยระบุว่า ระหว่างการทดสอบ พวกเขายืนยันได้ว่าสามารถเข้าถึง หนังสือเดินทาง ใบอนุญาต และ PII ของ Max Verstappen ได้ แต่ไม่ได้เปิดดูหรือบันทึกข้อมูลจริง
- ข้อมูลทดสอบทั้งหมดถูก ลบทันที และยุติการทดสอบเพิ่มเติม
การเปิดเผยช่องโหว่และการตอบสนอง
- 3 มิถุนายน 2025: แจ้ง FIA ครั้งแรกทางอีเมลและ LinkedIn
- วันเดียวกันนั้น FIA ได้ นำเว็บไซต์ออฟไลน์
- 10 มิถุนายน 2025: FIA แจ้งอย่างเป็นทางการว่า แก้ไขครบถ้วนแล้ว
- 22 ตุลาคม 2025: เผยแพร่บล็อกและ รายงานสู่สาธารณะ
ข้อสังเกต
- เป็นกรณีที่แสดงให้เห็นว่า ช่องโหว่ mass assignment ที่ดูเรียบง่าย ก็สามารถเกิดขึ้นได้แม้ในระบบที่ต้องการความปลอดภัยสูง
- เมื่ออุตสาหกรรมกีฬาเร่งเปลี่ยนผ่านสู่ดิจิทัล ความจำเป็นในการ คุ้มครองข้อมูลส่วนบุคคลและเสริมความแข็งแกร่งของการควบคุมสิทธิ์เข้าถึง ก็ยิ่งเพิ่มขึ้น
- โดยเฉพาะองค์กรนานาชาติอย่าง FIA จำเป็นต้องมีการตรวจสอบความปลอดภัยเป็นประจำต่อ การออกแบบ API และตรรกะการตรวจสอบสิทธิ์ อย่างต่อเนื่อง
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
นี่ไม่ใช่แค่ช่องโหว่จุดเดียว แต่เป็นการรวมกันของ ความล้มเหลวด้านความปลอดภัยหลายอย่าง
ตัวอย่างเช่น การเก็บเอกสารของผู้สมัครไว้บนระบบโปรดักชันต่อไปแม้จะบรรลุวัตถุประสงค์แล้ว เป็นสิ่งที่ไม่จำเป็นเลย
เรื่องแบบนี้ยังขัดกับหลักการลด blast radius (ขอบเขตความเสียหาย) ให้เหลือน้อยที่สุดด้วย
ระดับนี้ควรได้ตั๋วเข้าชมฟรีตลอดชีพด้วยซ้ำ
ทันทีที่กฎนี้พัง กฎอื่นทั้งหมดก็เป็นแค่เรื่องของเวลาก่อนจะพังตาม
Ian ถ้าเพิ่ม RSS feed ในเว็บไซต์ น่าจะช่วยเพิ่มผู้อ่านประจำได้อีก
น่าทึ่งที่วันเดียวกับที่มีการแจ้งเรื่อง ก็ ปิดเว็บไซต์ออฟไลน์ทันที
ความเร็วในการตอบสนองแบบนี้หาได้ยาก
สำหรับบริษัทขนาดนี้ ถือว่าไม่ค่อยเห็นบ่อยนักที่จะขยับตัวเร็วขนาดนี้
นี่มันเป็น ระดับความปลอดภัยที่แย่จนน่าอับอาย จริง ๆ
แต่พอเห็นอะไรแบบนี้ก็รู้สึกว่า imposter syndrome ของตัวเองเบาลงนิดหน่อย
ในสถานการณ์แบบนี้ก็อดเสียดายไม่ได้ว่า น่าจะให้ผู้เขียนได้ F1 Super License แล้วให้ขับรถเองไปเลย
สงสัยว่าเคยโดนขู่ทางกฎหมายจากการทำ การสำรวจด้านความปลอดภัย แบบนี้ไหม
แล้วในที่ที่ไม่มีโปรแกรม bug bounty เคยได้รับข้อเสนอค่าตอบแทนบ้างหรือเปล่า
ในวงการนี้มีคนที่ทั้งฝีมือไม่ถึงและไม่รับผิดชอบอยู่เยอะ
สำหรับคนแบบนั้น การแจ้งปัญหาความปลอดภัยคือ ‘งานน่ารำคาญ’ ที่โผล่เข้ามา ทำให้มีแรงจูงใจที่จะโทษผู้แจ้งหรือดำเนินคดีเพื่อปัดความรับผิดชอบ
เพราะแบบนี้ การ ทำงานแบบไม่เปิดเผยตัวตน จึงปลอดภัยที่สุด แล้วถ้าอยากเปิดเผยตัวตนทีหลังก็ค่อยทำได้
วิศวกรไอทีคนหนึ่งพบรหัสผ่านและรายงานว่าสามารถเข้าถึง phpMyAdmin ได้ แต่บริษัทกลับฟ้องเขา และ บริษัทชนะคดีไปถึงศาลสูงสุด
บทความที่เกี่ยวข้อง (Heise)
โดยปกติเรื่องแบบนี้จะอนุญาตได้ก็ต่อเมื่ออยู่ภายใต้การ ทดสอบ red team หรือ สัญญาทดสอบเจาะระบบ อย่างเป็นทางการเท่านั้น
การมาอ้างภายหลังว่า “ทำไปอย่างมีจริยธรรม” นั้นไม่เพียงพอ
ข้อเสนอแบบนี้ต้องปฏิเสธให้เด็ดขาด
หลังจากนั้น 8 ปีก็ไม่เคยเจอแบบนั้นอีกเลย
ทุกวันนี้บรรยากาศก็ดูเหมือนบริษัทต่าง ๆ จะเข้าใจการกระทำแบบนี้มากขึ้นกว่าเมื่อก่อน
วิธีแฮ็กที่ฉันชอบที่สุดคือ อ่าน JS แล้วแก้ไขคำขอ PUT
ได้ผลบ่อยกว่าที่คิด
บริษัทเก่าก็มาพร้อมกับความปลอดภัยแบบเก่า ๆ
RD ทำได้ดีมาก แต่ก็ไม่ได้ทำให้แปลกใจเลย
แทบมั่นใจได้เลยว่าแฮชน่าจะเป็น MD5
ชวนให้นึกถึง xkcd 1428
สิ่งที่แปลกคือ คนดูแลเว็บไซต์คือ Ian Carroll แต่ในตัวอย่างกลับมีนักล่า bug bounty ชื่อดัง Sam Curry โผล่มา