Advertising in the Telegram channel «𝔹𝔸𝔻 ℝ𝔸𝔹𝔹𝕀𝕋» from 6.00

Channel info
Full statistics

Recent Channel Posts

‼️ اختراق خوادم الويب (Hacking Web Server)

الصفحات من 530 لغاية 539 بتتكلّم عن نقطة مهمة: إن كتير من الاختراقات الكبيرة اللي اتسابت في التاريخ الرقمي بدأت بثغرات بسيطة في الخادم أو إعداداته. يعني مش دايمًا لازم يكون فيه عبقري خارق وهاكر عبقري علشان يحصل خرق؛ ساعات غلطة إدارية صغيرة، ملف سبام متساب، أو امتداد انتهى صلاحيته هو اللي بيفتح الباب كله. الحكاية دي اتأكدت في حالات مشهورة زي اختراق HBGary Federal سنة 2011، اللي بدأ بثغرات بسيطة في تطبيقات الويب.

الجزء ده بيركز على الثغرات اللي أصلها في برنامج خادم الويب نفسه (زي Apache أو Microsoft IIS) والإعدادات الافتراضية والملحقات اللي بتشتغل عليه — مش على لوجيك التطبيق المكتوب خصيصًا. زمان كانت الأنظمة أكثر عرضة لأن في برمجيات خوادم كانت بتتحمل شغل كبير من غير حماية، وده خلق فيروسات مدمرة زي Code Red وNimda اللي استهدفت IIS وعملت خراب كبير. دلوقتي الوضع اختلف شوية لأن الناس اتعلمت والموردين بقى عندهم وعي أمني أكبر، لكن لسه في مشاكل شائعة لازم نعرفها ونحلها.

أسباب تحسّن المخاطر نسبياً مع الوقت

🔸المطورين والمنصات اتعلموا من أخطاء الماضي: سواء في الشركات الكبيرة أو المجتمع المفتوح المصدر، في وعي أكبر بأهمية الأمان في التصميم والإعداد.

🔸الإعدادات الافتراضية تحسّنت: بقى فيه افتراضات أمانية أفضل بدل ما تبقى كل حاجة مفتوحة من الأول.

🔸سرعة إصدار الباتشات: الشركات بقت أسرع في الاستجابة للثغرات وإصدار تحديثات.

🔸أدوات وقائية ظهرت: منتجات زي URLScan من مايكروسوفت وأنظمة فحص التطبيقات اللي بتقلل السطح الهجومي.

🔸أدوات الفحص الآلية: ماسحات الثغرات خلت كشف المشكلات أسهل وأسرع، سواء للمدافعين أو للمهاجمين.

رغم كده، ما ينفعش نرتاح: في ثغرات كلاسيكية لسه بتظهر أو تنعاد بسبب أخطاء بسيطة في التكوين أو ترك ملفات غير لازمة. نعدي على كل نوع ونشرحه مع أمثلة وإجراءات مضادة.

‼️ الملفات النموذجية (Sample Files) — الحاجة اللي الناس بتنسى تشيلها

كثير من منتجات الخوادم والأطر البرمجية بتيجي معاها ملفات تعليمية أو أمثلة (sample/example files)، ودي درجة من درجات الراحة للمطورين علشان يعرفوا ازاي يشتغلوا بالمنتج. المشكلة إن لو الحاجات دي ما اتشالتش قبل ما السيرفر يدخل الإنتاج، المهاجم يقدر يستغلها لقراءة ملفات حساسة أو تنفيذ حاجات ما المفروض ينفذها حد برا.

❇️ أمثلة تاريخية

🔸 في إصدارات قديمة من IIS 4.0 كان في ملفات زي showcode.asp و codebrews.asp، واللي سمحت للمهاجم يقرأ محتوى ملفات تقريبا على الخادم بس عن طريق تلاعب بالمسارات. يعني حد كان يقدر يقرأ boot.ini ويشوف إعدادات النظام. الوضع ده كان سهل جدا واستغلته أدوات وتهجمات كتير.

إزاي تتعامل معاه؟

🔸 أبسط وأوضح إجراء: كل ملفات العينات والأمثلة لازم تتشال من السيرفرات اللي في الإنتاج.

🔸لو عندك سيرفر جديد أو تطبيق جديد، ضمن عملية التسليم (deployment) خطوة واضحة تشيل أي ملفات demonstration أو docs اللي جاية مع المنتج.

🔸 كمان مهم إن تكون عندك سياسة تراجع دورية (periodic review) للـ web root عشان تلاقي أي حاجة اتسابت بالغلط.

‼️ كشف الكود المصدري (Source Code Disclosure) — لما الكود يطلع للعالم

أيه المشكلة؟

لو المهاجم قدر يرجع الكود المصدري لصفحات التطبيق بدل ما الخادم ينفّذه، هيبقى عنده كل الأسرار: استعلامات SQL، كلمات مرور، مفاتيح تشفير، أو حتى كيفية تصميم الـauth. ده بيسهل عليه التخطيط لهجوم فعّال.

