qBittorrent RCE भेद्यता: 14 साल तक SSL certificate validation errors को अनदेखा किया गया

 (sharpsec.run)
2 पॉइंट द्वारा GN⁺ 2024-11-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • qBittorrent का DownloadManager 6 अप्रैल 2010 से 12 अक्टूबर 2024 तक लगभग 14 साल 6 महीने तक SSL certificate validation errors को अनदेखा करता रहा, जिससे network interception की स्थिति में कई download flows attack surface बन गए
  • इस समस्या को CVE-2024-51774 सौंपा गया है, और इसका दुरुपयोग करने के लिए MITM access या DNS spoofing की आवश्यकता होती है
  • Search, .torrent download, RSS feed और favicon download जैसे DownloadManager का उपयोग करने वाले paths प्रभावित थे, और expired या self-signed certificates भी स्वीकार किए जा सकते थे
  • Windows का Python install prompt और update-check RSS flow, hardcoded URL response बदले जाने पर executable download या update link manipulation तक ले जा सकता है
  • उपयोगकर्ताओं के लिए app के अंदर के update prompt की बजाय browser में v5.0.1 को सीधे manually download करके upgrade करना अधिक सुरक्षित है

14 साल से अधिक समय तक जारी certificate validation bypass

  • qBittorrent की DownloadManager class, 6 अप्रैल 2010 के commit 9824d86 के बाद से सभी SSL certificate validation errors को अनदेखा करती रही
  • default behavior को 12 अक्टूबर 2024 के commit 3d9e971 में certificates को validate करने वाले तरीके में बदला गया
  • इस लेखन के समय के अनुसार पहला patched release 2 दिन पहले जारी हुआ qBittorrent v5.0.1 है
  • इस समस्या को CVE-2024-51774 सौंपा गया है
  • exploit की शर्तें हैं MITM access या DNS spoofing

DownloadManager द्वारा बना बड़ा attack surface

  • DownloadManager के उपयोग का दायरा व्यापक होने से search, .torrent download, RSS feed और favicon download आदि प्रभावित हुए
  • ये paths expired certificates, self-signed certificates, या दोनों तरह के certificates भी स्वीकार कर सकते थे
  • मुख्य impact paths को Windows Python installation, software updates, RSS feeds, और decompression library attack surface में बांटा जा सकता है

Windows Python installation flow में executable download

  • Windows पर यदि पर्याप्त नया Python install नहीं है, तो qBittorrent search plugin के उपयोग के लिए Python install या update करने का prompt दिखाता है
  • यदि उपयोगकर्ता default चुने गए Yes पर क्लिक करता है या Enter दबाता है, तो hardcoded python.org URL से Python installer download किया जाता है
  • download के बाद qBittorrent उस file का नाम बदलकर .exe कर देता है और उसे चलाता है, फिर पूरा होने पर temporary file हटा देता है
  • यह behavior जून 2015 से अब तक मौजूद रहा है, और v3.2.1 से v5.0.0 तक प्रभावित हैं
  • अन्य OS variants में, यदि Python नहीं है या पर्याप्त नया नहीं है, तो search widget disable कर दिया जाता है, और वही behavior पुन: उत्पन्न नहीं होता दिखता
  • executable को उदाहरण के लिए C:\Users\_user_\AppData\Local\Temp\is-G61QK.tmp जैसे path में save किया जा सकता है
  • संभवतः QProcess behavior की वजह से, executable thread की दो instances बन सकती हैं, जिनमें से केवल एक बंद होती है और दूसरी sleeping state में रह सकती है

update-check RSS के जरिए URL manipulation

  • install किया गया Windows या Linux संस्करण वाला qBittorrent, यदि वह appImage file नहीं है, तो चलने पर default रूप से update check करता है
  • update check, hardcoded Fosshub RSS URL से XML document download करके program release information parse करने के तरीके से काम करता है
  • XML में यदि वर्तमान चल रहे version से उच्च version मिलता है, तो update URL निकाला जाता है, और बिना अतिरिक्त filtering या validation के उपयोगकर्ता से उस URL पर जाने के लिए पूछा जाता है
  • यदि उपयोगकर्ता prompt स्वीकार करता है, तो default browser में वह URL खुल जाता है
  • उपयोगकर्ता software द्वारा दिए गए link के trust context में .exe file की अपेक्षा कर सकता है
  • यदि attacker mediafire जैसी file-sharing site की ओर ले जाए, तो उपयोगकर्ता attacker-controlled executable को upgrade समझकर डाउनलोड कर सकता है
  • qBittorrent open source होने के कारण नवीनतम version में backdoor functionality जोड़कर उसे फिर से compile करना आसान है
  • developers binary signature verification के लिए keys प्रदान करते हैं, लेकिन सुरक्षा तभी प्रभावी है जब उपयोगकर्ता वास्तव में verify करे और verification failure को गंभीरता से माने

