कमजोर श्रेणियाँ (सभी छह): [7.24, 7.24.2), [7.0.0, 7.23.4), [6.0.0, 6.49.21)।

CVE-2026-67276 तंत्र

1. RouterOS प्रस्तुत SSH public-key ब्लॉब का मिलान उपयोगकर्ता की अधिकृत कुंजी से (कुंजी प्रकार, मापांक) द्वारा करता है — घातांक की तुलना नहीं की जाती।
2. हस्ताक्षर सत्यापन क्लाइंट-आपूर्ति कुंजी का उपयोग करता है, अर्थात हमलावर के ब्लॉब से घातांक।
3. {ssh-rsa, e=1, n=victim} प्रस्तुत करने से sig^1 mod n == sig बनता है, इसलिए वैध "हस्ताक्षर" केवल EMSA-PKCS1-v1_5(hash, authdata) है — जिसकी गणना कोई भी कर सकता है जो पीड़ित के सार्वजनिक मापांक को जानता है। कोई निजी कुंजी आवश्यक नहीं।
4. परिणाम: लक्षित उपयोगकर्ता के रूप में एक SSH कमांड चैनल।

पूर्वापेक्षाएँ (प्रकटीकरण का अपना न्यूनतम): लक्षित उपयोगकर्ता नाम + उस उपयोगकर्ता का अधिकृत RSA सार्वजनिक मापांक।

पुनरुत्पादन के लिए आवश्यक न्यूनतम जानकारी

1. लक्ष्य: कमजोर श्रेणियों में कोई भी RouterOS, SSH सुलभ (लैब: QEMU में KVM के साथ CHR छवि; वास्तविक हार्डवेयर समकक्ष)।
2. उपयोगकर्ता नाम एक खाते का जिसमें अधिकृत RSA कुंजी है।
3. उस अधिकृत कुंजी का RSA मापांक n (लीक/कैप्चर किए गए .pub, प्रावधान रिकॉर्ड, या --modulus-hex से)। यह एकमात्र गुप्त-निकट इनपुट है; निजी कुंजी कभी आवश्यक नहीं।
4. प्रकटीकरण-पुष्टि सर्वर व्यवहार (दोष स्वयं, CERT PL से): मिलान = (प्रकार, n), सत्यापन घातांक = क्लाइंट-आपूर्ति।
5. एक क्लाइंट जो मनमाना कुंजी ब्लॉब और मनमाना हस्ताक्षर बाइट्स प्रस्तुत कर सकता है (paramiko + ForgeKey हुक — स्टॉक OpenSSH नहीं कर सकता)।
6. हस्ताक्षर एल्गोरिथ्म जो सर्वर स्वीकार करता है (ssh-rsa 6.x पर, rsa-sha2-256 भी 7.x पर)।

फ़ाइलें

• forge_67276.py — प्रिमिटिव: OpenSSH pubkey पार्सिंग, RFC 8017 EMSA एन्कोडर, जाली ब्लॉब/हस्ताक्षर बिल्डर, संदर्भ RFC 8017 सत्यापनकर्ता।
• selftest.py — स्थानीय प्रमाण, कोई राउटर नहीं: एन्कोडर OpenSSL के लिए बाइट-समान (वास्तविक-हस्ताक्षर व्युत्क्रमण के माध्यम से), जाली हस्ताक्षर e=1 पर सत्यापित होता है और 65537 पर नहीं, पूर्ण RFC 4252 §7 वायर-शेप सिम। सभी 15 जाँचें PASS।
• poc_67276.py — paramiko क्लाइंट जो बाईपास करता है (प्रति-कनेक्शन एल्गोरिथ्म पिनिंग; --lab-i-own-this-target आवश्यक)।
• console_setup.py — qemu सीरियल टेलनेट पर एक-बार CHR तैयारी (10.0.2.2 के माध्यम से पीड़ित कुंजी प्राप्त करें, admin के लिए आयात करें, ssh सक्षम करें)।
• sanity_real_key.py — नियंत्रण: सामान्य pubkey प्रमाणीकरण पहले सफल होना चाहिए।
• victim_rsa / victim.pub — उत्पन्न डिस्पोजेबल 2048-बिट "पीड़ित" कुंजी जोड़ी; जानबूझकर Git से बाहर रखा गया।

स्थानीय सेटअप

लैब ([email protected] पर प्रावधानित)

• Kali x86_64, QEMU 11.0.1 + KVM, /root/mikrotrick-lab/, होस्ट ब्रिज br0 (192.168.100.1/24) टैप्स tap0-tap3 के साथ; br0 पर प्रति-MAC लीज़ के साथ dnsmasq।

