सर्वर सुरक्षा के लिए Zip Bomb का उपयोग

 (idiallo.com)
2 पॉइंट द्वारा GN⁺ 2025-04-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक निजी ब्लॉग ऑपरेटर कमजोरियों की स्कैनिंग, स्पैम और content scraping कम करने के लिए malicious bots को HTTP response के रूप में gzip-आधारित Zip Bomb भेजता है
  • सामान्य browsers और crawlers द्वारा इस्तेमाल होने वाले Accept-Encoding: gzip, deflate flow का उपयोग करते हुए, संदिग्ध requests पर 200 OK और Content-Encoding: gzip लौटाया जाता है
  • 1MB gzip file decompress होने पर लगभग 1GB, और 10MB file लगभग 10GB तक बढ़ जाती है, जिससे कई bots की memory खत्म हो जाती है या वे request रोक देते हैं
  • Server middleware blacklist IPs और spam patterns की जांच करता है, और शर्त पूरी होने पर पहले से बनाई गई Zip Bomb file भेजकर request processing खत्म कर देता है
  • इसे आसानी से detect और bypass किया जा सकता है, इसलिए यह पूर्ण सुरक्षा उपाय नहीं है, लेकिन brute-force crawling से server को बाधित करने वाले सरल bots को रोकने के लिए पर्याप्त है

Bot traffic और Zip Bomb इस्तेमाल करने की पृष्ठभूमि

  • Web traffic का बड़ा हिस्सा bots से आता है, और RSS readers, search engine crawlers, AI bots की तरह नया content खोजने वाले वैध उपयोग भी होते हैं
  • समस्या spammers, content scrapers और hackers द्वारा चलाए जाने वाले malicious bots हैं
    • पहले की नौकरी में, एक bot ने WordPress vulnerability ढूंढकर server में malicious script inject कर दी थी
    • वह server बाद में DDoS में इस्तेमाल होने वाले botnet का हिस्सा बन गया
    • शुरुआती websites में से एक को bots द्वारा बनाए गए spam के कारण Google Search से पूरी तरह बाहर कर दिया गया
  • इन अनुभवों के बाद malicious bots से server को बचाने के लिए Zip Bomb का उपयोग शुरू किया गया

gzip compression को रक्षा-उपाय में बदलने का तरीका

  • Zip Bomb एक छोटी compressed file होती है जो decompress होने की प्रक्रिया में बहुत बड़ी file में expand होकर machine पर दबाव डालती है
  • Web के शुरुआती दिनों में gzip compression धीमे internet environment में data transfer कम करने के लिए लाया गया था
    • 50KB HTML file को 10KB तक घटाने पर 40KB transfer बचाया जा सकता है
    • Dial-up internet पर page download time 12 सेकंड से घटकर 3 सेकंड हो जाता था
  • Browser request करते समय header के जरिए बताता है कि वह कौन-से compression methods support करता है
Accept-Encoding: gzip, deflate
  • Server भी compression support करता हो, तो expected data का compressed version लौटाता है
  • Web crawling bots भी large-scale data collect करने के लिए gzip जैसे compression को support करते हैं, और इसी विशेषता का defense में उपयोग किया जाता है

malicious request पर भेजा जाने वाला response

  • Blog पर security vulnerabilities scan करने वाले bots अक्सर आते हैं, और अधिकांश को ignore कर दिया जाता है
  • अगर request malicious input inject करने या response explore करने की कोशिश करती मानी जाए, तो 200 OK के साथ gzip response भेजा जाता है
Content-Encoding: gzip
  • भेजी जाने वाली file का आकार स्थिति के अनुसार 1MB~10MB होता है
    • 1MB file decompress होने पर लगभग 1GB तक बढ़ जाती है
    • 10MB file decompress होने पर लगभग 10GB तक बढ़ जाती है
  • Bot header देखकर इसे compressed file मानता है और content खोजने के लिए decompress करने की कोशिश करता है
  • File लगातार expand होती रहती है, जिससे memory खत्म हो सकती है और server या script crash हो सकती है
  • जिन persistent scripts के लिए 1MB file पर्याप्त नहीं होती, उन्हें 10MB file भेजी जाती है, और कहा जाता है कि इस स्थिति में script तुरंत terminate हो जाती है

