हैक होने के बाद मेरे Hetzner सर्वर ने Monero माइनिंग शुरू कर दी

 (blog.jakesaunders.dev)
1 पॉइंट द्वारा GN⁺ 2025-12-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक व्यक्ति द्वारा संचालित Hetzner सर्वर पर असामान्य CPU उपयोग दिखा, और जांच करने पर पाया गया कि क्रिप्टोकरेंसी Monero माइनिंग प्रोग्राम (xmrig) चल रहा था
  • कारण यह था कि Umami analytics tool container, जिसमें Next.js की remote code execution vulnerability (CVE-2025-66478) मौजूद थी, उस पर हमला किया गया
  • सौभाग्य से वह container non-root user के रूप में चल रहा था और उसमें host mount या privilege escalation नहीं था, इसलिए घुसपैठ container के भीतर ही सीमित रही
  • हमलावर ने Next.js server components की unsafe deserialization का दुरुपयोग करके malicious payload चलाया और miner इंस्टॉल किया
  • यह मामला dependency management और container security settings के महत्व को दिखाता है, और लेखक ने firewall enable करना, SSH hardening, और नियमित updates जैसी सुरक्षा व्यवस्थाएं मजबूत कीं

हैक की घटना और शुरुआती प्रतिक्रिया

  • Hetzner से यह चेतावनी ईमेल मिला कि सर्वर बाहरी नेटवर्क को scan कर रहा था
    • इसमें यह सूचना भी थी कि 4 घंटे के भीतर कार्रवाई न होने पर सर्वर को block किया जा सकता है
  • SSH से लॉग इन करके जांचने पर /tmp/.XIN-unix/javae पथ पर 819% CPU उपयोग करने वाली process और कई xmrig processes मिलीं
  • पुष्टि हुई कि लगभग 10 दिनों तक क्रिप्टोकरेंसी माइनिंग चलती रही

घुसपैठ के रास्ते की जांच

  • सभी malicious processes UID 1001 user के रूप में चल रही थीं, जो Umami container से मेल खाती थीं
  • /app/node_modules/next/dist/server/lib/xmrig-6.24.0/ directory में miner executable मिला
  • run command में auto.c3pool.org:443 mining pool address और user key शामिल थी

Next.js vulnerability और हमले का तरीका

  • मूल कारण Next.js की React Server Components deserialization vulnerability (CVE-2025-66478) था
    • यदि हमलावर crafted HTTP request भेजे, तो सर्वर पर arbitrary code execute हो सकता है
    • नतीजतन क्रिप्टोकरेंसी miner को install और run करना संभव हो गया
  • लेखक को लगा था कि “वह Next.js का सीधे उपयोग नहीं करता,” लेकिन बाद में पता चला कि Umami, Next.js आधारित है

container isolation की पुष्टि

  • पुष्टि हुई कि /tmp/.XIN-unix/javae host filesystem पर मौजूद नहीं था
    • Docker के ps output में container process दिखने का यह केवल एक प्रभाव था; वास्तव में isolation बरकरार था
  • docker inspect के नतीजे
    • user: nextjs
    • Privileged: false
    • Mounts: नहीं
  • इसलिए malicious code host access, cron registration, system service creation, rootkit installation जैसी गतिविधियां नहीं कर सका

recovery और security hardening

  • संक्रमित Umami container को stop और delete करने के बाद CPU उपयोग सामान्य हो गया
  • UFW firewall enable करके केवल SSH·HTTP·HTTPS की अनुमति दी गई
  • Hetzner को जांच के नतीजे भेजने के बाद ticket 1 घंटे के भीतर बंद हो गया

सबक और सुधार के बिंदु

  • “मैं X का उपयोग नहीं करता” का अर्थ उसकी dependencies तक नहीं पहुंचता
    • जिन tools का उपयोग हो रहा है, वे किस technology stack पर बने हैं, यह जांचना जरूरी है
  • container isolation की प्रभावशीलता साबित हुई
    • non-root user, non-privileged mode, और अनावश्यक volumes का उपयोग न करने से नुकसान फैलने से रुका
  • security की layered defense (Defense in Depth) की आवश्यकता
    • firewall, fail2ban, monitoring, और नियमित updates आवश्यक हैं
  • खुद Dockerfile लिखने और container permissions को न्यूनतम रखने के महत्व पर जोर

