نوشته های مهران سیفعلی‌نیا

تفاوت HTTP/0.9 و HTTP/1.0 و HTTP1.1 و HTTP/2

مهران سیفعلی‌نیا — Thu, 26 Oct 2023 22:55:55 +0330

مقدمهشاید برای شما هم سوال پیش اومده باشه که چرا این همه پروتکل مختلف برای برقراری ارتباط بین کاربر و سرور وجود داره و حتی فرق اینا چیه؟ اصلا دونستن اینا به توسعه دهنده‌ها یا کارسشناسای امنیت کمکی میکنه؟ (بله کمک می‌کنه?)مخصوصا تو بحث امنیت به‌نظر من دونستن تفاوت‌های بین نسخه‌های مختلف این پروتکل‌ها می‌تونه فهمیدن کارکرد و نقاط ضعف و قوتشون رو برای شما شفاف‌تر کنه و این یعنی درک بهتر ساختار یه فناوری. (دارم سعی می‌کنم با استفاده از جملات انگیزشی مثلا شما رو ترغیب کنم? )تفاوت‌های HTTP/0.9 و HTTP/1.0خب؛ می‌تونیم تفاوت‌های این دوتا پروتکل رو خیلی ساده و خودمونی، توی 5 دسته مختلف بررسی کنیم:1- تاریخ انتشار نسخه HTTP/0.9 در تاریخ 1991 به‌عنوان اولین نسخه کاربردی از HTTP ارائه شد (سنش از منم بیشتره) و پنج سال بعد یعنی تو سال 1996 نسخه HTTP/1.0 رونمایی شد که درواقع یه نسخه ارتقاء یافته از HTTP/0.9 بود که هم ایراداتش بر طرف شده بود و هم یکسری قابلیت باحال بهش اضافه شده بود.2- متدهای درخواستخب نسخه 0.9 خیلی مسخره بود!! باورتون میشه؟ فقط از متد GET پشتبانی می‌کرد. یعنی عملا شما به‌جز دریافت اطلاعات، کار دیگه‌ای نمی‌تونی باهاش انجام بدی؛ ولی توی نسخه 1.0 کلی متد جدید یعنی متدهایی مثل POST و HEAD بهش اضافه شد که به کاربر امکان ارسال داده برای سرور رو فراهم کرد و کلی دست توسعه دهنده‌ها رو برای ساخت سامانه‌های خفن‌تر باز کرد.3- پاسخ سروراصلا این یکی رو دیگه باورتون نمیشه. تو نسخه 0.9 پاسخ سرور شامل هیچ سرآیندی نبود? (سرآیند همون Header میشه) ینی پاسخی که دریافت می‌شد، یک نسخه خالص و خام از HTML بود. ولی خب یک پدر آمرزیده‌ای اومد و توی نسخه 1.0 سرآیندها رو به پاسخ سرور اضافه کرد، یعنی سرور توی این نسخه، می‌تونه یکسری اطلاعات اضافی برای کاربر ارسال کن؛ اطلاعاتی که ساختار پاسخ رو شفاف می‌کنند، مثل سرآیندهای Content-Type، Content-length، Server، User-Agent و...4- نسخه ارتباطیخب توی نسخه 0.9 فقط خودش یدونه بود و کسی جلودارش نبود، پس توی درخواست‌ها چیزی به اسم نسخه درخواست یا همون HTTP version تعریف نشده بود. اما توی نسخه 1.0، هم در درخواست و هم در پاسخ، مشخص شده که از چه نسخه‌ای از این پروتکل استفاده میشه.5- مدیریت خطاوقتی که نسخه 0.9 اومد، به نظر کسی در نظر نگرفته بود که ممکنه خطاهای مختلفی موقع ارتباط برقرار کردن با سرور رخ بده. ینی بهش فکر کرده بودنا، ولی خیلی کلی؛ فقط اگه خطایی رخ می‌داد، سرور بهت می‌گفت خطا رخ داده! ولی نسخه 1.0 اومد و کلا زندگی ما رو عوض کرد! ینی چیزی رو تحت عنوان کد وضعیت (Status Code) معرفی کرد که مثلا وقتی همه چیز اوکی باشه، کد 200 میده، چیزی پیدا نشه 404 میده، خیلی درخواست بفرستی سرور عصبانی بشه 429 میده و...تفاوت‌های HTTP/1.0 و HTTP/1.1خب؛ این دوتا درواقع خیلی تفاوت چشمگیری مثل تفاوت نسخه 0.9 و 1.0 ندارن؛ اما یکم بهبودش دادن و بهتر از قبل شده، بریم با هم بررسی کنیم که چیا اینجا جدیده:1- تداوم ارتباطخب توی نسخه 1.0 یک ارتباط (Connection) با سرور برقرار میشه، پاسخ دریافت میشه و ارتباط بسته میشه. تامام! ? ولی توی نسخه 1.1 این قضیه فرق میکنه و کاربر می‌تونه بیشتر از یک درخواست و پاسخ رو تنها توی یک ارتباط رد و بدل کنه که این موضوع به‌شدت روی کارایی (Performance) و سرعت یک سامانه تاثیر می‌ذاره. البته توجه کنید که این ارتباط در لحظه فقط می‌تونه یک درخواست ارسال کنه و یک پاسخ دریافت کنه و همزمان نمی‌تونه چندین درخواست بفرسته یا حتی نمی‌تونه در حین ارسال یک درخواست، پاسخی دریافت کنه.2- استفاده از قابلیت Pipeliningتوی نسخه 1.0 چیزی تحت عنوان Pipeline وجود نداره و کاربر مجبوره منتظر بمونه تا پاسخ یکی از درخواست‌هاش بیاد تا بتونه درخواست دوم رو ارسال کنه. این خیلی رو مخ بود، ولی خب توی نسخه 1.1 قابلیتی اضافه شد که به کاربر اجازه میده تا هر چندتا درخواست که دلش می‌خواد رو بفرسته، قبل از اینکه جواب درخواست‌‌های قبلی رو گرفته باشه.3- اضافه شدن سرآیندهای بیشترخب اینو دیگه زیاد کشش نمیدم، نسخه 1.0 همه سرآیندها رو پشتیبانی نمی‌کرد، این سرآیندها تو نسخه 1.1 اضافه شدن، سرآیندهایی مثل Cache-Control، Transfer-Encoding و Upgrade. (البته سرآیند Host هم هست که تو مورد بعدی جدا توضیحش دادم)4- اضافه شدن سرآیند Hostتوی نسخه 1.0 سرآیندی به اسم Host وجود نداشت و قطعا تو استفاده از هاست‌های اشتراکی داستان درست میشد! (البته بعضی از افسانه‌ها میگن که توی این نسخه هم میشد از سرآیند Host استفاده کرد ولی خیلی از سرورها و کاربران اونو متوجه نمی‌شدن و همچنین استفاده از اون اجباری نبوده) ولی تو نسخه 1.1 این سرآیند به طور اجباری باید در تمام درخواست‌ها وجود داشته باشه.تفاوت‌های HTTP/1.1 و HTTP/2اینجا هم دوباره یک جهش بزرگ تو پروتکل داشتیم و کلی قابلیت جدید بهش اضافه شده، قراره اینا رو هم با هم دیگه بررسی کنیم و کلی لذت ببریم! ?1- ارتباط چند جانبهدر نسخه 1.1 درسته که ما می‌تونستیم چندین درخواست رو تنها توی یک ارتباط، ارسال و پاسخ‌ها رو هم همونجا دریافت کنیم، اما قابلیت ارسال و دریافت همزمان وجود نداشت. تو نسخه 2 از این پروتکل، ما می‌تونیم به صورت موازی، چندین درخواست و پاسخ رو هم زمان ارسال و دریافت کنیم. ینی در حالی که داریم درخواستمون رو می‌فرستیم، میتونیم هم زمان پاسخ درخواست‌ قبلی رو هم بگیریم.2- فشرده‌سازی سرآیندهاتو نسخه 1.1، سرآیندها به صورت متن واضح ارسال می‌شدن که یه سری ایرادات امنیتی هم داشت. اما تو نسخه 2 دیگه از این خبرا نیست و سرآیندها با استفاده از الگوریتم HPACK فشرده میشن و بعد ارسال میشن. HPACK علاوه‌بر اینکه سرآیندها رو در قالب جدیدی ارسال می‌کنه، بلکه از کدگذاری Huffman هم استفاده می‌کنه تا حجم سرآیندها رو کاهش بده و داده کمتری این وسط رد و بدل بشه.3- پروتکل باینریهمه مون با نسخه 1.1 کار کردیم و دیدیم که محتوا و سرآیندها به صورت متنی ارسال میشن. این مورد برای انسان‌ها قابل فهم‌تر و راحت‌تره ولی کارآمدی کمتری هنگام پردازش داره. نسخه 2 اومده و از قابلیت ارسال داده‌ها به صورت باینری استفاده کرده. مخصوصا سرآیندها که کلا دیگه در قالب باینری ارسال میشن.4- ارسال سروراین یکی از قابلیت‌های خیلی جذابه. تو نسخه 1.1، سرور تنها در صورتی می‌تونست به کاربر دیتا بفرسته که کاربر درخواست داده بود. ینی بهتر بخوام بگم، سرور فقط می‌تونست به درخواست‌ها پاسخ بده. ولی تو نسخه 2 قابلیتی به اسم Push Server اضافه شده که سرور هروقت حس کنه که ممکنه داده‌ای لازم بشه، بدون اینکه کاربر درخواستی بزنه، اون داده‌ها رو برای کاربر ارسال می‌کنه. ینی نشستی داری ماستتو می‌خوری که یهو از سرور پاسخ دریافت میشه!تموم شد دیگه، دنبال چه هستی او رفته از اینجا (متن بسیار خنده دار) ? ?? ?اگر به نظرتون جالب بود و خوشتون اومده،حتما بازخورد بدید تا در صورت تمایل، تفاوت‌‌های HTTP/2 و HTTP/3 رو هم با هم بررسی کنیم. ❤️

