اختبار اختراق Telnet — لماذا يبقى بروتوكول قديم خطراً حقيقياً حتى اليوم

ما هو Telnet ولماذا لا يزال يهمنا؟

Telnet بروتوكول شبكي قديم جداً — يعود تصميمه الأساسي إلى أواخر الستينيات وأوائل السبعينيات (موثَّق رسمياً بمعيار RFC 854) — يُستخدم لتأسيس جلسة طرفية (Terminal Session) تفاعلية مع جهاز بعيد عبر الشبكة. من الناحية العملية، هو سلف تاريخي مباشر لبروتوكول SSH، ويؤدي نفس الوظيفة الأساسية: الوصول عن بُعد لسطر أوامر جهاز آخر.

المشكلة الجوهرية أن Telnet صُمِّم بزمن لم يكن فيه أمن الشبكات اعتباراً تصميمياً أساسياً، وبقي حتى اليوم بلا أي طبقة تشفير مدمجة إطلاقاً. هذا وحده يكفي لتفسير لماذا أصبح بروتوكولاً “قديماً” بالمعايير الأمنية الحديثة، رغم أنه لا يزال موجوداً فعلياً على شبكات حقيقية.

المنفذ الافتراضي: 23 (TCP)

23/tcp open  telnet  syn-ack

لماذا لا يزال منتشراً رغم قدمه؟

رغم أن أي مؤسسة حديثة تدرك أهمية استبداله بـSSH، لا يزال Telnet يظهر عملياً بثلاث فئات من الأجهزة تحديداً:

• معدّات شبكية قديمة (راوترات، مبدّلات Switches، أجهزة إدارة قديمة) لم تُحدَّث إعداداتها الافتراضية منذ سنوات.
• أجهزة إنترنت الأشياء (IoT) رخيصة الثمن، خصوصاً كاميرات المراقبة وأجهزة التوجيه المنزلية، حيث يكون Telnet مفعَّلاً افتراضياً للصيانة عن بُعد من الشركة المصنِّعة، غالباً بدون علم المستخدم النهائي.
• بيئات تقنية تشغيلية (OT) وأنظمة تحكم صناعي قديمة، حيث استبدال البروتوكول يتطلب توقف تشغيل مكلفاً، فتبقى الأجهزة كما هي لسنوات طويلة.

هذا يجعل Telnet هدفاً واقعياً بمرحلة الاستطلاع بأي اختبار اختراق شبكي، لا مجرد فضول أكاديمي عن بروتوكول منقرض.

المشكلة الجوهرية: لا تشفير إطلاقاً

كل ما يُرسَل عبر جلسة Telnet — اسم المستخدم، كلمة المرور، وكل أمر يُكتب بالجلسة — ينتقل نصاً صريحاً غير مشفَّر (Plaintext) عبر الشبكة. هذا يعني أن أي طرف قادر على مراقبة حركة مرور الشبكة بين العميل والخادم (سواء عبر الوصول لنفس الشبكة المحلية، أو التموضع بأي نقطة وسيطة على مسار الاتصال) يستطيع ببساطة قراءة كل شيء مباشرة، بدون الحاجة لأي عملية فك تشفير أو استغلال ثغرة تقنية معقدة.

هذه النقطة تحديداً هي ما يجعل Telnet مختلفاً جوهرياً عن أغلب “الثغرات” التقليدية: المشكلة ليست خللاً برمجياً يمكن تصحيحه بتحديث، بل خاصية تصميمية أساسية بالبروتوكول نفسه — الحل الوحيد الحقيقي هو استبداله بالكامل، لا “تصحيحه”.

الاستطلاع (Enumeration)

جمع معلومات البانر (Banner Grabbing)

أول خطوة عملية هي الاتصال المباشر بالمنفذ لمعرفة نوع الجهاز أو نظام التشغيل الذي يكشفه البانر الترحيبي، والذي غالباً ما يفصح عن معلومات أكثر مما ينبغي (اسم الشركة المصنِّعة، رقم الإصدار، أحياناً حتى تعليمات تسجيل الدخول):