RSS feed और link injection

  • application द्वारा parse की जाने वाली सभी RSS feeds DownloadManager से होकर गुजरती हैं, इसलिए उन्हें hijack किया जा सकता है
  • पीड़ित द्वारा देखे जाने वाले URLs को observe और list किया जा सकता है, और RSS URLs स्वभाव से static होते हैं और लंबे समय तक बने रहते हैं
  • प्रत्येक item का link element सीधे parse किया जाता है, और उपयोगकर्ता double-click करने पर उसे download किया जा सकता है
  • MITM tampering न होने पर भी, उपयोगकर्ता जिस RSS feed को subscribe करता है उसमें author या feed-poisoning attacker द्वारा डाला गया कोई भी arbitrary URL एक double-click से खुल सकता है
  • CVE-2019-13640 वह भेद्यता थी जिसने torrent name या current tracker parameter के shell metacharacters के जरिए remote command execution की अनुमति दी थी, और MITM attacker RSS में malicious data डाल सकता है, जिससे combined risk बढ़ जाता है

GeoIP database download और decompression attack surface

  • qBittorrent चलने पर default रूप से hardcoded URL से .gz extension वाली binary MaxMind GeoIP database को auto-download और decompress करता है
  • यदि zlib decompression में कोई भेद्यता हो, तो attacker अधिकतम 64MB arbitrary file के साथ इस attack surface को निशाना बना सकता है
  • उदाहरण के तौर पर बताई गई CVE-2022-37434, 2022 की CVSS 9.8 Critical buffer overflow है, लेकिन यहां inflateGetHeader() function call नहीं होता, इसलिए यह लागू नहीं होती
  • decompression के बाद binary MaxMind database को parse करने वाला code 2024 तक अच्छी तरह सुरक्षित है, लेकिन अतीत में स्थिति अलग थी और अतिरिक्त attack surface रहा हो सकता है
  • gzip::decompress() function के एक commit में target buffer को stack की static allocation से heap की dynamic allocation में बदला गया था, और write से पहले checks होने के कारण यह exploitable नहीं था

automation योग्य attack scenarios

  • Python installer URL और update RSS feed URL दोनों hardcoded हैं, इसलिए MITM environment में malicious script vulnerable versions को enumerate करके attack कर सकती है
  • RSS feed URL, qBittorrent के चलने के दौरान ही visit होने की वजह से software fingerprint के रूप में इस्तेमाल किया जा सकता है
  • certificate validation न होने के कारण attacker QUANTUM जैसे जटिल Man-On-The-Side deployment के बिना target server को spoof कर सकता है
  • hardcoded URL की प्रकृति के कारण browser या अन्य applications की secure connection failure चेतावनी के बिना, केवल qBittorrent के unvalidated requests को selectively intercept किया जा सकता है
  • mitmproxy के -s option और Python script को साथ इस्तेमाल करने पर निम्न automation संभव है
    • Python .exe को arbitrary executable से बदलना: single-click RCE
    • qBittorrent update RSS के URL को automatically बदलना: browser hijacking/RCE, मध्यम स्तर की user interaction आवश्यक
    • qBittorrent RSS viewer के पूरे या specific links को बदलना: 2019 तक RCE, download hijacking

upgrade और workaround

  • qBittorrent v5.0.1 पर upgrade करना चाहिए
  • upgrade के लिए app के अंदर के update prompt की बजाय browser से सीधे manual download करने की सिफारिश की जाती है
  • विकल्प के रूप में Deluge, Transmission जैसे ऐसे clients उपयोग किए जा सकते हैं जिनमें यह भेद्यता नहीं है
  • MITM आवश्यक होने वाले attacks को केवल theoretical risk मानकर खारिज करना कठिन है, और हालिया इतिहास व कुछ देशों के वास्तविक उदाहरणों को ध्यान में रखना चाहिए
  • repository maintainer से संपर्क हुआ था, लेकिन GitHub security advisory जारी करने का इरादा है या नहीं, इस पर कोई उत्तर नहीं मिला

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

