Hetzner·Linode पर Jabber.ru के एन्क्रिप्टेड ट्रैफिक को इंटरसेप्ट किए जाने के संकेत मिले

 (notes.valdikss.org.ru)
1 पॉइंट द्वारा GN⁺ 2023-10-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • रूसी XMPP सेवा jabber.ru/xmpp.ru के Hetzner dedicated server और Linode VPS पर port 5222 XMPP STARTTLS connections को transparent MiTM proxy से इंटरसेप्ट किए जाने के संकेत मिले
  • हमलावर ने Let’s Encrypt से कई TLS certificates जारी कराकर encrypted connections को बीच में terminate किया, और Hetzner के jabber.ru port 5222 द्वारा expired certificate लौटाने पर समस्या सामने आई
  • server compromise या उसी network segment में ARP spoofing के निशान नहीं मिले, और Linode instance ने सामान्य VM से अलग route और gateway MAC दिखाया, जिससे hosting network reconfiguration की संभावना बढ़ती है
  • MiTM कम-से-कम 21 जुलाई 2023 से 19 अक्टूबर 2023 तक पुष्टि किया गया, और 18 अप्रैल 2023 से शुरू होने की संभावना बची हुई है; port 5222 connections के 100% प्रभावित हुए और port 5223 इससे बाहर था
  • उस अवधि के jabber.ru/xmpp.ru communications को compromised माना जाना चाहिए, और OMEMO, OTR, PGP जैसे end-to-end encryption भी तभी सुरक्षित रहे जब दोनों पक्षों ने keys verify की हों

expired certificate से सामने आया interception

  • jabber.ru 2000 में शुरू हुई रूसी XMPP सेवा है, जिसे xmpp.ru के नाम से भी जाना जाता है
  • 16 अक्टूबर 2023 को service access करते समय “Certificate has expired” संदेश दिखा, लेकिन server पर install सभी certificates updated थे
  • यह anomaly केवल XMPP STARTTLS के लिए port 5222 पर दिखी, और XMPP TLS के port 5223 जैसे दूसरे ports पर observe नहीं हुई
  • प्रभावित servers में Germany का एक Hetzner dedicated server और दो Linode virtual servers शामिल थे
  • port 5222 traffic में देखा गया कि server को client का original ClientHello नहीं बल्कि replaced ClientHello मिल रहा था

server के अंदर compromise की जांच के नतीजे

  • जांच का दायरा server hacking की संभावना और local network spoofing की संभावना था
  • server side पर निम्न items जांचे गए, लेकिन कोई खास anomaly नहीं मिली
    • पूरे logs
    • executables और libraries के modification times
    • running processes, memory maps, dangling file descriptors
    • statically compiled busybox का उपयोग करके user-space LD_PRELOAD hijacking library की मौजूदगी
    • LiME से kernel memory dump करके volatility से analyze की गई kernel-level hijacking module की मौजूदगी
  • Hetzner dedicated server के kernel logs में केवल 18 जुलाई 2023 को physical network link के 19 seconds तक टूटने का record असामान्य रूप से मिला
  • Linode servers केवल Hetzner server तक alternative route के लिए tunnel के रूप में इस्तेमाल किए गए थे, और SSH, NTP जैसी basic services ही चल रही थीं
  • Hetzner↔Linode tunnel के अंदर Hetzner server का normal ServerHello दिखा, लेकिन Linode network interface से client को भेजते समय यह बदल गया
    • यानी उसी तरह का encrypted connection interception Hetzner और Linode दोनों तरफ हुआ