nc -vn <IP> 23

أو باستخدام عميل Telnet نفسه مباشرة:

telnet <IP> 23

فحص Nmap المتخصص

يمتلك Nmap مجموعة سكربتات مخصصة لبروتوكول Telnet تكشف معلومات إضافية عن الخيارات المدعومة والبانر:

nmap -p23 <ip> -sC -sV          # فحص افتراضي مع كشف الإصدار
nmap -p23 <ip> --script telnet-encryption   # التحقق من دعم أي طبقة تشفير اختيارية
nmap -p23 <ip> --script telnet-ntlm-info    # استخراج معلومات NTLM إن وُجدت (تطبيقات Telnet على ويندوز)
nmap -p23 <ip> --script telnet-brute        # تخمين بيانات اعتماد آلي مباشرة عبر Nmap نفسه
nmap -p23 <ip> --script telnet-topt         # عرض كل خيارات التفاوض (Options) التي يدعمها الخادم

تنبيه مهم بمرحلة الاستطلاع: لا تقتصر فحصك على المنفذ 23 فقط. أجهزة إنترنت الأشياء المدمجة كثيراً ما تُشغِّل خدمة Telnet على منافذ غير قياسية مثل 2323 أو 9999 لتفادي الفحص الآلي السطحي — فحص شامل للمنافذ المفتوحة (لا الشائعة فقط) يبقى ضرورياً قبل الحكم بغياب الخدمة.

البحث عبر Shodan

محرك البحث Shodan يفهرس ملايين الأجهزة المتصلة بمنفذ Telnet المفتوح حول العالم، وهو نقطة انطلاق شائعة لأبحاث تستهدف أجهزة إنترنت الأشياء المكشوفة تحديداً:

telnet
port:23

تحقق دائماً: هل تُطلَب مصادقة أصلاً؟

قبل الانتقال مباشرة لتجربة بيانات اعتماد، تحقق أولاً هل الجهاز يطلب تسجيل دخول من الأساس. كثير من معدّات الشبكات القديمة أو الأجهزة المُعدَّة بشكل خاطئ تمنح صدفة (Shell) فورية بمجرد الاتصال، دون أي طلب مصادقة إطلاقاً — خصوصاً على معدّات شبكية قديمة (مثل بعض أجهزة Cisco المُعدَّة بكلمة مرور على مستوى الخط line vty فقط دون تفعيل مصادقة مستخدمين فردية)، حيث الوصول لمنفذ Telnet نفسه يُعتبَر كافياً بحد ذاته لدى مُعِدّ الجهاز الأصلي. هذا يجعل مجرد الاتصال الأولي بالبانر خطوة تستحق التوقف عندها قبل الانتقال لأي خطوة أعقد.

بيانات الاعتماد الافتراضية: نقطة الضعف الأكبر عملياً

المشكلة الأكثر استغلالاً واقعياً بأجهزة Telnet ليست ثغرة تقنية معقدة، بل ببساطة بيانات اعتماد افتراضية لم تُغيَّر أبداً. عدد ضخم من أجهزة الشبكات وإنترنت الأشياء يُشحَن من المصنع بمجموعة صغيرة ومعروفة علناً من أسماء المستخدمين وكلمات المرور، ولا يقوم أغلب المستخدمين بتغييرها إطلاقاً بعد التركيب.

هذا النمط تحديداً — أجهزة IoT بأعداد ضخمة، بيانات اعتماد افتراضية موحَّدة ومعروفة، وبروتوكول إدارة مفتوح دون تشفير — هو بالضبط ما استغلته شبكة الروبوتات الخبيثة الشهيرة Mirai عام 2016، التي مسحت الإنترنت بحثاً عن أجهزة IoT تستجيب على منفذ Telnet، وجرَّبت عليها قائمة قصيرة من بيانات الاعتماد الافتراضية الشائعة (نحو 60 مجموعة فقط)، لتُجنِّد مئات الآلاف من الأجهزة المخترَقة بهجمات حرمان من الخدمة (DDoS) ضخمة من أشهرها بتاريخ الإنترنت. هذا مثال واقعي وموثَّق تاريخياً يوضّح كيف أن مشكلة “بسيطة” (كلمة مرور افتراضية لم تتغيَّر) على بروتوكول قديم يمكن أن تتحول لتهديد بحجم عالمي حين تتكرر على ملايين الأجهزة دفعة واحدة.