1 टिप्पणियां

 
GN⁺ 2024-11-02
Hacker News की राय

  • qBittorrent की DownloadManager क्लास 6 अप्रैल 2010 के commit 9824d86 के बाद से 14 साल 6 महीने तक सभी प्लेटफ़ॉर्म पर आने वाली सभी SSL certificate verification errors को ignore करती रही
    यह काफ़ी गंभीर लगता है

    • ध्यान देने वाली बात यह है कि यह bug नहीं, बल्कि “feature” था
      void downloadThread::ignoreSslErrors(QNetworkReply* reply,QList errors) {
      // Ignore all SSL errors
      reply->ignoreSslErrors(errors);
      }

      https://github.com/qbittorrent/qBittorrent/commit/9824d86a3c...

  • मैं इस vulnerability को हल्का नहीं दिखाना चाहता, लेकिन remote code execution संभव होने वाले path में valid TLS certificate और domain name के combination को ही इकलौती रक्षा-रेखा मानना लगभग आपदा जैसा है
    कम-से-कम अगर application इंटरनेट से कोई artifact डाउनलोड करके चलाती है, तो उसे किसी खास version पर pin करना चाहिए और चलाने से पहले डाउनलोड की गई file का hash verify करना चाहिए

    • तो क्या इसका मतलब है कि automatic updates असंभव हैं?

    • मेरे हिसाब से न्यूनतम मानक signature verification है
      अगर software को पर्याप्त बार update किया जाता है, तो key rotation के मौके भी पर्याप्त मिलेंगे

    • Windows पर build tools में code signing certificate इस्तेमाल करके, डाउनलोड की गई binary को operating system से verify कराया जा सकता है
      हालांकि code signing में timestamp server ज़रूर इस्तेमाल करना चाहिए, ताकि certificate expire होने के बाद भी चीज़ें न टूटें

    • यहां संभावित man-in-the-middle attack की प्रकृति के कारण hash check मुश्किल लगता है
      अगर attacker request की सामग्री देख और बदल सकता है, तो hash check integrity verification के अलावा बेकार हो जाता है

      desktop app का किसी खास domain पर automatic update या check request भेजने का तरीका, कुल मिलाकर security के नज़रिए से शायद पर्याप्त ध्यान नहीं पाता
      ऐसे scenario भी हैं जहां मूल लेखक domain renew करना बंद कर दे और वह hostile तरीके से hijack हो जाए, लेकिन अभी तक अच्छा समाधान नहीं मिला

  • यह जानना हैरान करने वाला होगा कि पिछले लगभग 15 सालों में असल में कितने लोग इस issue से प्रभावित हुए
    इंटरनेट के थोड़े संदिग्ध हिस्से में भी, भीड़ में घुलमिल सकने वाले attacker के लिए SSL verification कितना महत्वपूर्ण रहा होगा, यही सोचता हूं
    बहुत सारी चीज़ें “बस चलती रहती” हैं क्योंकि कोई परवाह नहीं करता, और अब जब यह issue spotlight में आ गया है, तो जो लोग automatic update नहीं करते उनके लिए स्थिति खराब ही होगी

    • शायद यह संख्या 0 के करीब होगी
      यह code python.org से Python डाउनलोड करने के लिए था, और इसका exploit संभव है, लेकिन काफ़ी targeted होना पड़ेगा और target तक कुछ हद तक access पहले से चाहिए होगा
      किसी और तरीके से exploit करने के लिए python.org domain hijack जैसी चीज़ चाहिए होगी, जिसे शायद सब notice कर लेते
    • यह जानना दिलचस्प होगा कि पिछले लगभग 15 सालों में वास्तव में कितने लोग प्रभावित हुए, लेकिन निजी तौर पर मुझे लगता है कि संख्या लगभग 0 के करीब है
      अगर कोई प्रभावित हुआ भी होगा, तो ज़्यादातर संभावना है कि वह targeted attack रहा होगा
    • मुझे भी लगता है 0
      article का बड़ा हिस्सा बढ़ा-चढ़ाकर लिखा हुआ लगता है, और हां, कुछ गड़बड़ तो है, लेकिन “qBittorrent remote code execution” कहना तकनीकी रूप से सही होते हुए भी काफी alarmist है
    • web browser से किए जाने वाले काम web browser से ही करता हूं, और torrent app तभी खोलता हूं जब खुद से मिली .torrent file डाउनलोड करनी हो
    • मैंने भी यही सोचा
      वास्तविक data पाना लगभग असंभव लगता है, लेकिन अगर देख पाते तो मज़ेदार होता

  • अगर आपने qBittorrent का code देखा है, तो पता होगा कि वह सचमुच भयानक code था
    बिना comments वाले functions कई-कई pages तक चलते थे, line spacing भी बेहद घनी थी, और वह किसी बेगुनाह कैद किए गए psychosis patient की जेल-डायरी जैसा दिखता था
    मैंने जितना छोटा हिस्सा देखा, compressed कुछ pages भर में ही, return values की कोई checking नहीं थी

    याद है कि किसी field में आम तौर पर सही 2-letter value की जगह सही 3-letter value आ जाए, तो करीब 1 मिनट बाद program crash हो जाता था
    करीब 20 साल पहले C++ में पैसे लेकर programming दो बार की थी, और maintainer का “तो खुद ही देख लीजिए” वाला message मिलने पर मैंने इसे debugger में चलाकर देखा
    GUI में गलत value और सही value पढ़े जाने की जगह तक पहुंचा, और उस value को follow करते-करते देखा कि कब -1 इधर-उधर pass होने लगा, और program कुछ समय तक बस चलता रहा

    आखिर में गलत value के साथ चला हुआ path किसी काफी दूर के function में, बेगुनाह कैद किए गए psychosis patient जैसे error message के साथ crash हो गया
    बाद में असली qBittorrent developers में से एक ने अगले release में इसे fix कर दिया, लेकिन code ऐसा ही था

  • बस “BUGFIX: Don't ignore SSL errors (sledgehammer999)” लिखा है
    https://www.qbittorrent.org/news
    निजी तौर पर मुझे लगता है कि security advisory होनी चाहिए

  • सही certificate check करने पर भी, remote executable डाउनलोड करके चलाना definition के हिसाब से remote code execution vulnerability है
    Syncthing भी यही तरीका इस्तेमाल करता है; शायद वह certificate check करता होगा, लेकिन unattended automatic updates को तार्किक रूप से RAT/Trojan horse से अलग करना मुश्किल है

    • बिल्कुल ऐसा नहीं है
    • इस बात से सहमत होना मुश्किल है
      vulnerability वाला हिस्सा तब पैदा होता है जब कोई third party उसका दुरुपयोग कर सके
      software provider पर वैसे भी भरोसा करना पड़ता है, इसलिए automatic update अपने-आप remote code execution vulnerability नहीं है
    • यह “क्या आप latest version पर upgrade करना चाहते हैं?” पर Yes दबाने से मूल रूप से अलग नहीं है
    • अगर वही लोग जिन्होंने original program डाउनलोड किया था unattended automatic update भी करते हैं, या अगर ऐसा नहीं है, तो इसे कैसे देखा जाए?

  • इस vulnerability का direct cause तो नहीं था, लेकिन ऐसी applications जो संभावित रूप से malicious nodes की बड़ी संख्या से communicate करती हैं, उन्हें memory safety से काफी फायदा हो सकता है
    लेकिन मौजूदा implementations सब C++ में लिखे हुए लगते हैं
    article में भी point 4 में ऐसी किस्म की vulnerability की संभावना पर बात की गई है

