⭕ تصاحب حساب کاربری

تو این مقاله یک تکنیک جالب بایپس 403 در API بررسی میشه
اندپوینت زیر در صورت ارسال درخواست کد 403 میده و میگه دسترسی ندارید
POST /<organizationID>/addEmail/<DemoUserID>/
تست نفوذگر اینجا با یک تکنیک ساده از traversal sequence استفاده کرده و در ادامه اش از UserID قربانی استفاده کرده
POST /<organizationID>/addEmail/<DemoUserID>/../<UserID>/

و در اینجا کد 200 گرفته و با موفقیت ایمیل قربانی رو تغییر داده

لینک مقاله:
https://gonzxph.medium.com/account-takeover-worth-of-2500-e643661f94e9

تحلیل:‌ به نظر میاد برنامه نویس اینجا اومده Requests URI رو گرفته و  چک کرده که آیا DemoUserID در organization وجود داره یا خیر؟ اگر وجود نداشت به کاربر بگه که شما دسترسی این کار رو ندارید و اگر وجود داشت بنظر میاد این درخواست برای سرویس دیگه ای که مسئول تغییر ایمیل بوده ارسال شده
در اینجا ما ۲ تا زبان مختلف پایتون و php رو در مواجه با این موضوع تست کردیم تا ببینم رفتار این ها با traversal sequence به چه صورت هست؟(‌ traversal sequence هم همون /.. هست). و آیا path normalization دارند؟ ( یعنی فانکشن با لایبرری بیاد traversal sequence هارو apply‌ کنه و مسیر یا path به اصطلاح normalize بشه
لینک مرتبط با path normalization اگر خواستید مطالعه کنید
https://en.wikipedia.org/wiki/URI_normalization

در اینجا یک سرور apache بالا آوردیم و بهش درخواست ارسال کردیم
درخواست اول با پایتون به این صورت
import requests
requests.get("https://server/a/b/../c")
درخواست دوم با php به این صورت
file_get_contents("https://server/a/b/../c");

نتایج جالب بود
لاگ سرور آپاچی:
"GET /a/c HTTP/1.1" 404 492 "-" "python-requests/2.28.1"
"GET /a/b/../c HTTP/1.1" 404 455 "-" "-"

این یعنی لایبرری requests پایتون اینجا path normalization رو اپلای کرده و php این کار رو نکرده
این تست هایی که انجام دادیم صرفا نشان دهنده این هستند که رفتار زبان و لایبرری و فریمورک های مختلف فرق میکنه.
حالا برگردیم به آسیب پذیری ای که داشتیم توضیحش میدادیم

گفتیم بعد از بررسی request uri برنامه نویس میاد این رو به سرویس دیگه ای ارسال میکنه حالا اگر این ارسال کردن با زبانی یا لایبرری اتفاق بیفته که path normalization انجام بده آسیب پذیری وجود داره و اگر انجام نده آسیب پذیری وجود نداره.

این ها صرفا یک فرض بود و ممکنه موضوع به طور کل چیز دیگه ای باشه ولی خب ما نیاز داشتیم یکم دیپ بشیم و ببینم موضوع از چه قرار هست

#ATO #bypass403
کانال آموزش کامپیوتر
@Engineer_Computer

⭕️ بایپس جزئی rate limit در Login AWS Console

محققی از آزمایشگاه امنیتی datadog اومده و بر روی فانکشن authentication در AWS Console کار کرده. بهتر هست بگیم روی متد IAM user در بخش sign in کار کرده.
اگر به طور خلاصه و ساده بخوام بگم IAM user چی هست ابتدا باید بگم که وقتی شما یک اکانت AWS میسازید یه کاربر root به شما داده میشه. بقیه یوزر ها مثل IAM users یا AWS IAM Identity Center users توسط این اکانت روت ساخته میشن.
(مرجع)

این فانکشن طبیعتا از rate limit برخوردا بوده و هنگام authenticate درخواست http زیر رو به سرور ارسال میکرده:
POST /authenticate HTTP/2
Host: signin.aws.amazon.com
Content-Length: 257
Content-Type: application/x-www-form-urlencoded
Origin: https://signin.aws.amazon.com

action=iam-user-authentication
&account=884527801452
&username=christophe
&password=<your-password>
&client_id=arn%3Aaws%3Asignin%3A%3A%3Aconsole%2Fcanvas
&redirect_uri=https%3A%2F%2Fus-east-1.console.aws.amazon.com%2Fconsole
اگر credential داده شده نادرست بودند پاسخ زیر
{
"state": "FAIL",
"properties": {
"result": "FAILURE",
"text": "Your authentication information is incorrect. Please try again."
}
}
و اگر درست بودند پاسخ زیر به کاربر نمایش داده میشد:
{
"state": "SUCCESS",
"properties": {
"result": "SUCCESS",
"redirectUrl": "https://us-east-1.console.aws.amazon.com/console?code\u003<token>"
}
}
همچنین در صورتی که تعداد درخواست های ارسال از حد مجاز میگذشت اپلیکیشن پیام زیر رو به کاربر نمایش میداده:
Failed attempt for password batman: 'Too many invalid passwords have been used to attempt to sign-in to this account. Please wait 4 seconds before your next attempt.'
محقق بعد از ارسال ۳۰ درخواست auth پشت سر هم که invalid credentials رو شامل میشده برای ۴ ثانیه از ارسال درخواست auth منع شده. تنها کاری که محقق انجام داده در اسکریپت brute force اش یک فانکشن sleep ساده بوده که در صورت برخورد با محدودیت به مدت 5 ثانیه هیچ درخواستی ارسال نشه و بعد از 5 ثانیه ارسال درخواست از سرگیری بشه.
همچنین اسکریپت بروت فورس اش رو باز نویسی کرده با 30 thread parallel این کار رو انجام داده که در نهایت منجر به ارسال 280 درخواست بر دقیقه یا بهتر هست بگیم 4.6 درخواست بر ثانیه شده.

در نهایت این موضوع و brute force کردن حساب کاربر در صورتی که top password داشته باشه و همچنین 2fa حساب کاربر فعال نبوده باشه،‌ میتونسته باعث تصاحب حساب کاربری بشه.

کاری که AWS Team برای جلوگیری انجام داده افزایش و سفت و سخت تر کردن rate limit هست.
طبیعتا اگر ما میخواستیم این جلوگیری رو انجام بدیم این کار هارو میتونستیم کنیم:
1) اضافه کردن محدودیت زمانی rate limit به طور افزایشی یعنی بار اول اگر 4 ثانیه هست بار دوم 8 ثانیه و بار سوم 12 ثانیه و ...
2) پیاده سازی مکانیزم Capctha به طور امن
3) مسدود کردن IP بعد از X بار تلاش نادرست ( این مسدود کردن باید موقتی باشه و نمیتونه دائمی باشه اصولا)
4) قفل کردن یا Lock کردن حسابی که داره brute force بر روش صورت میگیره:‌ حالا قابلیت unlock کردن اون حساب میتونه از یه چنل دیگه مثل email یا phone صورت بگیره.