دور زدن تایید ایمیل ثبت‌نام

مهران سیفعلی‌نیا — Fri, 04 Aug 2023 19:56:06 +0330

خب این یکی از رایتاپای خیلی کوتاهه که زیاد وقتتون رو نمیگیره، قرآیندش هم پیچیده نیست. ?خب، یکی بود یکی نبود؛ یه سایتی بود که وقتی توش ثبت‌نام میکردی بهت می‌گفت باید ایمیلت رو تایید کنی وگرنه نمی‌تونی بیشتر از 48 ساعت از سایت استفاده کنی. ?خب فکر کنید من اینقدر بیکار بودم که دو روز صبر کردم ببینم راست میگه یا فقط داره تهدید میکنه! ? متاسفانه راست می‌گفت و بعد از 48 ساعت، دیگه نمی‌شد از سایت استفاده کرد و این خطا رو نشون می‌داد.حالا اینجا یه دکمه هست که تو عکس هم دیده میشه، نوشته `Click to resend`، وقتی که روی این دکمه کلیک کنید، یه ایمیل تایید براتون ارسال میشه. حالا وقتی داستان جالب میشه که نگاه کنید و ببینید تو همین صفحه که عکسش رو بالاتر گذاشتم، یه پارامتر توی URL هست به اسم token که اولش با CBC شروع شده؛ میبینید دیگه؟اینم ایمیلی که برای من اومده!!! ?ای وای! ? لینکی که برای فعال‌سازی ایمیل من استفاده میشه، دقیقا شامل همون token ای هست که الان بهش اشاره کردیم. یعنی ما تو صفحه اول، توی آدرس UserReactivate?Token=1234 یه مقداری رو داریم که همونو اگه برای آدرس UserEmailConfirm?Token1234 استفاده کنیم. ایمیل تایید میشه.خب ما به راحتی با ایمیل هرکسی که دوست داشته باشیم یه اکانت اینجا می‌سازیم و بعدش که درخواست ایمیل رو ارسال می‌کنیم، مقدار Token رو از توی درخواست نگاه می‌کنیم (یواشکی که کسی نفهمه) بعدش یهو میایم همون رو میفرستیم به آدرس UserEmailConfirm و تمام؛ ایمیل ما (که درواقع ایمیل یکی دیگس) تایید میشه. ?منبع

دور زدن کنترل دسترسی در Adobe ColdFusion (CVE-2023-29298)

مهران سیفعلی‌نیا — Wed, 26 Jul 2023 12:14:32 +0330