• इच्छित गेस्ट स्थिति: e1000 NIC, स्थिर गेस्ट IP, admin पासवर्ड labpass123, और admin के लिए आयातित पीड़ित कुंजी। पहले-लॉगिन पर बाध्य पासवर्ड परिवर्तन SSH (bootstrap_password.py डायलॉग पढ़ता है) या QEMU मॉनिटर sendkey (mon_type.py) के माध्यम से चलाए गए — CHR का सीरियल कंसोल डिफ़ॉल्ट रूप से मृत है; VGA कंसोल केवल मॉनिटर screendump के माध्यम से पठनीय है।
• Mac से टनल: ssh -N -L 2222:192.168.100.11:22 -L 2223:192.168.100.12:22 -L 2224:192.168.100.13:22 -L 2225:192.168.100.14:22 [email protected]

पुनः चलाएँ (उदाहरण, VM3):

देखे गए परिणाम (2026-09-06 स्वतंत्र पुनः सत्यापन)

7.x जोड़ी के लिए, वास्तविक-कुंजी बेसलाइन दोनों बिल्डों पर सफल होती है, SSH none प्रमाणीकरण अस्वीकृत है, गलत-मापांक जालसाजी 7.23.3 द्वारा अस्वीकृत है, और सही-मापांक जालसाजी केवल 7.23.3 पर सफल होती है। यह एक वैध कमजोर-बनाम-पैच किया गया तुलना है।

6.49.21 गेस्ट को स्वतंत्र पुनः सत्यापन के दौरान दस्तावेज़ित रूप से प्रावधानित नहीं किया गया था: admin समाप्त रहा, /user ssh-keys print detail खाली था, और एक क्रेडेंशियल-मुक्त SSH none अनुरोध ने कमांड निष्पादित किए। असंबंधित वास्तविक RSA कुंजियाँ और गलत-मापांक e=1 कुंजियाँ इसलिए भी सफल दिखीं। इस गेस्ट को पुनः प्रावधानित करें और सत्यापित करें कि none और एक असंबंधित कुंजी अस्वीकृत हैं इसे पैच किए गए नियंत्रण के रूप में उपयोग करने से पहले।

संस्करण बारीकी: 6.49.20 पर सर्वर-साइड मिलान e=1 ब्लॉब को अस्वीकार करता है (/log ssh,debug: can't find matching key for user: admin) — प्रकटीकृत घातांक-छूट 6.x के मिलानकर्ता में देखने योग्य नहीं थी हालाँकि CERT की व्यापक श्रेणी [6.0.0, 6.49.21) सूचीबद्ध करती है। पुष्टि कमजोर: 7.23.3। पुष्टि पैच किया गया: 7.23.4। वर्तमान 6.49.21 लैब स्थिति न तो परिणाम साबित करती है। जंगल में MikroTrick गतिविधि ने भी 7.x डिवाइसों को लक्षित किया।

वायर-प्रारूप निष्कर्ष (RFC 8332): ब्लॉब की आंतरिक प्रकार स्ट्रिंग ssh-rsa ही रहती है rsa-sha2-256/512 हस्ताक्षर एल्गोरिदम के लिए भी; सिग एल्गोरिथ्म केवल बाहरी एल्गोरिथ्म फ़ील्ड में जाता है। इसे अनदेखा करने से सर्वर userauth के बीच में डिस्कनेक्ट हो जाता है (ब्लॉब पार्स त्रुटि) — 6.x और 7.x दोनों पर देखा गया। PoC का ForgeKey इसे संभालता है, और --exp-enc aligned|canonical टॉगल करता है e=1 mpint चौड़ाई (1 बनाम 3 बाइट्स)। 7.23.3 पर दोनों चौड़ाई प्रमाणित होती हैं — मिलानकर्ता घातांक को पार्स करता है और वास्तव में इसके मान को अनदेखा करता है। 6.49.20 पर न तो प्रमाणित होता है (can't find matching key) — ऊपर संस्करण बारीकी देखें। सर्वर-साइड /system logging add topics=ssh,debug + /log print पैकेट हेक्सडंप ने यह सब सतह पर लाया।

इस लैब द्वारा उपयोग किए गए स्रोत छवि संग्रह SHA-256 मान:

रक्षात्मक नोट्स (CERT PL)

• तुरंत पैच करें: 7.25beta3 / 7.24.2 / 7.23.4 / 6.49.21।
• अंतरिम: SSH/WWW/bandwidth-test को विश्वसनीय प्रबंधन नेटवर्क तक सीमित करें; बिना पैच वाले डिवाइसों से RouterOS-आरंभित SSH/TLS से बचें।
• IOCs: लॉग पंक्तियाँ login failure for user -2 via ssh, user <name> added by ssh:-2@<ip>; अज्ञात उच्च-विशेषाधिकार उपयोगकर्ता ops; /system/device-mode/print "Flagged" मार्कर (समझौते का संकेत देता है, इसकी अनुपस्थिति कुछ साबित नहीं करती)। देखे गए हमलावर IP: 82.192.72.4, 103.102.31.18।

स्रोत

• CERT PL सलाह: https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
• CERT PL CVE पृष्ठ: https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/
• MikroTik बुलेटिन (2026-09-03): https://mikrotik.com/supportsec/september-2026-vulnerability/
• "Flagged" तंत्र: https://manual.mikrotik.com/docs/system-information-and-utilities/device-mode#flagged-status