تخمين بيانات الاعتماد بالقوة العمياء

عندما لا تنجح بيانات الاعتماد الافتراضية المعروفة، يمكن اللجوء لتخمين منظَّم باستخدام أدوات مخصصة:

hydra -l admin -P /path/to/wordlist.txt <IP> telnet

أو باستخدام أداة Medusa كبديل:

medusa -h <IP> -u admin -P /path/to/wordlist.txt -M telnet

وأداة Ncrack كخيار ثالث، مفيدة تحديداً عندما تريد الانتقال مباشرة لجلسة تفاعلية فور نجاح إحدى المحاولات بدلاً من الاكتفاء بعرض بيانات الاعتماد الصحيحة:

ncrack -p 23 --user admin -P /path/to/wordlist.txt <IP>

هجوم الوسيط والتنصت (Sniffing / MITM)

بما أن حركة مرور Telnet غير مشفَّرة بالكامل، فإن أي وضعية تسمح للمهاجم بمراقبة حركة الشبكة كافية لسرقة بيانات الاعتماد كاملة دون أي حاجة لكسرها أو تخمينها إطلاقاً. أبسط سيناريو عملي:

• المهاجم موجود على نفس الشبكة المحلية للضحية (سواء عبر شبكة Wi-Fi مشتركة، أو مقطع شبكي (VLAN) واحد).
• باستخدام أداة تحليل حزم مثل Wireshark أو tcpdump، يمكن تصفية حركة المرور على المنفذ 23 مباشرة ومشاهدة كل حرف يُكتب أثناء تسجيل الدخول، بما فيه كلمة المرور، بشكل نص واضح تماماً.
• إذا لم تكن حركة المرور تمر أصلاً عبر جهاز المهاجم (شبكة مبدَّلة Switched Network)، يمكن اللجوء لتقنيات انتحال إضافية مثل ARP Spoofing (عبر أدوات مثل Ettercap أو Bettercap) لإعادة توجيه حركة المرور عبر جهاز المهاجم أولاً قبل وصولها لوجهتها الحقيقية.

هذا النوع من الهجوم لا يحتاج أي مهارة استغلال متقدمة — المشكلة بالكامل ناتجة عن غياب التشفير، لا عن خلل برمجي يتطلب استغلالاً معقداً.

بعد الوصول: ماذا يعني الحصول على جلسة Telnet فعلياً؟

بمجرد نجاح تسجيل الدخول (سواء ببيانات اعتماد افتراضية أو مسروقة أو مخمَّنة)، تحصل على جلسة طرفية كاملة (Full Shell) مباشرة — بخلاف بعض البروتوكولات الأخرى التي قد تمنح وصولاً محدوداً أو مقيَّداً، Telnet بطبيعته مصمَّم أصلاً لمنح تحكم كامل بسطر الأوامر. هذا يعني أن مستوى الخطر بعد اختراق بيانات اعتماد Telnet ناجحة عادة ما يكون مطابقاً لمستوى الخطر عند اختراق SSH بنجاح — تحكم كامل بالجهاز بصلاحيات الحساب المُستخدَم لتسجيل الدخول.

أتمتة الخطوات الأولى عبر Metasploit

إطار عمل Metasploit يوفّر مجموعة وحدات جاهزة تغطي أغلب مراحل التعامل مع Telnet دون كتابة سكربتات مخصصة:

• auxiliary/scanner/telnet/telnet_version — لجمع البانر وتعداد الخيارات المدعومة آلياً.
• auxiliary/scanner/telnet/brute_telnet — لتنفيذ هجوم قوة عمياء متعدد الخيوط.
• auxiliary/scanner/telnet/telnet_encrypt_overflow — يستهدف تحديداً خدمات Telnet قديمة على أنظمة Solaris 9/10 عبر ثغرة تجاوز سعة بمعالجة خيار التشفير (ENCRYPT)، وقد يؤدي لتنفيذ أوامر عن بُعد.
• exploit/linux/mips/netgear_telnetenable — يُفعِّل خدمة Telnet على عدد من راوترات NETGEAR عبر إرسال حزمة معدَّة خصيصاً، حتى لو كانت الخدمة معطَّلة أصلاً بإعدادات الجهاز.

رفع مستوى الصدفة (TTY Upgrade)

الصدفة (Shell) التي تحصل عليها عبر Telnet غالباً ما تكون “غبية” (Dumb TTY) — لا تدعم اختصارات لوحة المفاتيح الاعتيادية، ولا التحكم بالمهام، ولا حتى تمرير أوامر تفاعلية معقدة بشكل سليم. الحل المعتاد بهذه الحالة (وهو أسلوب عام يتكرر بعد أي نوع وصول محدود مشابه، لا يقتصر على Telnet وحده) هو ترقية الصدفة لصدفة تفاعلية كاملة عبر Python المتوفر غالباً على أي نظام Linux:

python -c 'import pty;pty.spawn("/bin/bash")'

ثغرة حديثة تستحق المتابعة: تجاوز مصادقة بخدمة GNU Inetutils telnetd (CVE-2026-24061)

من الأمثلة الحديثة والمثيرة للاهتمام على أن Telnet لا يزال عرضة لثغرات برمجية فعلية، لا فقط لضعف تصميمي عام، ثغرة CVE-2026-24061 المكتشَفة بخدمة telnetd التابعة لحزمة GNU Inetutils — وهي أحد التطبيقات الشائعة لخادم Telnet على أنظمة Linux.

جذر المشكلة يعود لطريقة غير آمنة بمعالجة بيانات يتحكم بها العميل مباشرة. بروتوكول Telnet يحتوي خاصية تفاوض تُسمى NEW_ENVIRON، تسمح للعميل بإرسال متغيرات بيئة (Environment Variables) للخادم أثناء تأسيس الاتصال — من ضمنها متغير USER. المشكلة أن خدمة telnetd كانت تأخذ قيمة هذا المتغير وتضعها مباشرة داخل قالب أمر تسجيل الدخول (عبر رمز نائب %U) دون أي تنقية أو تحقق من محتواها إطلاقاً.

الاستغلال الفعلي بسيط بشكل لافت: إذا أرسل العميل قيمة USER تبدأ بشرطة (-)، فإن أمر login الناتج يفسِّرها كخيار سطر أوامر بدلاً من اسم مستخدم عادي. تحديداً، إرسال القيمة -f root يحوّل الأمر النهائي إلى ما يعادل /usr/bin/login -h <hostname> "-f root" — وخيار -f بأمر login يعني تحديداً “هذا المستخدم مصادَق عليه مسبقاً، لا تطلب كلمة مرور”. النتيجة: صدفة (Shell) بصلاحيات root كاملة، دون أي بيانات اعتماد ودون أي تفاعل يتجاوز الاتصال الأولي نفسه.

هذا يوضّح مبدأً أمنياً عاماً مهماً يتكرر بأشكال مختلفة بثغرات كثيرة: أي قيمة قادمة من العميل تُمرَّر لاحقاً كوسيط بسطر أوامر يجب تنقيتها والتحقق من محتواها أولاً — الثقة بمدخلات العميل دون تحقق، حتى لو بدت “مجرد اسم مستخدم”، يمكن أن تفتح باباً لتفسير تلك القيمة بشكل مختلف تماماً عما هو متوقَّع.

