یکی از مهمترین مسائلی که روز به روز درحال گستردگی و فراگیر شدن در بین مدیران امنیتی (ایران؟!) در زمینه امنیت (تحت وب) میباشد ، استفاده از یک میانجی بعنوان شناسایی و مقابله با تهدیدات و حملات مبتنی بر برنامه کاربردی وب و ترافیکی که در این بین رد و بدل خواهند شد ، است.
[ این مطلب جهت آشنایی با نوع و ساختار شناسایی حملات توسط WAF و فهم/تلاش یک متخصص تست نفوذ برای تکنیک های دور زدن قوانین (Signature) مورد استفاده در آن میباشد. ]
چرا مدیران امنیتی به اینگونه ابزار ها نیاز پیدا خواهند نمود ؟
مهمترین و در عین حال اصلی ترین موضوع ، محدود بودن دانش کافی توسعه دهندگان و برنامه نویسان تحت وب از لحاظ آسیب پذیری های شناخته شده (Reported) و ناشناخته (!) است. چرا که ، رفته رفته به سمت گستردگی Web2 و استفاده از Ajax و توابع بشدت داینامیک JavaScript ، نزدیک و همچنین Multiple Bypassing در این نوع ساختار برنامه های کاربردی جدید ، بسیار امر مهمی برای مقابله با آن بشمار خواهد آمد.
ساختار یک (WAF (Web Application Firewall چگونه است و نحوه ی شناسایی حملات آن به چه صورت انجام میگیرد ؟
هر نوع درخواست و پاسخی که در بین داده های HTTP / HTTPS / SOAP / XML-RPC / Web Service Layers رد و بدل خواهند شد ، توسط WAF قابل بررسی و محدودیت گذاری میباشد.
بطور کلی 2 نوع ساختار/قانون در بین WAF های رایج مشخص است :
- وابسته به یک لیست سیاه و یا یک لیست سفید (BlackList / WhiteList Based)
- تابع یک قانون (Signature) و سیاست های قابل تغییر (Rule/Policy Based)
WhiteList Based Filtering :
تصور بر آن داریم بعنوان ورودی از کاربر که فقط کاراکترهای عددی [0-9] را مورد قبول واقع میدارد را بعنوان یک سیاست در قسمتی از ورودی های خود در WAF اعمال نمودیم.
http://pentesterlab.ir/?id=1
مزیت ها :
- در این نوع به کمترین Rule جهت Protection و محدودیت نیاز پیدا خواهد شد.
- کمترین میزان درخواست های False Positives شکل خواهد گرفت.
معایب (سو استفاده ها) :
- در همه جهات قابل استفاده نیست! (پاکسازی صورت مساله را مصداق قرار خواهد داد!) [استفاده از Rewrite Engine]
- زمان بیشتری جهت اجرای آن نیاز است.
در نتیجه میتوان گفت WhiteList گذاری در قوانین مورد استفاده WAF بشکلی ایفا خواهد شد تا در یک نقطه از برنامه کاربردی به مقداری خاص محدودیت اعمال شود.
BlackList Based Filtering :
تصور کنید جهت اعمال جلوگیری از اجرای حملات XSS ، تگ <script> در یک Rule تعریف شده بطور کلی مورد Filter قرار خواهد گرفت. (User Inputs , URL Based)
<http://pentesterlab.ir/?s=<script>alert(1)</script
پس آسیب پذیری با سناریوی بالا قابل اکسپلویت نیست.
مزیت ها :
- کمترین زمان برای اجرای آن نیاز است.
معایب (قابل استفاده توسط تستر نفوذ) :
- اجرای False Positives بیشتر
- کمترین Image may be NSFW.
Clik here to view.
نوع Protection صورت گرفته (Bypass-able) - پردازش زیاد جهت Detection
یک نمونه از Bypass Payload :
<http://pentesterlab.ir/?s=<script>alert(1)<%2Fscript
قابل توجه : بسیاری از Protection های مرورگرها جهت جلوگیری از اجرای این نوع حملات (Client Side) نیز به همین گونه Filter را اعمال مینمایند.
باید بدانیم که هنوز در پیاده سازی WAF های رایجی مثل ModSecurity هوشمندی خاصی در نظر گرفته نشده ، این سری از IDS/IPS ها طبق قانون و سیاستی که برای آنها تعریف و تئوری یافت حملات نیز بصورت Regular Expressions باشد، عمل مینمایند. پس نقطه ی مثبتی برای تستر های نفوذ که روی روش شناسی گریز از Filtering های WAF تحقیق انجام خواهند داد ، میباشد.
یکی از موضوعات بسیار مهم و پرخطر که Ivan Ristic هم در مقالاتش نسبت به پیاده سازی و تعریف قوانین در فایروال های تحت وب به آن اشاره میکند ، نقاط تصمیم گیری و عدم تطابق قوانین (Impedance Mismatch) است، بطوریکه یک تصمیم اشتباه در یکی از قوانین مورد استفاده در آن میتواند اشتباهات جبران ناپذیری را شامل شود.
در مباحث گریز از فایروال های تحت وب به این نکته باید توجه داشت که تمامی جهات را برای رسیدن به نقطه ی کور از WAF را آزمایش و نتیجه را مورد بررسی قرار میدهیم.
مانند :
GET /?p=<code>Sqli_Payloads</code> HTTP/1.0 .Host: pentest-center.ir User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0
در واقع ما روش Bypass ای در GET اعمال نکردیم ، تنها در Hostname به آخرین مقدار آن ” . ” را مورد تزریق قرار دادیم.
هدف ما از مثال بالا این نیست که با این روش شما حتماً میتونید برید شاد و خندان هر WAF ای که سر راهتون رو گرفت رو با این تکنیک مورد عنایت قرار بدید! هدف این بود که بگیم هیچ WAF ای تابحال بصورت هوشمندانه عمل نکرده ، پس راه نفوذ و دور خوردن آن نیز موجود است ، فقط کمی نیاز به تجربه و تکرار آزمایش میباشد.
در حالیکه یک دیواره آتش تحت وب ، میتواند تمامی ترافیکی که در HTTP رد و بدل میشود را درک و آنالایز نماید و همچنین بسیاری از ریز پروتکل ها و داده های فرمت را برای دسترسی محدود هندل میکند. این پروسه هم زمان بیشتر و هم چرخه های طولانی و با پردازش بالا را برای CPU را موجب خواهد شد ، پس این امر ممکن هست با محتوا (Content ) هایی که هم طول آنها زیاد و هم از Byte Stream های مختلف تشکیل شده باعث بروز خطا (درحالت خوبش!) و یا بطور کلی از کار افتادن / سرریز بافر و … شود.
تازه مطلب بالا ممکن هست برای یک آنالایز Headers در HTTP اتفاق بیفته که اصلاً ما میگیم ویژگی هایی پیشرفته ای مثل ثابت نگه داشتن زمان ممکن برای یک Authentication معمولی تا … ، حالا فکرشو بکنید نوشتن اینگونه ابزار ها چقدر نیاز به دقت در استفاده از حافظه هست :)
تئوری ویژگی رفع آسیب پذیری مجازی (Virtual Patching) در WAF ها به چه صورت شکل میگیرد و چه مواردی میتواند در گریز از آن به ما کمک کند؟
Image may be NSFW.
Clik here to view.
بطور خلاصه کارایی یک عمل Virtual Patching به چند قسمت تقسیم شده :
- تعریف ساختار URL هایی که برای WebApp استفاده میشوند ، در لیست Allowable های مد نظر (سیاست های WAF) اعمال خواهد شد.
- جمع آوری مکانیسم ها و سناریوهای حملات طبق شرایط WebApp مورد نظر
- تعریف بعنوان شناخت (محدود) آسیب پذیری های 0day و بستر هایی جهت جلوگیری از اجرای آن
که البته مشاوران و مسئولان امنیتی سازمانها اغلب از 2 مورد اول جهت امن سازی WebApp استفاده خواهند نمود.
موارد گریز از دید یک فایروال تحت وب ( WAF Evading )
بطور کلی در این مطلب به چند نمونه از روش شناسی که با استفاده از Protocol Levels جهت رد شدن از یک فایروال تحت وب استفاده میشود اشاره خواهیم کرد :
- Path Parameters و راه کار های Bypassing با استفاده از آن
- Multiple Parameters
- HTTP Parameter Pollution , HTTP Response Splitting
- Invalid URL-Encoding
در روش Path Parameters Evasion میتوانیم به این نکته اشاره کنیم که معمولاً در Rule هایی که برای GET تعریف خواهند شد ، به پارامتر های قبل از متغیر GET شونده بصورت بدیهی اهمیتی داده نمیشود ! لذا ما از این فرصت میتوانیم به نحوی استفاده کنیم تا سناریوی نفوذ خود را بکلی بدون هیچگونه دردسر قابل اثبات نماییم :
http://pentesterlab.ir/?id=1
قانونی که در WAF اعمال شده (فقط اعداد قبل قبول خواهند بود) :
<Location /index.php>
# Allow only numbers in id
SecRule ARGS:id "!^\d+$"
</Location>سناریوی ما جهت دور زدن آن :
http://pentesterlab.ir/index.php/xxx?id=1Our_Sqli_Payload
البته به این نکته هم باید توجه کنیم که این مورد نیازمند فعال بودن PATH_INFO در WebServer است.
یکی دیگر از موارد گریز را میتوان Multiple Parameters در برنامه های کاربردی وب را اشاره کرد.
در این مکانسیم بسیار ساده ما میتوانیم چند پارامتر را بعنوان درخواست ارسال نماییم که سناریوی حمله ما میتواند در پارامتر اول و یا آخر شکل گیرد.
http://pentesterlab.ir/?id=1&userid=1Our_Sqli_Payload
در PHP نسخه 5.3 میتوان در مقادیر Cookie جهت ارسال پارامتر نیز استفاده کرد! پس :
GET /index.php Cookie: userid=1Our_Sqli_Payload
HTTP Response Splitting نام دیگری از مورد گریز ما میباشد ، آسیب پذیری ای که شاید کمتر شاهد آن بوده ایم ، اما این مورد شاید یکی از موارد خطرناک جهت موارد دورزنی فایروال های تحت وب و .. بحساب آید.
در این مورد باید بگوییم ، میتوانیم چند پارامتر را با نام های یکسان در یک برنامه کاربردی ارسال نماییم :
http://pentesterlab.ir/?id=1&id=2Our_Sqli_Payload
در این میان WAF مورد نظر ما گیج خواهد شد! نمیداند کدامیک را مورد بازبینی و کدام یک را مورد قبول واقع دارد. اما با کمال ناباوری WebApp آخرین پارامتر را اجرا خواهد نمود!
و نهایتاً مورد آخر جهت فرار از دید WAF ، استفاده از Invalid URL Encoding است. در این مورد ما میتوانیم پارامتر های GET را بصورت URL Encode درخواست نماییم :
در مثال زیر حرف i بصورت %69 آمده است :
http://pentesterlab.ir/?<strong>%69</strong>d=1Our_Sqli_Payload
از %}9 هم میتوان بجای حرف i استفاده نمود :
http://pentesterlab.ir/?%}9d=1Our_Sqli_Payload
و چند نمونه از راه های گریز که فقط نام میبرم ، تحقیق به پای خود شما! :
- Parameter Name , Type Evasion
- Common Programming Mistakes
- Supplying an Arbitrary Value
- Attacking Parameter Parsing
نتیجه گیری ما از این مساله این است که رفته رفته به موارد بیشتری از Bypassing فایروال های تحت وب و همچنین بسوی WAF های هوشمند تری نظیر IronBee برخواهیم خورد.
امیدوارم شاد و سلامت باشید.
با احترام