❇️ أمثلة تاريخية

🔸 ثغرة +.htr في IIS كانت بتسمح بالمهاجم إنه يطالب بملف معين في الصورة الخام بتاعته ويخلّيه يقراه بدل ما ينفّذه.

🔸 مشاكل مشابهة حصلت في Apache Tomcat وBEA WebLogic، حيث كان إضافة أحرف خاصة أو رموز في نهاية الطلب (زي index.js%70) بتخلي السيرفر يرجّع كود JSP بدل ما يعالجه وينفذه.

الإجراءات المضادة

🔹دايمًا طبّق الباتشات الأمنية فور صدورها لأن أغلب الحالات دول اتحلت بتصحيحات من المطورين.

🔹الأهم: ما تخزّنش بيانات حساسة داخل الكود الثابت (hard-coded). كلمات السر، مفاتيح DB، أسرار التشفير لازم تبقى في مخازن آمنة (مثل vaults أو متغيرات بيئة مقفولة أو إدارة أسرار).

🔹راجع صلاحيات الملفات: تأكد إن صلاحيات الملفات على الخادم تمنع الوصول للملفات المصدرية لأي مستخدم عادي.

‼️ هجمات التطبيع (Canonicalization Attacks) — الخدع في أسماء الملفات والتمثيل

شرح الفكرة بشكل مبسّط

♦️ التطبيع أو canonicalization معناها تحويل اسم المورد (زي مسار ملف) لشكله القياسي قبل إن التطبيق يتعامل معاه. المشكلة إن ممكن يكون في طرق مختلفة لكتابة نفس الملف، والمهاجم يستغل الاختلافات دي عشان يخدع التطبيق أو الخادم.

أمثلة عملية

♦️ ::$DATA في IIS: استغلال اسم مورد مخصوص سمح بتحميل الكود المصدري لملفات ASP بدل تنفيذها.

397

19:54

05.10.2025

♦️ في Apache على Windows، كان ممكن الطلب بـ /CGI-BIN/foo بدل /cgi-bin/foo يخلي الخادم يتعامل مع المسار بطريقة غير متوقعة لأن نظام ملفات Windows مش حساس لحالة الأحرف لكن Apache حساس — فالتوافق بين تصرفات النظام والـserver خلق ثغرة.

♦️ ثغرات Unicode وDouble Decode في IIS: النوع ده من الهجمات اتوظفته فيروسات زي Nimda علشان تتجاوز فلاتر وتوصل لملفات مش مفروض توصلها.

إجراءات مضادة عملية

🔹 حدّث منصة الويب دايمًا. المطورين غالبًا يحطوا حلول للتطبيع في التحديثات.

🔹اعزل دلائل السكربت (scripts) عن الـ document root — يعني ما تخليش ملفات تنفيذ السكربتات متاحة في نفس المكان اللي الخدمة العادية بتقدّم منه المحتوى الساكن.

🔹استخدم أدوات تصفية للطلبات زي URLScan أو WAF (Web Application Firewall) لضرب الطلبات اللي فيها رموز مش متوقعة أو ترميزات متعددة أو تسلسلات بتحاول تخرج عن المعهود.

‼️ ملحقات الخادم (Server Extensions) — الامتدادات اللي بتجيب مشكلات

خوادم الويب بتحصل على ميزات كثيرة عن طريق ملحقات وبرمجيات إضافية: WebDAV للتعامل مع المجلدات عن طريق HTTP، بروتوكولات طباعة، خدمات فهرسة، وحدات SSL، إلخ. المشكلة إن كل ملحق بيفتح مساحة جديدة ممكن يكون فيها ثغرة.

أمثلة مهمة ومؤثرة

♦️ الـ WebDAV على IIS: ثغرة مشهورة كانت بتخلي الخادم يرد بمحتوى ملفات ASP بدل تنفيذها لما يجيلها طلب HTTP محدد يحتوي هيدر Translate: f ويضيف شرطة مائلة عكسية (\) في نهاية الـURL. الملحق يتلخبط ويرجع المحتوى النصي، وبكده تتكشف كلمات المرور أو إعدادات مهمة لو كانت محفوظة في الملفات.

♦️ برضه في الماضي اتعرفت ثغرات في خدمات الفهرسة (Indexing Service)، وفي بروتوكولات الطباعة عبر الشبكة، وفي تعاملات SSL معينة.

الإجراءات المضادة

🔹 تعطيل أي ملحقات أو خدمات مش محتاجها عشان تقلل السطح الهجومي. لو مش بتستخدم WebDAV، خلّيه مقفل.

🔹 لو بتستخدم ملحق لا غنى عنه، طبّق تحديثات الملحق فورًا وتابع إعلانات الأمان الخاصة به.

🔹 راجع صلاحيات الوصول للملفات اللي الملحقات دي بتتعامل معاها، وما تخليش ملفات حساسة في مجلدات ممكن الملحق يوصلها.

