ﻣﻦ ﮔﺮﻓﺘﺎر ﺳﻨﮕﻴﻨﻲ ﺳﻜﻮﺗﻲ ﻫﺴﺘﻢ ﻛﻪ ﮔﻮﻳﺎ ﻗﺒﻞ از ﻫﺮﻓﺮﻳﺎدي ﻻزم اﺳﺖ (مسعود فردمنش)
سلام. خیلی وقت بود متاسفانه بخاطر خیلی از مسائل وقت نمیشد بیام و مطلب بزارم. امیدوارم سلامت باشید.
مقدمه : بسمت آسیب پذیری های Web2 بعلت گسترده و فراگیر شدن اون در سال 2012 نزدیک میشیم پس این موضوع ممکنه در سال های بعد خیلی خیلی مورد بحث قرار بگیره .
همانطور که مستحضرید ، یکی از آسیب پذیری هایی که در مواقع استفاده از (Document Object Model (DOM در HTML پرداخته میشود ؛ XSS Payloads ای هستند که با سناریو های معمولی (Classic) و در حالت BlackBox Testing سخت تر قابل کشف (یافت) میباشند.
اما خوشبختانه ، تستر نفوذ به منبع JavaScript دسترسی کامل دارد ، پس با بررسی و آنالایز سورس کد به نقاط حساس این موضوع پی خواهد برد.
– خیلی از دوستان بهم فشار آوردن که اینقدر چرا رسمی مینویسی و آدم هیچی حالیش نمیشه و … ، ولی اینطور نوشتن حالا نمیگیم تخصصی ولی این جنبه رو باید در نظر بگیریم که اگر به زبان خیلی مفهومی و قابل تشخیص برای هر فردی که اینجا رو ملاحظه میکنه این امر ضروریه که اینطوری بنویسم ولی سعی میکنم کمی با نوستالوژی مضاح و آمیانه بگم که غمی از ما نمونه بین رفقا !
ما هدفمون از انتشار این مطالب آب دوغ خیاری ، این نیست که بگیم کلیت این نوع آسیب پذیری ها در چیه ، میخوایم با همه ی مکانیسم ها و سناریو ها + شبیه سازی موارد گفته شده (حالا توی این پست خدا رو شکر نمونه ی HoneyPot اش رو هم آوردیم !) ثابت کنیم و بطور کاملاً مفهومی به نقاط حساس این موضوع دسترسی داشته باشیم.
پس یک کمی روی بحث چالش میندازیم.
اصولاً DOM وقتی مورد استفاده ی برنامه نویسان ما قرار میگیره که از دو مورد در برنامشون استفاده کنند :
- 3rd Party » یه کتابخونه برای بهینه سازی و Modular سازی برنامه هست (که الان خیلی جا افتاده در بین برنامه های بزرگ و کوچک مثل wp , joomla , mybb , ..)
- XHR Response » یک مورد ایجکس (Ajax) خیلی زیبا واسمون ردیف میکنه ! (عمل دریافت و پردازش داده ها بدون نیاز به refresh)
در واقع برنامه نویس میاد و ورودی هاش رو طوری که استاندارد Ajax و مبتنی بر DOM هست قرار میده :
http://pentest-center.ir/?do=charge#onlinepay
وقتی که ما درخواست بارگزاری صفحه پرداخت آنلاین (onlinepay) رو میدیم واکشی اطلاعات بصورت ajax برامون دریافت میشه و این کار باعث بازنویسی DOM که به این میگن عملیات innerHTML میشه (خب به ما چه ؟)
ما میایم و در این بین درخواست و پاسخ های DOM که از کتابخونه ی Third Party هستند رو بصورت Post بررسی و تمهیداتی برای ویرایششون (حالا از نوع هم Abuse یا Malicious Codes) اعمال میکنیم. (ضمن درنظر گرفتن ثواب عظیم اینکار)
حالا بحث جذاب شد ! چون میخوایم در مورد یکی از سوتی های IE جون که مایکروسافت خیلی براش زحمت کشیده که اینقدر پربار اومده بیرون صحبت کنیم 0day ای که Code Execution Privilege داره اونم با چی ؟ با سوتی DOM !! جالبیش اینجاست که این دست آسیب پذیری رو چند وقت پیش در فریمورک BlackHole شاهد بودیم که ارائه داده شد !
خب ، از جفنگیات کم کنیم و به ادامه بحث منتقل شیم . قضیه چی بوده ؟ این بوده که یه بنده خدایی (از Developer های اینترنت اکسپلورر عزیز) که مسئول بخش فراخوانی عکس هایی بصورت iframe که از یه فایل فلش فراخوانی شده بوده احیاناً توجه نکرده چی شده !
این فراخوانی که از DOM داده ها رو از یه تابع خیلی مشنگیانه بدون هیچ ف/ی/ل/ط/ر و Protection ای پردازش و (در یک iframe) میگرفته ، حاصل PoC ای بوده که متاسپلویت انتشار داده.
یک آرایه از تصاویر و یه المنت با تابع window.document.createElement ایجاد شده :
Image may be NSFW.
Clik here to view.
حالا ما میایم و پارامتر هایی که از تابع document استفاده میکنند رو ویرایش میکنیم :
;((document.execCommand(eval(2+2
;("document.write("Hajiو shellcode مون رو مطابق میلمون با کتابخونه ی heap جاواسکریپت تزریق میکنیم :
Image may be NSFW.
Clik here to view.
حالا این سناریو باید با هر مکانیسمی که هکر عزیزمون به یوزر میچپونه قابل اجرا باشه.
اما چرا shellcode ما قابل اجراست ؟ ساده هست . چون عملیات پردازش DOM سمت سرور صورت میگیره : )
بعد از اینکه تمام عملیات والفجر با موفقیت صورت گرفت حالا باید فایل swf فراخوانی شه. از Source ای قابل مشاهده هست این برداشت میشه که نقطه ی حساس موضوع که باعث اجرای Byte کدهای ما میشه درش استفاده شده !
Image may be NSFW.
Clik here to view.
در نهایت با تابع eval هم این موارد توضیح داده شده اجرا میشه !
Image may be NSFW.
Clik here to view.
با اجازه ی شما این موضوع چون وقت منو زیاد گرفت بصورت چند دسته ای میکنم تا بخش بعدیش انشاالله چند روز آینده یا چند هفته دیگه (!) منتشر شه .
با احترام