CVE-2024-6387: regreSSHion — OpenSSH RCE After 18 Years

OpenSSH के सिग्नल-हैंडलर में एक रेस कंडीशन अनऑथेंटिकेटेड हमलावरों को glibc चलाने वाले Linux सर्वर पर root के रूप में मनमाना कोड निष्पादित करने देती है। इसे "regreSSHion" नाम दिया गया — CVE-2006-5051 की एक रिग्रेशन जो 2020 में ग़लती से दोबारा शामिल हो गई थी। यह लगभग 1.4 करोड़ इंटरनेट-एक्सपोज़्ड SSH सर्वर को प्रभावित करती है। CVSS 8.1 हाई।

CVE-2024-6387 क्या है?

CVE-2024-6387 OpenSSH के सर्वर (sshd) में एक सिग्नल-हैंडलर रेस कंडीशन है। जब कोई क्लाइंट LoginGraceTime (डिफ़ॉल्ट: 120 सेकंड) के भीतर ऑथेंटिकेट नहीं करता, तो sshd कनेक्शन समाप्त करने के लिए SIGALRM कॉल करता है। सिग्नल-हैंडलर async-signal-unsafe फ़ंक्शन कॉल करता है — विशेष रूप से syslog() — जो अन्य ऑपरेशनों के साथ समवर्ती रूप से कॉल होने पर हीप-स्थिति को भ्रष्ट कर सकता है।

भेद्यता खोजने वाले Qualys शोधकर्ताओं ने इसे "regreSSHion" नाम दिया क्योंकि एक समान बग (CVE-2006-5051) को 2006 में ठीक किया गया था, लेकिन अक्टूबर 2020 में OpenSSH 8.5p1 जारी होने पर वह फ़िक्स अनजाने में हटा दिया गया — यानी यह भेद्यता खोजे जाने से पहले लगभग चार साल तक चुपचाप फिर से मौजूद रही।

प्रभावित वर्ज़न

glibc आवश्यकता: Qualys के PoC ने glibc के malloc इम्प्लीमेंटेशन का शोषण किया। OpenBSD का sshd भेद्य नहीं है। Alpine Linux (जो musl libc इस्तेमाल करता है) और macOS प्रदर्शित शोषण-तकनीक के प्रति भेद्य नहीं हैं, हालाँकि रेस कंडीशन अभी भी मौजूद है।

रेस कंडीशन की व्याख्या

C प्रोग्राम में सिग्नल-हैंडलर को केवल "async-signal-safe" फ़ंक्शन कॉल करने चाहिए — libc फ़ंक्शन का एक छोटा सबसेट जिन्हें सिग्नल-हैंडलर के भीतर से कॉल करना सुरक्षित है क्योंकि वे शेयर्ड स्टेट का उपयोग नहीं करते। syslog() फ़ंक्शन async-signal-safe नहीं है क्योंकि यह आंतरिक रूप से malloc इस्तेमाल करता है।

# The problematic code path (simplified):
# When LoginGraceTime expires:
SIGALRM → grace_alarm_handler() → syslog() → malloc() internally
                                              ↕ RACE
           main sshd thread also calls        malloc() / free()

# If both malloc operations interleave:
# → Heap corruption
# → With enough attempts: controlled heap layout
# → Remote code execution as root

शोषण के लिए विश्वसनीय रूप से रेस कंडीशन जीतना ज़रूरी है, जिसके लिए मिनटों में हज़ारों कनेक्शन-प्रयास चाहिए। यह इंटरनेट-स्केल पर स्वचालित शोषण को सामान्य "fire and forget" भेद्यताओं से कुछ धीमा बना देता है — लेकिन किसी लक्ष्य तक स्थायी पहुँच रखने वाले परिष्कृत एक्टरों के पास पर्याप्त समय होता है।

शोषण की कठिनाई

Qualys ने 32-बिट सिस्टम (x86) पर विश्वसनीय शोषण प्रदर्शित किया। 64-बिट सिस्टम पर, ASLR कठिनाई को काफ़ी बढ़ा देता है। शोधकर्ताओं का कहना है कि 6-8 घंटों में ~10,000 प्रयासों के साथ, 64-बिट सिस्टम पर शोषण सैद्धांतिक रूप से संभव है, लेकिन उन्होंने x86_64 के लिए कोई काम करने वाला PoC प्रकाशित नहीं किया।

