
निजी Nginx Rift ASLR लैब, एक्सप्लॉइट चेन, और डेमो रिकॉर्डिंग
CVE-2026-42945 के लिए RCE प्रूफ ऑफ कॉन्सेप्ट, जो NGINX के ngx_http_rewrite_module में 2008 में पेश किया गया एक गंभीर हीप बफर ओवरफ्लो है। यह बग rewrite और set निर्देशों का उपयोग करने वाले सर्वरों के खिलाफ बिना प्रमाणीकरण के रिमोट कोड निष्पादन को सक्षम बनाता है।
यह फोर्क मूल PoC को एक ASLR-बाईपास श्रृंखला के साथ विस्तारित करता है जो NGINX ओवरफ्लो को एक सामान्य समान-होस्ट LFI/मनमाना-फ़ाइल-रीड प्रिमिटिव के साथ जोड़ता है। फ़ाइल-रीड प्रिमिटिव का उपयोग nginx वर्कर मैप्स, libc, और लाइव /proc/<worker>/mem को पुनर्प्राप्त करने, फिर system() पते और प्रयोग करने योग्य हीप लक्ष्यों को दूरस्थ रूप से प्राप्त करने के लिए किया जाता है।
इस लैब के पुराने संस्करणों ने जानबूझकर एक nginx वर्कर को क्रैश किया ताकि सेवा एक कोर डंप लिखे, फिर उस कोर डंप को फ़ाइल-रीड प्रिमिटिव के माध्यम से प्राप्त और पार्स किया ताकि ASLR-संवेदनशील प्रक्रिया स्थिति, जिसमें हीप लक्ष्य शामिल हैं, को पुनर्प्राप्त किया जा सके। इस रिपॉजिटरी में, कोरलेस केवल "पठनीय क्रैश कोर डंप के बिना" के लिए संक्षिप्त है: वर्तमान डिफ़ॉल्ट पथ उस क्रैश-कोर निर्भरता को लाइव procfs मेमोरी रीड के साथ बदल देता है, जबकि संरक्षित लीगेसी कोर-निर्देशित पथ अभी भी उत्पन्न वर्कर कोर डंप का उपयोग करता है।
यह भेद्यता — तीन अन्य मेमोरी भ्रष्टाचार मुद्दों (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) के साथ — depthfirst के सुरक्षा विश्लेषण प्रणाली द्वारा NGINX स्रोत के ऑनबोर्डिंग के एक क्लिक के बाद स्वायत्त रूप से खोजी गई थी।
अपने कोड में ऐसे मुद्दे खोजना चाहते हैं? उसी प्रणाली को https://depthfirst.com/open-defense पर आज़माएं।
NGINX की स्क्रिप्ट इंजन दो-पास प्रक्रिया का उपयोग करती है: पहले आवश्यक बफर आकार की गणना करें, फिर डेटा कॉपी करें। is_args फ़्लैग मुख्य इंजन पर सेट किया जाता है जब एक rewrite प्रतिस्थापन में ? होता है, लेकिन लंबाई-गणना पास ताज़ा शून्य किए गए उप-इंजन पर चलता है। इसलिए:
is_args = 0 देखता है → कच्ची कैप्चर लंबाई लौटाता है।is_args = 1 देखता है → ngx_escape_uri को NGX_ESCAPE_ARGS के साथ कॉल करता है, प्रत्येक एस्केप करने योग्य बाइट को 3 बाइट्स में विस्तारित करता है।कॉपी हमलावर-नियंत्रित URI डेटा के साथ छोटे हीप बफर को ओवरफ्लो करती है। शोषण क्रॉस-अनुरोध हीप फेंग शुई का उपयोग करके एक आसन्न ngx_pool_t के cleanup पॉइंटर को भ्रष्ट करता है (POST निकायों के माध्यम से स्प्रे किया जाता है, क्योंकि URI बाइट्स में नल बाइट्स नहीं हो सकते), इसे एक नकली ngx_pool_cleanup_s पर पुनर्निर्देशित करता है जो पूल विनाश पर system() को लागू करता है।
इस बग के बारे में हमारे तकनीकी लेख में और पढ़ें।
| उत्पाद | प्रभावित | निम्न में ठीक किया गया |
|---|---|---|
| NGINX ओपन सोर्स | 0.6.27 – 1.30.0 | 1.31.0, 1.30.1 |
| NGINX प्लस | R32 – R36 | R36 P4, R35 P2, R32 P6 |
पूर्ण विक्रेता सलाह: https://my.f5.com/manage/s/article/K000160932