الإصدارات المتأثرة: GNU Inetutils telnetd من الإصدار 1.9.3 وحتى 2.7 — أي أن الثغرة بقيت غير مكتشَفة لأكثر من 11 عاماً كاملة قبل الإفصاح عنها.

التصحيح: أضافت الإصدارات اللاحقة دالة تنقية (sanitize()) ترفض أي قيمة تبدأ بشرطة أو تحتوي على رموز خاصة بالصدفة (Shell Metacharacters) قبل استخدامها بأمر تسجيل الدخول.

كيف تتحقق من تعرّض جهازك؟

telnetd --version
systemctl status inetutils-telnetd

راجع أيضاً سجلات النظام بحثاً عن أي عمليات تسجيل دخول لمستخدم root دون بيانات اعتماد واضحة — مؤشر محتمل على استغلال سابق لهذه الثغرة تحديداً.

ثغرة ثانية بنفس الخدمة: تجاوز سعة المخزن المؤقت بمعالجة LINEMODE (CVE-2026-32746)

بعد وقت قصير من الكشف عن CVE-2026-24061، اكتشف باحثو شركة WatchTowr ثغرة مستقلة تماماً بنفس خدمة GNU Inetutils telnetd — وهذه المرة، الخلل عمره أطول بكثير: 32 عاماً كاملة قبل اكتشافه.

آلية الثغرة: أثناء تفاوض بروتوكول Telnet، يدعم الخادم خاصية تُسمى LINEMODE، تسمح للعميل بتخصيص كيفية تعامل الطرفية مع بعض الأحرف الخاصة (Special Characters) عبر إرسال مجموعات بيانات ثلاثية (Triplets). المشكلة أن الكود المسؤول عن استقبال هذه البيانات يخزّنها داخل مصفوفة (Array) ذات حجم ثابت ومحدود مسبقاً، دون أي تحقق من حجم البيانات المُرسَلة فعلياً قبل تخزينها. هذا يسمح للمهاجم بإرسال بيانات أكبر من سعة المصفوفة المخصَّصة، فتفيض (Overflow) لتكتب فوق متغيرات مجاورة بذاكرة البرنامج — وهو ما يُعرف تقنياً بـالكتابة خارج الحدود المخصَّصة (Out-of-Bounds Write).

النقطة الأخطر: هذه الثغرة لا تتطلب أي مصادقة إطلاقاً، ويكفي اتصال شبكي واحد بالمنفذ 23 لتحفيزها — بدون بيانات اعتماد، بدون تفاعل من المستخدم، وبدون أي وضعية شبكية خاصة يحتاجها المهاجم.

بحسب تحليل WatchTowr، استغلال الثغرة لتحقيق تنفيذ أوامر كامل ليس بالبساطة نفسها رغم خطورتها النظرية — هناك عدة قيود تقنية تعقّد الاستغلال الموثوق (حدود على طول البيانات المقبولة، تعامل خاص مع بعض القيم البايتية، واختلاف صعوبة الاستغلال حسب معمارية المعالج)، وأثبت الباحثون إمكانية تحقيق تسريب لعناوين الذاكرة وتخريب مؤشرات داخلية كخطوة أولى، دون إثبات تنفيذ أوامر عن بُعد كامل وموثوق على كل بيئة.

نطاق التأثير الواسع بشكل لافت: الثغرة لا تقتصر على Linux فقط، بل تمتد لعدد كبير من الأنظمة والمنتجات التي تعتمد على نفس كود telnetd الأساسي، من ضمنها توزيعات Ubuntu وDebian، وأنظمة FreeBSD وNetBSD، ومنتجات تجارية مثل Citrix NetScaler، وحتى أنظمة تشغيل أقل شيوعاً مثل Haiku وTrueNAS Core.

