Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
Log in
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
CVE-2022-1015-1016 — डेविड द्वारा खोजे और दस्तावेज़ीकृत किए गए CVE-2022-1015 और 1016 का स्पेनिश अनुवाद। | Kitploit
उपकरण/GitHubGitHub/zanezhub/cve-2022-1015-1016
विशेषाधिकार वृद्धिभेद्यता विश्लेषणशोषणलर्निंग और शिक्षाबाइनरी शोषण
GitHubzanezhub/cve-2022-1015-1016

CVE-2022-1015-1016

डेविड द्वारा खोजे और दस्तावेज़ीकृत किए गए CVE-2022-1015 और 1016 का स्पेनिश अनुवाद।

रिपॉजिटरी देखें
164 साल पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें
वेबसाइट

CVE-2022-1015 & CVE-2022-1026

यह README.md डेविड के ब्लॉग का अनुवाद है। डेविड ने लिनक्स कर्नेल में CVE-1015 और 1016 पाए। आप मूल दस्तावेज़ पढ़ने के लिए उनकी वेबसाइट पर जा सकते हैं।

यहाँ उनके सोशल मीडिया लिंक हैं:

  • Twitter
  • Github

nf_tables में लिनक्स की दो नई कमजोरियों का विश्लेषण

2 अप्रैल 2022 को प्रकाशित।

  • CVE-2022-1015 इनपुट आर्गुमेंट्स के अपर्याप्त सत्यापन के कारण आउट-ऑफ-बाउंड्स एक्सेस की अनुमति देता है, जो रिमोट कोड निष्पादन और स्थानीय विशेषाधिकार वृद्धि का कारण बन सकता है।
  • CVE-2022-1016 स्टैक पर संग्रहीत चरों के खराब प्रारंभिकरण से संबंधित है, जिसका उपयोग कर्नेल से यूज़रस्पेस तक डेटा की एक विस्तृत श्रृंखला को लीक करने के लिए किया जा सकता है।

ये समस्याएँ उबंटू और RHEL के नवीनतम संस्करणों की डिफ़ॉल्ट कॉन्फ़िगरेशन में शोषण योग्य होनी चाहिए। मैंने CVE-2022-1015 के लिए अपना प्रूफ-ऑफ-कॉन्सेप्ट (PoC) आर्क लिनक्स के कर्नेल संस्करण 5.16-rc3 को लक्ष्य करके लिखा।

यह दस्तावेज़ उन लोगों के लिए है जिन्हें कार्यक्षमता और सुरक्षा के संदर्भ में लिनक्स कर्नेल का बुनियादी ज्ञान है। मैंने इस दस्तावेज़ को उन लोगों के लिए भी अनुकूल बनाने की कोशिश की जिन्हें नेटवर्किंग स्टैक का ज्ञान नहीं है, ताकि यह सभी के लिए सुलभ हो सके।

यहाँ एक पढ़ने की मार्गदर्शिका है:

  • यदि आप केवल कमजोरी के बारे में पढ़ने के लिए यहाँ हैं, तो सेक्शन 4 से शुरू करें
  • यदि आप कर्नेल सबसिस्टम के बारे में कुछ संदर्भ भी चाहते हैं, तो सेक्शन 2 से शुरू करें
  • यदि आप अतिरिक्त संदर्भ में रुचि रखते हैं, तो पूरा दस्तावेज़ पढ़ें

1. संदर्भ

फरवरी के मध्य में, Google के सुरक्षा कार्यक्रम ने घोषणा की कि वे अपना kCTF पुरस्कार कार्यक्रम जारी रखेंगे, जो nsjail सैंडबॉक्स में अविशेषाधिकार प्राप्त प्रक्रियाओं से रूट उपयोगकर्ता तक विशेषाधिकार वृद्धि करने वाले लिनक्स कर्नेल एक्सप्लॉइट के लिए $31,337 से $91,337 तक का पुरस्कार प्रदान करता है।

