SOP Bypass Types

بایپس کردن SOP عمدتاً به دلیل پیچیدگی increasing document object model (DOM) و جاوا اسکریپت رایج شده است. سپس این با عملکردهای سمت سرور مانند تغییر مسیرها ترکیب می‌شود. اکثریت بای‌پس‌های SOP باگ‌های منطقی هستند، یعنی نتیجه یک سردرگمی منطقی یا عدم تطابق بین لایه‌ها و مؤلفه‌های مختلف در مرورگرها هستند. برای مثال، یک مؤلفه ممکن است یک Null-Byte را شناسایی کرده و اجرای یک کد را متوقف می کند، در حالی که دیگری انتخاب می کند که به طور کامل آن را نادیده بگیرد و کد را اجرا کند.

چندین بایپس SOP به مرورگرهای جداگانه محدود نمی شوند زیرا در اجزای مشترک وجود دارند و به طور بالقوه بر چندین مرورگر تأثیر می گذارند. به عنوان مثال، یک بایپس کردن در موتور رندر WebKit روی همه مرورگرهای ساخته شده در بالای یک موتور تأثیر می گذارد. به طور مشابه، بایپس کردن SOP موجود در افزونه هایی مانند جاوا می تواند به طور بالقوه بر همه مرورگرهایی که از این افزونه ها پشتیبانی می کنند تأثیر بگذارد.

