SQL इंजेक्शन के ज़रिए एयरपोर्ट सुरक्षा को बाइपास करना

 (ian.sh)
1 पॉइंट द्वारा GN⁺ 2024-08-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • TSA के KCM/CASS authentication flow में अगर airline-side system compromise हो जाता, तो arbitrary users को ऐसे जोड़ा जा सकता था जैसे उन्होंने employment status verification पास कर लिया हो, जिससे security screening bypass या cockpit access तक संभव हो सकता था
  • FlyCASS छोटे airlines के लिए CASS web interface देता था, और Air Transport International login page में SQL injection के ज़रिए admin login संभव था
  • Admin screen में नए employee को जोड़ते समय बिना extra verification KCM और CASS permissions दी जा सकती थीं, इसलिए test user दोनों systems में approved status में दिखा
  • अप्रैल 2024 के अंत में ARINC, FAA, DHS/CISA को disclosure के बाद DHS ने पुष्टि की कि FlyCASS को KCM/CASS से अलग कर दिया गया है, लेकिन TSA के explanation पर correction request का जवाब नहीं दिया
  • TSA ने कहा कि KCM barcode issue होने से पहले screening होती है, इसलिए checkpoint access संभव नहीं था; लेकिन असल process में employee ID manual entry path बचा हुआ था, जिससे vulnerability का impact ज्यादा बड़ा था

KCM और CASS क्या verify करते हैं

  • Known Crewmember(KCM) TSA का program है, जो pilots और flight attendants को domestic personal travel के दौरान भी security screening bypass करने देता है
    • Employee dedicated line में KCM barcode दिखाता है या TSA employee को employee number और airline बताता है
    • TSA employee का laptop airline से employment status confirm करता है, और success होने पर वह employee अलग screening के बिना secure area में जा सकता है
  • Cockpit Access Security System(CASS) cockpit access eligibility verify करने वाला अलग system है
    • ज्यादातर aircraft में cockpit के अंदर, flying pilots के पीछे jumpseat होता है
    • Pilot commute या repositioning करते समय अगर paid seat का इस्तेमाल करना मुश्किल हो, तो jumpseat इस्तेमाल कर सकता है
    • Gate employee CASS से verify कर सकता है कि jumpseat user approved pilot है या नहीं, और crew को CASS authentication की बात बता सकता है
  • दोनों प्रक्रियाओं का मुख्य आधार current airline employment status verification है
    • अगर कोई airline employee नहीं है, तो उसका background check नहीं हुआ होगा, इसलिए security screening bypass या cockpit access allow नहीं होना चाहिए
    • Approved person सही है या नहीं, यह confirm करने के लिए crew member की photo भी return की जाती है

ARINC और airline-specific authentication systems

  • ARINC Collins Aerospace की subsidiary है, और ऐसा लगता है कि TSA ने KCM operation इसे सौंपा है
  • ARINC pilots और flight attendants के लिए KCM status check करने वाली online website और airlines के बीच approval requests route करने वाले API जैसे central components operate करता है
  • KCM और CASS में participate करने के लिए हर airline अपना authentication system चलाती दिखती है, और यह system ARINC के hub के साथ interact करता है
    • TSA और airlines CockpitAccessRequest, CrewVerificationRequest जैसे requests ARINC को भेज सकते हैं
    • ARINC request को संबंधित airline system तक route करता है और response प्राप्त करता है
  • KCM में फिलहाल 77 airlines participate कर रही हैं
    • बड़े airlines ने संभवतः अपने systems बनाए होंगे, लेकिन छोटे airlines KCM या CASS requests का जवाब कैसे देते हैं, यह investigation का विषय बना

FlyCASS में मिला SQL injection

  • Researchers authentication system वास्तव में operate करने वाले vendor को ढूंढ रहे थे, तभी उन्हें FlyCASS नाम की site मिली
    • FlyCASS छोटे airlines को CASS के लिए web-based interface देता है
    • हर airline का अलग login page था, और Air Transport International(8C) को /ati से access किया जा सकता था
  • Login page पर username में single quote डालते ही तुरंत MySQL error return हुआ
    • ऐसा लगा कि username सीधे login SQL query में insert किया जा रहा था
    • sqlmap से SQL injection issue confirm हुआ
  • Username ' or '1'='1 और password ') OR MD5('1')=MD5('1 के combination से Air Transport International के admin account में login किया जा सकता था