एक गरीब छात्र होने के नाते, इसने स्वाभाविक रूप से मेरा ध्यान आकर्षित किया। यह पहली बार था जब मैं "वास्तविक दुनिया" की कमजोरी की तलाश कर रहा था, लेकिन अपनी टीम के साथ CTF खेलने के अपने साहसिक कार्यों में, मैं सुरक्षा के संदर्भ में लिनक्स कर्नेल से परिचित हो गया था। घंटों और घंटों के बाद बहुत कम या बिना किसी प्रगति के (लेकिन लिनक्स के बारे में अधिक ज्ञान के साथ) मैं nf_tables मॉड्यूल में कुछ कमजोरियाँ खोजने में सफल रहा।

दुख की बात है कि दिन के अंत में, मुझे पता चला कि यह मॉड्यूल Google के kCTF नियमों में मौजूद नहीं था (इसलिए मुझे इन दो कमजोरियों के लिए कोई पुरस्कार नहीं मिला)। लेकिन जाहिर है, मैंने फिर भी उन्हें रिपोर्ट किया और CVE-2022-1015 के लिए एक LPE (स्थानीय विशेषाधिकार वृद्धि) एक्सप्लॉइट लिखा।

1.1 लक्ष्य की पहचान और ऑडिट रणनीति

ठीक है, तो आपने तय कर लिया है कि आप लिनक्स में कुछ कमजोरियाँ खोजेंगे। अब क्या? लिनक्स एक विशाल परियोजना है, और पेड़ों के लिए जंगल न देख पाना काफी आसान है (आप विवरणों पर इतना ध्यान केंद्रित करते हैं कि आप वास्तव में महत्वपूर्ण चीजों की दृष्टि खो देते हैं, आपके पास स्थिति का कोई समग्र दृश्य नहीं होता है)। इसे और बदतर बनाने के लिए, कई भाग दस्तावेजित नहीं हैं और आपको यह समझने के लिए बहुत सारा कोड पढ़ना होगा कि क्या हो रहा है।

मैंने लिनक्स सुरक्षा मॉडल का विस्तृत दृष्टिकोण प्राप्त करने का प्रयास करके शुरुआत की। एक बग ढूँढना एक बात है; लेकिन एक अच्छा बग ढूँढना बिल्कुल अलग बात है। आखिरकार, सभी बग समान नहीं बनाए गए हैं:

  • यदि किसी बग के लिए रूट विशेषाधिकारों की आवश्यकता है, तो कोई महत्वपूर्ण सुरक्षा सीमा नहीं है (जब तक कि kernel module signing सक्षम न हो)
    • मेरे दिमाग में कुछ चीजें आती हैं जैसे कि फाइल सिस्टम (वर्चुअल) के कई मॉड्यूल। केवल प्रारंभिक रूट उपयोगकर्ता ही इन फाइल सिस्टम को माउंट कर सकता है। अपवाद vfs है जो FS_USERNS_MOUNT निर्दिष्ट करता है, जिस स्थिति में आप उन्हें user namespace में माउंट कर सकते हैं।
  • यदि किसी बग तक सिस्टम कॉल के माध्यम से नहीं पहुँचा जा सकता है, तो संभवतः इसका शोषण नहीं किया जा सकता है।
    • यह हार्डवेयर ड्राइवरों पर लागू होता है, क्योंकि आपके पास मशीन तक भौतिक पहुँच नहीं है। निम्न-स्तरीय नेटवर्क ड्राइवर अभी भी एक अच्छा लक्ष्य हो सकते हैं यदि आप जैसे ब्लूटूथ या 802.11.ac के माध्यम से डेटा भेज सकते हैं।
    • जाहिर है यह उस परिदृश्य पर निर्भर करता है जिसमें आप हैं।
  • कई बग के लिए CAP_SYS_ADMIN या CAP_NET_ADMIN की आवश्यकता होती है।
    • User namespaces डिफ़ॉल्ट रूप से सक्षम हैं इसलिए यह कोई समस्या नहीं है।
    • अन्यथा पहले आपको कंटेनर के अंदर root उपयोगकर्ता के namespace में विशेषाधिकार वृद्धि करनी होगी।
  • सभी मॉड्यूल आपके लक्ष्य में मौजूद नहीं होंगे।
    • लिनक्स एक असाधारण रूप से उच्च कॉन्फ़िगरेबल सॉफ्टवेयर का टुकड़ा है, इसलिए सभी कॉन्फ़िगरेशन विभिन्न तरीकों से भिन्न हो सकते हैं।
    • कर्नेल कॉन्फ़िगरेशन आमतौर पर /proc/config.gz से एक्सेस किया जा सकता है। मॉड्यूल को (=m) में लोड किया जा सकता है या अलग से संकलित किया जा सकता है और रनटाइम पर लोड किया जा सकता है (=y)।
    • आप /proc/modules और /proc/kallsyms का उपयोग कर सकते हैं, लेकिन वे हमेशा विश्वसनीय नहीं होते, क्योंकि मॉड्यूल को कर्नेल में गतिशील रूप से लोड किया जा सकता है (जैसे request_module)।
    • यदि आप सुनिश्चित नहीं हैं, तो एक छोटा प्रोग्राम लिखें जो मॉड्यूल के साथ इंटरैक्ट करने का प्रयास करे।

