WSTG-ATHZ-01

بررسی Directory Traversal File Include

در این بخش از دوره آموزشی OWASP-WSTG به پنجمین بخش از استاندارد WSTG با شناسه WSTG-ATHZ-01 می پردازیم که مربوط به بررسی Directory Traversal File Include می باشد.

خلاصه

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

به طور سنتی، سرورهای وب و برنامه‌های کاربردی وب، مکانیزم‌های احراز هویت را برای کنترل دسترسی به فایل‌ها و منابع پیاده سازی می‌کنند. سرورهای وب سعی می‌کنند فایل‌های کاربران را در یک “root directory” یا “web document root” محدود کنند، که نشان‌دهنده یک دایرکتوری فیزیکی در سیستم فایل است. کاربران باید این دایرکتوری را به عنوان دایرکتوری پایه در ساختار سلسله مراتبی برنامه کاربردی وب در نظر بگیرند.

تعریف سطوح دسترسی با استفاده از فهرست‌های کنترل دسترسی (ACL) انجام می‌شود که مشخص می‌کند کدام کاربران یا گروه‌ها قرار است قادر به دسترسی، اصلاح یا اجرای یک فایل خاص بر روی سرور باشند. این مکانیزم‌ها برای جلوگیری از دسترسی کاربران مخرب به فایل‌های حساس (برای مثال، /etc/passwd در یک پلتفرم مانند یونیکس) ‏یا برای جلوگیری از اجرای فرمان‌های سیستم طراحی شده‌اند.

بسیاری از برنامه‌های کاربردی وب از اسکریپت‌های سمت سرور برای Include نمودن انواع مختلف فایل‌ها استفاده می‌کنند. استفاده از این روش برای مدیریت تصاویر، Template ها، Load نمودن متون استاتیک و غیره بسیار رایج است. متاسفانه، این برنامه‌ها در صورتی که پارامترهای ورودی (‏یعنی، پارامترهای فرم، مقادیر کوکی)‏ را به درستی اعتبارسنجی نکنند، منجر به بروز آسیب‌پذیری‌های امنیتی خواهند شد.

در سرورهای وب و برنامه‌های کاربردی وب، این نوع مشکل منجر به حملات path traversal/file include ، می‌شوند. با Exploit نمودن این نوع آسیب‌پذیری، مهاجم قادر به خواندن دایرکتوری‌ها یا فایل‌هایی است که به طور معمول قادر به خواندن آن‌ها نبوده است. همچنین امکان دسترسی به داده‌های خارج از web document root وجود داشته، یا حتی امکان Include نمودن اسکریپت‌ها و دیگر انواع فایل‌ها از وب سایت‌های خارجی وجود خواهد داشت.

این نوع حمله همچنین به عنوان حمله نقطه – نقطه – اسلش، directory traversal،directory climbing یا backtracking هم شناخته می‌شود.

در طول یک ارزیابی، تست نفوذگر باید برای کشف نقض امنیتی path traversal و فایلInclude ، دو مرحله مختلف را انجام دهد:

• شناسایی وکتورهای ورودی (یک ارزیابی سیستماتیک از هر وکتور ورودی)
• تکنیک‌های ارزیابی (‏ارزیابی اصولی هر تکنیک حمله مورد استفاده توسط مهاجم برای بهره‌برداری از آسیب‌پذیری)

اهداف تست

• شناسایی نقاط تزریق مربوط به path traversal
• ارزیابی تکنیک‌های Bypass نمودن و شناسایی گستره آسیب‌پذیری

چگونه تست را انجام دهیم

آزمایش جعبه سیاه

شناسایی وکتورهای ورودی

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

در اینجا چند نمونه از مواردی که باید در این مرحله انجام شوند آورده شده‌است:

آیا پارامترهای درخواستی وجود دارند که می‌توانند برای عملیات مربوط به فایل مورد استفاده قرار گیرند؟
آیا پسوند فایل غیر معمول وجود دارد؟
آیا نام‌های متغیر جالبی وجود دارند؟