چندین دسته از بای پس های SOP وجود دارد. با این حال، مشابه کار alو Schwenk(2017، ما آنها را به چهار نوع
مختلف تقسیم کرده ایم: partial read, full read, partial write, and full read and write. برای هر دسته، حملات بالقوه ای که در دسته های مربوطه قرار می گیرند نیز ذکر شده است.
@TryHackBox

SOP Bypass-CVE-2007-0981

بیایید یک مورد کلاسیک از یک بای پس SOP به دلیل عدم تطابق لایه را بررسی کنیم، که در نسخه های قدیمی فایرفاکس کشف شده و به عنوان CVE-2007-0981 ثبت شده است. بیایید نگاهی به POC بیندازیم:

POC

location.hostname="evil.com\x00www.bing.com "

@TryHackBox

جدول 1.6 دسته بندی های بای پس SOP

@TryHackBox

در این POC، ویژگی location.hostname روی evil.com تنظیم شده است، پس از آن یک null byte "\x00" و سپس bing.com تنظیم می شود. Null byte معمولاً به عنوان پایان دهنده های رشته ای در بسیاری از زبان های برنامه نویسی شناخته می شوند. با این حال، در این مورد، DOM، بخشی از موتور رندر، \x00 را به عنوان یک پایان دهنده رشته در نظر نمی گیرد. بنابراین، " evil.com \ x00www.bing.com " را به عنوان یک زیر دامنه از bing.com تفسیر می کند.


برعکس، حل‌کننده DNS که بخشی از لایه شبکه است، null byte را تشخیص می‌دهد، زیرا پایان‌دهنده رشته، اجرا را متوقف می‌کند و مبدا را به عنوان evil.com در نظر می‌گیرد، بدون توجه به بقیه رشته. در نتیجه، به مهاجم اجازه می‌دهد کوکی‌ها را برای bing.com و زیر دامنه‌های آن تنظیم، تغییر یا حذف کند.
@TryHackBox

شکل 1.9 عدم تطابق لایه ها بین DNS Resolver و DOM
@TryHackBox

شکل 1.10 عدم تطابق لایه ها بین resolver DNS و ذخیره کوکی.
@TryHackBox

SOP Bypass-CVE-2011-3246

نمونه مشابهی است و بر نسخه های قدیمی مرورگر سافاری تأثیر می گذارد. بای پس SOP یک مورد بسیار مشابه دیگر از سردرگمی منطقی و عدم تطابق لایه است. با این حال، این بار عدم تطابق بین بخش ذخیره کوکی لایه پایدار و حل‌کننده DNS از لایه شبکه است.

POC

<img src=" https://evil.com % 00.bing.com">

@TryHackBox

🖥 مخزن: Vuls – اسکنر آسیب پذیری

Vuls
یک اسکنر آسیب‌پذیری منبع باز برای Linux، FreeBSD، Container، WordPress، کتابخانه‌های زبان برنامه‌نویسی، دستگاه‌های شبکه است که در Go نوشته شده است.

- این ابزار تجزیه و تحلیل آسیب پذیری های نرم افزار نصب شده بر روی سیستم را خودکار می کند ، که انجام دستی در یک محیط تولید بسیار دشوار است.

https://github.com/future-architect/vuls?tab=readme-ov-file

#Web #Redteam #Recon
@TryHackBox

SITE ISOLATION

اکثر بای‌پس‌های SOP به دلیل منشأهای متفاوتی هستند که پروسس رندر یکسانی را به اشتراک می‌گذارند. این امر به ویژه در مورد قاب بندی بین سایتی و پاپ آپ رایج است. یک پروسس رندر مسئول مدیریت رندر است

شکل 1.11 isolation سایت.

منبع:
https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html

@TryHackBox

از صفحات وب این شامل قابلیت هایی مانند تجزیه HTML و CSS و اجرای جاوا اسکریپت است.
پیش از این، مرورگرها مبداهای مختلف را در پروسس های رندر جداگانه جدا نمی کردند. از این رو، هنگامی که یک بای پس SOP پیدا شد، به اسکریپت‌هایی از یک مبدا اجازه می‌دهد تا به طور بالقوه به داده‌هایی از مبدا دیگر در همان پروسس دسترسی داشته باشند.

در ایزوله سازی سایت، هر پروسس در پروسس رندر جداگانه خود که در سطح سیستم عامل مجزا شده است اجرا می شود. با ایزوله سازی سایت، حتی اگر یک بای پس SOP در پروسس رندر رخ دهد، دسترسی به داده‌های منبع متقابل بسیار چالش برانگیزتر است. نمودار زیر (شکل 1.11) نشان می‌دهد که evil.com چگونه bank.com را از طریق Iframe بارگیری می‌کند و چگونه یک صفحه وب منفرد بین دو پروسس رندر تقسیم می‌شود.

@TryHackBox

ADDRESS BAR SPOOFING BUGS

طبق گوگل [ https://bughunters.google.com/about/rules/6625378258649088google-and-alphabet-vulnerability-reward-program-vrp-rules ]، نوار آدرس تنها نشانگر امنیتی در مرورگرهای مدرن است که می توان به آن اعتماد کرد. این منطقی به نظر می رسد زیرا نوار آدرس راه اصلی برای کاربران برای تأیید اینکه آیا در وب سایت صحیح هستند یا خیر است.

فروشندگان مرورگر از این موضوع آگاه هستند و بنابراین کنترل های داخلی را برای اطمینان از مطابقت محتوای نمایش داده شده در مرورگر با URL موجود در نوار آدرس پیاده سازی کرده اند.

آسیب‌پذیری جعل آدرس بار زمانی رخ می‌دهد که  آدرس بار به دامنه صحیحی اشاره می‌کند که کاربر می‌خواهد از آن بازدید کند. با این حال، محتوای دامنه توسط مهاجم کنترل می شود. در زیر پوشش، آسیب‌پذیری‌های جعل مبتنی بر مرورگر با بهره‌برداری از نقص‌های مرورگر برای ایجاد این توهم که کاربران در دامنه قانونی هستند، اجرا می‌شوند. بیایید به چند مثال نگاهی بیندازیم:

@TryHackBox

Address Bar Spoofing
- مثال 1

در جاوا اسکریپت، چندین توابع به کاربران این امکان را می دهند که اجرای یک رویداد را به تاخیر بیاندازند یا یک رویداد را در فواصل زمانی منظم اجرا کنند. این روش ها قدرتمند هستند و می توان از آنها برای جستجوی آسیب پذیری های Address Bar Spoofing استفاده کرد. بیایید به نمونه ای از این تکنیک نگاه کنیم:

کد

<noscript>
w = window.open("www.facebook.com", "_blank");
setTimeout(function(){w.document.write("<html>This is
not Facebook</html>")},5000);
</noscript>

این اسکریپت وب سایت فیس بوک را در یک پنجره جدید با استفاده از عملکرد " window.open " باز می کند و سپس سعی می کند صفحه را با متن "This is not Facebook" با استفاده از document.write پس از پنج ثانیه تاخیر بازنویسی کند. اجرا با استفاده از آن به تاخیر می افتد. تابع "setTimeout". در طول این فرآیند، مرورگر ممکن است آدرس بار را به روز نکند، بنابراین در حالی که آدرس بار همچنان به facebook.com اشاره می کند، محتوای نمایش داده شده در واقع توسط مهاجم کنترل می شود. در اینجا نمونه ای از مرورگر Yandex (CVE(2020-7369)) است که آدرس بار را با استفاده از همان تکنیک حفظ می کند.
@TryHackBox

Address Bar Spoofing

مثال 2

یکی دیگر از تکنیک‌های راه‌اندازی address bar spoofing، استفاده از یک پورت ناموجود برای حفظ آدرس بار همراه با استفاده از توابع زمان‌بندی جاوا اسکریپت برای ایجاد تاخیرهای مناسب است. بیایید به نمونه ای از این تکنیک نگاه کنیم:

کد

function spoof(){
document.write("<h1>This is not Bing</h1>");

@TryHackBox

شکل 1.12 جعل نوار آدرس یا همون آدرس بار مرورگر Yandex.

@TryHackBox

document.location = "https://bing.com:1234";
setInterval(function(){document.location="https:// bing.com:1234";},9800);
};



این اسکریپت از تابع document.location برای هدایت کاربر به " https://bing.com " در یک پورت غیر استاندارد، "1234" استفاده می کند. بسته به مرورگر، زمانی طول می کشد تا در نهایت خطای توقف اتصال را بازگردانید، زیرا هیچ سرویسی در این پورت اجرا نمی شود. در طول این بازه زمانی، زمانی که مرورگر تلاش می‌کند تا « https://bing.com:1234 » را بارگیری کند، تابع setInterval به طور مکرر فراخوانی می‌شود، که باعث هدایت مجدد به URL می‌شود، بنابراین پروسس در فواصل زمانی مشخص بازیابی می‌شود.

این پروسس URL جعلی را در نوار آدرس حفظ می کند و در عین حال به مهاجمان اجازه می دهد محتوای صفحه وب را تغییر دهند. این پس از هر بازه زمانی مشخص اجرا می شود، بنابراین URL در پروسس حفظ می شود، در حالی که به مهاجمان اجازه می دهد محتوا را در سند بنویسند که منجر به جعل نوار آدرس می شود. در حالت ایده آل، رفتار صحیح برای مرورگر این است که وقتی تابع setInterval برای تغییر مسیر فراخوانی می شود، به "about: blank" تغییر مسیر دهد.

از همان POC برای ایجاد آسیب‌پذیری‌های جعل نوار آدرس در مرورگرهای سافاری چندین بار به همراه سایر مرورگرهای محبوب مانند Microsoft Edge و DuckDuckGo استفاده شده است. جالب اینجاست که مرورگر سافاری پورت را مخفی می‌کند و از این رو تنها URL قابل مشاهده برای کاربر، bing.com است.

@TryHackBox

ورکشاپ تست نفوذ لایو ازصفر تا صد برروی یک اپلیکیشن اندرویدی واقعی! به تدریس مهندس میثم منصف

@TryHackBox

👾 CVE PoC

• قبلاً سرویس های مختلف از نام های متفاوتی برای نشان دادن آسیب پذیری های یکسان استفاده می کردند. برای از بین بردن سردرگمی با نام آسیب‌پذیری‌ها، MITER راه‌حلی را پیشنهاد کرده است که مستقل از فروشندگان مختلف ابزار تشخیص آسیب‌پذیری است. این راه حل به عنوان پایگاه داده آسیب پذیری و قرار گرفتن در معرض مشترک CVE پیاده سازی شد. این راه حل به همه متخصصان و تولید کنندگان اجازه می داد که به یک زبان صحبت کنند. در این پایگاه داده، برای هر آسیب‌پذیری، از ویژگی رکورد زیر استفاده می‌شود: CVE- YYYY-NNNN ، که در آن YYYY سال کشف آسیب‌پذیری است و NNNN شماره سریال آن است.

• اگر سوالی دارید ، "این CVE های شما از کجا می آیند؟" سپس پاسخ این است: بیایید تصور کنیم که آسیب پذیری دیگری پیدا کرده اید و می خواهید در مورد آن به تمام دنیا بگویید. برای انجام این کار، باید فرم خاصی را در وب سایت miter پر کنید. و در واقع این همه چیز است)) https://www.cve.org/ResourcesSupport/FAQs

• اما نکته پست کمی متفاوت است. امروز پیشنهاد می‌کنم یک مخزن بسیار مفید را بررسی کنید، که تقریباً همه CVE‌ها را از سال 1999 شامل می‌شود، مرتب‌سازی راحت (بر اساس سال) وجود دارد و به‌روزرسانی‌های روزانه وجود دارد: https://github.com/trickest/cve . امیدوارم خیلی مفید باشه...
@TryHackBox