✏️ مقاله تالیف شده
Performing an IoT Pentest

📚برخی از سرفصل ها
📗چالش‌های ویژه در IoT Pentest و Structuring the Pentest in IoT
📕بررسی Embedded Devices در معماری IoT و اهمیت Firmware در IoT
❄️بررسی آسیب‌پذیری‌ها و تهدیدات رایج

⭐️ @RadvanSec

New Video: Broken Access Control (New Pattern)

For the first time, a Broken Access Control scenario that hasn’t been discussed anywhere before.
Not a recycled bug. Not a typical misconfiguration.
A new logic flaw that changes how access control issues can be analyzed and chained. 🔥

This video explains the idea and mindset behind it.

🎥 Watch on YouTube:
https://youtu.be/X3oj-nx6580

دوستانی که پیگیر حل چلنج اخر هستند لینک حل یوتیوب رو قرار دادیم لطفا دقت کنید با تشکر

ضمنا چلنج تقریبا ۸۰ درصد بر اساس سناریو real-world بود

و کلا سه نفر موفق شدند حل کنند✌️

From Traditional Pentesting to AI Red Teaming

After OSCP+ and CPTS, I felt the security landscape shifting.
So I dove into AI security. Here's what I discovered.

🎓 C-AI/MLPEN (Certified AI/ML Pentester)
Prompt injection, jailbreaks, model manipulation, AI-specific attack vectors.
What surprised me most? How many traditional pentesting concepts translate directly.
Trust boundaries. Input validation failures. Implicit assumptions.
Same problems, new context.

🧠 Jason Haddix's AI Security Training
"Attacking AI" and "Red Blue Purple AI" filled the gaps.
Real-world scenarios. Current attack research. Practical methodology.

🔬 Hands-On: Real AI Security Projects

🔴 Indirect Prompt Injection Attacks
- Exploited AI agents via blog comments & social media profiles
- 100% success rate - agents executed hidden instructions
- Key finding: AI agents inherit trust from their environment

🧪 AI Agent Testing Framework
- Built pytest test suites validating AI agent behavior
- Created prompt difficulty calibration (100% vs 37.5% success rates)
- Same task, different prompts = dramatically different agent behavior

💡 The Key Insight
AI agents don't verify - they obey.
An attacker doesn't need to attack the model directly.
Just poison what it consumes.

Traditional offensive security skills transfer directly.
We've been exploiting trust assumptions for years.
AI is just another attack surface.

💬 Have you started exploring AI red teaming? What's your biggest challenge?

#AIRedTeam #LLMSecurity #PromptInjection #CyberSecurity #OSCP #CPTS #OffensiveSecurity

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

بهتون اولین کتابی که میتونم معرفی کنم در این زمینه ارزش خوندن داشته باشه و برای شروع درک و مفهوم استراکچر هوش مصنوعی و نحوه ی معماری دیتا بخونید و حدااقل یه چیزایی درموردش بدونید کتاب
Artificial Intelligence Modern Approach
هست

نکته بعدی اینکه دوره هایی که سر و ته ندارن رو هم شرکت نکنید الان کم کم داره این اتفاق میافته یکسری ها هم موج سواری میکنن به هرچیزی کلمه ai میچسبونن و به اسم مسیر و حوزه جدید ارائه میکنن و بابت دوره هاشون هزینه های هنگفتی میگیرن شما قبل از اینکه دوره شرکت کنی (نه هر دوره ای!) حدااقل پایه و بیس رو بلد باش و بعد دوره شرکت کن تا بتونی عملی یکسری چیزارو متوجهشون بشی و البته همزمان مطالعه روزانه فراموش نباید بشه و حتما مطالعه روزانه باید روتین زندگیتون بشه در هر حوزه ای که هستید…
اگر شما متمرکز رو یک حوزه باشید خوبه ولی اگر از حوزه های دیگه هم چیزایی یاد بگیرید یکسری اوقات تو ذهنتون یه جرقه هایی میاد که باعث میشه بتونید دوتا حوزه که در ظاهر هیچ ربطی بهم ندارند شما بهم مربوطش کنید اینطوری میشید یک انسان متفکر و خلاق و ایده های نیچ هم از همین جاها میاد که میتونه گاهی اوقات دنیارو تغییر بده

در کل هرچیزی که به ذهنتون اومد و احمقانه بنظر میرسید و حتی اگر همه شمارو تمسخر کردند مطمن باشید اون بهترین فکره (در شرایط خاص)

🧠 تحلیل تخصصی CVE-2025-14847 – «MongoBleed»: افشای حافظه در MongoDB

📌 شناسه آسیب‌پذیری: CVE-2025-14847
📌 نام غیررسمی: MongoBleed
📌 CVSS: ~8.7 (High/High-Severity)
The Hacker News

📌 وضعیت احراز هویت: بدون نیاز به احراز هویت (Pre-auth)
The Hacker News

🧩 ماهیت فنی آسیب‌پذیری

این نقص در لایه‌ی فشرده‌سازی/دکمپرسیون پیام‌های پروتکل شبکه MongoDB قرار دارد و ناشی از مدیریت نادرست طول داده‌های فشرده‌شده با zlib است.

در پروتکل MongoDB، پیام‌های شبکه‌ای می‌توانند با الگوریتم‌های فشرده‌سازی ارسال شوند. نقص زمانی رخ می‌دهد که فیلد طول ادعایی (uncompressedSize) در هدر پیامِ فشرده با مقدار واقعی داده همخوانی ندارد. سرور بر اساس این مقدار ادعایی بافرهایی اختصاص می‌دهد، اما داده‌های دکمپرش شده واقعی کوتاه‌تر هستند. به‌دلیل مدیریت نادرست، بخش‌های حافظه‌ی heap مقداردهی‌نشده در پاسخ جای می‌گیرند و به‌صورت ناقص به کلاینت ارسال می‌شوند.
The Hacker News