Python में लिखा Deluge भी C++ वाले libtorrent पर निर्भर करता है
मुझे नहीं पता कि पुराने Java-आधारित Azureus क्लाइंट का कोई आधुनिक fork है या नहीं
आजकल कई BitTorrent क्लाइंट GUI और असल torrent processing संभालने वाली daemon process को अलग रखते हैं, इसलिए daemon को Java में बनाकर native GUI से जोड़ें तो security, performance और user experience के बीच ठीक-ठाक संतुलन मिल सकता है

  • यूं ही थोड़ा खोजने पर भी कुछ pure Go BitTorrent libraries मिल जाती हैं

  • Rust में लिखा और libtorrent पर निर्भर न रहने वाला rqbit है: https://github.com/ikatson/rqbit

  • चर्चा के लिए खुद खोजने के बजाय अगर आलसी सवाल पूछूं, तो libtorrent का विकल्प बनाना हो तो शुरुआत कहां से करनी चाहिए?
    यह भी जानना चाहूंगा कि कोई कोशिशें या सफल उदाहरण रहे हैं या नहीं, और क्या किसी दूसरी implementation का उपयोग करने वाले वाकई काम करने वाले क्लाइंट मौजूद हैं

  • खासकर पीछे के items की ओर जाते-जाते यह थोड़ा बढ़ा-चढ़ाकर बताया गया लगता है
    नंबर 1, “छिपे हुए function वाला malicious executable loader”, असल में यह है कि client HTTPS से python.org से Python डाउनलोड करता है
    यह अच्छा नहीं है, और खासकर 3.12.4 पर hardcode होना भी समस्या है, लेकिन मुझे ऐसा स्पष्ट exploit path नहीं दिखता जिसमें man-in-the-middle attack और user interaction दोनों की जरूरत न हो

    नंबर 2, “browser hijacking + executable download”, असल में यह है कि client HTTPS से RSS file डाउनलोड करता है और कुछ शर्तों पर user से पूछता है कि उस file के अंदर का URL खोला जाए या नहीं
    इसका risk नंबर 1 से भी कम है, और user पर man-in-the-middle attack करके उसे “update” क्लिक करवाने पर भी आखिर में दिखा सकने वाली चीज सिर्फ web page ही है

    नंबर 3, “RSS feed में arbitrary URL injection”, लगता है researcher ने RSS client के expected behavior को गलत समझा है
    नंबर 4, “decompression library attack surface”, अगर आप zlib vulnerability खोज सकते हैं तो torrent client पर attack करने से कहीं ज्यादा बुरी चीजें कर सकते हैं
    input decompression मूल रूप से safe मानी जाने वाली operation है

    • stream compression support करने वाला HTTP server जैसी चीज तुरंत दिमाग में आती है

    • सही है
      बहुत negative नहीं कहना चाहता, लेकिन लगता है security “researchers” थोड़ी publicity के लिए बेहद कम संभावना वाली चीजों को भी पकड़ लेते हैं
      अगर इसे ईमानदारी से document किया होता तो मैं ज्यादा सम्मान करता, लेकिन यहां जिस तरह किया गया है वह बस नापसंदगी पैदा करता है

    • अगर certificate errors को ignore नहीं किया गया होता, तो वे items मामूली होते
      असली समस्या SSL errors को ignore करने में है, इसलिए व्यावहारिक रूप से सभी HTTPS downloads HTTP downloads में downgrade हो गए, और man-in-the-middle attack के बिना भी attack possible है

      दूसरे शब्दों में, SSL verification न होने की वजह से HTTPS URLs ने reviewers को सुरक्षा होने का झूठा भरोसा दे दिया

    • सहमत हूं
      इसे “remote code execution vulnerability” कहना बेहिसाब बढ़ा-चढ़ाकर कहना है

      क्या अगली बार यह कहा जाएगा कि web browser में “remote code execution vulnerability” है क्योंकि वह user को किसी arbitrary site से, जो safe हो भी सकती है और नहीं भी, program डाउनलोड करके चलाने देता है?
      या फिर यह भी नए सिरे से announce किया जाएगा कि अगर आप authoritarian country में रहते हैं तो सरकार बुरी चीजें कर सकती है?

  • article में दिए दूसरे options की तुलना में qBittorrent 1000 गुना ज्यादा performance वाला client है, ऐसे में इन issues की quality इतनी low होना चौंकाने वाला है

    • Deluge भी qBittorrent जितना ही performance देता है
      performance देने वाला libtorrent-rasterbar(libtorrent.org) है

  • latest version compile और run करने के लिए https://github.com/userdocs/qbittorrent-nox-static Docker से static binary build कर देने वाली अच्छी helper script है
    मैं libtorrent 1.2 के साथ 5.0.0 run करना चाहता था, और यह script भारी रूप से सबसे आसान निकली