• example.com/getUserProfile.jsp?item=ikki.html
• example.com/index.php?file=content
• example.com/main.cgi?home=index.htm

آیا شناسایی کوکی‌های مورد استفاده توسط برنامه وب برای تولید پویای صفحات یا الگوها ممکن است؟

• Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJgMSSPKVMV:TEMPLATE=flower
• Cookie: USER=1826cc8f:PSTYLE=GreenDotRed

تکنیک‌های ارزیابی

مرحله بعدی تست، تجزیه و تحلیل توابع اعتبارسنجی ورودی موجود در برنامه کاربردی وب است. با استفاده از مثال قبلی، صفحه دینامیک به نام getUserProfile.jsp اطلاعات ایستا را از یک فایل بارگذاری می‌کند و محتوا را به کاربران نشان می‌دهد. یک مهاجم می‌تواند رشته مخرب … / … / … / … / etc / passwd را وارد کند تا فایل مربوط به نام‌های کاربری در یک سیستم لینوکس یا یونیکس را Include نماید. بدیهی است که این نوع حمله تنها در صورتی امکان پذیر است که اعتبار سنجی ورودی‌های کاربر به درستی انجام نشده باشد. با توجه به سطوح دسترسی تعریف شده در فایل سیستم، خود برنامه کاربردی وب باید قادر به خواندن این فایل باشد.

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

برای مثال کوکی‌ها:

همچنین ممکن است که فایل‌ها و اسکریپت‌های موجود در وب سایت خارجی را نیز بتوان Include نمود:

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

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

مثال‌های زیر چگونگی امکان نشان دادن کد مبدا مولفه CGI را بدون استفاده از کاراکترهای path traversal نشان می‌دهند.

مولفه main.cgi در همان دایرکتوری فایل‌های ایستا HTML نرمال که توسط برنامه استفاده می‌شوند، قرار دارد. در برخی موارد، تست نفوذگر نیاز به کدگذاری درخواست‌ها با استفاده از کاراکترهای خاص مانند %00 دارد تا بدین وسیله کنترل کننده پسوند فایل را Bypass نموده و یا از اجرای اسکریپت جلوگیری به عمل آورد.

نکته: این یک اشتباه رایج توسط توسعه دهندگان است که انتظار هیچ شکلی از کدگذاری (کدگذاری های مختلف غیر از موارد رایج) را نداشته باشند و بنابراین تنها برای محتوای کدگذاری شده پایه، اعتبارسنجی را انجام دهند. اگر در ابتدا رشته مورد تست، پاسخ مناسبی را در بر نداشت، طرح کدگذاری دیگری را امتحان کنید.

هر سیستم‌عامل از کاراکترهای مختلف به عنوان جداکننده مسیر استفاده می‌کند:

Unix-like OS:
o root directory: /
o directory separator: /
Windows OS:
o root directory: drive letter :
o directory separator: \ or /
Classic macOS:
o root directory: drive letter :
o directory separator: :

ما باید مکانیزم‌های کدگذاری کاراکتر زیر را در نظر بگیریم:

URL encoding and double URL encoding
o %2e%2e%2f represents ../
o %2e%2e/ represents ../
o ..%2f represents ../
o %2e%2e%5c represents ..\
o %2e%2e\ represents ..\
o ..%5c represents ..\
o %252e%252e%255c represents ..\
o ..%255c represents ..\ and so on.
Unicode/UTF-8 Encoding (it only works in systems that are able to accept overlong UTF-8 sequences)
o ..%c0%af represents ../
o ..%c1%9c represents ..\

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

Windows Shell: نصب هر یک از موارد زیر برای مسیرهای استفاده‌شده در دستور shell هیچ تفاوتی در عملکرد ایجاد نمی‌کند:

استفاده از علامت های < و > در انتهای مسیر
استفاده از دابل کوتیشن در انتهای مسیر
نشانگرهای مربوط به دایرکتوری فعلی مانند ./ یا .\

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

Windows API: موارد زیر هنگامی که در هر دستور پوسته یا فراخوانی API استفاده می‌شوند که در آن یک رشته به عنوان نام پرونده گرفته می‌شود، دور انداخته می‌شوند:

• periods
• spaces

Windows UNC Filepaths: برای ارجاع پرونده‌ها بر روی ‍SMB Shareها استفاده می‌شود. گاهی اوقات، یک برنامه می‌تواند برای ارجاع به فایل‌هایی در یک UNC filepath راه دور ایجاد شود. در این صورت، سرور Windows SMB ممکن است اعتبارات ذخیره‌شده را برای مهاجم ارسال کند، که می‌تواند ضبط و شکسته شود. این‌ها همچنین ممکن است با یک آدرس IP خود ارجاع یا نام دامنه برای فرار از فیلتر استفاده شوند، یا برای دسترسی به فایل‌های روی SMB Shareها که برای مهاجم خارج از دسترس هستند اما از سرور وب در دسترس هستند، استفاده شوند.

• \\server_or_ip\path\to\file.abc
• \\?\server_or_ip\path\to\file.abc

Windows NT Device Namespace: برای اشاره به فضای نام دستگاه ویندوز استفاده می‌شود. مراجع خاص، امکان دسترسی به فایل سیستم‌ها را با استفاده از یک مسیر متفاوت فراهم می‌کنند.

ممکن است معادل یک حرف محرک مانند c:\ یا حتی یک drive volume بدون آن باشد.

• \\.\GLOBALROOT\Device\HarddiskVolume1

به اولین درایو دیسک روی دستگاه مراجعه می‌کند:

\\.\CdRom0

آزمایش جعبه خاکستری

هنگامی که تجزیه و تحلیل با یک رویکرد آزمون جعبه خاکستری انجام می‌شود، تست نفوذگرها باید همان روش آزمون جعبه سیاه را دنبال کنند. با این حال، از آنجایی که آن‌ها می‌توانند کد منبع را مرور کنند، امکان جستجوی راحت‌تر و دقیق‌تر وکتورهای ورودی وجود دارد. در طول بررسی کد منبع، آن‌ها می‌توانند از ابزارهای ساده (مانند دستور grep) برای جستجوی یک یا چند الگوی مشترک در کد برنامه استفاده کنند:

inclusion functions/methods، عملیات فایل سیستم و غیره.

با استفاده از موتورهای جستجوی کد آنلاین (‏به عنوان مثالSearchcode)‏، همچنین ممکن است امکان پیدا کردن معایب path traversal در نرم‌افزارهای Open Source منتشر شده در اینترنت وجود داشته باشد.

برای PHP، تست نفوذگرها می‌توانند از regex زیر استفاده کنند:

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

برخی برنامه‌های کاربردی وب، صفحات پویا را با استفاده از مقادیر و پارامترهای ذخیره‌شده در یک پایگاه‌داده تولید می‌کنند. ممکن است قرار دادن رشته‌های path traversal ویژه زمانی که برنامه داده‌ها را به پایگاه‌داده اضافه می‌کند، امکان پذیر باشد. کشف این نوع مشکل امنیتی به دلیل این واقعیت که پارامترهای داخل توابع شمول داخلی و ایمن به نظر می‌رسند اما واقعیت ندارند، دشوار است.

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

یک برنامه کاربردی تحت وب را با این دستورالعمل‌ها در نظر بگیرید:

آزمایش برای عیب با استفاده از موارد زیر به دست می‌آید:

ابزارها

• DotDotPwn – The Directory Traversal Fuzzer
• Path Traversal Fuzz Strings (from WFuzz Tool)
• OWASP ZAP
• Burp Suite
• Enconding/Decoding tools
• String searcher “grep”
• DirBuster