این رخداد امکان افشای بخش‌های تصادفی حافظه سرور را به مهاجم فراهم می‌کند حتی بدون داشتن credential یا session معتبر.

🧪 سازوکار اثبات مفهوم (PoC)

PoCهای اولیه به این صورت عمل می‌کنند:

ارسال بسته‌های zlib با هدرهای دارای مقدار طول غیرمنطقی (یعنی طول واقعی کوچکتر از چیزی که هدر گزارش می‌دهد).

سرور بافر بزرگتری تخصیص می‌دهد و سپس عمل دکمپرسیون انجام می‌شود.

بخش‌های “مقداردهی‌نشده” حافظه که هنوز پاک نشده‌اند، در پاسخ ارسال می‌شوند.

با پروب‌های متعدد می‌توان بخش‌های مختلف حافظه را بیرون کشید.

داده‌هایی مانند پیکربندی WiredTiger، آدرس‌های اتصال، و داده‌های موقت ممکن است لو بروند.
Cyber Security News

این روند از نظر مفهومی شبیه Heartbleed (که در OpenSSL رخ داد) است: هر دو مورد منجر به افشای تصادفی بخش‌هایی از حافظه‌ی پروسه می‌شود.

🎯 دامنه‌ی تأثیر

آسیب‌پذیری در نسخه‌های متعددی از MongoDB وجود دارد:

نسخه‌های آسیب‌پذیر

MongoDB 8.2.0 – 8.2.2

MongoDB 8.0.0 – 8.0.16

MongoDB 7.0.0 – 7.0.26

MongoDB 6.0.0 – 6.0.26

MongoDB 5.0.0 – 5.0.31

MongoDB 4.4.0 – 4.4.29

MongoDB تمام نسخه‌های 4.2, 4.0, 3.6
The Hacker News

توجه: برخی مستندات نیز اشاره دارند که تحت شرایط خاص و ترکیب با سایر نقص‌ها، ممکن است امکان RCE یا حملات زنجیره‌ای فراهم شود، اگرچه در تحلیل رسمی MongoDB تمرکز بر افشای حافظه بوده است.

Exploit

⭐️ @RadvanSec

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

ملاحظات کلیدی HTTP/1.1 (Idempotency، Pipelining، Retry و TCP Close)

در HTTP/1.1 مفهوم Idempotency نقش محوری در طراحی امن کلاینت‌ها و API ها دارد یک درخواست Idempotent در صورت اجرای چند باره وضعیت نهایی سیستم را تغییر نمیدهد. متدهای GET، HEAD، PUT، DELETE، OPTIONS و TRACE در این دسته قرار می‌گیرند، در حالی که POST ذاتاا Non-Idempotent است و تکرار آن می‌تواند منجر به ایجاد چند باره منبع، ثبت تراکنش تکراری یا تغییرات غیرقابل بازگشت شود که threat modeling میشه Race-Condition

به همین دلیل، اگرچه HTTP/1.1 از Request Pipelining پشتیبانی می‌کند، این قابلیت فقط برای درخواست‌های Idempotent (خودتوان) ایمن است
در Pipelining، چند درخواست بدون انتظار برای پاسخ قبلی ارسال می‌شوند. اگر Transport Connection پیش از دریافت پاسخ قطع شود، کلاینت نمی‌تواند تشخیص دهد که یک درخواست Non-Idempotent اجرا شده، اجرا نشده یا به‌صورت ناقص اجرا شده است. تکرار چنین درخواستی می‌تواند باعث Double Charge، Duplicate Order یا Data Corruption شود (Race-Condition Exploit) بنابراین درخواست ‌های Non-Idempotent مانند POST نباید Pipeline شوند

همین منطق در مورد Retry نیز صادق است. در صورت قطع ناگهانی اتصال، درخواست‌های Idempotent می‌توانند به‌ طور خودکار دوباره ارسال شوند، اما Non-Idempotent Request ها نباید Auto-Retry شوند. به همین علت User Agent ها تصمیم به تکرار POST را به کاربر انسانی واگذار می‌کنند؛ نمونه شناخته ‌شده آن هشدار مرورگر هنگام Refresh صفحه‌ای است که با POST ایجاد شده است.

در سطح پایین‌تر، موضوع Graceful Connection Close در TCP مطرح می‌ شود. اتصال TCP دوطرفه است و شامل کانال ارسال و دریافت مستقل است. فراخوانی close() هر دو کانال را می بندد (Full Close)، اما با shutdown() می‌توان فقط یکی از کانال ‌ها را بست (Half Close)
الگوی رایج این است که کلاینت پس از پایان ارسال درخواست، کانال خروجی را می‌ بندد ولی کانال ورودی را برای دریافت پاسخ کامل باز نگه می‌دارد. پیاده‌ سازی نادرست این رفتار می‌تواند باعث پاسخ ناقص، وضعیت نامشخص درخواست و تکرار ناخواسته عملیات شود.

جمع‌بندی: POST یک متد Non-Idempotent است، نباید Pipeline یا Auto-Retry شود، قطع ناگهانی TCP منبع رایج Race Condition و Logic Bug است، و مدیریت نادرست Half/Full Close می‌تواند به تکرار تراکنش یا خرابی وضعیت منجر شود. این‌ ها دقیقا همان نقاطی هستند که در پیاده‌سازی‌های ضعیف API و Proxy ها باگ‌ های سطح بالا از آن‌ها استخراج می‌شود

⭐️ @RadvanSec

CVE-2025-6023

Grafana Bypass :
https://blog.ethiack.com/blog/grafana-cve-2025-6023-bypass-a-technical-deep-dive

⭐️ @RadvanSec