تیم امنیتی Rapid7 یه آسیب‌پذیری کنترل دسترسی روی ColdFusion پیدا کرده، اونم جایی که دسترسی به پنل و خدمات مدیریتی توسط درخواست‌های خارجی محدود شده. این کنترل دسترسی خارجی، یه لیستی از IP ها رو داره که فقط اون آدرس‌ها مجازن تا به Endpointهای مدیریتی روی ColdFusion دسترسی داشته باشن. وقتی یه درخواست از یه آدرس IP به سمت سرور ارسال بشه که تو این لیست نباشه، دسترسی به منبع مورد نظر ممکن نیست.(مثل اینکه این قابلیت پروفایل امنه) ?از طریق این لینک می‌تونید یک پروفایل امن ایجاد کنید. پروفایل امن تنها اجازه میده تا آدرس IPهای خاصی اجازه دسترسی به مسیرهای حساس مدیریتی رو داشته باشن. ?تاثیر آسیب‌پذیریبا توجه به این آسیب‌پذیری، هکر می‌تونه به تمام Endpointهای CFM و CFC در مسیر /CFIDE/ دسترسی پیدا کنه که شامل 437 فایل CFM و 96 فایل CFC در نسخه 2021 آپدیت 6 هست؛ این موضوع باعث از بین رفتن تضمین پروفایل امن در سرویس ColdFusion میشه. البته اینم بگم که دسترسی به این مسیرها به معنی این نیست که هکر می‌تونه از همه این منابع استفاده کنه و خیلی از اون‌ها قبل از اجرا شدن، نشست کاربر رو چک می‌کنن. با این حال تاثیری که دسترسی به این منابع می‌تونه داشته باشه، به شرح زیره:ممکنه هکر به هر روشی داخل سامانه لاگین کرده باشه، پس می‌تونه از این آسیب‌پذیری برای دسترسی به تمام منابع استفاده کنه.ممکنه باعث افشای اطلاعات حساس بشهممکنه بشه از آسیب‌پذیری‌های دیگه سوءاستفاده کرد، مثل CVE-2023-26360آنالیز آسیب‌پذیریخب، موقعی که یه درخواست خارجی به مسیرهای حساس زده میشه، کنترل سطح دسترسی اون درخواست‌ها رو محدود میکنه، درواقع کسی نمی‌تونه با یه درخواست خارجی، به این مسیرها دسترسی داشته باشه.بعضی از Java Servletها کنترل سطح دسترسی رو روی منابع خودشون اعمال می‌کنن:مورد coldfusion.CfmServlet که تمامی درخواست‌های ارسال شده به CFMها رو مدیریت می‌کنه.مورد coldfusion.xml.rpc.CFCServlet که تمامی درخواست‌های ارسال شده به CFML و CFC رو مدیریت میکنه.مورد coldfusion.rds.RdsGlobals که درخواست‌های RDS رو مدیریت می‌کنه.قابلیت کنترل دسترسی در کلاس coldfusion.filter.IPFilterUtils تعریف شده که متد checkAdminAccess منطق مربوط به دسترسی رو اجرا می‌کنه که می‌‌تونید کدش رو در ادامه ببینید.با بررسی این کد می‌تونیم متوجه بشیم که مسیری که بهش درخواست زده میشه با یک لیست مقایسه میشه و اگه اون مسیر، تو این لیست وجود داشته باشه، بررسی می‌کنه که آیا IP درخواست کننده در لیست آدرس‌های مجاز وجود داره یا نه؟ اگه درخواستی که به مسیرهای حساس زده میشه، از IP متفرقه باشه، یک خطا رخ میده و جلوی دسترسی ما گرفته میشه. ?آدرس ارسال شده از طرف هکر با تابع java.lang.String.startsWith بررسی میشه که به راحتی میشه با اضافه کردن یه کاراکتر به اول مسیر، اون رو دور زد. اینجا با اضافه کردن یه / به ابتدای مسیر، به راحتی تابع دور زده میشه. برای مثال وقتی می‌خوایم به مسیر /CFIDE/adminapi درخواست بزنیم، چون این مسیر حساس هست و دسترسی بهش ممکن نیست ما به مسیر //CFIDE/adminapiدرخوست میزنیم و این مسیر دیگه حساس در نظر گرفته نمی‌شه چونکه تو لیست نیست!بهره‌برداری از آسیب‌پذیریبهره‌برداری از این آسیب‌پذیری، روی نسخه ColdFusion 2021 Update 6 (2021.0.06.330132) نصب شده روی Windows Server 2022 و با فعال کردن پروفایل امن برای دسترسی به مسیرهای حساس انجام شده و تنها آدرس مجاز، 127.0.0.1 هست. ما می‌تونیم به راحتی با یک دستور cURL مشخص کنیم که سامانه آسیب‌پذیره. برای مثال، ما میخوایم از تابع wizardHash استفاده کنیم و برای اینکار باید به Endpoint مربوطه ینی /CFIDE/wizards/common/utils.cfcیک درخواست cURL بزنیم. مطابق دستور زیر:curl -v -k http://172.23.10.174:8500/CFIDE/wizards/common/utils.cfc?method=wizardHash^&inPassword=fooهمونطور که تو تصویر زیر مشخصه، امکان ارسال درخواست وجود نداره و ما خطای 500 گرفتیم.حالا میایم و از دوتا Forward slash تو درخواست استفاده می‌کنیم:curl -v -k http://172.23.10.174:8500//CFIDE/wizards/common/utils.cfc?method=wizardHash^&inPassword=fooخب می‌بینیم که پاسخ 200 گرفتیم! ?حالا میایم توی مرورگر و سعی می‌کنیم صفحه مدیریت ColdFusion رو باز کنیم. اما حتی این مسیر هم جزو مسیرهای حساسه و از اینترنت قابل دسترس نیست. ?اما به راحتی با اضافه کردن یه / به ابتدای مسیر، صفحه باز شد! ?اتصال آسیب‌پذیری CVE-2023-29298 به CVE-2023-26360همونطور که دیدیم با استفاده از آسیب‌پذیری CVE-2023-29298 می‌تونیم کنترل دسترسی رو دور بزنیم، اما این مورد وقتی خطرناک‌تر میشه که با آسیب‌پذیری‌های دیگه‌ای Chain بشه، مثلا آسیب‌پذیری CVE-2023-26360؛ این آسیب‌پذیری منجر میشه بتونیم فایل‌های داخلی سرور رو بخونیم (البته میشه ازش به RCE هم رسید ولی اینجا باهاش کاری نداریم فعلا) برای خوندن فایل‌های داخلی، هکر باید حتما به یه CFC Endpoint معتبر درخواست بزنه. مشکل اینجا بود که کار هکر خیلی سخته چون اگه پروفایل امن فعال باشه، هکر نمی‌تونه به این Endpoint درخواست بزنه ولی الان می‌خوایم با استفاده از آسیب‌پذیری 29298 این مشکل رو رفع کنیم و فایل password.properties رو بخونیم. دستور cURL اون به این شکله:curl -v -k http://172.26.181.162:8500/CFIDE/wizards/common/utils.cfc?method=wizardHash^&inPassword=foo^&_cfclient=true^&returnFormat=wddx -X POST -H "Content-Type: application/x-www-form-urlencoded" --data "_variables={\"about\":{\"_metadata\":{\"classname\":\"\\..\\lib\\password.properties\"},\"_variables\":{}}}"که البته بهمون اجازه دسترسی به این Endpoint داده نمیشه. ☹️ پس میایم و دستور زیر رو می‌زنیم.curl -v -k http://172.26.181.162:8500//CFIDE/wizards/common/utils.cfc?method=wizardHash^&inPassword=foo^&_cfclient=true^&returnFormat=wddx -X POST -H "Content-Type: application/x-www-form-urlencoded" --data "_variables={\"about\":{\"_metadata\":{\"classname\":\"\\..\\lib\\password.properties\"},\"_variables\":{}}}"و نتیجه میشه خوندن فایل ?خب دیدیم که با استفاده از دو آسیب‌پذیری CVE-2023-29298 و CVE-2023-26360 تونستیم بدون مجوز، فایل داخلی password.propertiesرو بخونیم. ?راه‌های جلوگیریبرای رفع این مشکل فقط کافیه ColdFusion رو به یکی از نسخه‌های زیر آپدیت کنیم.ColdFusion 2023 GA buildColdFusion 2021 Update 7ColdFusion 2018 Update 17منبع

آسیب‌پذیری بحرانی در TP-Link

مهران سیفعلی‌نیا — Wed, 21 Jun 2023 11:55:37 +0330

