دوره SEC542 – بخش بیست و یکم

در این بخش از دوره آموزشی SEC542 شما با آسیب پذیری های LFI و RFI و همچنین آسیب پذیری Directory Traversal آشنا خواهید شد.

آسیب پذیری LFI/RFI

آسیب‌پذیری File Inclusion یا همان آسیب پذیری LFI/RFI به مهاجم اجازه می‌دهد تا با اکسپلویت مکانیزم‌های “dynamic file inclusion”، بتواند یک فایل را در اپلیکیشن آسیب‌پذیر include کند. این آسیب‌پذیری به دلیل عدم اعتبارسنجی و فیلتر مناسب ورودی‌های کاربر و استفاده مستقیم از آن‌ها، اتفاق می‌افتد.

تست شماره OTG-INPVAL-012 از استاندارد OWASP، آسیب‌پذیری File Inclusion از نوع remote و local را پوشش می‌دهد.

Local and Remote File Include

باگ‌های File Inclusion یا همان آسیب پذیری LFI/RFI می‌توانند فایل‌های local (محلی) و remote (راه دور) را دریافت کنند. این تقسیم ‌بندی از دید اپلیکیشن انجام شده است. بدین ترتیب فایل‌های local فایل‌هایی هستند که بر روی سروری که اپلیکیشن بر روی آن در حال اجراست، وجود دارند.

فایل‌های remote روی سروری غیر از سرور اپلیکیشن قرار دارند. به خاطر داشته باشید که فیلترینگ نوع egress (اعمال محدودیت بر روی ترافیک outbound مابین چند شبکه) ممکن است جلوی load کردن فایل‌ها از سرورهای remote خارجی را در اپلیکیشن بگیرد، اما برای سرورهای داخل یک شبکه همچنان این قابلیت وجود دارد.

مهاجم با یافتن یک Local File Inclusion می‌تواند فایل‌هایی از سرور را بخواند که این مصداق فاش شدن اطلاعات یا information disclosure است. در صورت وجود Remote File Inclusion نیز امکان بازیابی فایل‌ها از یک سرور خارجی وجود داشته و محتویات فایل توسط اپلیکیشن استفاده می‌شود. در نوع remote ، احتمال وجود code execution در اپلیکیشن افزایش می‌یابد.

Directory Traversal and File Inclusion

Directory Traversal یک آسیب‌پذیری است که به ما اجازه می‌دهد از مسیر روت وب خارج شویم. بطور کلی وب‌سرور باید محدودیتی برای مسیرهایی که قرارست از آن‌ها فایل لود شود، اعمال کند.

پس از یافت Directory Traversal و خروج از مسیر اصلی اپلیکیشن، می‌توانیم فایل‌هایی از مسیرهای حفاظت شده (غیرمجاز) را لود یا اجرا کنیم. مسیر C:\Windows یا /etc دو نمونه از این مسیرها می‌باشند. این کار همان file inclusion است. گرچه این آسیب‌پذیری قدیمی است اما در اپلیکیشن‌های مدرن راه‌های جدید و جالبی برای بازی با آن وجود دارد.

Directory Traversal و file inclusion زمانی اتفاق می‌افتند که ما وب‌اپلیکیشن را فریب می‌دهیم تا فایل‌هایی را خارج از دایرکتوری WEBROOT بخواند یا اجرا کند. البته از file include برای خواندن فایل‌های داخل WEBROOT نیز می‌توان استفاده کرد.

متدولوژی دقیق استفاده از این آسیب‌پذیری‌ها به ماهیت و ذات آسیب‌پذیری در آن اپلیکیشن بستگی دارد. بعضی اوقات، آسیب‌پذیری به ما این اجازه را می‌دهد تا به سادگی با وارد نمودن “../../../../etc/shadow” یا هر فایل دیگر، به نتیجه برسیم. اما گاهی لازم است مثلا کدگذاری پیلود را تغییر داده و آن را بصورت Unicode وارد کنیم.

آسیب پذیری Command Injection

چند سال پیش، وب‌سرور IIS آسیب‌پذیری Directory Traversal داشت…چندین بار! اولین بار، با ارائه یک وصله امنیتی که کاراکتر “/” را تشخیص می‌داد، آسیب‌پذیری برطرف گشت. این روش به آسانی با انکد کردن کاراکتر “/” با Unicode بایپس شد. دلیلش دیکد شدن کاراکتر، بعد از دسترسی به دایرکتوری درخواستی بود.

مثال‌های سنتی

مثال مورد بررسی، یک آسیب‌پذیری از IIS است. این آسیب‌پذیری به مهاجم اجازه می‌داد تا یک URL بسازد که به دایرکتوری scripts دسترسی یافته و سپس دایرکتوری را به عقب برگشته تا در نهایت به cmd.exe برسد. دلیل اهمیت دایرکتوری scripts این بود که بطور پیش‌فرض این دایرکتوری، تنها دایرکتوری بود که برنامه‌ها از آن اجازه اجرا شدن داشتند.

http://vulnsite/scripts/../../../winnt/system32/cmd.exe+/c+dir

در این مثال برنامه cmd.exe اجرا شده و لیست دایرکتوری‌ها را برمی‌گرداند. گاهی برای بایپس فیلترها می‌توان از روش encoding استفاده نمود.