حالة التصحيح وقت الكشف: لم يكن مشروع inetutils قد أصدر بعد إصداراً رسمياً مُصحَّحاً بشكل جاهز للتنزيل المباشر؛ التصحيح توفَّر فقط عبر كود المصدر (Git) مباشرة، ما يعني أن كثيراً من الأنظمة المتأثرة قد تبقى معرَّضة لفترة أطول من المعتاد ريثما تصل التصحيحات لقنوات التوزيع الرسمية لكل نظام تشغيل على حدة.

التوصيات الدفاعية

• استبدل Telnet بـSSH كلياً أينما أمكن ذلك تقنياً — هذا الحل الوحيد الجذري، لا مجرد تخفيف مؤقت.
• إذا تعذَّر الاستبدال الفوري (معدّات قديمة لا تدعم SSH إطلاقاً)، اعزل الجهاز على شبكة فرعية (VLAN) منفصلة تماماً عن الشبكة العامة، بحيث لا يصل لمنفذ Telnet إلا من مصدر موثوق ومحدود جغرافياً وشبكياً.
• غيِّر بيانات الاعتماد الافتراضية فوراً عند تركيب أي جهاز جديد — هذه الخطوة الفردية وحدها كانت لتمنع حملة Mirai بالكامل لو طُبِّقت على نطاق واسع.
• راقب حركة الشبكة بحثاً عن اتصالات Telnet غير متوقَّعة — وجود أي حركة مرور فعلية على المنفذ 23 داخل شبكة حديثة مؤشر يستحق التحقيق الفوري بحد ذاته.

ملاحظات OPSEC

أدوات الحماية التي قد تكشف النشاط:

• سجلات النظام على الجهاز المستهدَف: أغلب تطبيقات خادم Telnet تسجّل محاولات تسجيل الدخول (الناجحة والفاشلة) بسجلات النظام المحلية، وإن كانت أجهزة IoT الرخيصة أحياناً لا تحتفظ بسجلات فعلية إطلاقاً.
• أنظمة كشف التسلل على مستوى الشبكة (NIDS): يمكنها رصد أي حركة مرور Telnet غير معتادة، خصوصاً على شبكات يُفترَض أنها لا تستخدم هذا البروتوكول أصلاً.
• أدوات مراقبة الشبكة المحلية: أي محاولة انتحال ARP لتنفيذ هجوم وسيط تترك أثراً واضحاً على أدوات مثل Wireshark أو Arpwatch.

مستوى الضجيج لكل تقنية:

كيف نقلل الأثر:

• فضّل التنصت السلبي (بدون انتحال) كلما كانت حركة المرور تمر أصلاً عبر مقطعك الشبكي — أهدأ خيار متاح بكثير.
• إذا احتجت لانتحال ARP، اقتصر عليه ضمن نطاق اختبار مصرَّح به صراحة فقط، وكن مستعداً لاكتشافه بسهولة عبر أي أداة مراقبة شبكة حديثة.
• جرّب بيانات الاعتماد الافتراضية الأكثر شيوعاً أولاً قبل اللجوء لـBrute Force منظَّم — أغلب الأجهزة المعرَّضة فعلياً تسقط بمحاولات قليلة جداً، دون الحاجة لضجيج قائمة كلمات ضخمة.

🛠️ أدوات لفحص Telnet

ملاحظات

• Telnet موثَّق رسمياً بمعيار RFC 854 الصادر عن IETF منذ عام 1983، وهو المرجع التقني الأساسي للبروتوكول من الناحية النظرية البحتة.
• حملة الروبوتات الخبيثة Mirai (2016) تبقى المثال الأشهر تاريخياً على الأثر الواقعي لترك بيانات اعتماد Telnet الافتراضية دون تغيير على نطاق واسع من أجهزة إنترنت الأشياء.

المصادر

• التحليل التقني لثغرة CVE-2026-24061: OffSec — GNU InetUtils telnetd Authentication Bypass Vulnerability
• التحليل التقني لثغرة CVE-2026-32746: WatchTowr Labs — A 32-Year-Old Bug Walks Into a Telnet Server
• مرجع عام حول منهجية اختبار اختراق Telnet: HackTricks — Pentesting Telnet