همونطور که میدونیم، هر هکر مهربونی کارش اینه که بره تو اینترنت بچرخه و باگ پیدا کنه. توی یکی از این جستجوی‌های مرموز، به یک زیردامنه سازمان TP-Link رسیدیم که کلی اطلاعات مهم و محرمانه افشاء می‌کرد. این اطلاعات شامل رمزعبور به صورت متنی هم بود!!! تو این رایتاپ قراره متوجه بشیم که هدف ما معنویه، کی دنبال پوله آخه؟!ثبت‌نام در سامانهخب کار ما با ساخت یه حساب تو یکی از زیردامنه‌های TP-Link شروع میشه، این زیردامنه مربوط به خدمات مشتریان تجاریه و خب توقع میره که از FBI هم امن‌‎تر باشه!بعد از اینکه کار ما تو بخش ساخت حساب تموم شد، یه پیامی نشون داده میشه که تایید میکنه همه چیز خوش و خرم بوده و حالا باید منتظر باشیم تا اطلاعات ما توسط نیروی انسانی سازمان بررسی و تایید بشه.پیام اولاین پیام رو دیدم، ولی اهمیت ندادم! سعی کردم وارد حساب بشم ولی خب نشد ☹️پیام دوم رو هم دیدم، ولی بازم اهمیت ندادم ?پیام دومدور زدن این سازوکار فوق امنیتی!خب از اونجایی که به هیچ کدوم از پیام‌هایی که میگفت نمی‌تونی وارد حسابت بشی توجه نکردم، اینجا بود که توانایی‌های جدیدی در من پدیدار شد! و یهو رفتم روی گزینه "فراموشی رمزعبور" کلیک کردم. ایمیلم رو وارد کردم و درخواست به رمزعبور جدید دادم. (برای حسابی که هنوز تایید نشده)فراموشی رمزعبوریه رمزعبور موقت برام ارسال شد، خب؟رمزعبور موقت برای ورودبا استفاده از این رمزعبور موقت سعی کردم وارد حساب کاربریم بشم و خب چون به هیچ کدوم از پیغام‌های قبلی توجه نکرده بودم، تونستم وارد حساب بشم ? و اینبار وارد بخش پروفایل کاربریم شدم تا اطلاعاتم رو وارد کنم (درواقع ازم خواست که رمزعبور جدید وارد کنم)انتخاب رمزعبور جدیدخب دیدیم که مثل آب خوردن تونستیم اون تاییدی که منتظرش بودیم تا منابع انسانی سازمان اونو انجام بده تا بتونیم وارد حسابمون بشیم رو دور بزنیم. این تازه یه آسیب‌پذیری بود که خب تونستیم بدون اجازه سازمان، وارد حساب کاربری بشیم.دیگه وارد شدیمافشای اطلاعات حساس?خب، بعد از اینکه وارد شدیم، شروع کردم به بررسی پایانه‌ها و APIهای سامانه که یهو دیدم عه، یه جایی هست که وقتی بهش درخواست می‌زنیم، اطلاعات ما رو نشون میده که شامل رمزعبور ما هم میشه! این خودش خیلی بده ها! ینی چی که رمزعبور رو نشون میدن! (درسته رمز برای خودمونه، اما جلوتر متوجه می‌شیم که چرا نباید رمز خودمون رو بهمون نشون بده) حالا از اینا بگذریم، متوجه شدم که توی درخواستی که داریم میزنیم برای مشاهده اطلاعات خودمون، یه ID هم داره ارسال میشه که این ID درواقع شناسه کاربری خود ماست.اطلاعات مهم!من سعی کردم این ID رو تغییر بدم تا ببینم می‌تونم اطلاعات (شامل رمزعبور) یکی دیگه رو ببینم یا نه، به این باگ میگن IDOR؛ خب موفق شدم و اطلاعات ادمین رو پیدا کردم ?ارجاع نا امن به یک موجودیت که با اسم IDOR شناخته میشه، یه آسیب‌پذیریه که وقتی رخ میده که برنامه اجازه داره مستقیما بیاد و یه منبع یا اطلاعات رو از داخل منابع سرور یا سایت بخونه بدون اینکه احراز هویت بشه. خب این اجازه میده تا هکر بیاد اطلاعات بقیه رو هم بخونه (درحالی که فقط باید مثل یه بچه خوب اطلاعات خودش رو بخونه)دیدن اطلاعات یکی دیگه (ادمین)خب اینجا اومدم و حمله‌ای رو انجام دادم که بهش میگن بروت فورس، ینی اومدم و اون ID رو از 1 تا 99999 تست کردم و اطلاعات تمامی مشتریان TP-Link رو به‌دست آوردم؛ ینی کلا هرکسی که تو این سایت اکانت داشت، الان دیگه اکانتش نداشت! چون اکانتش برا من بود ?گزارش به سازمانخب من این باگ خیلی خیلی خیلی خیلی خیلی خطرناک که منجر میشد TP-Link به فنا بره رو بهشون گزارش دادم و اونا هم گفتن باشه، بذار بررسی کنیم بهت خبر می‌دیم.بررسی کردن!بعد از اینکه بررسی کردن گفتن که "ای وای، این خیلی خطرناک بود، مرسی داداشی! ?" همین دیگه، پول که ندادن ولی خب حداقل باعث شدیم دنیای مجازی جای امن‌تری باشه (فعلا با اینا خودمون رو گول بزنیم... ?)گدایَن :(منبع

حمله DOS از طریق Cache Poisoning

مهران سیفعلی‌نیا — Fri, 26 May 2023 21:44:49 +0330

امروز می‌خوایم راجع به حافظه کش، منع خدمت و آسیب‌پذیری که اخیرا رو یه کمپانی گنده پیدا کردم صحبت کنیم.این کَش که میگی، چی چی هست؟حافظه کَش (به انگلیسی: Cache) یه حافظه سیستمی میانیه که برای ذخیره موقت داده‌ها استفاده میشه تا بتونیم کارایی (Performance) بهتری رو هنگام گشتن تو صفحات وب داشته باشیم.چند مدل سیستم کش داریم:سمت کاربر (لوکال): کش مرورگر که روی دستگاه کاربر ذخیره میشه.سمت سرور: این مورد پاسخ بعضی از درخواست‌های مشخص رو روی سرور واسط ذخیره می‌کنه تا وقتی بقیه به اون منبع درخواست می‌زنن، دیگه بار روی سرور نیوفته و کاربرا پاسخشون رو از اون واسط میانی دریافت می‌کنند نه از سرور اصلی.پس حتما متوجه شدید که نون توی کش سمت سروره! پس یکم بیشتر توضیح میدم:حافظه کش، پاسخ ثابتی رو (که قبلا ذخیره کرده) به درخواست‌های مشابه ارسال می‌کنه. مثلا اگه به آدرس a.txt درخواست زده باشی، این درخواست به سرور ارسال میشه، جوابش از سرور گرفته میشه و قبل از اینکه به‌دست شما برسه، روی واسط میانی که نقش حافظه کش رو داره ذخیره میشه. حالا اگه یه نفر بعد از شما درخواستی برای مشاهده فایل a.txt بزنه، دیگه درخواستش به سرور نمیره! بلکه واسط میانی که فایل a.txt رو ذخیره کرده، اون فایل رو برای بقیه هم میفرسته.توجه کنید که این ذخیره دائمی نیست و بعد از یه مدت زمان مشخصی، اون فایل از روی حافظه کش پاک میشه و مجدد باید از سرور گرفته بشه.آلوده‌سازی حافظه کشبه نقل از PortSwigger بزرگ: آسیب‌پذیری آلوده‌سازی حافظه کش وب، یک تکنیک پیشرفتست که به کمک اون، نفوذگر میاد و از این رفتار وب و حافظه کش استفاده می‌کنه تا پاسخ‌های شیطانی خودش رو برای کاربرای دیگه ارسال کنه!یه حمله موفق آلوده‌سازی حافظه کش، می‌تونه به آسیب‌پذیری‌های مختلفی از جمله تزریق HTML، XSS، هدایت آزاد (Open Redirect)، منع خدمت (DOS) و... منجر بشه.رفتار حافظه کشبرای بهره‌برداری از حافظه کش، نفوذگر باید کامل درک کنه که این سازوکار داره چجوری کار می‌کنه. خب ببینید، قبلتر گفتم که حافظه کش میاد و پاسخ مشابهی رو به درخواست‌های مشابه میده، اما سوال اصلی اینجاست که از کجا می‌فهمه این درخواست مشابه قبلیه؟؟؟خب اینجا باید با چیزی تحت عنوان مقادیر کلیدی در حافظه کش آشنا بشیم. (Chace Keys) این مقادیر درواقع بخشی از درخواست ما هستند که مثل اثر انگشت برای شناسایی درخواست‌های یکسان استفاده میشه. اگر درخواستی بیاد به حافظه کش و اثر انگشت اون با اثر انگشت درخواست اولیه (ذخیره شده تو حافظه کش) یکی باشه، ینی این دو درخواست یکین و حافظه کش خودش میاد و بهش جواب میده و دیگه سمت سرور نمیفرسته. حالا درخواست ما قطعا شامل بخش‌های دیگه‌ای هم میشه که تاثیری روی شناسایی درخواست‌های یکسان نداره، به اونا میگن درخواست‌های Unkeyed (فارسیش نمیدونم چی میشه دیگه، آهان بهش میگیم مقادیر غیرکلیدی D: ) که حافظه کش اهمیتی نمیده این موارد تو درخواست‌های مختلف یکی باشن یا با هم فرق کنن. این مقادیر غیر کلیدی دقیقا جایی هست که نفوذگر میاد و ازش برای تزریق و ایجاد حمله استفاده می‌کنه. مثلا خیلی از سرآیندها غیرکلیدی هستن، این درحالیه که مقدار این مقادیر توی پاسخ هم دیده میشه! (مفاهیم اولیه برای حملات تزریق HTML و XSS) بذارید یه مثال کوچیک هم بزنم. فکر کنید من یه درخواست میزنم به یه سایت و با مرورگر کروم میرم، این سایت سرآیند User-Agent مرورگر من رو روی صفحه نشون میده و می‌نویسه "شما با مرورگر کروم وارد شده‌اید."، حالا اگه این پاسخ روی سرور کش ذخیره بشه، یکی بعدا بیاد داخل سایت که از مرورگر فایرفاکس استفاده می‌کنه، اگه درخواستی رو ارسال کنه به منبعی که من قبلا ارسال کردم، سرور کش میاد و همون پاسخی که من گرفته بودم رو میده به اون بنده خدا، اینجا اتفاقی که می‌افته اینه که اون بنده خدا با فایرفاکس اومده تو سایت اما سایت داره بهش میگه "شما با مرورگر کروم وارد شده‌اید." !!!! خب این مورد میتونه باعث چی بشه؟1- ذخیره یک مقدار تزریق شده در پاسخ‌های کش2- ارائه این مقادیر تزریق شده به بقیه کاربرا# به این میگن تزریق حافظه کشمقادیر کلیدی میتونن متفاوت باشن و این که چه چیزی به‌عنوان مقادیر کلیدی درنظر گرفته بشه، به تنظیمات سرور کش بستگی داره. بعضی وقت‌ها فقط خط اول درخواست (Request line) و سرآیند Host به‌عنوان مقدار کلیدی در نظر گرفته میشن و تمامی بخش‌های دیگه به‌عنوان مقادیر غیرکلیدی در نظر گرفته میشن. پس خیلی مهمه که به‌عنوان هکر کلاه سفید قبل از اینکه بیایم حمله کنیم، مقادیر کلیدی و غیرکلیدی رو شناسایی کنیم.از آلوده‌سازی حافظه کش تا منع خدمتخب من تونستم تو زمان خیلی کوتاهی این باگ رو توی یه کمپانی بزرگ پیدا کنم. اولین کاری که برای پیدا کردن این آسیب‌پذیری باید انجام بدیم، اینه که پاسخ سرور رو با دقت بررسی کنیم.اولین نکته خیلی مهم تو این درخواست، سرآیند X-Cahce که مقدارش برابر با HIT هست، این نشون میده که پاسخی که ما گرفتیم داره از سرور کش میاد نه از خود سرور! ولی اگه مقدارش برابر با MISS بود ینی اینکه این پاسخ داره مستقیم از سرور میاد و کش نشده. البته خیلی مهمه که بدونید سرآیند X-Cache استاندارد نیست و ممکنه اسمش تو سایت‌های مختلف عوض بشه و چیز دیگه‌ای باشه! اما مقدارش همیشه یا HIT و یا MISS هست.دومین نکته خیلی مهم سرآیند Age هست که اینم مربوط به تنظیمات کشه، عددی که جلوی این سرآیند نوشته شده، نشون میده که این پاسخ به‌مدت چند ثانیه قراره تو حافظه کش ذخیره بمونه (بعدش پاک میشه)؛ بعضی وقتا ممکنه سرآیندهای دیگه‌ای هم ببینید، مثلا ممکنه Cache-Control رو ببنیم که یکسری تنظیمات مربوط به کش رو همراه خودش داره، یکی از این تظیمات که خیلی مهمه، اسمش هست max-age که اینجا تو این پاسخی که عکسش رو گذاشتم وجود نداره. این پیکربندی مشخص میکنه که تا چه مدتی ما اجازه نداریم درخواست جدید برای گرفتن داده‌ها ارسال کنیم. (به‌عبارت دیگه زمانی که داده‌ها باید کش بمونن) این موارد به مهاجم کمک می‌کنه تا تشخیص بده چه زمانی باید آلوده‌سازی خودش رو انجام بده.سومین نکته خیلی مهم سرآیندیه به اسم Vary که اینجا هم ما داریمش، این سرآیند خیلی مهمه چرا؟ چون داره به‌صورت واضح به ما یکسری از مقادیر کلیدی رو اعلام می‌کنه. مثلا اینجا دو سرآیند Accept-Encoding و x-wf-forwarded-proto کلیدی هستن و میشه ازشون برای مشخص کردن درخواست‌های یکسان استفاده کرد. البته یه نکته خیلی مهم وجود داره و اونم اینه که ممکنه مقادیر کلیدی دیگه‌ای هم وجود داشته باشن که توی این سرآیند بهشون اشاره‌ای نشده باشه.تکنیک Cache Bustingقبل از اینکه کار رو شروع کنیم باید این نکته رو در نظر بگیرید که توی سامانه‌های عملیاتی، نباید با حملات آلوده‌سازی حافظه کش، باعث از کار افتادن سامانه بشیم، مخصوصا وقتی که سامانه ما مهم و حیاتی باشه، چون می‌تونه آسیب زیادی به اون سازمان بزنه. برای اینکار از تکنیکی به اسم Cache Busting استفاده می‌کنیم. بعضی از اجزاء همیشه به‌عنوان مقادیر کلیدی در نظر گرفته میشن، با URL شروع میکنیم. (البته همیشه استثناء وجود داره)اگر یک پاسخ کش برای درخواست به https://www.example.com داخل کش سرور ذخیره بشه و یک کاربر بیاد و درخواست بزنه به https://www.example.com/?test=test اونوقت سرور کش، این درخواست رو به‌عنوان یک درخواست جدید در نظر می‌گیره و اون رو به سرور اصلی ارسال می‌کنه. (چون URL یکی از مقادیر کلیدیه که با تغییرش باعث میشیم سرور درخواست ما رو یک درخواست جدید در نظر بگیره)این رفتار به ما اجازه میده تا یک سامانه رو بدون اینکه آسیبی بهش وارد بشه بررسی کنیم. برای اینکار فقط کافیه تا یه پارامتر تصادفی به آدرس URL اضافه کنیم تا مطمئن باشیم کسی به اون آدرس درخواست نمی‌زنه. این باعث میشه تا بتونیم آسیب‌پذیری رو بدون آسیب زدن به سامانه پیدا کنیم.برگردیم سر بحث اصلیبعد از بررسی‌ها مشخص شد که سرور داره از سازوکار کش استفاده می‌کنه و دو سرآیند Accept-Encoding و x-wf-forwarded-proto هم جزو مقادیر کلیدی هستن. خب حالا من اومدم به دنبال مقادیر غیر کلیدی بگردم تا بتونم تزریق خودم رو انجام بدم. خب اینجا یه سرآیند داریم به اسم X-Timer که این مورد معمولا تو پاسخ هم رفلکت میشه (البته ازش نمیشه به XSS رسید چون داخل سرآیندها رفلکت میشه و اصلا توی بدنه‌ی پاسخ قرار نمیگیره). اما وقتی چنین رفتاری داره، یعنی این سرآیند داره سمت سرور پردازش میشه، پس ممکنه بتونیم ازش برای ایجاد خطا استفاده کنیم. موفق هم شدم :)همونطور که میبینید برای اینکه سامانه رو خراب نکنم، اومدم و یه پارامتر الکی به درخواست اضافه کردم (mycachebuster=zhero_) و بعدش درخواستم رو ارسال کردم. خب به خاطر اینکه سرآیند X-Timer رو دستکاری کردم به خطا خوردم، حالا یه مرورگر دیگه باز کردم و به همون آدرس درخواست زدم (بدون اینکه سرآیند X-Timer رو دست بزنم) و بووووممممم! خطا داد!صفحه مورد نظر دیگه قابل استفاده نیست و از دسترس خارج شده!چند نکته طلایی:برای اینکه تاثیر آسیب‌پذیری زیاد باشه، بهتره که اون رو توی مسیر اصلی سایت (با اضافه کردن یه پارامتر تصادفی) امتحان کنیم، اگر نشد، روی فایل‌های مهم مثل CSS یا فونت‌ها (چون اختلال تو اینا باعث میشه سایت دیگه درست کار نکنه)گاهی ممکنه چندین سرور کش داشته باشیم پس مطمئن بشید که درخواستتون رو چندین بار پشت سر هم ارسال کنید تا تمام سرورها آلوده بشن.حتما بعد از اعمال حمله، با یک آدرس IP دیگه تست کنید که سایت هنوز کار میکنه یا نه، چون ممکنه گاهی حمله فقط روی کش سرورهای محلی یا داخلی ذخیره بشه (مثل شبکه داخلی شرکت، خود کامپیوتر و...)منبع: اینجا

درک بهتر آسیب‌پذیری LDAP Injection و چند مثال از آن

مهران سیفعلی‌نیا — Fri, 19 May 2023 14:42:37 +0330

اِل دَپ که یک پروتکل برای دسترسی و مدیریت سرویس‌های مربوط به دایرکتوری‌ها هست، و به انگلیسی LDAP نوشته میشه، مخفف Lightweight Directory Access Protocol هست. (چه چیزا!) از این پروتکل معمولا برای سازماندهی احراز هویت و سطح دسترسی کاربران یک سازمان استفاده میشه. خب طبیعیه که مثل بقیه فناوری‌های مربوط به وب، این یکی هم پر از آسیب‌پذیری‌های امنیتی باشه؛ که یکی از محبوب‌ترین‌هاش به تزریق LDAP (LDAP Injection) معروفه که قراره اینجا درباره اون صحبت کنیم.تزریق LDAP چیه دیگه؟تزریق LDAP از پیاده‌سازی‌های نادرست یا طراحی‌های نا ایمن در سرویس‌های LDAP بوجود میاد (البته زیادم مهم نیست بدونیم چرا بوجود میاد D: ) سرویس‌های LDAP برای ذخیره و سازماندهی داده‌ها در ساختار سلسه مراتبی درختی استفاده میشن مثلا نام‌کاربری، رمزعبور و اطلاعات ارتباطی و... حالا تزریق LDAP به هکر اجازه میده تا با اضافه کردن کدهای مخرب بتونه Queryهای LDAP رو دستکاری کنه و به اطلاعات غیرمجاز دسترسی پیدا کنه یا فرآیندهای احراز هویت رو دور بزنه.ساخت پیلودهای LDAP Injectionخب خب خب... حرف زدن بسته، بریم سراغ چندتا مثال تا بتونیم مفاهیم رو بهتر درک کنیم. برای اینکه بتونید بهتر و سریع‌تر این آسیب‌پذیری رو پیدا کنید و ازش سوءاستفاده مفید (!) کنید، بهتره که ساختار LDAP رو مطالعه کنید و اون رو بشناسید، چیز زیاد پیچیده‌ای نیست؛ یکسری کوئری برای فیلتر کردن داده‌ها و دسترسی به اون‌هاست. مثلا کد زیر رو در نظر بگیرید که برای احراز هویت کاربر استفاده میشه: (هرجایی از این مقاله در خصوص کوئری‌های LDAP سوالی داشتید حتما کامنت کنید، خوشحال میشم بتونم کمک کنم.)(&(uid=<نام کاربری>)(userPassword={CLEAR}<رمزعبور>))خب این کوئری دنبال یه کاربر خاص می‌گرده که نام‌کاربری و رمزعبور خاصی داره. (همون احراز هویت یا فرآیند وروده)حالا اینجا نفوذگر (هکر) می‌تونه بیاد و با تزریق کد زیر به جای <نام کاربری> ، فیلتر مربوطه رو دور بزنه:*)(uid=*))(|(uid=*در نهایت، کوئری که سمت سرور پردازش میشه میشه چیزی شبیه این:(&(uid=*)(uid=*))(|(uid=*)(userPassword={CLEAR}<رمزعبور>))خب این کد داره بررسی می‌کنه که اگر نام‌کاربری هرچی بود! نتیجه رو به ما برگردونه. در ادامه هم برای اینکه قسمت رمزعبور ما رو اذیت نکنه، یه شرط OR بهش اضافه کرده؛ خلاصه کوئری داره میگه که اگر نام‌کاربری هرچیزی بود و همچنین نام‌کاربری هرچیزی بود!!! یا اگر نام‌کاربری هرچیزی بود یا رمزعبور هم برابر بود با یه‌چیزی، بذار ما وارد حساب بشیم! (اگه نفهمیدی چی شد، احتمالا باید با درباره‌ی اوپراتورهای شرطی مطالعه کنی)خب حالا که فهمیدیم چجوری میشه تزریق کرد، بریم یکسری پیلود دیگه رو با هم بررسی کنیم.1- دریافت اطلاعات تمامی کاربران:در نظر بگیرید که یه برنامه‌ای داره از LDAP برای جستجو کردن کاربری استفاده می‌کنه که ایمیل خاصی داره (بخش جستجوی کاربران بر اساس ایمیل) خب کوئری اصلی چیزی شبیه به اینه:(&(objectClass=person)(mail=<ایمیل>))هکر می‌تونه با تزریق کد مخرب (همون پیلود) زیر، به اطلاعات تمامی کاربرا دسترسی پیدا کنه:*)(objectClass=person)|با تزریق این پیلود، کوئری که سمت سرور پردازش میشه، نهایتا میشه این:(&(objectClass=person)(mail=*)(objectClass=person))(|)که این کوئری شئ person رو برای تمامی ایمیل‌ها برمی‌گردونه.2- دور زدن سطح دسترسی گروه‌های مختلف:حالا فکر کنید یک برنامه‌ای داره چک می‌کنه که آیا یک کاربر، عضو گروه خاصی هست یا نه؟ (برای اینکه بتونه از قابلیت‌های اون گروه استفاده کنه:(&(objectClass=group)(cn=<نام گروه>)(member=<نام‌کاربری>))اینجا هکر می‌تونه با تزریق در <نام گروه>بیاد و این چک کردن رو دور بزنه و به قابلیت‌های تمامی گروه‌ها دسترسی پیدا کنه:*)(objectClass=*)(نتیجه نهایی کوئری که سمت سرور پردازش میشه، اینه:(&(objectClass=group)(cn=*)(objectClass=*)(member=<نام‌کاربری>))خب همونطور که مشخصه این کوئری کاربر مربوطه رو بدون در نظر گرفتن گروه و کلاسش، برمیگردونه.3- ارتقاء سطح دسترسی:یه برنامه دیگه رو در نظر بگیرید که با کوئری LDAP میاد و چک میکنه که آیا یک کاربر مدیره یا نه:(&(objectClass=person)(uid=<نام‌کاربری>)(isAdmin=TRUE))هکر می‌تونه با تزریق پیلود زیر به‌جای <نام‌کاربری>، سطح دسترسی خودش رو به ادمین ارتقاء بده:*)(isAdmin=*)(کوئری نهایی که به سرور ارسال میشه اینه:(&(objectClass=person)(uid=*)(isAdmin=*)(isAdmin=TRUE))خب این کوئری تمامی کاربران رو با هر مقداری برای isAdmin برمی‌گردونه که باعث میشه کل فرآیند دور بخوره. هدف از این نمونه‌ها این بود که متوجه بشیم به‌طور کلی قراره چطور تزریق رو انجام بدیم و اینکه حتما تزریق ما باید بر اساس ساختار کوئری اصلی انجام بشه، یعنی ما باید قبل از تزریق کردن، ساختار و دلیل وجود یک کوئری خاص رو بدونیم.راه‌های جلوگیری:برای اینکه در برابر حملات تزریق LDAP ایمن باشیم، باید یکسری نکات رو رعایت کنیم:1- اعتبارسنجی و بهینه‌سازی ورودی‌های کاربر: باید قوانین سختگیرانه‌ای برای اعتبارسنجی ورودی‌های کاربر پیاده‌سازی بشه، مثلا یک لیست سفید برای کاراکترهای مجاز تعریف بشه و کاراکترهای خطرناکی مثل * یا (& باید بهینه بشن یا اسکیپ بشن تا جلوی حملات تزریق LDAP گرفته بشه.2- استفاده از کوئری‌های پارامترایز شده: درست مثل تزریق SQL، برای جلوگیری از تزریق LDAP یکی از راه‌های خیلی مفید می‌تونه استفاده از ساختار پارامترایز شده برای کوئری‌ها باشه. استفاده از ساختار پارامترایز، باعث میشه تا ورودی کاربر از کوئری اصلی جدا بشه و مطمئن میشه که ورودی کاربر به‌عنوان داده در نظر گرفته میشه نه به‌عنوان بخشی از کوئری. (برای اطلاعات بیشتر می‌تونید Parameterized Query رو مطالعه کنید)3- استفاده از کتابخانه‌های امن برای LDAP: بعضی از کتابخانه‌هایی که برای LDAP استفاده میشن خودشون به‌صورت ایمن نوشته شدن و جلوی حملات تزریق رو می‌گین. مثلا کتابخونه System.DirectoryServices.Protocols در .NET یک نسخه امن از کتابخانه LDAP هست که جلوی خیلی از حملات رو می‌گیره.4- حداقل دسترسی برای حساب‌های سرویس‌های LDAP: حساب‌هایی که سرویس‌های LDAP روی اون‌ها اجرا میشه، باید حداقل مجوزها و دسترسی‌ها رو داشته باشن تا جلوی حملات (خدایی نکرده) مخرب گرفته بشه و اگر حمله‌ای شد، هکر نتونه کار خاصی انجام بده.5- ارسال این مقاله برای برنامه‌نویس‌ها و ادمین‌های سرویس‌های LDAP :)))منبع اصلی: اینفوسک رایتاپس