Linode network में दिखे असामान्य संकेत

  • network perspective से निम्न items जांचे गए, लेकिन server के आसपास network में hijacking के निशान नहीं मिले
    • gateway MAC address पर ARP spoofing की मौजूदगी
    • L2 segment में एक IP ARP requests का कई बार जवाब देता है या नहीं
    • ICMP redirect आदि से inject किए गए abnormal routing rules
    • Netfilter rules
    • IPsec जैसे आसानी से detect न होने वाले tunnel की मौजूदगी
  • प्रभावित Linode machine उसी network segment के adjacent IPs को ARP से खोज या ping नहीं कर सकती थी, लेकिन external networks से वे adjacent IPs normal तरीके से काम कर रहे थे
  • अप्रभावित third-party Linode VM adjacent hosts को ping कर सकता था और Cisco Systems router से जुड़ा था
  • इसके उलट प्रभावित VPS ऐसे gateway से जुड़ा था जिसके MAC address के manufacturer की पहचान नहीं हो सकी
  • इस फर्क के कारण यह संभावना बढ़ती है कि प्रभावित Linode VM सामान्य Linode instance से अलग network setup में था, या किसी separate VLAN में isolate किया गया था

forged certificates और Certificate Transparency के निशान

  • crt.sh certificate transparency database में jabber.ru servers द्वारा जारी न किए गए rogue certificates मिले
  • normal XMPP service में दो प्रकार के certificates इस्तेमाल होते थे
    • xmpp.ru, *.xmpp.ru
    • jabber.ru, *.jabber.ru
  • maliciously issued certificates की configuration normal certificates से थोड़ी अलग थी
    • wildcard Subject Alternative Name गायब था, या
    • jabber.ru, xmpp.ru को एक ही certificate में जोड़कर issue किया गया था
  • xmpp.ru domain की ओर इशारा करने वाली Linode-side MiTM configuration में कुछ गलतियां थीं
    • original server requested XMPP domain के अनुसार jabber.ru और xmpp.ru दोनों certificates देने के लिए configured था
    • MiTM side केवल xmpp.ru certificate देता था
  • 18 जुलाई 2023 का certificate issuance time, Hetzner server के network link के कुछ seconds के लिए टूटने के समय से लगभग मेल खाता है
  • external network scanner ने confirm किया कि Linode server कम-से-कम 21 जुलाई 2023 से port 5222 पर 04:b7:85… certificate दे रहा था
  • उस scanner ने Hetzner range process नहीं की थी

port 5222 के आगे का equipment और route difference

  • बाहर से Linode VPS पर additional network tests किए गए
  • उसी Linode segment के adjacent hosts laptop internet connection से hop 13 पर पहुंच योग्य थे
  • dawn.jabber.ru Linode server का intercepted port 5222 भी hop 13 पर पहुंच योग्य था
  • लेकिन उसी server के SSH port 22 जैसे non-intercepted ports केवल एक additional private hop से गुजरकर hop 14 पर पहुंच योग्य थे
  • इस result का मतलब है कि Linode VM का IP address किसी additional device के पीछे रखा गया था, और वह device TCP port 5222 को directly handle करता था जबकि दूसरे ports को actual destination तक route करता था
  • VPS के अंदर source port 5222 से नई connection बनाना संभव नहीं था
    • router उस source port से निकले packets का जवाब नहीं देता था
    • TTL=0 या TTL=1 outgoing packet के लिए ICMP error या Time-to-Live Exceeded भी नहीं भेजता था

STARTTLS termination method और detection fingerprint

  • testssl.sh से जांच में पाया गया कि intercepting proxy Linode xmpp.ru और Hetzner jabber.ru दोनों पर anonymous ciphers allow करता है
  • यह एक दुर्लभ misconfiguration है और XMPP MiTM detection fingerprint के रूप में इस्तेमाल हो सकती है
  • सामान्य SSL/TLS libraries आम तौर पर anonymous cipher support के बिना compile होती हैं, और config file में explicit allow करने पर भी service को उनका उपयोग करने के लिए configure करना अक्सर मुश्किल होता है
  • original server पर anonymous cipher configured नहीं था
  • उसी testssl.sh command से करीब 20 popular XMPP services की जांच की गई, लेकिन Anonymous NULL Ciphers support जैसी anomaly नहीं मिली

