Bitwarden के वॉल्ट को लीक करने वाली Nginx भेद्यता

 (labs.hakaioffsec.com)
1 पॉइंट द्वारा GN⁺ 2023-07-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Nginx, एक बहुउद्देश्यीय web server है जिसका 2004 से प्रमुख market share रहा है
  • Nginx की गलत configuration सुरक्षा भेद्यताओं और data exposure का कारण बन सकती है
  • Nginx की भेद्यताओं का पता लगाने के लिए automated tool NavGix का परिचय
  • इस भेद्यता के जरिए अनचाहे दायरे की files और directories तक access किया जा सकता है
  • Bitwarden और Google के HPC Toolkit पर case studies इस भेद्यता की गंभीरता दिखाती हैं

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

1 टिप्पणियां

 
GN⁺ 2023-07-04
Hacker News टिप्पणियाँ

  • जानकारी के लिए, gixy (nginx config checker) इस समस्या को पकड़ लेता है: https://github.com/yandex/gixy/blob/master/docs/en/plugins/a...
    और NixOS अपने जरिए जनरेट किए गए config पर gixy अपने-आप चलाता है, और समस्या मिलने पर system build को अस्वीकार कर देता है

    • अगर एक webserver को ऐसे जाल से बचने के लिए users से अतिरिक्त tool की ज़रूरत पड़ती है, तो शायद default सेटिंग्स पर दोबारा विचार करना चाहिए
    • मुझे gixy के बारे में पता नहीं था, लेकिन इसे home server पर चलाया तो एक vulnerability मिली. मैं 301 redirect में $uri का इस्तेमाल कर रहा था
    • मैंने Nix एक बार इस्तेमाल किया है और अभी तक यह काफ़ी अच्छा लगा
      लेकिन सोच रहा हूँ कि क्या कोई बेहतर option searcher है. हज़ारों options में पूरी सूची खोजने का तरीका मुझे खास पसंद नहीं आया, और मैं सिर्फ ssh जैसे package को देखकर उससे जुड़े options ही देखना चाहता हूँ, लेकिन बहुत सारे गैर-ज़रूरी results भी साथ आ जाते हैं
    • NixOS अब Gixy नहीं चलाता. https://github.com/NixOS/nixpkgs/pull/209075 देखें

  • यह शायद बेवकूफी भरा सवाल हो, लेकिन क्या कोई अच्छा कारण है कि nginx URL path में .. के जरिए parent directory में ऊपर जाने की अनुमति दे? यह तो बस मुसीबत को न्योता देने जैसा लगता है
    संपादन: असली vulnerability में क्या हो रहा है, इस पर मैं थोड़ा भ्रमित हूँ. ऐसा लगता है कि http://localhost/foo../secretfile.txt को /var/www/foo/../secretfile.txt जैसा समझा जाता है, लेकिन अगर server vulnerable नहीं है तो http://localhost/foo/../secretfile.txt को भी उसी तरह क्यों नहीं समझा जाएगा? मुझे समझ नहीं आ रहा कि path में .. सिर्फ कुछ मामलों में ही क्यों काम करता है

    • यह nginx में बहुत पहले से जानी-पहचानी समस्या है, और CTF में एक आम attack vector है: https://book.hacktricks.xyz/network-services-pentesting/pent...
    • समस्या यह है कि URL असली path नहीं होता. URL किसी resource का एक अमूर्त पता होता है, जो directory, file, executable, stream वगैरह कुछ भी हो सकता है
      इस मामले में, URL का एक हिस्सा config में local filesystem पर map होने के तरीके की वजह से nginx द्वारा directory (http://localhost/foo) के रूप में समझा जाता है. चूँकि वह directory जैसा दिखता है, nginx जब requested resource का पूरा path बनाता है तो वह "${mapped_path}/../secretfile.txt" बन जाता है, और भले ही URL के नज़रिए से इसका मतलब न बने, local filesystem पर यह वैध हो जाता है. URL असली path components नहीं बल्कि सिर्फ strings होते हैं, इसलिए slash की जगह भी मूल रूप से महत्वपूर्ण नहीं होती
      वेब के शुरू होने के बाद से यह webservers में बहुत आम समस्या रही है. URL को सीधे file paths पर map करना इसलिए लोकप्रिय था क्योंकि इसकी शुरुआत index वाले साधारण file servers से हुई थी, लेकिन जल्दी ही माहौल ऐसा हो गया जहाँ URL path नहीं बल्कि application identifiers बन गए. path का एक हिस्सा app को बताता है और बाकी हिस्सा parameters या arguments की तरह लिया जाता है
      और सामान्य तौर पर filesystem objects के लिए URL के . या .. का सम्मान करना अक्सर तर्कसंगत नहीं होता. मेरी apps request path को साफ़ करती हैं ताकि सही mapping हो सके. browser relative links बनाते समय URL को path की तरह मानते हैं, इसलिए trailing / को कब और कैसे इस्तेमाल करना है, इस पर भी सावधानी रखनी पड़ती है. server की तरफ़ इसका अर्थ किसी और resource से हो सकता है
    • “सामान्य” use case में इसकी ज़रूरत नहीं है. location में allow_parent_traversal on; जैसे flag के साथ इसे स्पष्ट रूप से चालू करने वाला व्यवहार बनाना ज़्यादा सही लगता है
    • मेरा अनुमान है कि NginX शायद "/foo/bar/.." की जाँच करके उसे रोकता होगा या "/foo/" में normalize करता होगा. लेकिन "/foo/bar.." पूरी तरह वैध filename है, इसलिए शायद ऐसी जाँच से बच निकलता है
    • path में .. कब काम करेगा, यह पूरी तरह file permissions पर निर्भर करता है
      इस मामले में मान लें कि web index directory (../index.html) से root directory (/) तक files पढ़ने की permission है, तो root तक नीचे जाने की permission होने के बाद आप root से पहुँच योग्य हर world-readable file, जैसे /etc/passwd, भी देख सकते हैं
      इसे तीन दाँत वाले काँटे की तरह सोचें, जहाँ webserver सबसे दाएँ वाले हिस्से पर है. अगर जिस हैंडल वाले हिस्से पर तीनों शाखाएँ मिलती हैं उसे filesystem मानें, तो जब webserver को अपने दाएँ वाले हिस्से से उस हैंडल तक आने वाली files और directories की access permission होती है, तब हैंडल तक पहुँचने के बाद वह दूसरी शाखाओं की files तक भी पहुँच सकता है

  • मुझे समझ नहीं आता कि इसे nginx की vulnerability क्यों नहीं माना जाता. यह व्यवहार पूरी तरह बेतुका है, किसी उपयोगी उद्देश्य का नहीं लगता, और तुरंत exploit किया जा सकता है

    • यह speed की वजह से ऐसा किया गया था. साधारण text substitution, यह जाँचने से कि path सही तरीके से slash पर खत्म होता है या नहीं, कहीं तेज़ है
      यह भी याद रखना चाहिए कि Nginx को Apache2 से ज़्यादा “web scale” साबित करने वाले benchmarks की वजह से लोकप्रियता मिली थी

  • ऐसा करने का विचार आता है। Linux kernel के filename parser में .. विकल्प को हटाने वाला Linux capability जैसा कोई option रखा जाए
    web apps में telephone modem वाले ज़माने से ही दो dots को किसी-न-किसी तरह घुसाने वाली कई bypass तकनीकें लगातार आती रही हैं। जैसे Linux kernel ने user space bugs की कई दूसरी categories के लिए किया, वैसे ही अब इस समस्या को भी एक बार में बंद करने का तरीका खोजने का समय आ गया है

    • https://man7.org/linux/man-pages/man2/openat2.2.html में RESOLVE_BENEATH है
      FreeBSD में सामान्य openat(2) पर O_RESOLVE_BENEATH के रूप में यह सुविधा मौजूद है
    • ऐसा करने पर बहुत-सी चीज़ें टूट जाएँगी, इसलिए यह समझदारी वाला काम नहीं होगा
      nginx को बहुत सीमित permissions वाले अलग user के रूप में चलाएँ या Docker में चलाएँ। इसके साथ regular updates करें, तो आम तौर पर security issues का 90% हल हो जाता है
    • /some/../path को लगभग 100% प्रतिबंधित होना चाहिए। “किसी ने बदसूरत code लिखा है” के अलावा इसका कोई तर्कसंगत use case नहीं है
      ../some/path का कम-से-कम कभी-कभी मतलब होता है
      लेकिन शायद यह उतना उपयोगी नहीं होगा जितना लगता है। कई apps OS को देने से पहले ही .. को resolve कर देते हैं
    • ज़्यादा फ़र्क नहीं पड़ेगा। code अक्सर filesystem API तक पहुँचने से पहले path को normalize कर देता है
    • kernel side पर एक अलग व्यवस्था पहले से है, यानी वही permission system जिस पर हम निर्भर करते हैं
      अगर आप किसी folder से web पर files serve कर रहे हैं, तो web framework को यह सुनिश्चित करना चाहिए कि वह तय public root folder के बाहर न निकल सके। अगर आप यह खुद बना रहे हैं, तो इसमें ऐसी तमाम स्थितियों पर विचार करना होगा

  • “Google VRP Team ने इस vulnerability को ढूँढने के लिए 500 डॉलर का reward दिया। उनका मानना था कि application पर इसका असर इतना गंभीर नहीं था कि अधिक reward दिया जाए” — तो GCP account email और private key exposure की कीमत सिर्फ 500 डॉलर है? यह क्या बात हुई। बिल्कुल Google जैसा लगता है

  • अच्छा है कि leaked चीज़ें अभी भी encrypted थीं। जब इस क्षेत्र में विशेषज्ञता रखने वाली कंपनियाँ भी leaks से नहीं बच पातीं, तो ईमानदारी से कहें तो यह best-case scenario ही है

  • शीर्षक काफ़ी संपादित किया गया है। मूल शीर्षक Hunting for Nginx Alias Traversals in the wild है
    HN submission title Bitwarden vulnerability पर ज़ोर देता है, लेकिन लेख में Google वाला मामला भी साथ में लिया गया है

    • ठीक है, शीर्षक वापस कर दिया गया है। submission title “Leaking Bitwarden's Vault with a Nginx vulnerability” था

  • अगर resource usage न्यूनतम रखते हुए भरोसेमंद और सुरक्षित static file serving ही चाहिए, तो आजकल सबसे अच्छा विकल्प क्या है? पहले मैं Nginx चुनता, लेकिन security के नज़रिये से सोचता हूँ कि शायद कम-purpose और कम-configurable tool बेहतर हो

    • मैं https://static-web-server.net/ इस्तेमाल करता हूँ
      यह cross-platform है, Rust में लिखा गया है, configuration सरल है, और सुरक्षित defaults देता है। इसके hardened container images और hardened NixOS modules भी हैं
      मैं Caddy की सिफारिश नहीं करूँगा। इसकी official Docker image default रूप से root के रूप में चलती है [1], और यह ठीक से sandboxed systemd unit file भी नहीं देती [2]
      [1]: https://github.com/caddyserver/caddy-docker/issues/104
      [2]: https://github.com/caddyserver/dist/blob/master/init/caddy.s...
      संपादन: शब्दों को थोड़ा सुधारा
    • थोड़ा प्रचार करूँ तो, Caddy यहाँ बहुत अच्छा काम करता है। यह automatic HTTPS देता है, Go में लिखा है इसलिए memory safety bugs की चिंता नहीं, और इसमें मज़बूत file_server module है
    • मैं कई सालों से Caddy इस्तेमाल कर रहा हूँ। यह automatic SSL certificates, file serving, और reverse proxy देता है, और इसकी configuration बहुत आसान और साफ़ है। Go single binary होने से “installation” भी आसान है और config file भी सिर्फ एक है
    • Caddy को configure करके static files serve करना काफ़ी सरल है
    • Merecat: https://github.com/troglobit/merecat/

  • शायद यह बेवकूफ़ी भरा सवाल हो, लेकिन Bitwarden ने शुरुआत से ही /attachments के लिए unauthenticated requests क्यों allow किए? अगर Nginx bug होने पर भी उस URL के लिए authentication चाहिए होती, तो क्या request fail नहीं हो जाती?

    • यह exploit webserver configuration को target करता है, इसलिए Bitwarden का authentication code या Bitwarden का कोई code चलता ही नहीं। किसी project का Nginx या उसके module की बजाय अपना authentication इस्तेमाल करना अजीब या ग़लत नहीं है
      फिर भी Docker के ज़रिए risky configuration deploy की गई, इसलिए ज़िम्मेदारी Bitwarden की ही है। लगता है Bitwarden ने यह माना भी और बाद में इसे ठीक किया

  • मूर्खतापूर्ण सवाल के लिए माफ़ी। क्या सही directory और file ownership होने पर ऐसी traversal रुक नहीं जानी चाहिए?
    अगर nginx root के रूप में नहीं चल रहा है, तो nginx user उन फ़ाइलों के अलावा दूसरी फ़ाइलें कैसे पढ़ सकता है जो उसे स्पष्ट रूप से assign की गई हों?

    • बिलकुल रोका जा सकता है। app को एक user के रूप में चलाइए, nginx को दूसरे user के रूप में, सभी app files पर go-rwx लगाइए, और “static” files का group www-data रखकर सिर्फ g+r दीजिए, तो webserver app files तक पहुँच नहीं पाएगा
      यह सचमुच app hosting 101 है, और 20 साल पहले भी लोग ऐसा ही करते थे
    • आह, 022 umask का कमाल। मैं व्यक्तिगत रूप से हमेशा यह सलाह देता हूँ कि दूसरे users आपकी files पढ़ न सकें। अगर सभी files पर करना मुश्किल हो, तो कम से कम /home के नीचे जैसी महत्वपूर्ण directories पर तो ऐसा होना ही चाहिए
      group membership के साथ थोड़ा और काम करना पड़ सकता है, लेकिन यह पूरी तरह से इसके लायक है
    • बाकी लोग क्या करते हैं पता नहीं, लेकिन आजकल मैं निजी इस्तेमाल के लिए nginx को ठीक से install नहीं करता। बस Docker image चला देता हूँ। और यह root के रूप में चल रही है या नहीं, इसकी सच में जाँच भी नहीं करता
      शायद मैं वाकई बहुत बुरी तरह गड़बड़ कर रहा हूँ। आह
    • सामान्य umask 022 होती है, इसलिए ज़्यादातर मामलों में nginx worker पढ़ तो सकता है लेकिन लिख नहीं सकता। www-data जैसे user को स्पष्ट रूप से assign करने की भी ज़रूरत नहीं होती। अगर application sensitive data बनाती है, तो निश्चित रूप से 077 umask इस्तेमाल करना बेहतर है
    • सही है
      दुर्भाग्य से nginx और दूसरे web servers को सामान्य web applications में अक्सर root के रूप में चलना पड़ता है। क्योंकि उन्हें 80 या 443 port पर listen करना होता है। 1024 से कम ports केवल root ही खोल सकता है
      और विस्तार से यहाँ समझाया गया है: https://unix.stackexchange.com/questions/134301/why-does-ngi...