⭕️Microsoft Exchange: OWASSRF + TabShell
(CVE-2022-41076)

The TabShell vulnerability its a form of Privilege Escalation which allows breaking out of the restricted Powershell Sandbox after you have successfully gained access through OWASSRF.

For a detailed write see research:
https://blog.viettelcybersecurity.com/tabshell-owassrf/

PoC:
https://gist.github.com/testanull/518871a2e2057caa2bc9c6ae6634103e

#owa #ssrf #tabshell #poc
کانال آموزش کامپیوتر
@Engineer_Computer

⭕️ دور زدن SSRF Protection از طریق Cross Protocol Redirect

یکی از راه هایی که حتما میدونید برای دور زدن SSRF Protection و دستیابی به internal asset مثل localhost و ... این هست که ما redirect انجام بدیم. برای مثال آدرس URL ای به اپ میدیم که تحت کنترل ماست و اون درخواست http رو ریدایرکت میکنه به یه asset inernal

محقق طی یه پروژه با تارگتی روبه رو میشه که هیچگونه جلوگیری ای برای ssrf نداشته و بعد از گزارش برنامه نویس از لایببری ssrf-req-filter توی node.js استفاده میکنه و محقق هنگام اولین retest متوجه میشه آسیب پذیری پچ شده اما زمانی که محقق Cross-Protocol Redirect رو تست میکنه دوباره با موفقیت به اون asset internal دسترسی میگیره

اما Cross-Protocol Redirect چیه؟ منظور اینه که پروتکل از http به https هنگام ریدایرکت تغییر پیدا کنه یا برعکس
در اینجا محقق URL ابتدایی که به App داده پروتکل https داشته اما در ریدایرکت گفته که به localhost ریدایرکت صورت بگیره روی پروتکل http
https://example.com/?redirect=https://localhost

اما چرا این اتفاق میفته؟ به طور خلاصه ما کد JS شبیه به کد زیر رو داریم که از ssrf جلوگیری کنه
request({
    uri: url,
    agent: ssrfFilter(url),
});
اما در لایبرری request در قسمت lib/redirect.js ما یه شرط جالب داریم:
if (request.uri.protocol !== uriPrev.protocol) {
  delete request.agent
}
بازم هم به طور خیلی خلاصه بخوام بگم این شرط بررسی میکنه که اگر هنگام ریدایرکت تغییر پروتکل داشتیم request.agent حذف بشه که در این کیس ما باعث میشه ssrf filter ای نداشته باشیم (‌ چون خود متد ssrfFilter اگر دقت کنید در قسمت agent کال شده)

https://blog.doyensec.com/2023/03/16/ssrf-remediation-bypass.html

#web_security #ssrf
@Engineer_Computer

#Unpatched #Powerful #SSRF in #Exchange
اخیرا یک آسیب پذیری از مایکروسافت Exchange مطرح شده که محقق اعلام میکنه، مایکروسافت آسیب پذیری SSRF کشف شده رو در سطح حساسیت بالا نمیدونه و اصلاح نمیکند.

آسیب پذیری در Attachment ایجاد ایمیل است که با تابع CreateAttachmentFromUri فعال شده و از Methods های Exchange OWAService استفاده میکند.

در تابع CreateAttachmentFromUri یک Initialize برای تماس با Execute method پیاده سازی میشود که تماسی با تابع InternalExecute گرفته خواهد شد.

در این تابع یک تماس با CreateAttachmentFromUri.DownloadAndAttachFileFromUri گرفته میشود و پارامتر های uri ، name ، subscriptionId و غیره به آن پاس داده میشود که ورودی uri برای مهاجم مهم است.

نهایتا در asynchronous task یک پیاده سازی از کلاس HttpClient ساخته میشود، بعد uri پاس داده شده مهاجم در httpResponseMessage ریخته شده و در نهایت در تابع CreateAttachmentAndSendPendingGetNotification داده دریافتی از Get HTTP به عنوان یک Pending Notification ایجاد خواهد شد.

@Engineer_Computer