Admin permissions से KCM/CASS approved users जोड़ना

  • FlyCASS participating airlines के लिए KCM और CASS दोनों operate कर रहा था
  • Air Transport International admin permissions मिलने पर, उस airline से जुड़े pilots और flight attendants की list manage की जा सकती थी
  • Airline में नया employee जोड़ते समय कोई additional check या authentication नहीं था
    • Airline admin किसी को भी KCM और CASS approved user के रूप में जोड़ सकता था
  • Test के लिए Test TestOnly नाम का employee बनाया गया, चुनी हुई test photo डाली गई, और KCM तथा CASS access permissions दी गईं
    • इसके बाद Query function से check करने पर test user KCM और CASS दोनों में approved status में था
  • सिर्फ basic SQL injection knowledge से site में login करके arbitrary users को KCM और CASS में जोड़ा जा सकता था
    • नतीजतन security screening skip करना और commercial passenger aircraft के cockpit तक access संभव हो सकता था
  • पहली problem मिलते ही disclosure process शुरू किया गया, और इसके अलावा कई और गंभीर issues भी मिले

Disclosure process और TSA की प्रतिक्रिया

  • सही disclosure contact ढूंढने की प्रक्रिया ही आसान नहीं थी
    • FlyCASS एक व्यक्ति द्वारा operate किया जा रहा लगता था, इसलिए शुरुआत से ही FlyCASS से contact करके उसे चौंकाना नहीं चाहते थे
  • 23 अप्रैल 2024 को Department of Homeland Security को issue disclose किया गया, और DHS ने इसे acknowledge किया और पुष्टि की कि वे इसे “बहुत गंभीरता से ले रहे हैं”
  • इसके बाद FlyCASS को KCM/CASS से disable कर दिया गया, और बाद में लगता है कि issue fix कर दिया गया
  • Issue fix होने के बाद safe disclosure coordinate करने की कोशिश की गई, लेकिन DHS ने जवाब देना बंद कर दिया
  • TSA press office ने vulnerability impact को deny करते हुए explanation जारी किया
    • TSA ने कहा कि नए KCM member को barcode issue करने से पहले screening process शुरू होता है, इसलिए इस vulnerability से KCM checkpoint access नहीं किया जा सकता
    • हालांकि KCM checkpoint use करने के लिए KCM barcode mandatory नहीं है, और TSO airline employee ID manually enter कर सकता है
    • Researchers ने यह बात TSA को बताई, जिसके बाद TSA ने अपनी website का वह section delete कर दिया जिसमें employee ID manual entry का उल्लेख था, और correction request का जवाब नहीं दिया
    • Confirm हुआ कि TSO द्वारा इस्तेमाल किया जाने वाला interface अब भी employee ID manual entry allow करता है

