Salt Typhoon के बाद सामने आई telecom stack की अस्थिरता

 (soatok.blog)
1 पॉइंट द्वारा GN⁺ 2025-03-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Salt Typhoon intrusion के बाद telecom open source की जांच के दौरान, FreeSWITCH में bundled XMLRPC library में बिना authentication वाला buffer overflow पाया गया
  • यह vulnerability उस code में होती है जो attacker द्वारा दिए गए Request URI को 4096-byte stack variable में sprintf() से लिखता है, और browser restrictions से अलग 4096 characters से ज्यादा लंबी request संभव हो सकती है
  • SignalWire ने जवाब दिया कि February 2025 में GitHub पर 3 fix PR public किए गए थे, लेकिन कहा कि FreeSWITCH Community का नया release summer 2025 तक planned नहीं है
  • Shodan पर FreeSWITCH search results करीब 8,300 थे, और release tag न होने के कारण operators को source build या firewall blocking के जरिए खुद response करना पड़ रहा है
  • यह case दिखाता है कि telecom security का risk सिर्फ vulnerability itself में नहीं, बल्कि vulnerability management और release response में भी बढ़ता है; 30 April 2025 को CVE-2025-44087 assign होने के बाद भी FreeSWITCH release नहीं था

Salt Typhoon के बाद FreeSWITCH को देखने की वजह

  • 2024 के अंत में, China government से जुड़ा बताया जाने वाला Salt Typhoon group द्वारा T-Mobile और अन्य telecom operators में intrusion की खबर शुरुआती वजह बनी
  • Mobile carrier networks की सीधे जांच करना संभव नहीं था, लेकिन GitHub पर telecom से जुड़े कई open source projects थे
  • पहले Asterisk और FreeSWITCH इस्तेमाल करने वाली companies के साथ काम करने का अनुभव था, लेकिन PBX, SIP, audio encoding का गहराई से analysis करने का अनुभव नहीं था
  • Telecom field में बेहतरीन C programmers, पुराने hacker communities और Bell Labs से आए engineers की tradition है, इसलिए उम्मीद थी कि simple vulnerabilities पहले ही मिल चुकी होंगी
  • लेकिन FreeSWITCH source code खोलते ही vulnerability मिल गई

XMLRPC HTTP request handler का buffer overflow

  • FreeSWITCH में bundled XMLRPC library का HTTP request handler fixed-size stack buffer z[4096] में URI लिखता है
  • Problematic code sprintf(z, "Index of %s" CRLF, uri); जैसा है, और uri Request URI के path हिस्से से आता है, इसलिए attacker इसे control कर सकता है
  • आम browsers अक्सर 2048 characters से लंबे URL को अच्छी तरह support नहीं करते, लेकिन संबंधित RFCs ज्यादातर करीब 8KB तक allow करते हैं और Cloudflare 32KB तक support करता है
  • यह मानना reasonable है कि attacker 4096 characters से लंबा Request URI भेज सकता है, और यही condition XMLRPC library के unauthenticated buffer overflow तक ले जाती है
  • Remote code execution तक विस्तार की प्रक्रिया यहां cover नहीं की गई है

Fix का तरीका और public patches

  • Fix direction sprintf() के बजाय snprintf() इस्तेमाल करना है
  • यह basic defensive C programming practice में आता है
  • SignalWire ने कहा कि issue हाल ही में fix किया गया है और ये PRs दिखाए
  • Patch पहले से GitHub पर public होने के कारण public post लिखना संभव माना गया

Vulnerability disclosure process और release gap

  • 27 January 2025 को FreeSWITCH security policy में लिखे email address पर vulnerability details भेजी गईं
  • 7 February 2025 को report मिली या नहीं, इसकी पुष्टि के लिए follow-up email भेजा गया
  • उसी दिन Andrey Volk ने जवाब दिया कि vulnerability हाल ही में fix हो गई है और related PRs देखें
  • जब नए security fix शामिल release tag की timeline पूछी गई, तो जवाब मिला कि FreeSWITCH Community release summer 2025 तक planned नहीं है
  • इसके कारण FreeSWITCH Advantage के लिए भुगतान न करने वाले users regular release तक vulnerable state में रह सकते हैं

