1 คะแนน โดย GN⁺ 2025-10-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักวิจัยด้านความปลอดภัยพบว่าสามารถเข้าถึงข้อมูลอ่อนไหวของนักขับ 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 ความคิดเห็น

 
GN⁺ 2025-10-23
ความคิดเห็นใน Hacker News
  • นี่ไม่ใช่แค่ช่องโหว่จุดเดียว แต่เป็นการรวมกันของ ความล้มเหลวด้านความปลอดภัยหลายอย่าง
    ตัวอย่างเช่น การเก็บเอกสารของผู้สมัครไว้บนระบบโปรดักชันต่อไปแม้จะบรรลุวัตถุประสงค์แล้ว เป็นสิ่งที่ไม่จำเป็นเลย
    เรื่องแบบนี้ยังขัดกับหลักการลด blast radius (ขอบเขตความเสียหาย) ให้เหลือน้อยที่สุดด้วย
    ระดับนี้ควรได้ตั๋วเข้าชมฟรีตลอดชีพด้วยซ้ำ

    • กฎข้อ 1: อย่าเชื่อถือข้อมูลที่ผู้ใช้ป้อนเข้ามาเด็ดขาด
      ทันทีที่กฎนี้พัง กฎอื่นทั้งหมดก็เป็นแค่เรื่องของเวลาก่อนจะพังตาม
  • Ian ถ้าเพิ่ม RSS feed ในเว็บไซต์ น่าจะช่วยเพิ่มผู้อ่านประจำได้อีก

    • Ian เป็นคนที่ เขียนเก่งมาก จริง ๆ
    • ฉันก็เห็นด้วยกับความเห็นนี้
  • น่าทึ่งที่วันเดียวกับที่มีการแจ้งเรื่อง ก็ ปิดเว็บไซต์ออฟไลน์ทันที
    ความเร็วในการตอบสนองแบบนี้หาได้ยาก

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

    • จะเรียกว่านี่คือระบบความปลอดภัยก็ยังรู้สึกกระดาก มันเปิดโล่งแทบทั้งหมดเลย
      แต่พอเห็นอะไรแบบนี้ก็รู้สึกว่า imposter syndrome ของตัวเองเบาลงนิดหน่อย
    • ถ้าได้เห็นวิดีโองานปาร์ตี้ด้วยจะยิ่งอึ้งกว่าเดิม
  • ในสถานการณ์แบบนี้ก็อดเสียดายไม่ได้ว่า น่าจะให้ผู้เขียนได้ F1 Super License แล้วให้ขับรถเองไปเลย

    • ถ้ามันจบแค่นั้นก็คงดีแค่ไหน
  • สงสัยว่าเคยโดนขู่ทางกฎหมายจากการทำ การสำรวจด้านความปลอดภัย แบบนี้ไหม
    แล้วในที่ที่ไม่มีโปรแกรม bug bounty เคยได้รับข้อเสนอค่าตอบแทนบ้างหรือเปล่า

    • การกระทำแบบนี้ อาจมีความเสี่ยงทางกฎหมาย
      ในวงการนี้มีคนที่ทั้งฝีมือไม่ถึงและไม่รับผิดชอบอยู่เยอะ
      สำหรับคนแบบนั้น การแจ้งปัญหาความปลอดภัยคือ ‘งานน่ารำคาญ’ ที่โผล่เข้ามา ทำให้มีแรงจูงใจที่จะโทษผู้แจ้งหรือดำเนินคดีเพื่อปัดความรับผิดชอบ
      เพราะแบบนี้ การ ทำงานแบบไม่เปิดเผยตัวตน จึงปลอดภัยที่สุด แล้วถ้าอยากเปิดเผยตัวตนทีหลังก็ค่อยทำได้
    • คดี “Modern Solution” ของเยอรมนีเป็นตัวอย่างที่ชัดเจน
      วิศวกรไอทีคนหนึ่งพบรหัสผ่านและรายงานว่าสามารถเข้าถึง phpMyAdmin ได้ แต่บริษัทกลับฟ้องเขา และ บริษัทชนะคดีไปถึงศาลสูงสุด
      บทความที่เกี่ยวข้อง (Heise)
    • อย่างที่อธิบายในบล็อก การ พยายามยกระดับสิทธิ์เป็นแอดมิน นั้นอยู่ในพื้นที่สีเทาทางกฎหมาย
      โดยปกติเรื่องแบบนี้จะอนุญาตได้ก็ต่อเมื่ออยู่ภายใต้การ ทดสอบ red team หรือ สัญญาทดสอบเจาะระบบ อย่างเป็นทางการเท่านั้น
      การมาอ้างภายหลังว่า “ทำไปอย่างมีจริยธรรม” นั้นไม่เพียงพอ
    • การขู่ทางกฎหมายจริง ๆ ไม่ได้เกิดบ่อย แต่บางบริษัทก็เสนอสินบนในชื่อ ‘bug bounty ย้อนหลัง’
      ข้อเสนอแบบนี้ต้องปฏิเสธให้เด็ดขาด
    • ตอนเรียนมหาวิทยาลัยเคยแจ้งช่องโหว่ให้บริษัทหนึ่ง แล้วบริษัทนั้นขู่จะดำเนินคดี แต่พออาจารย์ออกมาคัดค้านอย่างหนักก็ถอนเรื่องไป
      หลังจากนั้น 8 ปีก็ไม่เคยเจอแบบนั้นอีกเลย
      ทุกวันนี้บรรยากาศก็ดูเหมือนบริษัทต่าง ๆ จะเข้าใจการกระทำแบบนี้มากขึ้นกว่าเมื่อก่อน
  • วิธีแฮ็กที่ฉันชอบที่สุดคือ อ่าน JS แล้วแก้ไขคำขอ PUT
    ได้ผลบ่อยกว่าที่คิด

  • บริษัทเก่าก็มาพร้อมกับความปลอดภัยแบบเก่า ๆ
    RD ทำได้ดีมาก แต่ก็ไม่ได้ทำให้แปลกใจเลย
    แทบมั่นใจได้เลยว่าแฮชน่าจะเป็น MD5

    • อยากรู้เหมือนกันว่าใช้แฮชอัลกอริทึมอะไร
    • ถ้าเป็นเว็บไซต์ F1 วลี “move fast and break things” ก็ดูเข้ากันดี
      ชวนให้นึกถึง xkcd 1428
  • สิ่งที่แปลกคือ คนดูแลเว็บไซต์คือ Ian Carroll แต่ในตัวอย่างกลับมีนักล่า bug bounty ชื่อดัง Sam Curry โผล่มา

    • ตามโพสต์ระบุว่า Gal Nagli, Sam Curry, Ian ตกลงกันว่าจะลองแฮ็กเว็บไซต์ที่เกี่ยวกับ F1 ด้วยกัน
    • ถ้าไปดูโพสต์อื่น ๆ ของ Ian จะเห็นว่าพวกเขามักจะ ร่วมงานกัน บ่อย