لینک مقاله برای مطالعه:
https://securitylabs.datadoghq.com/articles/aws-console-rate-limit-bypass/

#bruteforce #web_security #rate_limit #ATO #AWS
کانال آموزش کامپیوتر
@Engineer_Computer

⭕️ Bypassing Single Sign On via login without password feature | 0 Click account takeover

در این مقاله،‌ هانتر موفق به دور زدن Single Sign On با استفاده از ویژگی لاگین بدون استفاده از پسورد شده است.
این قابلیت با ارسال کردن OTP به ایمیل کاربر صورت می پذیرد.
در این اپلیکیشن قابلیت لینک کردن تعدادی اکانت به یک ایمیل وجود داشت. در قابلیت لاگین بدون پسورد ابتدا شما باید ایمیل خودتون رو وارد میکردید سپس اپلیکیشن لیست حساب های موجود و لینک شده به ایمیل را به شما نشان می دهد. و با کلیک کردن بر روی دکمه Login without password رو به روی حساب به حساب مدنظر لاگین صورت میگرفت.
درخواست زیر برای تایید OTP و لاگین اکانت مورد نظر به سمت سرور ارسال می شود

POST /api/sso/login-without-password/auth HTTP/2

{"track":006,"action":"login-without-password","code":"[OTP]","token":"22123w2DS4543jg23324e35SD==","username":"attacker1"}
همونطور که مشاهده میکنید پارامتری به نام username در اینجا استفاده شده است. که دلیل استفاده از این پارامتر قبل تر توضیح داده شده است ( هر ایمیل ممکن است چند اکانت متصل شده و username را دارا باشد)
در اینجا هانتر با تغییر مقدار پارامتر username به username قربانی ( شخصی که حسابش به ایمیل اتکر لینک نشده است) قادر به تصاحب حساب کاربری وی شده است.

در این فیچر توسعه دهنده، عمل بررسی اینکه آیا نام کاربری به ایمیل مدنظر لینک شده است یا نه را انجام نداده و این در نهایت موجب آسیب پذیری Account Takeover شده است.

لینک مقاله:
https://aidilarf.medium.com/bypassing-sso-authentication-from-the-login-without-password-feature-lead-to-account-takeover-d2322a33a208

#web_security #ATO #SSO
کانال آموزش کامپیوتر
@Engineer_Computer