بهره‌برداری موفق از آسیب‌پذیری Prototype Pollution با استفاده از DOM XSS

مهران سیفعلی‌نیا — Sun, 14 May 2023 22:54:03 +0330

منبع: یه جایی تو توییتر!سلام به همه شکارچیای عزیز (همه هانترا) امروز تصمیم گرفتم که یه آسیب‌پذیری جالب و خفن رو با شما به اشتراک بذارم؛ قبلش بهتره یکم توضیح بدم که آسیب‌پذیری prototype pollution چیه. (میخواستم اسم این باگ رو فارسی بنویسم، دید خیلی مسخره میشه، آلوده‌سازی والد اولیه یا یه همیچی چیزی :) )آسیب‌پذیری Prototype Pollution چیه؟به نقل از گنده‌ی دنیای امنیت PortSwigger: این Prototype Pollution یه آسیب‌پذیری مربوط به زبان شیرین و دوست داشتنی JavaScript هست که به نفوذگر (همون هکر) اجازه می‌ده تا بیاد و خصیصه‌های (Properties) دلخواه خودش رو به والد اولیه یک شئ عمومی اضافه کنه. (اینا دیگه مربوط میشه به زبان برنامه‌نویسی، این واژه‌های عجیب و غریب تقصیر من نیست) البته که این آسیب‌پذیری به‌تنهایی قابل بهره‌برداری و سوءاستفاده نیست؛ در واقع با این کار نفوذگر می‌تونه خصیصه‌هایی از اشیاء رو تغییر بده که در حالت عادی بهشون دسترسی نداره. اگه برنامه، خدایی نکرده یادش بره که ورودی‌هایی که از کاربر می‌گیره رو درست و حسابی بررسی کنه، این قابلیت (دستکاری کردن والد اولیه یک شئ) می‌تونه با آسیب‌پذیری‌های دیگه ترکیب بشه و... :( خدا بیامرزه.منبع: پورت سوئیگرخب تا اینجا فهمیدیم که این آسیب‌پذیری قابل بهره‌برداری نیست و باید با یک آسیب‌پذیری دیگه ادغام بشه. قبل از اینکه بریم جلوتر، نیازه تا یه کوچولو با بعضی مفاهیم جاوا اسکریپت آشنا بشیم تا بتونیم بهتر درک کنیم که این آسیب‌پذیری چجوری کار میکنه.در جاوا اسکرپیت همه چیز یک شئ است!یک شئ در جاوا اسکریپت، مجموعه‌ای از کلیدها و مقادیر اون‌هاست که بهش میگن Key-Value که این مقادیر میتونن از هر نوعی باشن (رشته، عدد، عبارت شرطی و... ). ما می‌توینم تو جاوا اسکریپت به راحتی آب خوردن یک شئ بسازیم، همونطور که این پایین می‌بینید:let myObject = { prop1: "A simple string", prop2: 100, prop3: true }خب حالا برای دسترسی به این شئ که ایجاد کردیم می‌تونیم از دو روش استفاده کنیم؛ روش اول استفاده از نقطه برای دسترسی به شئ:myObject.prop1 // -> will return "A simple string"و روش دوم استفاده از براکت:myObject['prop2'] // -> will return 100حالا جلوتر قراره از یکی از این دو روش برای آلوده‌سازی والد اولیه یک شئ استفاده کنیم. بازم تاکید می‌کنم که فراموش نکنید که در زبان جاوا اسکریپت، هرچیزی یک شئ محسوب میشه و هر شئ به یک شئ دیگه متصل شده (والد اولیه) که بهش میگیم Prototype که این شئ تمامی متدها و خصیصه‌ها رو از والدش به ارث می‌بره.الگوی برنامه نویسی شئ‌گراجاوا اسکریپت یک زبان برنامه‌نویسی چند وجهیه که می‌تونیم باهاش به روش‌های مختلف برنامه‌نویسی کنیم؛ این روش‌ها عبارتند از:برنامه‌نویسی functionalبرنامه‌نویسی object-orientedبرنامه‌نویسی proceduralبرنامه‌نویسی prototypeتو این مورد ما بیشتر به برنامه‌نویسی object-oriented علاقه نشون می‌دیم چون این مدل از برنامه‌نویسی از اشیاء، کلاس‌ها و والدهای اولیه (Prototype) تشکیل میشه. قرار نیست که دوره جاوا اسکریپت برگذار کنیم! اما یکم درباره مفاهیم ارث‌‌بری و نمونه‌سازی والد اولیه میگیم.دوباره برمی‌گردیم به ستون امنیت کره‌ی زمین (PortSwigger) که ایشون در این باره می‌فرمایند:وقتی که خصیصه‌ای از یک شئ رو صدا می‌زنیم، موتور جاوا اسکریپت اول سعی می‌کنه تا اون خصیصه رو مستقیما از داخل خود همون شئ بخونه (شئ ای که داخلش هستیم و اونجا داریم خصیصه رو صدا می‌زنیم) اگه اون شی چنین خصیصه‌ای نداشته باشه جاوا اسکریپت شروع میکنه میره عقب و داخل والدهای اون شئ رو می‌گرده.وقتی که یه شئ جدید می‌سازیم، جاوا اسکریپت با توجه به نوع شئ ساخته شده، به‌صورت خودکار اون رو متصل می‌کنه به یکی از والدهای اولیه از پیش ساخته شد (ارث‌بری می‌کنه):اشاره به خصیصه‌های والد متصل شدهنوع شئ‌ای که من ساختم رشته هست. وقتی سعی میکنم تا با استفاده از نقطه، به یکی از خصیصه‌های شئ دسترسی پیدا کنم، همون‌طور که تو شکل بالا مشخصه، مرورگر به من کلی خصیصه نشون میده که من اون‌ها رو نساختم! این طبیعیه؛ چون جاوا اسکریپت خودکار اومده و شئ من رو به شئ والد رشته متصل کرده و شئ من از والد خودش (که یک شئ رشته هست) تمامی خصیصه‌های مربوط به رشته رو به ارث برده. حالا اینجا جذاب میشه. ما میتونیم با استفاده از کلمه کلیدی __proto__ به والد شئ مورد نظر اشاره کنیم. مثلا تو شکل زیر، من به والد شئ‌ای که خودم ساختم اشاره کردم و می‌بینیم که والد شئ من، خودش شئ رشته (String) هست.اشاره به والد از طریق __proto__تو تمامی اشیاء موجود در جاوا اسکریپت ما می‌تونیم به همین روش به والد یک شئ اشاره کنیم. خود شئ رشته که بالاتر دیدیم، از یک والد دیگه ارث‌بری کرده و خود اون والد هم از یه والد دیگه و این می‌تونه کلی زنجیره از والدها رو تشکیل بده. برای دسترسی به والدهای قبل‌تر می‌تونیم از دستور زیر استفاده کنیم. (اینجا ما سه تا والد رفتیم عقب، ولی شما هرچقدر دوست داری برو عقب، اصلا اینقدر برو عقب تا برسی به قطعه کدی که حضرت آدم نوشته ;)myObject.__proto__.__proto__.__proto__این مهمه که اشاره کنم اینجا این __proto__ که گفتیم، هم به‌عنوان Setter و هم به عنوان Getter عمل میکنه؛ یعنی هم می‌تونه به خصیصه دسترسی داشته باشه و هم می‌تونه اون‌ها رو تغییر بده (اینا هم باز مفاهیم برنامه‌نویسیه! ای بابا)خب حالا چی میشه اگه یه نفوذگر بیاد و خصیصه‌ای که مربوط به یک والد هست رو بازنویسی کنه، اونم نه هر خصیصه‌ای رو، بلکه خصیصه ‌ای که سایت داره ازش استفاده می‌کنه (البته با یه مقدارِ از قبل تعریف شده توسط برنامه‌نویس) اینجاس که مفهوم آلوده‌سازی مطرح میشه. ولی همونطور که قبلا هم گفتیم، هنوز نمیشه به تنهایی از این آلوده‌سازی، سوءاستفاده کرد.راهنمایی برای آلوده‌سازی موفق یک Prototypeمجدد از سلطان PortSwigger نقل قول می‌کنیم.آلوده‌سازی Prototype وقتی اتفاق می‌افته که جاوا اسکریپت به‌صورت بازگشتی میاد و یک خصیصه از شئ قابل کنترل توسط کاربر رو با یک شئ که از قبل وجود داره ادغام می‌کنه بدون اینکه ورودی‌های کاربر رو اعتبارسنجی کنه. برای اینکه بتونیم به‌صورت موفق از این آسیب‌پذیری بهره‌برداری کنیم، نیازه تا چندتا مورد رو بررسی کنیم که حتما وجود داشته باشن:* منبع آلوده‌سازی -- هر ورودی که به ما اجازه بده تا بتونیم والد یک شئ رو باخصیصه‌های دلخواه آلوده کنیم.* سینک -- یه تابع جاوا اسکریپت یا یک عنصر DOM که می‌تونه کد جاوا اسکریپت رو اجرا کنه.* گجت آسیب‌پذیر -- به هر خصیصه‌ای گفته میشه که تو کد ما، پاس داده میشه به یک سینک تا اجرا بشه، بدون اینکه اعتبارسنجی بشه.نمونه واقعی از این آسیب‌پذیری که بهش برخوردم :)خب حالا وقتشه که بریم سراغ سناریوی واقعی از این آسیب‌پذیری که تو یه برنامه خصوصی بهش برخوردم. داشتم روی سایت www.example.com کار می‌کردم و کلی هم آسیب‌پذیری داشت (XSS ،Iframe Injection) این موضوع باعث شد تا متوجه بشم این سایت اصلا ورودی‌های کاربر رو بررسی و اعتبارسنجی نمی‌کنه. بعد از اینکه به چندتا مورد برخوردم که اجازه می‌داد تا مستقیما HTML و JS تزریق کنم، به این فکر افتادم که آیا می‌تونم مستقیما از URL برای آلوده‌سازی Prototype استفاده کنم؟خب با دستور جذاب زیر شروع کردم اما وف جلومو گرفت :(?__proto__.zhero=zheroوف بی ادب خب یه سری روش رو امتحان کردم ولی هیچکدوم جواب نداد، حتی سعی کردم از Constructor استفاده کنم اما بازم به نتیجه نرسیدم و وف منو بلاک می‌کرد. بعدش اومدم از روش تزریق تو در تو استفاده کردم:?__pro__proto__to__.zhero=zheroاینم نمونه Constructor که به جای نقطه از براکت استفاده کردم:constructor[prototype][zhero]=zheroیادتون نره که حتما هر دو روش دسترسی به خصیصه‌های شئ رو تست کنید (استفاده از نقطه و استفاده از براکت) این مورد بعد از دور زدن وف خیلی می‌تونه مفید باشه.وقتی که داشتم توی Web Archive سایت رو بررسی می‌کردم، متوجه شدم که تعداد زیادی آدرس هستن که داخلشون از علامت # استفاده شده و بعدش اطلاعات مفیدی اومده اینکه بعد از این علامت یکسری اطلاعات قرار گرفته، مشخص می‌کنه که این علامت فقط یک هشتگ ساده نیست و قطعا سایت داره از این علامت برای گرفتن اطلاعات خاصی استفاده می‌کنه و بعدش اون‌ها رو به توابعی پاس میده که این توابع با آدرس URL و پارامترهای اون کار داره؛ پس تصمیم گرفتم که این رو تست کنم.#__proto__[zhero]=zheroاگه ساختار آدرس‌های URL رو به خوبی بشناسید، می‌دونید که این علامت و اطلاعات اون سمت سرور ارسال نمی‌شه و مستقیما توسط DOM در مرورگر پردازش میشه، پس وف قطعا جلوی ما رو نمیگیره. خب حالا توی کنسول مرورگر تست کردم و دیدم که تزریق ما موفقیت‌آمیز بوده و والد شئ آلوده شده:آلوده‌سازی موفقبا توجه به نتایج، فهمیدیم که آلوده‌سازی انجام شده، یکم که بررسی کردم تونستم کد مسئول این همه نابسامانی رو پیدا کنم! (البته هنوز این کد بنده خدا کاری نکرده، ولی این کد همونیه که قراره ازش سوءاستفاده کنیم برای بهره‌برداری)قطعه کد خطا کار!همونطور که می‌بینید هیچ فیلتری اینجام اعمال نشده، چون هنوز هم قبل از اینکه مقادیر به تابع پاس داده بشن هم میشه فیلتر اعمال کرد تا جلوی تزریق مقادیر خطرناک گرفته بشه.با توجه به چیزایی که بالاتر گفتیم، برای موفقیت‌آمیز بودن حمله، باید یکسری نکات رو رعایت کنیم؛ یکی از این نکات این بود که تزریق ما باید یه‌جایی مورد استفاده قرار بگیره تا بتونیم ازش سوءاستفاه کنیم؛ پس شروع کردم به بررسی کد و دیدم چیزی که تزریق کردیم داخل تگ style به عنوان یک attribute و مقدار اون قرار می‌گیره:جایی که مقدار تزریق شده قرار گرفتبعد از اینکه اینو دیدم گفتم خب چیکار میشه کرد؟ خیلی سادس؛ یه Event Handler می‌خوام که بتونم باهاش کد جاوا اسکریپت اجرا کنم. چی بهتر از ؟ پس کد زیر رو تزریق کردم:#__proto__[]=alert(%22XSS by zhero_%22)و نتیجه شد این:بهره‌برداری از آسیب‌پذیریما تونستیم به آسیب‌پذیری XSS برسیم؛ البته که با تزریق کد می‌تونیم کارهای خفن‌تری بکنیم ولی برای اینکه ثابت کنیم آسیب‌پذیری وجود داره، به نظرم تا همینجا کافیه.مرسی که وقت ارزشمندتون رو گذاشتید و این رایتاپ رو خوندید، حتما حتما حتما اگه انتقاد یا پیشنهادی داشتید خوشحال میشم بهم بگید تا بتونم محتواهای بعدی رو بهتر و قوی‌تر تهیه کنم البته تا یادم نرفته بگم که این رایتاپ تجربه شخصی خود من نیست و اون رو آقای Allam Rachid نوشته و من فقط از این آدرس برداشتمش و ترجه کردم براتون.