Zip Bomb बनाना और server पर लागू करने का उदाहरण

  • Zip Bomb बनाते समय अपने device को crash या damage करने का risk उठाना पड़ सकता है
  • 10GB तक extract होने वाली gzip file नीचे दिए गए command से बनाई जाती है
dd if=/dev/zero bs=1G count=10 | gzip -c > 10GB.gz
  • Command की संरचना इस प्रकार है
    • dd: data copy या convert करने वाला command
    • if=/dev/zero: input के रूप में infinite zero-byte stream बनाने वाली special file का उपयोग
    • bs=1G: block size को 1GB पर set करना
    • count=10: 1GB के 10 blocks process करके 10GB zero data बनाना
    • gzip -c > 10GB.gz: output data को gzip से compress करके 10GB.gz file के रूप में save करना
  • इस स्थिति में resulting file size लगभग 10MB होता है
  • Server में current request malicious है या नहीं, यह जांचने वाला middleware जोड़ा जाता है
    • पूरे site को बार-बार scan करने वाले IPs की blacklist maintain की जाती है
    • Spam छोड़ने के बाद यह फिर से check करने आने वाला pattern भी detection में इस्तेमाल होता है कि वह spam page पर reflect हुआ या नहीं
if (ipIsBlackListed() || isMalicious()) {
    header("Content-Encoding: gzip");
    header("Content-Length: ". filesize(ZIP_BOMB_FILE_10G)); // 10 MB
    readfile(ZIP_BOMB_FILE_10G);
    exit;
}
  • Cost यह है कि कुछ स्थितियों में server को 10MB file transfer करनी पड़ती है
  • Article viral होने जैसी स्थिति में इसे 1MB file तक घटाया जाता है, और कहा जाता है कि यह file भी असरदार है

सीमाएं और उपयोग का दायरा

  • Zip Bomb पूर्ण सुरक्षा उपाय नहीं है
    • इसे आसानी से detect किया जा सकता है
    • इसे bypass भी किया जा सकता है
    • Client content को केवल partially भी read कर सकता है
  • फिर भी web को अंधाधुंध crawl करके server को बाधित करने वाले कम sophisticated bots को रोकने के tool के रूप में यह पर्याप्त है
  • काम करने का उदाहरण server logs replay में देखा जा सकता है: this replay of my server logs

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