confirmed conclusions और user impact

  • हमलावर ने 18 अप्रैल 2023 से jabber.ru और xmpp.ru domains के लिए Let’s Encrypt से कई SSL/TLS certificates जारी कराए
  • jabber.ru/xmpp.ru client XMPP traffic decrypt करने के लिए Man-in-the-Middle attack कम-से-कम 21 जुलाई 2023 से 19 अक्टूबर 2023 तक confirm हुआ
  • 18 अप्रैल 2023 से शुरू होने की संभावना है, लेकिन यह confirm नहीं है
  • impact scope XMPP STARTTLS port 5222 connections का 100% है, और port 5223 शामिल नहीं है
  • हमलावर TLS certificate reissue करने में विफल रहा, और Hetzner के jabber.ru port 5222 पर MiTM proxy expired certificate देने लगा
  • MiTM attack 18 अक्टूबर 2023 की investigation और network tests, तथा Hetzner·Linode support tickets submit करने के तुरंत बाद बंद हो गया
  • हालांकि कम-से-कम एक Linode server पर additional routing hop के रूप में passive eavesdropping जारी रहा
  • server hack होने के कोई निशान नहीं थे, और ऐसा दिखता है कि Hetzner और Linode networks को XMPP service IP addresses को target करके इस attack के लिए reconfigure किया गया था
  • उस अवधि के jabber.ru/xmpp.ru communications को compromised माना जाना चाहिए
    • हमलावर account password जाने बिना भी authenticated account से execute होने जैसा व्यवहार कर सकता था
    • account roster download, unencrypted server-side full message history access, नए messages भेजना, और real-time messages बदलना संभव था
  • OMEMO, OTR, PGP जैसे end-to-end encrypted communications interception से तभी सुरक्षित हैं जब दोनों पक्षों ने encryption keys verify की हों
  • users को PEP storage में नए unauthorized OMEMO·PGP keys की जांच करनी चाहिए और password बदलना चाहिए

operators के लिए prevention और monitoring

  • नए certificate issuance Certificate Transparency में record होते हैं, इसलिए Certificate Transparency monitoring set की जा सकती है
  • RFC 8657 के CAA Record Extensions for Account URI and ACME Method Binding का उपयोग करके certificate issuance method और issuable account identifiers को restrict किया जा सकता है
  • सभी services के SSL/TLS certificate changes को external service से monitor किया जा सकता है
  • default gateway के MAC address changes को monitor किया जा सकता है
  • XMPP का channel binding intercepting side के valid certificate पेश करने पर भी MiTM detect कर सकता है
    • client और server दोनों को SCRAM PLUS authentication mechanism support करना चाहिए
    • attack के समय jabber.ru पर यह enabled नहीं था
  • ACME developer Hugo Landau की additional recommendations More recommendations from ACME developer Hugo Landau में संकलित हैं

Hetzner और Linode के जवाब

  • 20 अक्टूबर 2023 तक Hetzner और Linode से पर्याप्त जवाब नहीं मिला था
  • 3 नवंबर 2023 के update में भी दोनों कंपनियों ने इस incident पर उचित जवाब नहीं दिया
  • Hetzner ने कहा कि वह dedicated root servers और Cloud servers के लिए केवल hardware, network access और आवश्यक infrastructure प्रदान करता है, इसलिए वह कोई additional solution नहीं दे सकता
  • Linode ने logs प्राप्त किए, लेकिन कहा कि उसने service को प्रभावित करने वाली illegal activity observe नहीं की, और ticket close कर दिया
  • operations side इस संभावना को अधिक वजन देता है कि German police request के तहत lawful interception के लिए Hetzner और Linode को configuration लागू करने के लिए मजबूर किया गया
  • एक और संभावना यह है कि Hetzner और Linode दोनों के internal networks में jabber.ru को specifically target करते हुए intrusion हुआ हो, लेकिन यह कहीं कम विश्वसनीय है और पूरी तरह असंभव नहीं होने वाला scenario बना रहता है

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