घटना के बाद उठाए गए कदम

  • Umami को नवीनतम version पर redeploy किया गया और सभी third-party containers का audit किया गया
    • run user, mounts, update timing, और आवश्यकता की जांच की गई
  • SSH key-based authentication पर स्विच, password login disable, और fail2ban configuration
  • Grafana और Node Exporter के जरिए monitoring मजबूत, और security updates तुरंत लागू किए गए

निष्कर्ष

  • Umami की Next.js vulnerability के कारण 10 दिनों तक Monero माइनिंग के लिए दुरुपयोग हुआ,
    लेकिन container isolation और non-root execution settings की वजह से नुकसान सीमित रहा
  • इस अनुभव से लेखक ने dependencies की समझ, security settings, और update management के महत्व को गहराई से महसूस किया
  • घटना लगभग 2 घंटे में संभाल ली गई, और यह container security के वास्तविक प्रभाव को साबित करने वाला मामला बन गया

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

1 टिप्पणियां

 
GN⁺ 2025-12-19
Hacker News की राय

  • पहले मैं UFW चालू करता था, लेकिन अब firewalld की सिफारिश करता हूँ
    UFW समय के साथ मैनेज करना मुश्किल हो जाता है, जबकि firewalld की XML-आधारित सेटिंग्स कहीं ज़्यादा स्थिर हैं
    firewall-cmd कमांड से SSH, HTTPS, पोर्ट 80 आदि कॉन्फ़िगर किए जा सकते हैं, और nftables backend का इस्तेमाल करना बेहतर है
    Docker के मामले में अक्सर firewall rules को bypass करके ports खोल दिए जाते हैं, इसलिए /etc/firewalld/firewalld.conf में StrictForwardPorts=yes सेट करना ज़्यादा सुरक्षित है

    • पोर्ट्स को 8080:8080 की तरह खोलने के बजाय 192.168.0.1:8080:8080 की तरह private IP पर bind करना बेहतर है
      मैं 10.0.10.11 VM पर Docker चलाता हूँ, और उसे सिर्फ WireGuard से accessible रखकर Caddy के साथ reverse proxy लगाना सुविधाजनक लगा
    • Docker की जगह Podman इंस्टॉल करने की सलाह है. Docker में firewall bypass की समस्या आम है
    • आप कोई भी netfilter frontend इस्तेमाल करें, outbound connections पर restriction न हो तो उसका ज़्यादा मतलब नहीं है
      malware बाहरी mining pool या C2 server से कनेक्ट होने की कोशिश करेगा, इसलिए unapproved binaries की network access रोकनी चाहिए
      /tmp, /var/tmp, /dev/shm से execute permission हटाना भी उपयोगी है
    • Hetzner मुफ़्त external firewall service देता है, इसलिए इसे पहली रक्षा-पंक्ति की तरह इस्तेमाल किया जा सकता है
    • व्यक्तिगत रूप से मुझे लगता है कि सिर्फ nftables.conf भी काफ़ी simple और clear है
      iptables अब deprecated है, इसलिए firewalld जैसी अतिरिक्त layer हमेशा ज़रूरी नहीं होती

  • यह शायद “React2Shell CVE-2025-55182” से जुड़ा मुद्दा है
    एक साल से ज़्यादा समय तक असर डालने वाली vulnerability होने के बावजूद इसे लगभग कोई ध्यान नहीं मिला, यह अजीब है
    अगर आपने पिछले 12 महीनों में Next.js से web app deploy किया है, तो उसके botnet का हिस्सा बनने की संभावना काफ़ी है
    industry का सिर्फ “Docker इस्तेमाल करो”, “firewall चालू करो” जैसे स्तर की सलाह देना निराशाजनक है
    आजकल frontend ecosystem से इतना मोहभंग हो गया है कि C++ की तरफ career बदलने पर विचार कर रहा हूँ

    • frontend की technology replacement cycle पहले की तुलना में काफ़ी धीमी हो गई है
      अब Next.js, React, Tailwind, Postgres का कॉम्बिनेशन 5 साल से लगभग standard बना हुआ है
      2000 के दशक के अंत से 2010 के शुरुआती दौर वाले framework proliferation के समय की तुलना में यह स्थिर है
      अगर trends और बदलाव पसंद नहीं हैं, तो AI development उससे कहीं तेज़ी से बदल रहा है
    • latest JS framework इस्तेमाल किए बिना भी web app आराम से बनाया जा सकता है
      backend में .NET, Java, Go जैसे solid tech stack इस्तेमाल करें, और frontend को अपनी पसंद से चुनें
      इससे CVE भी कम होंगे और tech fatigue भी घटेगी
    • मेरा Pangolin instance भी इस vulnerability से compromise हुआ था
      संबंधित GitHub चर्चा
    • मैंने भी लगभग 100 Next.js frontends deploy किए हैं, लेकिन Server Components इस्तेमाल नहीं किए थे, इसलिए शुक्र है कि असर नहीं पड़ा

  • अगर Docker container की CPU usage को --cpus="0.5" से limit कर दिया जाए, तो malfunctioning service या miner पूरे सिस्टम को प्रभावित नहीं कर पाएगा

    • container को read-only mode में चलाने से attack surface और कम हो सकता है
    • लेकिन CPU limit बहुत कम होने पर intrusion कम दिखाई दे सकती है, जिससे detection delay हो सकता है
    • app की performance profile अच्छी तरह पता होनी चाहिए. बाद में burst traffic आए तो अनजाने में throttle हो सकता है
    • memory की soft/hard limit भी साथ में सेट करना बेहतर है

  • firewall के बिना server चलाना काफ़ी bold choice है
    Hetzner का external firewall साथ में इस्तेमाल करने से गलती होने पर भी एक अतिरिक्त defence layer मिलती है
    मैं SSH को सिर्फ घर के IP के लिए allow करता हूँ, और बाहर से ज़रूरत पड़ने पर Hetzner website से अस्थायी रूप से खोलता हूँ

    • ज़्यादातर मामलों में firewall का बड़ा असर नहीं होता
      असली महत्वपूर्ण बात है RCE vulnerability वाला software न चलाना
      Docker अगर उद्धारक जैसा दिखा, तो वह असल में सिर्फ किस्मत अच्छी होने की बात थी
    • public web service हो तो firewall बहुत मददगार नहीं होता
      इसके बजाय bastion host रखकर HTTP proxy से input/output नियंत्रित किया जा सकता है, लेकिन उसकी setup जटिल है
    • 30 साल Linux चलाने में मेरे साथ hacking का सिर्फ एक ही मामला हुआ, जब well-known port खुला था
      non-standard port इस्तेमाल करना भी उम्मीद से ज़्यादा असरदार निकला
    • password authentication चालू रखना जोखिमभरा है. व्यक्तिगत रूप से मुझे नहीं लगता कि fail2ban हमेशा ज़रूरी है
    • मैं SSH port को random बदलकर port scanner avoidance की कोशिश करता हूँ
      यह कितना असरदार है पता नहीं, लेकिन थोड़ा मानसिक सुकून ज़रूर देता है

  • मुझे जिज्ञासा थी कि अगर Docker container root के रूप में चल रहा हो, तो क्या host तक भी attack किया जा सकता है

    • Docker security boundary नहीं है. यह सिर्फ process-level isolation देता है
      untrusted code चलाना हो तो VM(KVM/QEMU) या gVisor(https://gvisor.dev/), Firecracker(https://firecracker-microvm.github.io/) जैसी तकनीकें इस्तेमाल करनी चाहिए
      Docker को sandbox नहीं, बल्कि isolated execution environment के रूप में समझना चाहिए
    • attacker container के अंदर भी CPU इस्तेमाल करके Monero mining कर सकता है
      Docker की default settings में RAM, CPU, disk usage पर limit नहीं होती, इसलिए यह DoS attacks के लिए भी कमजोर है
      ऊपर से कई guides --privileged या CAP_SYS_PTRACE जैसे जोखिमभरे options सुझाती हैं
    • privileged mode में Docker socket के ज़रिए host root filesystem तक पहुँचना संभव है
      नया container उठाकर root privilege तक escalate भी किया जा सकता है
    • user namespace सक्षम करना ज़रूरी है, तभी वास्तविक security boundary बनती है
      Docker में यह अभी default नहीं है, इसलिए सेट न करने पर escape risk बड़ा रहता है
      पहले के ज़्यादातर container escapes user namespace से रोके जा सकते थे
    • container escape मौजूद हैं, लेकिन ज़्यादातर मामले साधारण automated mining attacks के होते हैं
      अगर server sensitive data नहीं संभालता, तो सिर्फ container साफ़ कर देना भी काफ़ी हो सकता है

  • attack surface कम करना है तो जिन services को public करने की ज़रूरत नहीं है, उन्हें बाहरी तौर पर expose नहीं करना चाहिए
    उदाहरण के लिए analytics tools को सिर्फ WireGuard या SSH SOCKS proxy के ज़रिए accessible रखना चाहिए

  • मैंने भी Hetzner server पर Monero miner infection झेला है
    अच्छी बात यह रही कि यह सिर्फ Incus के LXC container के अंदर हुआ, और CPU priority कम होने की वजह से मुझे तुरंत पता नहीं चला
    root account में SSH key जोड़ दी गई थी और remote management agent इंस्टॉल किया गया था
    आखिरकार मैंने container discard कर दिया, लेकिन कुछ सबक मिले

    • यह मानकर isolation और resource limits सेट करने चाहिए कि सिस्टम कभी न कभी compromise हो सकता है
    • ZFS snapshots और backups नियमित रूप से रखें, तो recovery आसान होती है
    • compromised system को discard कर देना आदर्श है, लेकिन स्थिति के हिसाब से rollback करके harden भी किया जा सकता है
    • miner ठीक से configured नहीं था इसलिए नज़र आ गया, लेकिन अगर वह चुपचाप घुसा होता तो शायद पता ही नहीं चलता
    • यह Umami इंस्टॉल किए हुए container में हुआ था

  • पोस्ट में इंसानी review के बिना जोड़ी गई AI hallucination वाली सामग्री शामिल थी
    बार-बार Puppeteer से जुड़ी vulnerability होने का दावा किया गया, लेकिन यह सही नहीं है

    • मूल पोस्ट के पहले पैराग्राफ़ में साफ़ लिखा था कि वह Claude session का transcript था

  • हाल में React 19 vulnerability का इस्तेमाल करके जगह-जगह Monero miner इंस्टॉल किए जा रहे हैं
    मेरे साथ भी वही समस्या हुई थी

    • ऐसे mining malware अक्सर आसानी से दिख जाते हैं और नुकसान भी सीमित करते हैं, इसलिए उल्टा उपयोगी साबित होते हैं
      वे किसी automated bug bounty की तरह काम करते हैं और vulnerability का पता दे देते हैं
      अगर network या process monitoring ठीक हो, तो इन्हें आसानी से detect किया जा सकता है
    • Oracle Cloud पर Umami server संक्रमित हो गया था, इसलिए server को reset करना पड़ा
      उसी बहाने backup system upgrade करने का अच्छा मौका मिल गया

  • ऐसे मामलों को देखकर लगता है कि VPS खुद manage न करने का फैसला सही था
    मैंने पहले किया है, लेकिन मुझे लगा कि मैं औसत स्तर का admin हूँ और security maintain करना मेरे लिए कठिन है
    इसलिए अब मैं यह काम विशेषज्ञों को सौंपकर पैसे देना ज़्यादा सुकूनभरा मानता हूँ