1 टिप्पणियां

 
GN⁺ 2025-04-30
Hacker News की राय

  • करीब 2001 में मेरे घर पर fixed line थी और मैं अपने घर के Linux बॉक्स से तरह-तरह की चीज़ें होस्ट करता था
    Windows NT अपडेट की वजह से कई सिस्टम में एक optimistic encryption फीचर ऑन हो गया था, जिसमें वे किसी खास port पर पहले कनेक्ट करके s/wan negotiate करते थे और फिर TCP ट्रैफिक भेजने की कोशिश करते थे, इसलिए firewall में ऐसा ट्रैफिक अक्सर दिखता था और मैंने उसे खास बात नहीं माना
    लेकिन एक मशीन लगातार हर कुछ सेकंड में कनेक्ट करने की कोशिश कर रही थी, जो बहुत परेशान करने वाला था, और मैंने उसके admin से संपर्क करने की कोशिश की लेकिन सफल नहीं हुआ
    आखिर में मैंने कुछ ऐसा संदेश दिया कि “मैं उस port पर एक नई service शुरू करने वाला हूं, उम्मीद है कोई समस्या नहीं होगी”, और जवाब न मिलने पर उस port पर एक server चला दिया जो /dev/urandom पढ़ता था, TCP_NODELAY वगैरह ऑन करता था और random data को जितनी तेजी से हो सके धकेलता था
    गलत तरह से configured NT बॉक्स कनेक्ट करता, करीब 5 सेकंड तक random data पीता और गायब हो जाता, फिर 5 मिनट बाद लौटकर buffer overflow की दवा खाकर फिर गायब हो जाता; यह pattern कई हफ्ते चलता रहा और फिर वह इंटरनेट से पूरी तरह गायब हो गया
    मैं अक्सर कल्पना करता हूं कि कोई admin सिर खुजा रहा होगा कि NT बॉक्स बार-बार reboot क्यों हो रहा है

    • programmer होने पर आपको दूसरों से मिलने वाले data की मात्रा पर हमेशा ऊपरी सीमा रखनी चाहिए
      हर request में time limit और consume किए जाने वाले data की मात्रा, दोनों की limit होनी चाहिए
    • लगभग उसी समय एक कंपनी हर शुक्रवार spam fax भेजती थी, और कई बार विनम्र voice messages छोड़ने के बावजूद उन्होंने अनदेखा किया
      इसलिए मैंने 100-page PDF बनाई जिसमें हर page एक बड़ा काला rectangle था, और उसे उस समय नए email-to-fax gateway से भेज दिया; एक घंटे के अंदर गुस्से भरा फोन आया और fax बंद हो गए
    • मैं सोचता हूं कि उस दौर में किसी random client के admin contact को आम तौर पर कैसे ढूंढते थे
      “बॉक्स के admin से संपर्क करने की कोशिश की और यह आम बात थी” वाला हिस्सा खास तौर पर दिलचस्प है
    • मैंने कभी अपने घर के RPi server की downtime detection को आधे-अधूरे तरीके से fix किया था: वह मेरे own domain को ping करता था और fail होने पर मानता था कि network down है और reboot कर देता था
      domain expire होने के बाद यह RPi हर 5 मिनट में मरने लगा, तो मुझे लगा power issue है, लेकिन बाद में वह CRON job याद आई
    • आपको यह जानकर हैरानी हो सकती है कि उस दौर में service provide करने वाले ज्यादातर NT installations में ऐसा कोई admin था ही नहीं जो समझ पाता कि क्या हो रहा है
      NT बॉक्स पर ऐसी services चलाने की वजह ही कई हजार मामलों में “admin की जरूरत न पड़े” थी, इसे कम मत आंकिए
      90s और early 2000s में मैंने बहुत सारे servers इंटरनेट पर डाले, और पूरी industry में standard practice यही थी कि बिना admin के इस्तेमाल करने के लिए NT इस्तेमाल करो

  • बचपन में मैंने बेवकूफी भरे prank के तौर पर अपने homepage पर ln -s /dev/zero index.html कर दिया था
    उस समय browsers इसे ठीक से handle नहीं कर पाते थे और लगभग hang हो जाते थे, कभी-कभी client system भी साथ में crash हो जाता था
    बाद में लगता है browsers ने actual content check करना और ऐसी requests को बंद करना शुरू कर दिया

    • एक बार मैंने encoder को वही macroblock row लगातार feed करके 64k×64k JPEG बनाया था
      कई साल बाद जाकर आखिरकार उसे खोल पाया
    • सोच रहा हूं कि क्या squashfs पर proper header वाली 500TB HTML file बनाई जा सकती है, उसमें closing tag के बिना अंतहीन content डाला जाए, और server को download से पहले file size report न करने दिया जाए
      कोई idea?
    • मुझे वह favicon.ico याद आ गया जो browser को crash कर देता था
      शायद यह वही था: https://freedomhacker.net/annoying-favicon-crash-bug-firefox...
    • उम्मीद है उस स्थिति में bandwidth का शुल्क KiB के हिसाब से नहीं देना पड़ता होगा
    • शायद अब /dev/zipbomb device बनाने का समय आ गया है

  • आजकल लगभग सभी browsers zstd और brotli accept करते हैं, इसलिए ऐसे bombs अब और ज्यादा effective हो सकते हैं
    This पुराने comment ने प्रभावशाली 1.2M:1 compression ratio दिखाया था, और zstd seems to be doing even better
    हालांकि bots शायद modern compression standards support न करते हों
    उल्टा, यही bot blocking का अच्छा तरीका भी हो सकता है: सभी modern browsers zstd support करते हैं, इसलिए allowlist में न होने वाले browser agents पर इसे जबरन apply करने से scrapers अपने-आप confuse हो सकते हैं

    • असल में मेरे one million checkboxes Datastar demo[1] में मैं compression से bots को filter कर रहा हूं
      यह हर interaction पर पूरा user view stream करने पर काफी निर्भर करता है, और SSE के ऊपर brotli इस्तेमाल करने पर 200:1 compression ratio[2] भी आसानी से मिल जाता है
      समस्या यह है कि कोई malicious actor बिना compression वाला stream request कर सकता है
      brotli को 98% browsers support करते हैं, इसलिए जो clients brotli compression support नहीं करते उन्हें मैं data नहीं भेजता, और कई scrapers व bots भी इसे support नहीं करते, इसलिए यह काफी अच्छी तरह काम करता है
      [1] checkboxes demo
      https://checkboxes.andersmurphy.com
      [2] article on brotli SSE
      https://andersmurphy.com/2025/04/15/why-you-should-use-brotl...
    • gzip के अंदर फिर gzip nest करने से यह और छोटा हो जाता है
      इसकी वजह यह है कि first-generation gzip में compressed 0 data block खुद low entropy का होता है, और nested zst 10G file को 99 bytes तक घटा देता है
    • सोच रहा हूं कि ऐसा bomb मिलने पर मेरा browser कैसे react करेगा
      खुद test करके देखना नहीं चाहता
    • gzip हर जगह मौजूद है, और सभी crawlers को परेशान कर सकता है

  • पुराने ऑफिस में देखा था कि bots ने WordPress vulnerability ढूंढकर server में malicious script डाल दी थी; यह हिस्सा थोड़ा विषय से हटकर है, फिर भी दिलचस्प है
    यह जानकर उल्टा तसल्ली हुई कि WordPress install करने के 1 घंटे के अंदर server पर PHP shell जादू की तरह deploy हो जाना सिर्फ मेरे साथ नहीं होता

    • जब किसी customer की WordPress site takeover/hand-over मिलती है, तो हालत ऐसी होती है: “ओह, random string नाम वाले 3 PHP shell पड़े हैं”
      3 से कम कभी नहीं होते, हमेशा guaranteed
    • अगर अपनी sanity बचानी है, तो WordPress को खुद host मत कीजिए
      पहले घंटे में नहीं तो भी, किसी दिन patch भूलते ही आखिरकार धमाका होगा
    • मैंने WordPress कभी host नहीं किया, लेकिन जैसे ही internet पर HTTP server expose करते हैं, /wp-login जैसी requests आने लगती हैं
      यह bots पहचानने का अच्छा तरीका भी बन जाता है; famous CMS से जुड़े paths request करने वाला IP दिखे तो उसे सीधे iptables hole में डाल देता हूं
    • WordPress एक शानदार backdoor है, और उसमें CMS features भी built-in हैं
    • DevOps पढ़ाते समय मैंने इसका इस्तेमाल किया है
      “अपना पहला hello world nginx server deploy कीजिए” कहने पर तुरंत logs में अजीब requests दिखनी शुरू हो जाती हैं

  • ssh में भी मैंने कुछ ऐसा ही किया था; root password guess कर रहे ssh client को मारने का तरीका निकाल लिया था
    इसकी कीमत यह चुकानी पड़ी कि कई script kiddies ने मेरे छोटे server पर DDoS कर दिया, और आखिरकार मैंने साफ तौर पर बुरा काम कर रहे actors को पहचानकर firewall rules से IP block करने वाला तरीका अपना लिया
    हालांकि IPv6 में यह और मुश्किल होता जा रहा है
    अगर आप खुद web pages बनाते हैं, तो page में इंसानी आंखों से न दिखने वाले link के जरिए zip bomb डाल सकते हैं
    जैसे सफेद background पर सफेद text, hover/click highlight के बिना anchor; bot उसे download करके check करेगा, और crawler व AI scraper भी ऐसा ही करेंगे

    • मैंने अपने fediverse server के account request form में इस तरीके का एक variant इस्तेमाल किया
      समस्या बहुत simple bots की थी, जो web पर घूमते हुए publish होने जैसा दिखने वाले हर form में घटिया spam submit कर देते थे
      शुरुआत में distorted characters वाला simple CAPTCHA जोड़ा, जिसने कई bots रोक दिए, लेकिन सभी नहीं
      server logs देखकर पता चला कि ये bots बस तीन requests तेजी से भेजते थे: form वाला page, CAPTCHA image, और form data POST request; CSS या JS बिल्कुल load नहीं करते थे
      इसलिए मैंने form में कुछ और fields जोड़ीं, उन्हें CSS से hide किया, और अगर उन fields में कुछ भी submit होता तो request fail कराकर session block कर दिया
      साथ ही CAPTCHA image को CSS background बना दिया और src को transparent image में बदल दिया; spam पूरी तरह रुक गया और असली users को कुछ भी पता नहीं चला
    • अगर आप ऐसी गतिविधि रोकना चाहते हैं, तो इसे देखना worth है
      https://github.com/skeeto/endlessh
    • अगर link इंसानी आंखों से नहीं दिखता, तो screen reader users का क्या होगा, इसकी चिंता होती है
    • समझ नहीं आता कि IPv6 में firewall blocking ज्यादा मुश्किल क्यों है
      दोनों में से तो यह उल्टा ज्यादा आसान लगता है
    • ऐसे links text browser, screen reader, या page links list करने वाले bookmarklet इस्तेमाल करने वालों को दिख सकते हैं

  • Zip bombs मजेदार होते हैं
    एक security product में मैंने vulnerability पाई थी कि अगर zip archive किसी खास size से बड़ा हो, या कोई file उसे contain करती हो, तो वह malware scanning ठीक से नहीं करता था
    असल में Office XML document के अंदर zip bomb डालने पर, वह product आसानी से पहचाने जा सकने वाला malware मौजूद होने के बावजूद OOXML file को pass कर सकता था

    • आज भी कई popular EDR में file size वाली समस्या वैसी ही बनी हुई है

  • अपने usual honeypot script की जगह यह deploy करके देखा, लेकिन लगता है ठीक से काम नहीं कर रहा
    web server logs देखने पर bots 10MB वाला पूरा poison download नहीं कर रहे, अलग-अलग lengths पर cut off कर रहे हैं
    अभी तक मैंने लगभग 1.5MB से ज्यादा लेते नहीं देखा
    या शायद यह काम कर रहा है? हो सकता है stream में on-the-fly decode करते-करते मर रहे हों
    उदाहरण के लिए अगर log में 1.5MB read हुआ दिखता है, तो memory में on-the-fly 1.5GB decode करते हुए crash हुआ हो सकता है
    confirm करने का कोई तरीका नहीं है

    • content maze आजमाने लायक हो सकता है
      जैसे अनंत generated content जिसमें दूसरी generated pages के ढेर सारे references हों
      simple wget और bots के adapt होने से पहले तक इससे मदद मिल सकती है
      वैसे मैं bot side पर हूं, लेकिन मदद करने में दिक्कत नहीं
    • शायद file size को आधा-randomize करना पड़े
      लगता है कुछ bots के पास download किए जाने वाले resource size पर hard limit होती है
      इनमें से काफी annoying LLM training/scraping bots हैं, इसलिए 800KB की zip bomb भेजने से उन्हें मार न भी पाएं, तो उनके computing resources जरूर waste करा सकते हैं
    • अगर वे लौटकर आते हैं तो इसका मतलब detect करके avoid कर रहे हैं, और अगर नहीं लौटते तो crash हुए हैं—mission accomplished

  • यह बताना जरूरी है कि यह classic zip file नहीं, बल्कि gzip bomb है
    यह nested zip से antivirus गिराने वाला तरीका नहीं, बल्कि आम compressed web page की तरह काम करता है

  • कुछ समय पहले Tor Project की censorship circumvention infrastructure का एक हिस्सा zip bomb पर blog post वाली same site से operate हो रहा था[0]
    उन zip files में से एक Google ने crawl कर ली और वह malicious domain list में चली गई, जिससे Tor के Snowflake tool का काफी अहम हिस्सा टूट गया
    इसे ठीक करने में कई हफ्ते लगे[1]
    [0] https://www.bamsoftware.com/hacks/zipbomb/
    [1] https://www.bamsoftware.com/hacks/zipbomb/#safebrowsing

  • अपने application के uploads को protect करने के लिए मैंने करीब 10MB के fixed-size temporary disk partitions बनाए और उनमें decompress किया
    अगर कोई बहुत बड़ा upload कर भी दे, तो नुकसान उसी के अंदर confined रहता है

    • unzip -p | head -c 10MB
    • बेहद बड़ी file को decompress न करने की जगह, आपने जान-बूझकर disk को partition किया?