हालाँकि, इस बाधा को इनसे कम किया जा सकता है:

• ASLR को हराने वाले इन्फ़ॉर्मेशन-लीक (संयुक्त एक्सप्लॉइट)
• उन माहौल में ब्रूट-फ़ोर्सिंग जहाँ fail2ban या रेट-लिमिटिंग कॉन्फ़िगर नहीं है
• शोषण-तकनीक को बेहतर बनाने वाला भविष्य का शोध
• भेद्य 32-बिट सिस्टम तक पहुँच (IoT और एम्बेडेड Linux में अभी भी आम)

पहचान

# Check OpenSSH version
ssh -V
sshd -V

# Check installed package version (Debian/Ubuntu)
dpkg -l openssh-server | grep openssh

# Check installed package version (RHEL/CentOS)
rpm -qa | grep openssh-server

# Check for brute-force attempts indicative of regreSSHion exploitation
# (very high connection rate from single IP, all failing within grace period)
grep "Connection closed by" /var/log/auth.log | 
  awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# Check for failed logins at high rate
grep "Failed\|Invalid" /var/log/auth.log | 
  awk '{print $11}' | sort | uniq -c | sort -rn | head -10

सुधार

1. OpenSSH को 9.8p1+ में अपडेट करें: सभी प्रमुख डिस्ट्रीब्यूशन ने खुलासे के कुछ ही दिनों के भीतर पैच जारी किए। apt update && apt upgrade openssh-server या समकक्ष कमांड।
2. LoginGraceTime को 0 पर सेट करें: सेट करना LoginGraceTime 0 — /etc/ssh/sshd_config में SIGALRM हैंडलर को कॉल होने से रोकता है, रेस कंडीशन को ख़त्म कर देता है (हालाँकि इससे ग्रेस-टाइमआउट हट जाता है):

   echo "LoginGraceTime 0" >> /etc/ssh/sshd_config
   systemctl reload sshd

3. SSH कनेक्शन को रेट-लिमिट करें: शोषण के लिए ज़रूरी हज़ारों कनेक्शन को रोकने के लिए fail2ban या iptables रेट-लिमिटिंग कॉन्फ़िगर करें
4. IP के आधार पर SSH एक्सेस प्रतिबंधित करें: sshd को ज्ञात मैनेजमेंट IP-रेंज तक सीमित करने के लिए AllowUsers, ListenAddress, या फ़ायरवॉल नियम इस्तेमाल करें
5. केवल SSH की का उपयोग करें: पासवर्ड ऑथेंटिकेशन अक्षम करें — की-आधारित ऑथ एक मज़बूत प्री-ऑथेंटिकेशन फ़िल्टर जोड़ता है
6. SSH को नॉन-स्टैंडर्ड पोर्ट पर ले जाने पर विचार करें: अवसरवादी स्कैनर-शोर को कम करता है, हालाँकि यह कोई सुरक्षा-नियंत्रण नहीं है

KENSAI पहचान क्षमता

• SSH बैनर स्कैनिंग: KENSAI सभी इंटरनेट-फ़ेसिंग एसेट पर OpenSSH वर्ज़न की पहचान करता है, 8.5p1–9.7p1 को CVE-2024-6387 के प्रति भेद्य के रूप में फ़्लैग करता है
• इंटरनल नेटवर्क स्कैनिंग: इंटरनल नेटवर्क पर भेद्य SSH सर्वर की व्यापक खोज
• कॉन्फ़िगरेशन ऑडिट: सुधारात्मक कॉन्फ़िगरेशन (LoginGraceTime, AllowUsers, की-ओनली ऑथ) की जाँच करता है
• पैच सत्यापन: सुधार के बाद पैच लागू होने की पुष्टि करता है
• एक्सपोज़र संदर्भ: इंटरनल-ओनली सिस्टम की तुलना में इंटरनेट-एक्सपोज़्ड SSH सर्वर को प्राथमिकता देता है