آشنایی با آسیب پذیری اجرای کد از راه دور HTTP.SYS در وب سرور IIS

آشنایی با آسیب پذیری اجرای کد از راه دور HTTP.SYS در وب سرور IIS این آسیب پذیری در پشته پروتکل HTTP وجود دارد و معمولا زمانی که HTTP در حال پارس کردن یک دستور آسیب پذیر می باشد، رخ می دهد. نفوذگری که از این آسیب پذیری به درستی بهره برداری کند، می تواند کدهای دلخواه خود را در زمینه system account اجرا کند.

IIS یکی از قدرتمندترین وب­ سرورهای ارائه شده توسط مایکروسافت می­ باشد که برای میزبانی وب اپلیکیشن ASP.NET به کار برده می­ شود. این وب سرور موتور پردازشی برای handle کردن درخواست­ های ASP.NET دارد. بنابراین وقتی درخواستی از سمت کلاینت به سرور ارسال می­ شود، IIS آن درخواست را دریافت کرده و پردازش می کند و پاسخ آن را به سمت کلاینت می فرستد.

با توجه به معماری و ساختار IIS ، می­ توان آن را به دو لایه تقسیم کرد:

  1. Kernel Mode
  2. 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