FIA बग के जरिए Max Verstappen के पासपोर्ट और व्यक्तिगत पहचान जानकारी तक पहुंच का मामला

• सुरक्षा शोधकर्ताओं ने पाया कि FIA की driver categorisation वेबसाइट की एक vulnerability के जरिए F1 ड्राइवरों की संवेदनशील जानकारी तक पहुंचा जा सकता था
• यह सिस्टम FIA Super Licence से अलग संचालित होता है और एक ऐसा पोर्टल है जहां ड्राइवर अपनी श्रेणी (Bronze/Silver/Gold/Platinum) के लिए आवेदन या नवीनीकरण कर सकते हैं
• शोधकर्ताओं ने HTTP PUT request में mass assignment vulnerability का उपयोग करके admin privileges हासिल किए और internal dashboard तक पहुंच गए
• इसके जरिए वे पासपोर्ट, ईमेल, फोन नंबर, password hash, CV सहित PII वाले सभी ड्राइवरों के डेटा को देख सकते थे
• यह मामला दिखाता है कि sports industry के digitisation के साथ security management का महत्व कितना बढ़ गया है

---

पृष्ठभूमि: F1 और साइबरसुरक्षा का संगम

• पिछले कुछ वर्षों में security startup और venture capital निवेश में वृद्धि के कारण बड़े networking event अब F1 Grand Prix के केंद्र में आयोजित होने की प्रवृत्ति दिखा रहे हैं
  • CrowdStrike, Darktrace आदि ने team sponsor के रूप में लाखों डॉलर निवेश किए हैं
  • Bitdefender ने आधिकारिक cybersecurity partnership करके racing team की security संभाली
• शोधकर्ता Gal Nagli, Sam Curry, Ian Carroll ने ऐसे आयोजनों में भाग लेते हुए F1-संबंधित support websites की security weaknesses तलाशने की कोशिश की
• यह ब्लॉग तीन-भाग वाली श्रृंखला का पहला भाग है और F1-संबंधित सिस्टम में मिली पहली vulnerability पर केंद्रित है

FIA driver categorisation system का अवलोकन

• F1 ड्राइवरों के पास FIA Super Licence होना चाहिए, जो हर साल प्रत्येक देश की motorsport association (ASN) के जरिए जारी किया जाता है
  • इसके लिए निर्धारित points, age, medical और written test requirements पूरी करनी होती हैं
• FIA अलग से Driver Categorisation system (drivercategorisation.fia.com) चलाता है, जो ड्राइवर की श्रेणी (Bronze से Platinum) का प्रबंधन करता है
  • यह पोर्टल public self-registration को support करता है, और प्रतिभागियों को अपनी श्रेणी आवेदन के साथ ID documents, career CV आदि upload करने होते हैं
  • Super Licence धारकों को अपने आप Platinum श्रेणी दी जाती है

vulnerability की खोज की प्रक्रिया

• शोधकर्ताओं ने account बनाने के बाद profile edit करने वाली HTTP PUT request को observe किया
  • request अपने आप में साधारण थी, लेकिन response JSON में roles, birthDate, status जैसे अतिरिक्त fields शामिल थे
• JavaScript code का विश्लेषण करने पर पता चला कि साइट में driver, FIA staff, admin जैसी कई roles मौजूद हैं
• शोधकर्ताओं ने यह जांचने के लिए कि roles field को बिना server-side validation के update किया जा सकता है या नहीं, admin role शामिल करके PUT request भेजी

admin privileges हासिल करना

• request का उदाहरण इस प्रकार था
  • "roles": [{"id": 1, "description": "ADMIN role", "name": "ADMIN"}]
• server ने इसे सामान्य रूप से process किया और response JSON में ADMIN role assigned स्थिति लौटाई
• दोबारा authentication के बाद login करने पर FIA admin dashboard दिखाई दिया, और driver categorisation, staff management, email template editing सहित पूरी server-side functionality तक पहुंच संभव हो गई

संवेदनशील जानकारी तक पहुंच की संभावना

• admin privileges से driver profile खोलने पर निम्न जानकारी उजागर हुई
  • password hash, email, phone number, passport copy, CV, personally identifiable information (PII)
  • driver evaluation से जुड़े internal comments और committee decision records
• शोधकर्ताओं ने परीक्षण के दौरान पुष्टि की कि Max Verstappen के पासपोर्ट, licence और PII तक पहुंच संभव थी, लेकिन उन्होंने स्पष्ट किया कि वास्तव में उन्हें देखा या save नहीं किया गया
• सभी test data को तुरंत delete कर दिया गया और आगे की घुसपैठ रोक दी गई

vulnerability disclosure और response

• 3 जून 2025: FIA को email और LinkedIn के जरिए पहली रिपोर्ट भेजी गई
• उसी दिन FIA ने site को offline कर दिया
• 10 जून 2025: FIA ने आधिकारिक रूप से comprehensive fix पूरा होने की सूचना दी
• 22 अक्टूबर 2025: ब्लॉग पोस्ट और public disclosure किया गया

निहितार्थ

• यह मामला दिखाता है कि साधारण mass assignment vulnerability भी उच्च-सुरक्षा वाले सिस्टम में हो सकती है
• sports industry के digitisation के तेज होने के साथ privacy protection और access control को मजबूत करने की जरूरत बढ़ रही है
• खासकर FIA जैसी अंतरराष्ट्रीय संस्थाओं के लिए API design और permission validation logic की नियमित security review आवश्यक है