संभावित additional attacks और disclosure timeline

  • Vulnerability से existing KCM member को modify किया जा सकता था, इसलिए existing registered user की photo और name change भी संभव थी
    • इस तरीके से new member screening process होने पर भी उसे bypass करने की संभावना थी
  • अगर unregistered KCM barcode हासिल किया जा सके, तो KCM website पर उसे सीधे employee ID में register भी किया जा सकता था
  • Disclosure timeline:
    • 2024-04-23: ARINC और FAA को initial disclosure
    • 2024-04-24: CISA के ज़रिए DHS को additional disclosure
    • 2024-04-25: DHS CISO ने confirm किया कि resolution work चल रहा है
    • 2024-05-07: DHS CISO ने confirm किया कि FlyCASS को KCM/CASS से अलग कर दिया गया है
    • 2024-05-17: TSA explanation पर DHS CISO से follow-up contact किया गया, लेकिन कोई response नहीं मिला
    • 2024-06-04: TSA explanation पर DHS CISO से फिर follow-up contact किया गया, लेकिन कोई response नहीं मिला

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-08-30
Hacker News की राय

  • यहां TSA की प्रतिक्रिया बचकानी और शर्मनाक स्तर की है, लेकिन यह देखते हुए कि यह संगठन असल सुरक्षा में ज्यादा दिलचस्पी नहीं रखता, यह चौंकाने वाली भी नहीं है
    DHS ने शुरुआत में रिपोर्ट को तेज़ी और पेशेवर तरीके से संभाला लगता है, लेकिन बाद में सुधार और disclosure प्रक्रिया पर ऊपरी स्तर का नियंत्रण आखिर तक बनाए नहीं रख पाया—यह दिलचस्प है

    • मैनेजमेंट, यहां तक कि IT मैनेजरों के लिए भी यह पूरी तरह समझना बहुत मुश्किल है कि ऐसी बातों का मतलब क्या होता है
      मैंने देखा है कि exposed keys जैसी बड़ी समस्याओं को मामूली मान लिया जाता है, जबकि पुरानी JavaScript लाइब्रेरी या IPv6 सपोर्ट न होना जैसी बातें escalate हो जाती हैं
      TSA और उसके पार्टनर संभावित exposure को कम करके दिखाने की कोशिश कर रहे हैं, यह साफ है, लेकिन कई मैनेजर vulnerabilities का मतलब समझने में संघर्ष करते हैं, और developers भी अपनी जिम्मेदारी कम करके दूसरों पर दोष डाल रहे होंगे
    • TSA security theater है; यह सुरक्षा देने से ज्यादा सुरक्षा होने का भ्रम देने के लिए मौजूद है
      असल में मकसद surveillance system को मजबूत करना और ताकतवर दिखने वाला बाहरी रूप बनाना लगता है
    • लगता है DHS के middle manager ने TSA के middle manager पर चिल्लाया, वह बात TSA के शीर्ष स्तर तक पहुंची, और फिर उनकी आम नीति इनकार·टालमटोल·अनदेखी लागू हो गई
    • बल्कि हैरानी की बात यह है कि उन्होंने सुबह-सुबह pentester के घर पर raid नहीं की, और anti-terrorism law की धाराएं दिखाकर उसे वकील के बिना हिरासत में नहीं रखा

  • ये लोग SQL injection की पुष्टि करके नहीं रुके, बल्कि नकली employee record तक बना दिया; यह चौंकाने वाला है कि Homeland Security संबंधित लोगों को गिरफ्तार करने नहीं आ गई
    मुझे लगा था Homeland Security ही वह जगह होगी जो responsible disclosure को malicious hacking समझकर वैसा ही नाम देने की सबसे अधिक संभावना रखती है
    असली vulnerability की अक्षमता से ज्यादा यह बात प्रभावशाली लगी

    • बात गलत नहीं है, लेकिन फोटो की जगह bright pink image डालकर नाम “Test TestOnly” रखने भर पर, jury member के रूप में मैं CFAA violation में दोषी मानने में हिचकूंगा
      अगर उन्होंने खुद को Known Crewmember में जोड़कर सचमुच airport screening bypass किया होता, तो वे जेल गए होते
    • अगर ऐसा माहौल बनाया जाए कि responsible disclosure पर भी prosecution हो सकता है, तो ऐसे systems को देखने वाले देश के सबसे अच्छे talent डरकर पीछे हट जाएंगे
      फिर कम friendly दूसरे देशों के सबसे अच्छे talent इन्हें देखेंगे, और उनके responsible तरीके से disclose करने की संभावना कम होगी
    • DHS आधिकारिक तौर पर Bugcrowd का इस्तेमाल करता है
      https://bugcrowd.com/engagements/dhs-vdp
      कई सालों से संबंध है, इसलिए कुछ हद तक वे इसके आदी होंगे। TSA खुद कम परिचित हो सकता है, लेकिन जब DHS पूरे विभाग की vulnerability disclosure policy (VDP) चलाता है और CISA के जरिए दूसरे विभागों को भी VDP चलाने की सलाह देता है, तो लगता नहीं कि वे DOJ से prosecution की मांग करेंगे
      हालांकि हो सकता है मैं जरूरत से ज्यादा optimistic हूं
    • जर्मनी जैसे देशों में, जहां ऐसी बातें आम हैं, लोग आमतौर पर समस्या पत्रकारों या CCC जैसे non-profit organizations को बताते हैं, और वे government agency या company को report करते हैं
      इससे responsible disclosure के कारण prosecution का जोखिम कम किया जा सकता है
      और सुरक्षित तरीका यह है कि report anonymous भेजी जाए और public disclosure या full disclosure की स्पष्ट deadline रखी जाए, हालांकि इस स्थिति में खोजकर्ता के रूप में credit मिलना मुश्किल होता है
    • limitation period लंबा है, और HSI अक्सर investigation लगभग पूरी होने तक prosecution टालता है

  • मामला इतना गंभीर है कि यह लिखते समय भी कोई MD5 से password store करने की समस्या कितनी खराब है, इस पर बात नहीं कर रहा
    इस मामले में यह भी सामने आता है कि salt तक इस्तेमाल नहीं किया गया था; वैसे MD5 में salt इस्तेमाल करना भी पर्याप्त नहीं है
    लेकिन अगर सिर्फ request से SQL query को मनमाने ढंग से खंगाला जा सकता है, तो password कितनी अच्छी तरह store किए गए हैं, इसका खास मतलब नहीं रह जाता

    • यह पहले Triplebyte interview में लगभग वैसा ही आने वाला सवाल था, और काफी अच्छे engineers भी इसे बड़ी संख्या में गलत करते थे
      salt इस्तेमाल करने और cryptographically secure hash तक पहुंचने वालों का अनुपात शायद 20% से कम था, और MD5 वाकई बहुत बार आता था
      यह देखते हुए कि इस interview से पहले भी काफी filtering हो चुकी होती थी, overall baseline उससे भी खराब है
    • SQL injection में md5 वाला हिस्सा pentester ने जोड़ा लगता है, शायद इसलिए कि injection parameter के अंदर parenthesis पर खत्म होने वाली call की जरूरत थी

  • “FlyCASS एक व्यक्ति द्वारा चलाया जाता है ऐसा लगा, इसलिए पहले संपर्क नहीं किया” वाली व्याख्या पर भरोसा करना मुश्किल है
    ऐसा लगता है कि उन्हें पता था कि site developer तुरंत fix कर देगा, और वे अपनी discovery को बड़ा धमाका बनाना चाहते थे

    • ऐसी bugs ही वे bugs हैं जिन्हें बड़ा बनाकर सामने लाना चाहिए
      यह मामला ऐसा नहीं कि जिम्मेदार व्यक्ति चुपचाप fix करके खत्म कर दे; database में मौजूद हर व्यक्ति को फिर से verify करना चाहिए
    • motivation जो भी हो, इतनी आम bug आने देने वाली engineering process खराब है
      अगर इकलौते developer ने तुरंत fix कर दिया होता, तो issue को ऊपर तक ले जाकर systematic तरीके से fix करवाना मुश्किल होता
      ऐसा full overhaul सचमुच होगा या नहीं, पता नहीं, लेकिन escalate न करने पर उसकी संभावना और कम हो जाती है
    • मैं सहमत हूं कि वे disclosure से पहले breach के scope को पूरी तरह समझना चाहते थे
    • ऐसे छेद वाली site से पहले संपर्क किए बिना सीधे Homeland Security के पास जाना बिल्कुल उचित नहीं था

  • समस्या की गंभीरता से इनकार करना चौंकाने वाला नहीं, लेकिन FBI को बताने या गिरफ्तार करने की कोशिश न करना काफी चौंकाने वाला है
    शायद यह छोटा-सा progress हो

    • लेखक ने TSA को सीधे report करने के बजाय FAA और CISA के जरिए, यानी DHS route से handle किया—यह सही चुनाव था
      अगर उन्होंने सीधे TSA को report किया होता, तो legal threats और bluff की संभावना काफी थी
    • ऐसी प्रक्रिया बहुत धीमी चलती है
      मैं 50 डॉलर की शर्त लगा सकता हूं कि Ian पर prosecution होगा
    • यह newsworthy है
      हैरानी की बात है कि fake ID वाला कोई bored 17-year-old अभी तक TikTok पर airplane में sneak-in करने का video नहीं डाल पाया
      SQL injection, सच में

  • मजेदार है कि एक पुराने ढंग का SQL injection सालाना अरबों डॉलर वाले पूरे security theater को निष्क्रिय कर देता है, लेकिन यह बहुत चौंकाने वाला भी नहीं है

    • क्या किसी को Bruce Schneier और उनका fake boarding pass याद है? पहले TSA की scribble ही पूरे system की कमजोरी थी

  • यह काफी हैरानी की बात है कि airlines ऐसे security-sensitive software को एक-व्यक्ति वाली कंपनी से खरीदती हैं
    अमेरिका की ज़्यादातर कंपनियों को SaaS बेचने के लिए जब आप एक निश्चित स्तर तक पहुँचते हैं, तो कम-से-कम SOC2 audit report तो मांगी ही जाती है
    audit standard के तौर पर SOC2 को बिना बड़ी आपत्तियों के पास करना काफी आसान माना जाता है, लेकिन अगर कंपनी एक ही व्यक्ति चला रहा हो, तो report में कई criteria पर red flags दिखने चाहिए
    मुझे लगा था कि TSA access system से integrate होने वाले software की requirements SOC2 से कहीं ज़्यादा सख्त होंगी

    • FlyCASS जैसी चीज़ इस्तेमाल करने वाली “airlines” खुद छोटी operators होती हैं, और अक्सर उनकी margins बेहद कम होती हैं या वे सीधे घाटे में चल रही होती हैं, इस उम्मीद में कि कभी पैसे आएँगे और business टिक पाएगा
      backend में लगभग हर चीज़ औसत small business से भी ज़्यादा duct tape से जैसे-तैसे चिपकी होती है
      कुछ पुराने passenger aircraft खरीदकर उन्हें cargo planes में बदल दें, तो आप “airline” बन सकते हैं
      क्या नई airline बनना valuable है? क्या उन्हें सिर्फ इसलिए बंद कर देना चाहिए कि उनके पास अभी वह system नहीं है जिसे बनाने में कई साल से लेकर दशकों तक लगते हैं? जो company दो aircraft से कहीं-न-कहीं के बीच बस 1 route चलाती है, क्या उसे बड़ी passenger airlines के लिए बने custom systems पर भारी पैसा खर्च करना चाहिए?
      यहाँ requirements और audits जवाब नहीं हैं। मूल design problem यह है कि TSA ने “airline XXX कहती है कि आप उसके employee हैं” वाली authentication को “देश के किसी भी airport पर सारी security screening bypass कर सकते हैं” जैसे बेहद व्यापक अधिकार से जोड़ दिया, और “क्या वह airline इस airport पर operate भी करती है?” जैसी बुनियादी जाँच तक नहीं थी

  • यह बात भी हैरान करने वाली थी कि ऐसा करना इतना आसान हो सकता है, लेकिन बाद में दी गई TSA response की व्याख्या सचमुच गंभीर रूप से बेचैन करने वाली है

  • जिन्होंने यह किया है, उन्हें शायद Homeland Security या FBI की visit मिलेगी
    समझ नहीं आता उन्होंने सोचा क्या हासिल होगा
    मुझे नहीं लगता कि government security की परवाह करती है, लेकिन वह retaliatory ज़रूर होती है

    • Homeland Security या FBI यह निष्कर्ष निकालने के बाद क्या हासिल कर सकती है कि ये “लोग” असल में दो जाने-माने और सक्षम security researchers हैं, जिन्होंने air travel को सुरक्षित बनाने के लिए responsible disclosure की कोशिश की?

  • यहाँ संभव तरीका यह है कि किसी बड़ी airline का ticket खरीदा जाए, prohibited items को cabin baggage में रखा जाए, फिर third-party FlyCASS system में SQL injection के जरिए खुद को किसी छोटी airline की Known Crew Member list में जोड़कर TSA screening bypass कर दी जाए
    फिर prohibited items लेकर बड़े aircraft में चढ़ जाना—क्या यही vulnerability है?

    • मोटे तौर पर हाँ
      आजकल ज़्यादातर TSA screening lines boarding pass तक नहीं मांगतीं, इसलिए theoretically कोई bomb लेकर जाकर इस पूरे security theater को bypass कर सकता है
    • सुनने में तो ऐसा लगता है कि cockpit में भी बैठ पाना संभव हो जाएगा?