Exposure scale और operators पर असर

  • उस समय Shodan पर FreeSWITCH search results करीब 8,300 थे
  • यह मानना मुश्किल है कि ये सभी instances enterprise support के लिए pay करते हैं, इसलिए दुनिया भर के हजारों telecom stacks summer तक vulnerable रह सकते हैं
  • Patch GitHub पर public होने के बावजूद release tag न हो तो आम operators के लिए आसानी से update करना मुश्किल होता है
  • FreeSWITCH operators को SignalWire के release का इंतजार करने के बजाय ये कदम consider करने चाहिए
    • Source से सीधे rebuild
    • Firewall level पर FreeSWITCH stack की public HTTP access block करना

Telecom security की structural problem

  • Telecom industry के एक परिचित से बातचीत में प्रतिक्रिया यह थी कि FreeSWITCH की response speed भी अपेक्षाकृत तेज मानी जाएगी
  • December 2024 में भी phone network में 17 साल से मौजूद SS7 vulnerability के बारे में warning फिर सामने आई थी
  • इस अनुभव के बाद Asterisk या अन्य software को आगे नहीं देखा गया
  • निष्कर्ष के तौर पर आज की telecom security अच्छी स्थिति में नहीं आंकी गई
  • इन systems को सुरक्षित बनाने से पैसा कमाने का incentive बहुत कम होना इसका बड़ा कारण लगता है

बाद की स्थिति

  • 30 April 2025 के update में, reported buffer overflow को CVE-2025-44087 assign किया गया
  • उसी समय भी FreeSWITCH का कोई tag या release नहीं था

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

