⭕️ بایپس جزئی 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

⭕️ Bypass Ban Time in Password Brute Force

در این سناریو هانتر زمانی که به Brute Force کردن فانکشن لاگین پرداخته به مدت 20 دقیقه محدودیت ارسال درخواست لاگین گرفته.
بعد به بررسی درخواست های Burp Suite میپردازه و سپس با اندپوینتی مواجه میشه که وقتی بازش میکنه اونجا لینکی مبنی بر Send password reset link میبینه و روش کلیک میکنه و وارد حسابش میشه و در واقع موفق به دورزدن Ban Time میشه.

https://medium.com/p/c3837e6bb8ed
#web_security
کانال آموزش کامپیوتر
@Engineer_computer

⭕️ Telegram bug bounties | RCE, privacy issues, and more…

تو این مقاله محقق از آسیب پذیری هایی که روی تلگرام پیدا کرده میگه. آسیب پذیری هایی مثل RCE روی WebView , افشای IP کاربر در تلگرام وب و ...


https://davtur19.medium.com/telegram-bug-bounties-rce-privacy-issues-and-more-b1f06a641c1b

#web_security #rce
@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

⚙️ Optimize Web Fuzzing

۲ تا نکته برای بهنیه کردن Fuzzing در وب سرور و API:

۱. نکته اول Fuzz کردن مسیر های 403:
اگر برای مثال به روت وب سروری درخواست زدید و به شما 403 داد بیاید به یک مسیر یونیک که مطمئن هستید وجود نداره درخواست بزنید مثلا:
/uniquePathUnique
اگر این مسیر هم به شما 403 داد Fuzz کردن رو این وب سرور میتونه کار بیهوده ای باشه:‌ چون ادمین ممکن هست وب سرور رو به پشت VPN منتقل کرده باشه یا هر مسیری رو ممنوع کرده باشه
اگر قصد دارید فازینگ شما بهینه باشه و کمبود زمان و منابع دارید این نوع تارگت هارو بیخیال بشید یا در اولویت پایین تری برای Fuzz بذارید.


۲. نکته دوم Fuzz کردن مسیر در API:
در وب سرور ها مثل Apache اگر به دایرکتوری موجودی درخواست بزنید برای مثال دایرکتوری files/ ماژول mod_dir شمارو به /files/ ریدایرکت میکنه. این ماژول کارش trailing slash redirect هست یعنی یه / به آخر اسم دایرکتوری اضافه میکنه و دایرکتوری رو برای شما serve میکنه. به / آخر trailing slash میگیم.

اما در API ها به این گونه نیست عموما. در API دو مسیر زیر
/auth/login/
/auth/login
میتونند دو اندپوینت کاملا متفاوت از هم باشند و دو function جدا از هم یا اگر فانکشن لاگین در /auth/login/ باشد و شما به auth/login/ درخواست بزنید ممکن است 404 بگیرید.

این موضوع قابل کنترل هم هست برای مثال فریمورک flask در حالت عادی مثل سناریو بالا عمل میکنه اما اگر ما مقدار strict_slashes رو در Routing برابر False قرار بدیم مثل زیر
@app.route('/auth/login/', strict_slashes=False)
تفاوتی بین /auth/login/ و auth/login/ نخواهد بود.

برای بهینه سازی Fuzzing در اینجا شما باید اندپوینت های موجود رو Analyze کنید و مشاهده کنید برنامه نویس از کدوم style برای مسیر دهی استفاده کرده مثلا اگر تمام اندپوینت های API با trailing slash تمام می شوند شما نیز در Fuzzing خود از trailing slash استفاده کنید و اگر تمام اندپوینت ها بدون / تمام می شوند شما هم از trailing slash استفاده نکنید.

#web_security #fuzzing #API
@Engineer_Computer

تو پروسه آموزش و یاددادن همیشه کلی چیز برای یادگیری هست✌️🏻
دارم یه اپ Vue آسیب پذیر آماده میکنم برای آموزش XSS in Vue.js بعد متوجه شدم این XSS ای که از طریق javascript scheme تو attribute href رخ میده زمانی که اتریبیوت target برابر blank_ باشه دیگ آسیب پذیر نیست
مثالش تو عکس بالا

#AppSec #XSS #web_security
@Engineer_Computer

🐞 What's security flaws with this code? How to fix it?
نقص امنیتی این کد چیه؟ اصلا نقص امنیتی داره؟ چنتا و به چه صورت؟‌ نحوه فیکس کردنش به چه صورت هست؟

#AppSec #code_challenge #vulnerable_code #web_security #FastAPI
@Engineer_Computer

Now the answer
مهم ترین آسیب پذیری ای که داشت و اکثرا دوستان هم گفتن Mass Assignment بود که میشد ما با role ای مثل admin برای خودمون account بسازیم که حالا توی fix فیلد های مهم رو صرف نظر از چیزی که کاربر میده ما تغییر میدیم، موضوع بعدی هم Insecure Password Storage بود که حالا پسورد hash میشه.

#AppSec #code_challenge #fixed_code #web_security #FastAPI
@Engineer_Computer