IIS یکی از قدرتمندترین وب سرورهای ارائه شده توسط مایکروسافت می باشد که برای میزبانی وب اپلیکیشن ASP.NET به کار برده می شود. این وب سرور موتور پردازشی برای handle کردن درخواست های ASP.NET دارد. بنابراین وقتی درخواستی از سمت کلاینت به سرور ارسال می شود، IIS آن درخواست را دریافت کرده و پردازش می کند و پاسخ آن را به سمت کلاینت می فرستد.
با توجه به معماری و ساختار IIS ، می توان آن را به دو لایه تقسیم کرد:
- Kernel Mode
- User Mode
Kernel Mode که با ظهور IIS6 معرفی گردید، در بردارنده سرویس HTTP.SYS می باشد. وقتی درخواستی از سمت کلاینت به سمت وب سرور ارسال میشود، در اولین مرحله به دست سرویس HTTP.SYS خواهد رسید. بعد از دریافت درخواست توسط سرویس HTTP.SYS، این سرویس مسئول ارجاع درخواست به Application Pool مربوطه می باشد. سوالی که در اینجا پیش می آید این است که چگونه HTTP.SYS متوجه می شود که باید درخواست را به کجا ارسال کند؟ انتخاب به صورت تصادفی صورت نمی گیرد؛ زیرا هر درخواست مربوط به وب اپلیکیشن خاصی می باشد و باید به Application Pool مختص به آن وب اپلیکیشن ارجاع داده شود. هر زمان که Application Poolای ایجاد می شود، ID برای آن ایجاد شده و در HTTP.SYS ثبت می شود. بنابراین هر زمان که HTTP.SYS درخواست های مربوط به وب اپلیکیشنی را دریافت می کند، Application Pool مربوطه را یافته و بر اساس آن درخواست را ارجاع می دهد.
به عبارتی دیگر می توان گفت که HTTP.SYS، درخواست های HTTP از شبکه را خوانده، درخواست ها را برای پردازش به IIS می فرستد و سپس پاسخ پردازش شده را به مرورگرهای مشتری برمی گرداند.
با توجه به بولتن امنیتی منتشر شده توسط مایکروسافت، MS15-034 یک آسیب پذیری اجرای کد از راه دور است که به دلیل پردازش نادرست HTTP.sys روی درخواست HTTP خاص ِ ایجاد شده توسط نفوذگر، رخ داده است. به طور خاص بهره برداری از این آسیب پذیری با استفاده از رنج هدر یک درخواست http رخ داده و موجب وقوع یک سرریز integer می شود. بولتن امنیتی ارائه شده، نشان می دهد که اجرای کد از راه دور هم ممکن است رخ دهد و به همین دلیل این آسیب پذیری به عنوان بحرانی در نظر گرفته می شود اما راهنمایی برای انجام باگ RCE از طریق این حفره ارائه نشده است.
قبل از تشریح این آسیب پذیری بهتر است که با رنج هدر آشنا شویم. رنج هدر در یک درخواست HTTP برای دریافت بخشی از داده درخواستی (یا محدوده از بایت ها) به یک منبع داده (resource) استفاده می شود. به عنوان مثال، درخواست های زیر نحوه به دست آوردن بخشی از فایل humans.txt گوگل با استفاده از رنج هدر را نشان می دهد.
تحلیل عمیقتر از آسیب پذیری مذکور:
تجزیه و تحلیل این آسیبپذیری را با بررسی تغییرات ایجاد شده در فایل http.sys وصله نشده (دارای آسیبپذیری) و وصله شده (بعد از رفع مشکل) شروع می کنیم.عکس زیر یک دید کلی از تابع UlpParseRange است (HTTP.sys آسیبپذیر در سمت چپ و HTTP.sys بدون مشکل در سمت راست نشان داده شده است)، این تابع پس از بروزرسانی، یک تفاوت کلیدی دارد و آن تفاوت یک فراخوانی اضافی به تابع RtlULongLongAdd() میباشد . هدف تابع اضافه شده، ارائه یک بررسی معتبر به منظور جلوگیری از وقوع سرریز Integer است. فقدان این بررسی در نسخه وصله نشده از HTTP.sys چیزی است که اجازه میدهد تا شرایط سرریز در قلب MS15-034 رخ دهد.
میتوان در کد موجود در عکس زیر دید که تابع UlpParseRange زمانی که نیاز به پردازش مقادیر منتقل شده از طریق رنج هدر است، توسط تابع HlContentRangeHeaderHandler فراخوانی میشود. در حال حاضر، نگاهی به تابع UlpParseRange می اندازیم، مکانی که باید شرط سرریز integer بررسی میشد را در نسخه آسیب پذیر HTTP.sys (بالا) می بینید و نحوهی رفع این مشکل در نسخه بروز شده هم از طریق افزودن RtlULongLongAdd دیده می شود.
شما میتوانید با تغییر مقدار پایین رنج هدر، DOS ایجاد کنید. به عنوان مثال bytes=18-18446744073709551615. شماره 18 تا حدودی دلخواه انتخاب شده است و بسیاری از مقادیر دیگر کار خواهند کرد، هر چند که این نیز به اندازه منبع درخواست شما بستگی دارد.RFC چندین فرمت رنج هدر را مجاز میداند. با امتحان فرمتهای مختلف میتوان دید که با ارسال رنجهای بایت چندگانه، میتوان به محتویات حافظه سیستم هدف دست یافت.
تشخیص سرور های آسیب پذیر:
شما می توانید یک بررسی اولیه در سرور خود به منظور تعیین امکان بهرهبرداری از این آسیب پذیری داشته باشید. به سادگی یک درخواست برای یک منبع استاتیک (مانند یک تصویر) ایجاد کنید و رنج هدر را با مقدار bytes = 0-18446744073709551615 منتقل کنید. یک سرور آسیب پذیر پاسخی با عنوان “Requested Range Not Satisfiable” ارسال خواهد کرد.
منابع :
https://www.securitysift.com/an-analysis-of-ms15-034
http://linux-web.ir/articles/windows-articles/iis-asp