1 टिप्पणियां

 
GN⁺ 2025-03-14
Hacker News की रायें

  • लेखक मानते हैं कि उन्हें carrier-grade infrastructure का कोई अनुभव नहीं है, लेकिन उनका शक कुल मिलाकर सही है
    असल में कई प्रमुख telecom operators पर 4G/5G penetration testing और security research काफी की है, और operators व equipment vendors के बीच फर्क जरूर है, फिर भी यह अब भी लगभग पूरी तरह horror show जैसा है
    बहुत हाल तक security असल में सिर्फ security by obscurity ही थी, और 4G/5G standards ने इसे address करना शुरू किया है, लेकिन अब भी गंभीर चिंता लायक बड़े छेद बचे हुए हैं
    किसी telecom operator में foothold बनाने की कोशिश करने वाला मध्यम स्तर या उससे ऊपर का threat actor ऐसा कर सकता है, यह कहना अतिशयोक्ति नहीं है; मैंने पेशेवर तौर पर इसे कई बार demonstrate किया है
    एक खास East Asian देश के equipment vendors के software stack की quality इतनी खराब है कि उन्हें लगभग APT की श्रेणी में रखा जा सकता है, और security लगभग मौजूद ही नहीं है
    Western देशों ने उन्हें ban किया, इसके अच्छे कारण हैं; Western equipment vendors का software कहीं ज्यादा mature है, लेकिन फिर भी वह उस स्तर से कई साल पीछे है जिसे हम modern security best practices मानते हैं

    • कुछ साल पहले UK ने Huawei equipment खरीदते समय सरकार/Huawei की joint lab बनाई थी ताकि source code का analysis करके उसकी safety verify की जा सके
      GCHQ का मानना था कि code quality ऐसी थी जिसे review करना संभव नहीं था, और यह भी guarantee नहीं की जा सकती थी कि दिया गया source code वही code है जो असली equipment पर चल रहा है
      क्योंकि Huawei खुद updates कर सकता था; जहां तक मुझे पता है, वह equipment 2020 के बाद ban कर दिया गया: https://www.washingtonpost.com/world/national-security/brita...
    • सोच रहा हूं कि क्या किसी खास equipment पर कोई public analysis post उपलब्ध है
      AliExpress से एक खरीदकर देखना चाहता हूं; क्या यह link शुरुआत के लिए ठीक रहेगा?
      https://vulners.com/search/types/huawei
    • जानना चाहता हूं कि एक आम hacker ऐसे equipment को research के लिए कैसे हासिल कर सकता है
    • यह बात कि किसी खास East Asian देश के equipment vendors के software stacks इतने खराब हैं कि उन्हें लगभग APT कहा जा सकता है, सुनकर तंज कसने का मन करता है कि अच्छा हुआ कुछ खास North American hardware और software vendors हैं जो security को बहुत गंभीरता से लेते हैं

  • 2025 में भी mobile communication standards में pre-shared keys क्यों इस्तेमाल होती हैं, यह सच में समझ नहीं आता
    RSA और Diffie-Hellman[1] कई दशकों से मौजूद हैं और certificate authority system भी पुराना है, फिर भी SIM cards अब भी ऐसी pre-shared key के साथ issue होते हैं जिसे सिर्फ card और operator जानते हैं, और बाद की authentication व encryption सब उसी key पर आधारित होती है
    अगर operator hack हो जाए और key leak हो जाए, तो कुछ नहीं किया जा सकता
    इससे भी बुरा यह है कि SIM card manufacturer को वह key operator को भेजनी पड़ती है, और manufacturer किसी दूसरे देश में हो सकता है जहां वह foreign government की मांगों के अधीन हो; इसलिए manufacturer hack या transit में interception के काफी मौके बनते हैं
    यह NOBUS vulnerability जैसा लगता है, और अगर SIM manufacturer या core network equipment vendor NSA के साथ मिलकर keys सौंप दे, तो दुनिया भर के mobile traffic को संभावित रूप से intercept किया जा सकता है
    [1] मुझे पता है कि ये algorithms अब best practice नहीं हैं और elliptic curves बेहतर हैं, लेकिन मौजूदा हालत से तो RSA भी बेहतर होगा
    [2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...

    • Gemalto को 15 साल पहले hack किया गया था
      “Edward Snowden द्वारा दिए गए NSA top-secret documents के अनुसार, American और British spies ने दुनिया के सबसे बड़े SIM card manufacturer के internal computer network को hack करके वे encryption keys चुरा लीं जिनका इस्तेमाल दुनिया भर में mobile phone communications की privacy बचाने के लिए होता है”
      https://theintercept.com/2015/02/19/great-sim-heist/
    • phone engineers से बात करने पर उन्होंने बताया कि base station से जुड़कर debugging करते समय वे गुजर रहे पूरे SMS को ज्यों का त्यों पढ़ सकते थे
      पता नहीं अब भी ऐसा है या नहीं, लेकिन पहले mobile phone को secure communication medium मानना मुश्किल था
      शायद end-to-end encrypted data communication के जरिए बात करना बेहतर होगा
    • कुछ algorithms को SIM card पर चलना पड़ता है, लेकिन कम से कम पुराने smartcards में RSA या non-elliptic-curve Diffie-Hellman support करने के लिए ऐसा coprocessor चाहिए होता था जिससे cost बढ़ती थी
      symmetric-key algorithms का एक फायदा यह भी है कि वे quantum-safe होते हैं
      फिर भी 2025 तक कम से कम ECC support होना चाहिए था, और अब ज्यादातर smartcards को इसे default रूप से support कर पाना चाहिए
      अगर SIM card vendors पर भरोसा नहीं किया जा सकता, तो असल में कोई जवाब नहीं है
      asymmetric approach में भी attack paths बस थोड़ा बदलते हैं; अगर card पर चलने वाले software पर भरोसा नहीं है, तो आप कैसे जानेंगे कि nondeterministic algorithms की random-number choice के जरिए plaintext leak नहीं किया जा रहा?
    • अगर आप keys सीधे distribute कर सकते हैं, तो asymmetric encryption जितना देती है उसके मुकाबले complexity ज्यादा जोड़ती है
      यह सोच कि symmetric system में RSA जोड़ने से वह ज्यादा secure हो जाएगा, कमजोर आधार वाली है; बल्कि मामला लगभग उल्टा है
      “NOBUS vulnerability” कहना भी खास तौर पर अजीब है, क्योंकि ऐसे system का trust root telecom operator ही होता है
      यह पूछने की भी जरूरत नहीं कि American telecom operator American intelligence agencies के साथ “collude” करता है या नहीं; मानकर चलना चाहिए कि करता ही है
    • एक बड़े telecom operator में tech support/customer service का काम किया था; कई security issues दिखे और उन्हें customer service बेहतर करने के solutions के साथ उठाया, तो जवाब मिला कि इससे company का पैसा घटेगा
      scammers telecom operators के बड़े customers होते हैं, और पकड़े जाकर blocked होने पर वे वापस आते हैं, नई line activation fee देते हैं और वही cycle दोहराते हैं
      scammers की वजह से add-on features upsell करना भी संभव हो जाता है, इसलिए problem हल न करने की तरफ भी revenue बनता रहता है

  • ब्लॉग पोस्ट के निष्कर्ष की तरह, यह बिल्कुल हैरान करने वाला नहीं है कि Freeswitch अपना कम्युनिटी रिलीज़ शेड्यूल नहीं बदलेगा
    पुराने Freeswitch में मजबूत कम्युनिटी भावना थी, लेकिन कुछ साल पहले इसके ज़्यादा आक्रामक तरीके से commercialize होने के बाद माहौल बदल गया
    उसके बाद से, जिन चीज़ों तक सार्वजनिक पहुंच होनी चाहिए थी, उन तक पहुंचने के लिए “registration” प्रक्रिया से गुजरना पड़ता था, और मेरी याद में APT repository जैसी कोई चीज़ registration wall के पीछे छिपा दी गई थी
    मैं free software community content तक पहुंचने के लिए किसी commercial company में register नहीं करना चाहता
    क्योंकि tech industry में सभी जानते हैं कि किसी commercial company को जानकारी देने पर sales reps upsell/cross-sell के लिए परेशान करते हैं और आपको अनचाही mailing lists में डाल देते हैं

    • SignalWire के बचाव में कहें तो, पुराने mailing lists पढ़ने पर लगा कि उन्होंने कई साल तक Freeswitch development को आगे बढ़ाया, लेकिन downstream projects से उन्हें ठीक से compensation नहीं मिला
      VoIP community के दूसरे हिस्सों को भी open source के प्रति अपनी उदारता को फिर से संतुलित करते देखा है, और सच कहूं तो उन्हें दोष देना मुश्किल है
      Matrix.org team ने भी FOSDEM’25 की अपनी एक presentation में इसी तरह commercial vendors द्वारा development पर free-ride करने की समस्या की बात की थी
    • अगर मैं गलत हूं तो सुधारें, लेकिन patched source code public नहीं है क्या?
      अगर वे APT repository तक मुफ्त में update कर दें तो सचमुच आभारी रहेंगे, लेकिन वह बस उतना ही “आभार योग्य काम” है
      अगर आप उनके code पर निर्भर हैं लेकिन support cost नहीं देना चाहते, तो APT package खुद build कर सकते हैं
      इस तरह किसी एक company द्वारा maintain किए जा रहे project से कैसी community spirit की उम्मीद करनी चाहिए, यह मुझे ठीक से नहीं पता

  • विदेशी threat actors, Five Eyes जैसे Western allies, और numbers लगातार बढ़ाने के दबाव को देखते हुए यह मानना उचित है कि online वास्तविक anonymity नहीं है
    अगर वे आपको चाहते हैं, तो आपको पकड़ने के साधन भी उनके पास हैं
    असल में यह pre-Internet era से बहुत अलग नहीं है
    अगर intercept नहीं होना चाहते, तो ऐसे तरीके से encrypt करना होगा जिस तक बड़ी security agencies electronically आसानी से access न कर सकें
    जैसे physical notes, बातों-बातों में मौखिक संदेश, hand gestures वगैरह
    साथ ही, जब कोई state actor सचमुच data का उपयोग करने के लिए resources allocate करे, तो online कही और की गई बातों के परिणाम भुगतने के लिए तैयार रहना होगा

  • सिर्फ article देखकर मैं इस निष्कर्ष से पूरी तरह आश्वस्त नहीं हूं कि “आज की telecom security गड़बड़ है”
    क्योंकि यह Freeswitch को मनमाने ढंग से चुनकर buffer overflow खोजने जैसा ज्यादा लगता है
    “telecom stack” vulnerable हो भी सकता है और नहीं भी, लेकिन यहां दिए गए evidence बहुत कमजोर हैं
    Salt Typhoon attack के बारे में कहा गया है कि उसने Cisco vulnerability का exploit किया, लेकिन analysts ने यह संभावना भी जताई कि attackers ने valid credentials का इस्तेमाल किया होगा: https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
    इसलिए इसका Freeswitch से संबंध नहीं है

    • Cisco Unified Call Manager में लगभग निश्चित रूप से vulnerabilities होंगी, और Metaswitch में भी, जिसे Microsoft ने सार्वजनिक रूप से खत्म कर दिया था फिर भी वह network core में घिसटता रहा
      Oracle SBC तो default behavior में ही अक्सर unstable होता है, और Teams इस हफ्ते जो TRouter implementation लेकर आता है उसकी अव्यवस्था में भी निश्चित रूप से ऐसे denial-of-service bugs होंगे जिन्हें ठीक से अलग नहीं किया गया
      MF Tandem की अव्यवस्था या यह बात तो छोड़ ही दें कि लगभग हर telecom operator raw unencrypted UDP SIP traffic को सीधे Internet पर बहा देता है
      इस क्षेत्र में secure systems बनाना संभव है, लेकिन हकीकत यह है कि ज्यादातर बड़े telecom operators Nortel, Metaswitch जैसी बहुत पहले मर चुकी companies या projects के proprietary, unmodifiable platforms चला रहे हैं, और ऐसी technical debt के ढेर भी जो network बनाने वाले पुराने, unpatched equipment से भी बदतर हैं
    • SignalWire द्वारा embargo तोड़ने के बाद, telecom security से ज्यादा परिचित security nerds के साथ कुछ बातचीत हुई
      “सब कुछ गड़बड़ है और इसे ठीक करने की कोई incentive नहीं है” कहना सिर्फ एक summary है
      सच कहूं तो वे conversations jargon न जानें तो follow करना बहुत मुश्किल है, और मैं खुद इस field को पर्याप्त नहीं समझता, इसलिए अनाड़ी तरीके से समझाने की कोशिश नहीं करना चाहता था और बस इतना ही लिखा
      मैंने बिल्कुल उम्मीद नहीं की थी कि मेरा blog Hacker News पर दिखाई देगा
    • मैंने telecom code पर काम किया है
      यह कई generations की legacy वाले complex network protocols को parse करने वाला code है, अक्सर secret में लिखा जाता है, और आमतौर पर C/C++ में होता है
      यह vulnerable हो ही नहीं सकता। बिल्कुल
    • telecom stack में protocol level से पैदा हुई चीज़ों समेत संदिग्ध security decisions भरी पड़ी हैं
      SS7 जैसे protocols ऐसे design किए गए थे मानो hackers या malicious actors जैसी कोई अवधारणा ही न हो
      उसके ऊपर firewall रख सकते हैं, लेकिन वह desired functionality से टकराता है और नहीं भी टकराए तो भी additional investment चाहिए
      DIAMETER बेहतर है, लेकिन उसमें भी अब भी बहुत छेद हैं
      हाल के वर्षों में telecom security priority बनने से सुधार हो रहे हैं, लेकिन दशकों के legacy hardware, software, firmware और network design को समेटना पड़ता है
      मुझे नहीं लगता कि telecom networks में standard Freeswitch को जस का तस चलाने वाली जगहें होंगी, लेकिन पुराने telecom product के रूप में Freeswitch में जिस तरह की समस्याएं हैं, जहां security उतनी नहीं खोजी गई जितनी उम्मीद थी, वैसी चीज़ें हर जगह फैली हैं
    • यह blog post “मैंने अपने professional काम जैसा कुछ किया” और “जिस पक्ष को मैंने report किया, वह मेरे और security industry के values share नहीं करता” के combination के बाद यह निष्कर्ष निकालता है कि telecom security गड़बड़ है
      लेखक ने अपने खाली समय में code देखा, bugs खोजे और report किए—यह शानदार है, और मैं इसे बिल्कुल रोकना नहीं चाहता
      लेकिन किसी software के एक maintainer ने security industry best practices के मुताबिक author के आगे झुककर व्यवहार नहीं किया, सिर्फ इस तथ्य के आधार पर “आज की telecom security गड़बड़ है” कहना कमजोर evidence है
      अगर कोई आपके code में bug लेकर आया, लेकिन यह दावा नहीं किया कि यह active exploitation में है, और exploitability verify करने के लिए PoC भी नहीं दिया, तो उसे साधारण bug की तरह treat न करने की क्या वजह है?
      अभी fix कर दें और next release में डाल दें
      क्या लोग changes देख सकते हैं? हां, वे बाकी changes भी देख सकते हैं
      अगर exploit ढूंढ सकते हैं तो शुभकामनाएं, reporter उसे ढूंढ नहीं पाया
      Linux distributions में भी यही होता है
      security bug report होता है, और कभी-कभी upstream author सिर्फ जिद्दी नहीं, बल्कि सचमुच दुनिया छोड़ चुका होता है
      अगर अपने schedule के हिसाब से बदलना है, तो खुद release कर दें

  • Freeswitch का एक ऐसा क्षेत्र जहां शायद यह काफी इस्तेमाल होता है, schools और universities की BigBlueButton installations हैं
    यह virtual classroom system है, और कई मामलों में support contract के बिना इस्तेमाल होता होगा; telecom operators की तुलना में मुझे इस तरफ ज्यादा चिंता है

  • सोच रहा हूँ कि XML RPC मॉड्यूल को असल में कितने लोग इस्तेमाल करते होंगे
    यह default रूप से load नहीं होता
    सुधार: Shodan के हिसाब से 468 हैं
    यह भी सोच रहा हूँ कि XML RPC मॉड्यूल में senddirectorydocument वाकई इस्तेमाल होता भी है या नहीं

    • आगे जांच कर देखी, लेकिन कोई भी action trigger नहीं कर पाया
      curl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";
      इसे trigger करने के तरीके पर कोई idea है?
      अगर कम-से-कम segfault कराने वाला PoC भी आ जाए, तो security release करने की संभावना ज्यादा हो सकती है

  • असली बढ़िया hacking CAMEL MAP injection में होती है
    SMS, USSD, और crown jewel यानी location services तक—हर तरह की अच्छी चीजों पर control मिलता है
    Caribbean के अमीर islands या Indonesia जैसी जगहों की कई “bulk SMS” कंपनियां spam भेजने से कहीं ज्यादा काम कर रही हैं

    • साथ में, MAP 2G और 3G technology है
      इसलिए यह पुरानी है, और 2G 1990s में design हुआ था
      लोग क्या उम्मीद करते हैं, समझ नहीं आता
      सच कहें तो इसका चल जाना ही गनीमत है

  • बड़े telecom operators core में FreeSwitch या Asterisk नहीं चलाते

    • Motorola का low-cost 911 phone system Emergency CallWorks(ECW), Proxmox पर Linux में proprietary modules के साथ चलने वाला Asterisk है
      हालांकि Motorola उस product को बंद कर रहा है, लेकिन field में यह मौजूद है
      जिसकी मैं देखभाल करता हूँ, वह मजबूत firewall के पीछे है, पर शायद सभी ऐसे नहीं होंगे
    • core में न भी हो, तो भी call recording, transcription, IVR, voice analytics, CRM integration, call queues, auto-dialing, SMS/chat features जैसे call data process करने वाले कई businesses stack में कहीं-न-कहीं FreeSWITCH, Asterisk या कुछ similar चलाने की काफी संभावना रखते हैं
      basic call routing और PSTN connectivity से ज्यादा कुछ करना चाहने वाली PBX वाली ज्यादातर companies third-party tools इस्तेमाल कर रही होंगी
      और ऐसे काफी tools FreeSWITCH, Asterisk या मिलती-जुलती चीजों पर बने होते हैं
    • “major” की definition पर बहुत कुछ निर्भर करता है

  • mobile telecom security से जुड़ी P1 Security presentation की जोरदार सिफारिश करूंगा: https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
    material पुराना है, लेकिन यह मानने की कोई वजह नहीं कि हालात बेहतर हुए हैं
    क्योंकि सुधार करने का कोई incentive नहीं है
    ऊपर से software security vulnerabilities समस्या का सिर्फ एक हिस्सा हैं; दूसरा हिस्सा यह है कि telecom operators control और core access सबसे कम बोली लगाने वालों को खुशी-खुशी outsource कर देते हैं: https://berthub.eu/articles/posts/5g-elephant-in-the-room/