[GN⁺]

Hacker News प्रतिक्रिया

• यह सिर्फ एक साधारण vulnerability नहीं, बल्कि कई security failures का मेल है
  उदाहरण के लिए, applicants के documents को उद्देश्य पूरा होने के बाद भी production server पर बने रहने देना बिल्कुल ज़रूरी नहीं है
  यह blast radius (नुकसान का दायरा) कम से कम रखने के सिद्धांत के भी खिलाफ है
  ऐसी स्थिति में तो कम से कम ज़िंदगी भर के लिए free tickets मिलनी चाहिए थीं

  • नियम 1: user input data पर कभी भरोसा मत करो
    जिस पल यह नियम टूटता है, बाकी सारे नियमों के गिरने में बस समय की बात रह जाती है

• Ian, अगर वेबसाइट में RSS feed जोड़ दी जाए तो शायद regular subscribers और बढ़ेंगे

  • Ian सच में बहुत अच्छा लिखते हैं
  • मैं भी इस राय से सहमत हूँ

• यह हैरान करने वाली बात है कि रिपोर्ट वाले उसी दिन साइट को offline कर दिया गया
  इतनी तेज़ response कम ही देखने को मिलती है

  • सही बात, fix भी काफ़ी जल्दी आया
    इस आकार की कंपनी का इतनी तेज़ी से हिलना-डुलना दुर्लभ है

• यह सच में शर्मनाक हद तक खराब security level है

  • इसे security कहना भी मुश्किल है, यह तो बस पूरी तरह खुला हुआ था
    फिर भी ऐसी चीज़ें देखकर मेरा impostor syndrome थोड़ा कम हो जाता है
  • अगर पार्टी की वीडियो भी देखोगे तो और हैरानी होगी

• ऐसी स्थिति में कम से कम लेखकों को F1 super license दे देनी चाहिए थी ताकि वे खुद कार चला सकें

  • काश बात सिर्फ इतनी ही होती

• यह जानने की जिज्ञासा है कि क्या इस तरह की security probing करते समय कभी कानूनी धमकियाँ मिली हैं
  और क्या bug bounty program न होने पर भी कभी reward offer मिला है

  • इस तरह का काम कानूनी रूप से जोखिम भरा हो सकता है
    इंडस्ट्री में ऐसे बहुत लोग हैं जिनमें न कौशल है, न ज़िम्मेदारी
    ऐसे लोगों के लिए security report सीधा ‘झंझट’ बन जाती है, इसलिए ज़िम्मेदारी से बचने के लिए reporter को दोष देने या कानूनी कार्रवाई करने की प्रेरणा पैदा होती है
    इसलिए anonymous रहकर काम करना सबसे सुरक्षित है। बाद में चाहें तो पहचान उजागर की जा सकती है
  • जर्मनी का “Modern Solution” मामला इसका प्रमुख उदाहरण है
    एक IT engineer ने password पाया और phpMyAdmin access की संभावना की report की, लेकिन कंपनी ने उस पर मुकदमा कर दिया, और मामला सर्वोच्च न्यायालय तक गया जहाँ कंपनी जीत गई
    संबंधित लेख (Heise)
  • जैसा ब्लॉग में बताया गया है, admin privilege escalation की कोशिश कानूनी रूप से धुंधले क्षेत्र में आती है
    ऐसी चीज़ें आम तौर पर सिर्फ औपचारिक red team test या penetration testing contract के तहत ही स्वीकार्य होती हैं
    बाद में यह कहना कि ‘इरादा ethical था’ काफ़ी नहीं होता
  • असली कानूनी धमकियाँ दुर्लभ हैं, लेकिन कुछ कंपनियाँ ‘retroactive bug bounty’ के नाम पर रिश्वत जैसी पेशकश भी करती हैं
    ऐसी पेशकशों को हर हाल में ठुकराना चाहिए
  • यूनिवर्सिटी के दिनों में जब मैंने एक vulnerability report की थी, तब कंपनी ने कानूनी धमकी दी थी, लेकिन प्रोफेसर के कड़े विरोध के बाद उसे वापस ले लिया गया
    उसके बाद 8 साल तक ऐसा कुछ नहीं हुआ
    आजकल कंपनियाँ पहले की तुलना में ऐसी गतिविधियों को ज़्यादा समझती हैं

• मेरा सबसे पसंदीदा hacking तरीका है JS पढ़ना और PUT request को modify करना
  यह उम्मीद से ज़्यादा बार काम कर जाता है

• पुरानी कंपनियों की security भी पुरानी होती है
  RD ने अच्छा काम किया, लेकिन यह बिल्कुल भी हैरान करने वाला नहीं है
  मुझे लगभग यक़ीन है कि hash शायद MD5 होगा

  • यह जानना दिलचस्प होगा कि कौन-सा hash algorithm इस्तेमाल हुआ
  • F1 साइट के लिए “move fast and break things” एकदम फिट बैठता है
    यह xkcd 1428 की याद दिलाता है

• अजीब बात यह है कि साइट operator Ian Carroll हैं, लेकिन उदाहरण में मशहूर bug bounty hunter Sam Curry दिखाई देते हैं

  • पोस्ट के मुताबिक, Gal Nagli, Sam Curry, Ian ने साथ मिलकर F1 से जुड़ी साइटों को hack करके देखने का फैसला किया था
  • Ian की दूसरी पोस्टों को देखें तो पता चलता है कि ये लोग अक्सर collaborate करते हैं