این، تنها مشکل IIS نیست بلکه سرورها و اپلیکیشن‌های زیادی آسیب‌پذیر بوده‌اند و هنوز هم از این دست آسیب‌پذیری یافت می‌شود. معمولا این باگ در پیاده‌سازی سرور ایجاد می‌شود اما در ادامه خواهیم دید که چطور اپلیکیشن‌ها نیز می‌توانند آسیب‌پذیر باشند.

لازم به ذکر است که وصله‌ها و راهکارهای امنیتی برای تمامی سرورهای آسیب‌پذیر منتشر شده است. پیشنهادات ارائه شده در گزارش تست نفوذ ما، باید شامل راهکار رفع آسیب‌پذیری و اطمینان از موثر بودن راهکارها باشد.

مثال اپلیکیشن

گاهی یک وب‌اپلیکیشن به مرورگر اجازه می‌دهد تا یک فایل تنظیمات و یک مسیر بر روی سرور را مشخص کند تا در تنظیمات اصلی کاربر جاری اعمال شود.

http://vulnsite/index.php?templ=../include/siteconfig.inc

از آنجائیکه هیچ فیلتری بر روی نوع و محتوای ورودی صورت نمی‌گیرد، می‌توانیم از پیلود زیر استفاده کنیم:

http//vulnsite/index.php?templ=/etc/passwd

همیشه آسیب‌پذیری directory traversal به راحتی قابل شناسایی نیست. مثلا ممکن است یک فیلد پنهان در یک فرم، تنها شامل یک متن ساده مانند message-stuff است اما این متن می‌تواند نام یک فایل باشد. سعی کنید آن را به ../message-stuff تغییر دهید و ببینید صفحه چگونه عوض می‌شود.

به خاطر داشته باشید که ما در مورد اکسپلویت کردن کدی صحبت می‌کنیم که توسط برنامه نویسانی نوشته شده که تنها به فکر نحوه کارکرد اپلیکیشن هستند نه امنیت آن. اگر همه چیز به خوبی پیش رود، اپلیکیشن رفتار نرمال خود را دارد. اما اگر به آن دست بزنیم، همه چیز بهم می‌ریزد.

هر کدی که مختص دسترسی به فایل‌ها از روی فایل‌سیستم سرور باشد، ممکن است آسیب‌پذیر باشد. اگر می‌توانیم، باید آن را چک کنیم.

Testing for Directory Traversal and File Include Flaws

برای تست این آسیب‌پذیری، خیلی ساده به دنبال پارامترهایی باشید که به نظر می‌رسد شامل نام فایل باشند. سپس آن‌ها را به گونه‌ای تغییر دهید که به خارج از مسیر روت وب اشاره کنند. همچنین به دنبال پارامترهایی باشید که اشاره به یک فایل دارند. مثلا templ=red ، که اپلیکیشن آن را به ../../template/red.php تبدیل می‌کند. مثال دیگر آن بصورت زیر می‌باشد:

config=site
../../includes/${config}.php

پارامترهای آشکار

برای پیاده‌سازی حملات directory traversal، باید مکان‌های پیش فرض فایل‌های مختلف را بدانید. مثلا، سیستم‌های لینوکس مبتنی بر Debian با وب‌سرور Apache، اغلب از مسیر /var/www/ یا /var/www/html به عنوان روت وب خود استفاده می‌کنند.

کاربران، هریک، روت‌های وب خود را در /home/username/public_html/ دارند. همچنین دایرکتوری /usr/lib/cgi-bin یک مکان رایج برای اسکریپت‌های CGI است. بقیه اپلیکیشن‌ها نیز ممکن است مسیرهای شناخته شده خود را برای روت وب و اسکریپت‌ها داشته باشند.

مهم‌ترین نکته اینست که بدانیم در حین اجرای اپلیکیشن/اسکریپت، مسیر جاری که در آن هستیم، کدام مسیر است. این اولین چیزی است که در هنگام تایپ “../” باید به آن فکر کنید.

زمانی که یک پارامتر آشکار (پارامتری که مسیر فایل دریافت می‌کند)پیدا می‌کنیم، باید بر اساس نوع سیستم‌عامل (که در فاز mapping تشخیص داده‌ایم)، مسیر فایل را وارد نمائیم. برای مثال به مسیرهای زیر دقت نمائید:

به خاطر داشته باشید که نتایج ممکن است در سورس صفحه ظاهر شوند.

Building Blocks

بعد از شناسایی پارامتری که به نظر می‌رسد آسیب‌پذیر باشد، راه‌های مختلف را برای لود فایل دلخواه امتحان کنید. اگر اپلیکیشن، از روی پارامترها مسیر می‌سازد، از منطق اپلیکیشن برای لود فایل استفاده کنید.

برای مثال، اگر از مثال بخش قبل استفاده کنیم، با ../../template/${tempvar}.php می‌توانیم کارهای زیر را انجام دهیم:

1- ../index ممکن است سورس کد فایل index را لود کند.
2- ../../../etc/passwd%00 ممکن است فایل /etc/passwd را لود کند.

%00 یک مقدار null است که در بسیاری از زبان‌های برنامه نویسی، برای مشخص نمودن انتهای یک رشته استفاده می‌شود. در مثال ما، نتیجه به شکل زیر درمی‌آید:

../../template/../../../etc/passwd%00.php

در این حالت، سیستم‌عامل، %00 و بقیه رشته (.php) را حذف می‌کند.

مطالب این بخش توسط سرکار خانم فهیمه رضایی تهیه شده است.