ये प्रतिबंध हमें उन फ़ाइल सिस्टम की सीमाओं को जानने में मदद करते हैं जिनमें हम कमजोरियाँ खोज सकते हैं। मुझे लगता है कि अपने इच्छित लक्ष्य पर हमले की योजना बनाने में अपना समय लेना एक अच्छा विचार है।

मैंने उपरोक्त बिंदु के बारे में अपना सबक सीखा है। जैसा कि मैंने उल्लेख किया, nf_tables मॉड्यूल kCTF द्वारा प्रस्तुत इंस्टेंस में लोड नहीं था। मैं शुरू से ही इसका एहसास कर सकता था और निराशा से बच सकता था :p। दूसरी ओर, यदि मुझे पहले इसका एहसास हो जाता तो आप शायद अब यह ब्लॉग नहीं पढ़ रहे होते, मुझे लगता है कि आखिरकार चीजें अच्छी ही हुईं।

एक स्पष्टीकरण कि क्यों COS, Google's container-optimized Linux fork, में nf_tables नहीं था, यहाँ और यहाँ पाया जा सकता है।

1.2 nf_tables: क्यों?

उपरोक्त बिंदुओं का मूल्यांकन करने के बाद, मैंने फैसला किया कि शुरू करने का मेरा सबसे अच्छा तरीका शायद नेटवर्किंग स्रोत कोड को देखना होगा। वहाँ कई दिलचस्प कार्यक्षमताओं के लिए CAP_NET_ADMIN की आवश्यकता होती है, लेकिन जैसा कि मैंने उल्लेख किया, यह वास्तव में कोई समस्या नहीं है। इसके विपरीत, मुझे संदेह है कि जिन घटकों को विशेष क्षमताओं की आवश्यकता होती है वे आमतौर पर कम सुरक्षित होते हैं, क्योंकि कर्नेल डेवलपर्स को सुरक्षा की झूठी भावना हो सकती है।

मैंने उस फ़ाइल सिस्टम को चुनने का भी प्रयास किया जिसके बारे में मैं और अधिक जानना चाहता था; इस तरह, भले ही आपको कोई बग न मिले, फिर भी आप बहुत सी दिलचस्प चीजें सीख सकेंगे।

मैंने कई नेटवर्किंग फ़ाइल सिस्टम की जाँच की, लेकिन मुझे कुछ भी महत्वपूर्ण नहीं मिला। net/ उपनिर्देशिका में नेविगेट करने के बाद, मेरी मुलाकात nf_tables मॉड्यूल से हुई। यह थोड़ा जटिल लग रहा था, इसलिए मैंने इसके बारे में जानने के लिए कुछ समय लेने का फैसला किया।

2. नेटफिल्टर का परिचय

टूल डाउनलोड करें