यह फोर्क मूल प्रकटीकरण PoC को बरकरार रखता है, लेकिन एक अधिक यथार्थवादी प्रश्न पर केंद्रित दूसरा शोध ट्रैक जोड़ता है:
क्या बग को ASLR सक्षम के साथ एक वास्तविक x86_64 लिनक्स VM के खिलाफ शोषित किया जा सकता है, बिना हार्डकोडेड डॉकर/लैब ऑफसेट पर निर्भर हुए?
इस शोध फोर्क में उत्तर हाँ, महत्वपूर्ण बाधाओं के साथ है। कार्यशील श्रृंखलाएं ASLR को अक्षम नहीं करती हैं और मूल हार्डकोडेड हीप/लिबक पतों का उपयोग नहीं करती हैं। इसके बजाय, वे समान-पोर्ट HTTP-सुलभ प्रिमिटिव के माध्यम से रनटाइम स्थिति प्राप्त करते हैं, फिर दूरस्थ रूप से प्राप्त प्रकटीकरण डेटा से अंतिम हीप लक्ष्य का चयन करते हैं।
अब दो ASLR-सक्षम एक्सप्लॉइट ट्रैक हैं, जिनमें कोरलेस पथ को वर्तमान सर्वश्रेष्ठ PoC माना जाता है:
nginx_rifter.py: स्वच्छ, आत्म-निहित मूल्यांकन और एकीकृत एक्सप्लॉइट प्रवेश बिंदु। इसकी डिफ़ॉल्ट एक्सप्लॉइट विधि अब कोरलेस /proc/<nginx-worker>/mem श्रृंखला है।nginx_rifter_core_v2_1.py: nginx_rifter.py का संरक्षित लीगेसी कोर-निर्देशित संस्करण। यह पुराने VM-परीक्षित क्रैश-कोर शोध पथ को पुन: उत्पन्न करने के लिए उपयोगी है, लेकिन यह अब पसंदीदा PoC नहीं है।tools/proc_mem_coreless_exploit.py: पहले का स्टैंडअलोन कोरलेस शोध हार्नेस। इसका तर्क nginx_rifter.py में विलय कर दिया गया है; उपकरण कच्चे प्रयोग पुनरावृत्ति के लिए बना हुआ है।लक्ष्य टोपोलॉजी जानबूझकर समान-पोर्ट है:
/api/.../lfi.php?file=.../phpinfo.phpवर्तमान कोरलेस proc-mem पथ निम्नलिखित उच्च-स्तरीय चरण करता है:
/proc/<pid>/maps, और मैप की गई libc फ़ाइल पढ़ता है।system() पते की गणना की जा सके।/proc/<worker>/mem से मैप की गई श्रेणियां पढ़ता है।लीगेसी कोर-निर्देशित पथ समान आधार-पता व्युत्पत्ति करता है, फिर जानबूझकर एक वर्कर को क्रैश करता है, LFI पर उत्पन्न कोर फ़ाइल को पढ़ता है, और उस कोर को स्प्रे किए गए नकली-क्लीनअप स्लॉट के लिए खनन करता है। यह एक उपयोगी शोध पुल था, लेकिन यह कोर-डंप नीति और फ़ाइलसिस्टम अनुमतियों पर निर्भर करता है जो डिफ़ॉल्ट तैनाती में कम सामान्य हैं।
यह मूल नियतात्मक डॉकर डेमो के समान नहीं है। x86_64 VM पथ सामान्य लिनक्स ASLR को सक्षम छोड़ता है और प्रत्येक रन पर प्रक्रिया-विशिष्ट पतों की पुनर्गणना करता है। डॉकर कोरलेस पथ भी ASLR को सक्षम छोड़ता है और असामान्य पठनीय-कोर आवश्यकता को हटा देता है, लेकिन यह procfs अनुमति व्यवहार पर निर्भर करता है जिसे लक्ष्य वर्ग के लिए सत्यापित किया जाना चाहिए।
यह फोर्क एक नियंत्रित शोध लैब है। ASLR-सक्षम श्रृंखलाएं मजबूत शर्तों पर निर्भर करती हैं जो सार्वभौमिक उत्पादन धारणाएं नहीं हैं:
/proc/<pid>/maps, मैप की गई libc, और बड़े मैप किए गए ऑफसेट पर /proc/<pid>/mem को पढ़ने में सक्षम होना चाहिए।/proc/<pid>/maps, मैप की गई libc, और उत्पन्न वर्कर कोर को पढ़ने में सक्षम होना चाहिए।phpinfo() और /proc/<pid>/maps PIE/libc आधार पतों को पुनर्प्राप्त करने के लिए पर्याप्त हैं, लेकिन वे अपने आप में इस एक्सप्लॉइट के लिए आवश्यक सटीक हीप ऑब्जेक्ट/विंडो को पुनर्प्राप्त करने के लिए पर्याप्त नहीं हैं। पुरानी श्रृंखला ने उस अंतिम प्रकटीकरण के लिए एक पठनीय क्रैश कोर का उपयोग किया। वर्तमान डिफ़ॉल्ट श्रृंखला इसके बजाय /proc/<worker>/mem का उपयोग करती है, जो समान-UID तैनाती में वास्तविक मनमाना-फ़ाइल-रीड परिणाम के करीब है क्योंकि यह कोर-डंप नीति को बदले बिना लाइव वर्कर मेमोरी को उजागर करती है।
महत्वपूर्ण शेष सीमाएं:
/proc/<pid>/mem ptrace-गेटेड है। यह डॉकर लैब में और आधिकारिक nginx:stable छवि मॉडल के खिलाफ समान-UID जांच में काम करता है, लेकिन विभिन्न-UID ऐप प्रक्रियाओं को डिफ़ॉल्ट procfs सुरक्षा के तहत विफल होना चाहिए।वर्तमान स्वच्छ प्रवेश बिंदु nginx_rifter.py है, एक मूल्यांकन-प्रथम उपकरण जो इस बात के करीब होने का इरादा रखता है कि एक अधिकृत परीक्षक एक ज्ञात कमजोर nginx तैनाती का मूल्यांकन कैसे करेगा जिसमें HTTP-सुलभ लोकल-फ़ाइल-रीड प्रिमिटिव है।
प्रारंभिक डेमो रनर की तुलना में, nginx_rifter.py कई तरह से वर्कफ़्लो में सुधार करता है:
--exploit स्पष्ट रूप से प्रदान नहीं किया जाता है, यह क्रैशिंग एक्सप्लॉइट नहीं चलाता है।HOST:PORT के रूप में प्रदान किया जाता है, और फ़ाइल-रीड प्रिमिटिव --file-read-template के माध्यम से मॉड्यूलर है।/proc/self/status, /proc/self/maps, और समान-UID वर्कर procfs पहुंच क्षमता शामिल है।system(), बिल्ड आईडी, बाइनरी हैश, OS विवरण, और proc-mem/कोर सेटिंग्स की खोज करता है।rewrite + set रूट उम्मीदवारों को फ़्लैग करता है।nginx_rifter.py में एकीकृत है; डिफ़ॉल्ट विधि कोरलेस proc-mem है।वर्तमान nginx_rifter.py आत्म-निहित है। यह अब मूल्यांकन या शोषण के लिए पहले के डेमो PoC संस्करणों या tools/proc_mem_coreless_exploit.py को आयात या शेल आउट नहीं करता है।
पुराना कोर-निर्देशित nginx_rifter.py कार्यान्वयन nginx_rifter_core_v2_1.py के रूप में संरक्षित है।
नया artifacts/nginx_rifter_v3_coreless_exploit_20260519.gif विलय किए गए v3 nginx_rifter.py कोरलेस एक्सप्लॉइट पथ को दर्शाता है। demo4.gif पहले के ऑल-इन-वन कोर-निर्देशित टूलिंग से मूल्यांकन और स्पष्ट एक्सप्लॉइट प्रवाह को दर्शाता है। पहले का nginx-aslr-demo.gif मूल ASLR-सक्षम एक्सप्लॉइट डेमो के रूप में बना हुआ है।
Ubuntu 24.04.3 LTS पर परीक्षित।
मूल ASLR-अक्षम डॉकर पुनरुत्पादन:
./setup.sh — कंटेनर बनाएं।docker compose -f env/docker-compose.yml up — कमजोर NGINX सर्वर प्रारंभ करें।python3 poc.py --shell — शेल प्राप्त करें।स्थानीय डॉकर पुनरुत्पादन प्रवाह के लिए, LAB.md देखें।
लीगेसी ASLR-सक्षम VM कोर-निर्देशित श्रृंखला:
./nginx_rifter_core_v2_1.py --target <target-host>:19321 --exploit --cmd id --fast
मूल्यांकन-प्रथम v3 उपकरण:
./nginx_rifter.py --target <target-host>:19321
nginx_rifter.py वर्तमान वास्तविक-विश्व-उन्मुख मूल्यांकक और एकीकृत PoC प्रवेश बिंदु है। इसका डिफ़ॉल्ट मोड क्रैशिंग एक्सप्लॉइट पथ नहीं चलाता है। यह HTTP फ़ाइल-रीड प्रिमिटिव का प्रोफाइल करता है, रेंज्ड और बाइनरी रीड की जांच करता है, OS/nginx/libc को फिंगरप्रिंट करता है, nginx वर्कर और ASLR-प्रासंगिक मैप्स की खोज करता है, समान-UID /proc/<worker>/mem पठनीयता का परीक्षण करता है, pid/cmdline/कॉन्फ़िगरेशन रीड के माध्यम से nginx कॉन्फ़िगरेशन पथों को पुनर्प्राप्त करने का प्रयास करता है, कमजोर rewrite + set रूट उम्मीदवारों को फ़्लैग करता है, और वर्तमान कोरलेस श्रृंखला के लिए एक व्यवहार्यता मैट्रिक्स प्रिंट करता है।
वर्तमान nginx_rifter.py आत्म-निहित है। यह अब मूल्यांकन या शोषण के लिए पहले के डेमो PoC संस्करणों या स्टैंडअलोन proc-mem शोध हार्नेस को आयात या शेल आउट नहीं करता है।
एक कस्टम LFI/डाउनलोड आकार के लिए:
./nginx_rifter.py --target <target-host>:19321 \
--file-read-template 'http://{host}:{port}/download?path={path_url}{range_query}'
एक्सप्लॉइट निष्पादन स्पष्ट है:
./nginx_rifter.py --target <target-host>:19321 --exploit --cmd id --fast
# केवल-खोज एक्सप्लॉइट स्मोक टेस्ट, कोई स्प्रे/प्रोब नहीं
./nginx_rifter.py --target <target-host>:19321 --exploit --derive-only --cmd id
डिफ़ॉल्ट एक्सप्लॉइट विधि कोरलेस proc-mem है। निम्नलिखित विकल्प पहले से ही डिफ़ॉल्ट रूप से चुने गए हैं क्योंकि वे कोरलेस डॉकर प्रूफ के लिए सबसे विश्वसनीय थे:
--exploit-method proc-mem
--target-len 6
--max-region 268435456
लीगेसी पठनीय-कोर मोड तुलना के लिए अभी भी उपलब्ध है, लेकिन संस्करणित स्क्रिप्ट उस पुराने पथ को पुन: उत्पन्न करने के लिए स्पष्ट है:
./nginx_rifter_core_v2_1.py --target <target-host>:19321 --exploit --cmd id --fast
लीगेसी रिकॉर्डिंग-अनुकूल टर्मिनल डेमो:
./demo_ctf_exploit_v1_9.py --host <target-host>:19321 --cmd id --clear
demo_ctf_exploit_v1_9.py कोर-निर्देशित लैब पथ के लिए पुराना ऑपरेटर-सामने वाला रनर है। वर्तमान पसंदीदा PoC प्रवेश बिंदु nginx_rifter.py है।
डिफ़ॉल्ट फ़ाइल-रीड प्रिमिटिव इस फोर्क का PHP रूट है:
/lfi.php?file=<path>&offset=<n>&length=<n>
एक अलग ज्ञात-कमजोर CTF ऐप या परीक्षण प्लेटफॉर्म के लिए, फ़ाइल-रीड वेक्टर मॉड्यूलर है:
./nginx_rifter.py --target <target-host>:19321 --exploit --cmd id \
--target-profile generic \
--file-read-template 'http://{host}:{port}/download?path={path_url}{range_query}'
टेम्पलेट {host}, {port}, {path_url}, {offset}, {length}, और {range_query} का समर्थन करता है। जेनेरिक प्रोफाइल इस फोर्क की लैब-विशिष्ट nginx कॉन्फ़िगरेशन अभिकथन को छोड़ देता है, लेकिन डिफ़ॉल्ट एक्सप्लॉइट को अभी भी समान अंतर्निहित क्षमताओं की आवश्यकता है: पठनीय nginx वर्कर /proc मैप्स, पठनीय libc, और पठनीय /proc/<worker>/mem। phpinfo() वैकल्पिक है; इसे अक्षम करने के लिए --phpinfo-path '' का उपयोग करें।
यथार्थवाद चेतावनी: LFI/फ़ाइल-रीड बग क्लास और समान-होस्ट nginx/PHP-FPM तैनाती मॉडल यथार्थवादी हैं। proc-mem श्रृंखला पहले की क्रैश-कोर श्रृंखला की तुलना में अधिक यथार्थवादी है क्योंकि इसे वर्कर कोर डंप को सक्षम या पढ़ने की आवश्यकता नहीं है। यह अभी भी एक सार्वभौमिक डिफ़ॉल्ट-उत्पादन धारणा नहीं है: समान-UID प्रक्रिया लेआउट, procfs/Yama नीति, कंटेनर नेमस्पेस सेटिंग्स, और फ़ाइल-रीड प्रिमिटिव की गुणवत्ता यह तय करती है कि /proc/<worker>/mem सुलभ है या नहीं।
गैर-LFI शोध प्रोब:
python3 tools/non_lfi_leak_probe.py --target <target-host>:19321
python3 tools/non_lfi_active_response_probe.py --target <target-host>:19321
ये नकारात्मक शोध प्रोब हैं, एक्सप्लॉइट प्रवेश बिंदु नहीं। वे LFI, phpinfo, procfs, कोर, डिबगर पहुंच, या हार्डकोडेड लाइव ASLR बेस का उपयोग किए बिना निष्क्रिय प्रतिबिंबित सिंक और एक प्रारंभिक विलंबित-प्रतिक्रिया ओवर-रीड आकार का अभ्यास करते हैं।
अतिरिक्त लैब नोट्स और रन लॉग docs/ के अंतर्गत हैं, विशेष रूप से:
docs/CTF_PLAN.mddocs/CTF_FINDINGS.mddocs/CTF_TESTS.mddocs/CTF_EXPERIMENT_LOG.mddocs/DEMO_POC_IMPROVEMENTS.mddocs/KNOWN_LAYOUT_PATTERNS.mddocs/VAGRANT_ESXI.mddocs/CORELESS_ASLR_PLAN.mddocs/CORELESS_ASLR_FINDINGS.mddocs/NON_LFI_ASLR_BYPASS_LOG.mddocs/DEMO_RECORDING_WORKFLOW.md