1 टिप्पणियां

 
GN⁺ 2023-10-21
Hacker News की टिप्पणियां

  • यह रूस की साइबरक्राइम जांच से जुड़ा होने की काफी अधिक संभावना लगती है। अगर आपने Krebs पढ़ा है या रूसी अंडरग्राउंड forums देखे हैं, तो xmpp.ru जाना-पहचाना लगेगा; असल में इसका वही संदर्भ है
    ऑपरेटर पर कुछ थोपने की कोशिश नहीं है, मतलब बस यह है कि anonymous service चलाने पर उसका स्वरूप ऐसा हो जाता है
    https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
    https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
    https://blog.talosintelligence.com/picking-apart-remcos/
    https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
    पोस्ट खुद वाकई दिलचस्प है, और यह एक practical example जैसा लगता है कि सभी को certificate transparency monitoring services इस्तेमाल करनी चाहिए

    • ड्रग संगठनों में Tor के साथ XMPP को सुरक्षित communication channel के रूप में व्यापक तौर पर इस्तेमाल किया जाता है। डार्कनेट मार्केट Hydra 2022 में EU में अपनी “services” फैलाने की कोशिश कर रहा था, तब जर्मन पुलिस ने उसे बंद कर दिया; यहां भी कुछ वैसा हुआ हो सकता है, या नहीं भी
    • मैं भी मोटे तौर पर ऐसा ही सोचता हूं। लगता है कि यह Genesis Market या Qakbot के बंद किए जाने से संबंधित हो सकता है

  • mitigation के ज्यादातर सुझावों से सहमत हूं। अगर target high-risk है, तो trusted certificate authorities पर निर्भर न रहने वाली authentication layers ऊपर से जोड़ने पर भी विचार किया जा सकता है: Tor onion services, SSH, WireGuard जैसी चीजें
    इस बात से सहमत हूं कि जारी किए गए सभी SSL/TLS certificates certificate transparency के दायरे में आते हैं, और crt.sh में RSS feed भी है
    CAA का इस्तेमाल सामान्य तौर पर अच्छा विचार है, लेकिन इस मामले में उससे मदद मिलेगी या नहीं, इस पर संदेह है। क्योंकि attacker CAA में allowed वही exact certificate configuration request कर सकता है; अगर specific validation method को और सख्ती से restrict किया जा सके, तो मदद मिल सकती है
    यह भी सहमत हूं कि सभी services के SSL/TLS certificate changes को external service से monitor करना चाहिए। high-risk targets को हमेशा पता होना चाहिए कि कौन-सा certificate valid है और इसे check करना चाहिए
    default gateway के MAC address changes को monitor करने का तरीका—ज्यादा sophisticated attack में MAC address को जस का तस रखा जा सकता है
    मुझे पहली बार पता चला कि XMPP की “channel binding” valid certificate पेश करने वाले man-in-the-middle attack को भी detect कर सकती है

    • मैं ACME-CAA (RFC 8657) का author हूं। CAA record में ACME account का unique identifier डाला जा सकता है, इसलिए जब तक attacker ACME account की private key न हासिल कर ले या ACME service को compel न करे, ऐसे attack को mitigate किया जा सकता है
      बेशक, यह assumption है कि nameserver DNSSEC से protected है। नहीं तो certificate authority के lookup करते समय DNS requests भी intercept की जा सकती हैं
      security considerations की पूरी सूची RFC 8657 में देखी जा सकती है। यह RFC आम RFCs की तुलना में पढ़ने में आसान बनाने के लिए design किया गया है
      background explanation वाली मेरी blog post: https://www.devever.net/~hl/acme-caa-live
    • अगर कोई राज्य अपने देश की certificate authority को बिना CT log के certificate issue करने का आदेश दे और gag order भी लगा दे, तो क्या होगा? न मानने पर जेल जाने की नौबत हो तो एक सामान्य system administrator शायद किसी Russian Jabber server को बचाने के लिए जेल जाना नहीं चाहेगा
    • अगर server तक physical access हो, तो वे बस उसी को target करेंगे। थोड़ी मेहनत से commodity hardware की disk, network, RAM को mirror किया जा सकता है

  • अगर उन्होंने असल man-in-the-middle attack को perfect तरीके से अंजाम दिया और certificate renewal भूल गए, तो यह काफी German-style बात होगी :-)

    • मुझे लगता है शायद किसी ने जानबूझकर “भूल” की हो। हो सकता है लोगों को यह बात पता चलवाने के लिए ऐसा किया गया हो
      या फिर शायद किसी ने आदेशों का बहुत ईमानदारी से पालन किया हो। certificate set करने का आदेश था, लेकिन auto-renewal की requirement नहीं थी :)
    • Let’s Encrypt लगातार notification emails भेजता है, फिर ऐसा कैसे हो सकता है?

  • Archive: https://archive.ph/C0jYJ
    theories दिलचस्प हैं, और अगर सच हैं तो बताती हैं कि certificate कैसे हासिल किया गया। यहां से सीख यह हो सकती है कि कई providers पर कई probes रखें, सभी TLS fingerprints check करें, unknown fingerprint दिखने पर alert पाएं, और certificate transparency logs की मौजूदगी भी verify करें
    openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin
    SHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16

    • “क्या ऐसे attack को prevent या monitor किया जा सकता है?” section जोड़ा गया है। पहले दिन से attack detect करने के लिए कई signals इस्तेमाल किए जा सकते हैं
      जारी किए गए सभी SSL/TLS certificates certificate transparency के दायरे में आते हैं, इसलिए Cert Spotter जैसी certificate transparency monitoring setup करना अच्छा है ताकि domain के लिए नया certificate issue होने पर email alert मिले
      RFC 8657 के CAA record extensions, यानी Account URI और ACME Method Binding से validation method को restrict करके और नया certificate issue कर सकने वाले exact account identifier को specify करके, दूसरे certificate authorities, ACME accounts या validation methods के जरिए domain certificate issuance को रोका जा सकता है
      external service से सभी services के SSL/TLS certificate changes को monitor करना चाहिए, और default gateway के MAC address changes को भी monitor करना चाहिए

  • MAC address local administered address नहीं था, इसलिए थोड़ा उत्सुक लगा। ऐसा लगा कि किसी ने यह address range जानबूझकर चुनी हो सकती है
    https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
    "90:de:01" linode और "90:de:00" linode खोजने पर लगता है कि हाल में इस block के addresses दूसरे Linode VM को भी assign किए गए हैं। अभी सीधे compare करने के लिए मेरे पास कोई Linode VM नहीं है, लेकिन traffic ऐसा दिखता है जैसे उसे Linode infrastructure के किसी दूसरे VM पर route किया गया हो

  • बिना आधार वाली अटकल है, लेकिन मुझे लगता है Jabber को target इसलिए किया गया क्योंकि darknet markets में drug trade या दूसरी illegal activities के लिए इसका इस्तेमाल मशहूर है
    यह दिखाता है कि सिर्फ “encrypted है, इसलिए ठीक है” पर भरोसा नहीं करना चाहिए। कम-से-कम messages को PGP से encrypt करना चाहिए
    मुझे यह भी जिज्ञासा है कि क्या PGP quantum computers से टूट सकता है, और आगे ऐसे attacks के खिलाफ hardening आएगी या नहीं। अगर messages बड़े पैमाने पर encrypted form में collect किए गए हैं, तो आखिरकार decrypt होना समय की बात हो सकता है
    और ऐसा लगता है कि हाथ लग सकने वाले लगभग हर web traffic के साथ यह हो रहा है। https://en.wikipedia.org/wiki/Utah_Data_Center देखें

    • Jabber/XMPP में कम-से-कम 10–15 साल पहले से end-to-end encryption मौजूद था। जब Facebook/Google Talk XMPP support करते थे, तब pidgin, kopete आदि से आम दोस्तों के साथ भी इसे ऐसे ही इस्तेमाल किया जाता था
      बेशक, internet पर किसी anonymous drug seller के साथ सुरक्षित तरीके से key exchange करना गलती करने में आसान है
    • यह man-in-the-middle attack Genesis Market shutdown का हिस्सा भी हो सकता है, लेकिन यह बस अचानक की गई अटकल है
      https://therecord.media/genesis-market-takedown-cybercrime
    • encryption की दूसरी layer मददगार होगी, लेकिन PGP को मैं खास तौर पर recommend नहीं करूंगा
      PGP में कई problems हैं और बहुत लोग इससे बचने की सलाह देते हैं। जैसे: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780

  • OMEMO, OTR, PGP जैसी end-to-end encrypted communications interception से तभी बचाती हैं जब दोनों पक्ष encryption keys verify कर चुके हों। attacker को इस्तेमाल किए गए हर end-to-end encryption method के लिए अलग man-in-the-middle attack बनाना होगा
    मैंने कुछ XMPP clients में देखा है कि जब तक वे यह न दिखाएं कि किसी खास encryption identity को explicitly verify किया गया है, तब तक उसे इस्तेमाल नहीं करने देते
    फिर भी यह अच्छी reminder है। अगर आपने कभी बेहद लंबी संख्या या उसके बराबर किसी value को देखकर handle नहीं किया है, तो यह मानना मुश्किल है कि end-to-end encryption सच में स्थापित हुआ था

  • इस कहानी में एक बात समझ नहीं आती। अगर यह lawful interception था, तो Hetzner और Linode ने अलग LE certificate और key के साथ man-in-the-middle interception क्यों set up किया होगा
    VPS की RAM या storage से TLS private key सीधे extract कर सकते थे। physical dedicated server भी हो तो बिना चेतावनी reboot के बाद RAM dump लेकर private key निकाली जा सकती है
    private key extraction CT logs में नहीं दिखता, इसलिए यह कहीं ज्यादा गुप्त और practically detect करना मुश्किल होता

    • शायद इसलिए कि यह ज्यादा आसान था
      एक और संभावना यह है कि एक पक्ष “search” था और दूसरा “interception”, इसलिए approval levels अलग रहे होंगे। हालांकि मुझे मौजूदा German legal situation की जानकारी नहीं है
    • शायद इसलिए कि वह तरीका “ज्यादा illegal” होता। अगर server सीधे cybercrime activity में involved नहीं है, तो server hack करना शायद allowed नहीं होगा
    • अगर physical server हो तो PCIe card को hot-plug करके DMA के जरिए मनचाहा data निकाला जा सकता है, है न? किसी purpose-built firmware वाले network card जैसे device से संभव लगता है
      law enforcement agencies के लिए यह इतना standard तरीका सुनाई देता है कि ऐसा equipment off-the-shelf मौजूद हो सकता है

  • एक user ने 3 दिन पहले ही Reddit पर post किया था: https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...

  • सोच रहा हूं कि क्या Hetzner/Linode से इस situation पर comment करने की legally मांग करने का कोई तरीका है। interception के पीछे किसी government agency या police होने की संभावना ज्यादा लगती है

    • Hetzner एक German company है, इसलिए अगर यह lawful interception है, तो जवाब मांगना संभव नहीं होगा। पहले lawyer के जरिए गए बिना मुश्किल है
      उल्टा, अगर यह lawful interception नहीं है तो Hetzner ने इसे allow किया होगा, ऐसा नहीं लगता। क्योंकि वह भी law violation होगा
    • इसकी कोई guarantee नहीं कि interception Hetzner या Linode के जरिए ही हुआ। उदाहरण के लिए यह telecom provider side पर भी हो सकता है, और लगभग हर देश में दशकों से telecom operators को lawful interception में सहयोग करने के लिए मजबूर किया जाता रहा है