‼️ تجاوز سعة المخزن المؤقت (Buffer Overflows) — لما الذاكرة تتخانق

ثغره Buffer overflow بيحصل لما البرنامج يحاول يكتب بيانات كبيرة في مساحة مخصصة أصغر، وده ممكن يبدّل في الذاكرة ويخلّي المهاجم ينفّذ كود بمستوى صلاحيات عالي. من أخطر الثغرات التاريخية.

❇️ أمثلة وتأثير عملي

في فترات مختلفة خلال التاريخ، تم اكتشاف ثغرات تجاوز سعة في خوادم مثل IIS وApache، وبعضها استُغل بواسطة ديدان وفيروسات زي Code Red وSlapper وScalper. النتائج كانت وقف خدمات، تنفيذ أكواد عن بعد، وانتشار سريع جدًا.

الوقاية

🔹أبسط وأقوى وسيلة: طبّق الباتشات اللي بتصدرها فرق التطوير للسيرفر فورًا. أغلب مصدري الخوادم بيصدروا تحديثات لمعالجة الثغرات دي أول بأول.

🔹على مستوى التطوير، لازم نتبع ممارسات برمجة آمنة (مثل استخدام لغات أو مكتبات بتضمن إدارة الذاكرة بأمان أو فحص الحدود) لتقليل وجود الثغرات الأصلية في البرامج.

‼️ هجمات حجب الخدمة (Denial of Service) — الضوضاء اللي توقف الخدمة

التمييز بين DoS وDDoS باختصار

🔸DoS: هجوم بيجي من مصدر واحد أو محدود وبيستنزف موارد السيرفر لحد ما يوقفه.

🔸DDoS: نفس الفكرة لكن المصادر كتيرة وموزعة، وده بيصعب الدفاع عنه لأنه جاي من كتير نقاط.

أمثلة حديثة لطرق مبتكرة

في أواخر 2011 اتعرفت ثغرة أثرت على بيئات تشغيل كثيرة (مثل PHP5, .NET, Java) بتعتمد على تصادمات دوال التجزئة (hash collisions). الهجوم كان بسيط: إرسال طلب POST فيه عدد كبير جدًا من المعاملات (parameters)، فخوادم الويب أو مكتبات الـparsing بتبدأ تعالج وتدخل في حالة أداء سيئ جدًا لحد ما الخادم ينهار. الفكرة إن الهجوم معتمد على نقطة تصميمية مش على ثغرة برمجية بحتة.

❇️ إجراءات مضادة عملية

🔹دايمًا حدّث. لو فيه تصحيح للثغرة من مزود التكنولوجيا، نفذه.

🔹نفّذ مراقبة وتحليل لحركة المرور (traffic monitoring) واستخدم سياسات تحديد معدلات الطلب (rate limiting) وWAFs اللي بتقدر ترفض أنماط مش طبيعية.

🔹تحضير خطط استجابة للحوادث (incident response) وخطط للتخفيف من تأثير DDoS (زي استخدام خدمات CDN أو مزودي حماية DDoS).

‼️ أدوات فحص ثغرات خوادم الويب — الكاشف الآلي

بدل البحث اليدوي اللي بياخد وقت ومجهود ويغفل حاجات، الأدوات دي بتعمل مسح واسع وبسرعة وتطلع تقارير تساعد المسؤولين ينسقوا الإجراءات. كمان المهاجمين بيستخدموها لنفس الغرض، عشان كده مهم المسح الاستباقي.

أدوات مشهورة وماذا تفعل

429

19:54

05.10.2025

Nikto: أداة مفتوحة المصدر مخصصة لفحص خوادم الويب. بتبعت مجموعة من طلبات HTTP المصممة عشان تكشف ملفات نموذجية، رؤوس HTTP ناقصة، إصدارات قديمة، ومشاكل تهيئة. قاعدة بيانات الفحوص بتتحدث باستمرار. Nikto مفيدة في الاكتشاف السريع للهروبات السطحية.

Nessus: أداة فحص أكثر شمولًا، بتفحص الشبكة كلها مش بس الويب. فيها آلاف plugins تختبر ثغرات متعددة، منها ثغرات خوادم الويب. Nessus بيدي تقارير مفصلة ومصنّفة حسب مستوى الخطورة، ومناسب كجزء من سياسات المسح الدوري.

(طبعاً في ادوات Automation احسن من الأثنين دول، لكن تمام)

‼️ الخاتمة| TheEndGame

في الآخر الموضوع مش محتاج سحر، محتاج انتظام. شيل اللي مش لازِم، حدّث بسرعة، وقفّل اللي مش بتستخدمه، وارجع افحص تاني. الأمان روتين مش حدث لمرة واحدة: لو خليت الفحص والتحديث جزء من شغلك اليومي، هتوفر على نفسك مشاكل كبيرة بعدين. وخلاصة النصيحة: كل حاجة مش لازمة اقفلها — والسيرفر هيرتاح وإنت هتنعم بنوم أحسن.

546