Forwarded from کانال بایت امن
——
——
_
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍1
⭕️ برای دور زدن Elastic EDR در فرآیند Lateral Movement، مهاجم باید زنجیرهای از تکنیکهای پنهانسازی را به کار بگیرد. ابتدا برای انتقال فایل از طریق SMB، باید Magic Bytes لودر تغییر یابد و فایل با پسوند غیرحساسی مانند .png منتقل شود تا هشدارهای اولیه صادر نگردد. در مرحله بعد، به جای تغییر نام به
علاوه بر این، استفاده از مسیرهای استثنا شده (Exclusion) مانند
#RedTeam #Evasion
@securation
.exe که مشکوک است، از پسوند .scr (فایل اسکرینسیور) استفاده میشود که در ویندوز ماهیت اجرایی دارد اما اغلب قوانین شناسایی را دور میزند. همچنین، به جای پروتکل WMI که به شدت مانیتور میشود، تکنیک scshell برای اجرای راه دور از طریق سرویسهای ویندوز به کار گرفته میشود تا از شناسایی فعالیتهای مشکوک جلوگیری شود.علاوه بر این، استفاده از مسیرهای استثنا شده (Exclusion) مانند
C:\ProgramData\Microsoft\Search نقشی حیاتی دارد، زیرا اجرای فایل از این پوشهها باعث میشود EDR هشداری صادر نکند. برای نهایی کردن حمله و تغییر پسوند در سیستم مقصد نیز، به جای روشهای معمول که باعث ایجاد فرآیندهای مشکوک میشوند، از یک Unmanaged PowerShell Runspace در داخل فرآیند قانونی msiexec.exe استفاده میشود. این رویکرد باعث میشود بارگذاری DLL های اتوماسیون کاملا عادی به نظر برسد و در نهایت اتصال Beacon بدون فعال شدن هشدارهای امنیتی برقرار گردد.#RedTeam #Evasion
@securation
Medium
Bypassing Elastic EDR to Perform Lateral Movement
So, I have just recently started playing around with EDRs. As this would have been my first time testing an EDR, I wanted an open-source…
❤13👍2
⭕️ افتا: هشدار باش سایبری
۱۴۰۴/۱۲/۹
🔴 با توجه به شرایط فعلی کشور ضروری است اقدامات زیر انجام و هرگونه رخداد سایبری مشکوک، سریعا به مرکز افتا اعلام شود:
🔻 1. در دسترس بودن متولیان فنی سایبری و پیمانکاران سامانههای حیاتی برای مقابله با حوادث احتمالی
🔻 2.قطع فیزیکی تمامی پورتهای مدیریتی از جمله ILO و IPMI و مدیریت ذخیرهسازها (Storage)
🔻 3.حصول اطمینان از جداسازی فیزیکی شبکه مدیریتی تجهیزات (OOB) از سایر شبکهها
🔻 4.قطع هرگونه دسترسی از راه دور و دسترسیهای غیر ضروری به سامانهها، تجهیزات و سرویسهای حیاتی
🔻 5.حصول اطمینان از جداسازی شبکه های OT از سایر شبکهها
🔻 6.ممنوعیت نصب هر نوع سامانه یا تجهیز جدید و یا هرگونه اقدام نگهداری و بهروزرسانی بر روی سامانهها و تجهیزات موجود
🔻 7.حصول اطمینان از تغییر رمز عبور کاربران در سطح مدیریتی برای سامانهها و تجهیزات فناوری و صنعتی
🔻 8.شناسایی و حذف حسابهای کاربری غیرضروری در سامانهها، تجهیزات و سرویسهای حیاتی
🔻 9.بروز بودن، صحت و اطمینان از نگهداری نسخههای پشتیبان در خارج از سازمان
🔻 10.حصول اطمینان از ذخیره مطمئن و متمرکز انواع لاگهای امنیتی
🔻 11.هر گونه تماس یا ارسال پیامک از سرشمارههای ناشناس، No Number و یا Private برای اقدام بر روی سامانهها و زیرساخت مورد تایید نیست و نیاز به اخذ تاییدیه از مرکز افتاست.
@securation
۱۴۰۴/۱۲/۹
🔴 با توجه به شرایط فعلی کشور ضروری است اقدامات زیر انجام و هرگونه رخداد سایبری مشکوک، سریعا به مرکز افتا اعلام شود:
🔻 1. در دسترس بودن متولیان فنی سایبری و پیمانکاران سامانههای حیاتی برای مقابله با حوادث احتمالی
🔻 2.قطع فیزیکی تمامی پورتهای مدیریتی از جمله ILO و IPMI و مدیریت ذخیرهسازها (Storage)
🔻 3.حصول اطمینان از جداسازی فیزیکی شبکه مدیریتی تجهیزات (OOB) از سایر شبکهها
🔻 4.قطع هرگونه دسترسی از راه دور و دسترسیهای غیر ضروری به سامانهها، تجهیزات و سرویسهای حیاتی
🔻 5.حصول اطمینان از جداسازی شبکه های OT از سایر شبکهها
🔻 6.ممنوعیت نصب هر نوع سامانه یا تجهیز جدید و یا هرگونه اقدام نگهداری و بهروزرسانی بر روی سامانهها و تجهیزات موجود
🔻 7.حصول اطمینان از تغییر رمز عبور کاربران در سطح مدیریتی برای سامانهها و تجهیزات فناوری و صنعتی
🔻 8.شناسایی و حذف حسابهای کاربری غیرضروری در سامانهها، تجهیزات و سرویسهای حیاتی
🔻 9.بروز بودن، صحت و اطمینان از نگهداری نسخههای پشتیبان در خارج از سازمان
🔻 10.حصول اطمینان از ذخیره مطمئن و متمرکز انواع لاگهای امنیتی
🔻 11.هر گونه تماس یا ارسال پیامک از سرشمارههای ناشناس، No Number و یا Private برای اقدام بر روی سامانهها و زیرساخت مورد تایید نیست و نیاز به اخذ تاییدیه از مرکز افتاست.
@securation
😁11👍8
👎60😁9
This media is not supported in your browser
VIEW IN TELEGRAM
نوروز باستان ، یادگار شکوه و عظمت ایران زمین است.
نوروزمان از تمدن شش هزار ساله ی ما قدم برمیدارد و بر برگ جدید این سرزمین قدم میگذارد.
بهار همیشه با نسیم و شکوفه های زیبا نمی آید ، گاه آنقدر زمستان طولانی و سخت جان بوده که یخ ها را باید با صدایی مهیب و ویرانگر شکسته تا رودخانه ی حبس شده طغیان کند .
ما خوب میدانیم که برای تولدی دوباره ، گاه چاره ای جز عبور از دل آتش نیست ، ما وارثان ققنوس هستیم و خوب میدانیم که همین تلخی خاکستر امروز ، نقطه ی پرواز فردای ماست.
سالی که گذشت سخت بود و غم های فراوان داشت ، اما امیدواریم سال جدید زندگی ایرانیان پررونق و دلهایتان با ایمان ، قوی و پایدار باشد.
برای تک تک شما در زندگی و دلهایتان نور و شکوفایی آرزومند هستیم.
در سایه ی عزت و سربلندی بمانید.
ارداتمند ❤️💐
نوروزمان از تمدن شش هزار ساله ی ما قدم برمیدارد و بر برگ جدید این سرزمین قدم میگذارد.
بهار همیشه با نسیم و شکوفه های زیبا نمی آید ، گاه آنقدر زمستان طولانی و سخت جان بوده که یخ ها را باید با صدایی مهیب و ویرانگر شکسته تا رودخانه ی حبس شده طغیان کند .
ما خوب میدانیم که برای تولدی دوباره ، گاه چاره ای جز عبور از دل آتش نیست ، ما وارثان ققنوس هستیم و خوب میدانیم که همین تلخی خاکستر امروز ، نقطه ی پرواز فردای ماست.
سالی که گذشت سخت بود و غم های فراوان داشت ، اما امیدواریم سال جدید زندگی ایرانیان پررونق و دلهایتان با ایمان ، قوی و پایدار باشد.
برای تک تک شما در زندگی و دلهایتان نور و شکوفایی آرزومند هستیم.
در سایه ی عزت و سربلندی بمانید.
ارداتمند ❤️💐
❤15
لینک کانال در مسنجر بله رو داشته باشید عضو بشید :
ble.ir/securation
گروه امنیت سایبری در بله :
ble.ir/join/EtgBeo1eQ8
ble.ir/securation
گروه امنیت سایبری در بله :
ble.ir/join/EtgBeo1eQ8
👎50😁11
⭕️ هک تلگرام فقط با ارسال یک استیکر متحرک!
آسیب پذیری زیروکلیک در تلگرام نسخه اندروید و لینوکس کشف شده است که مهاجم با ارسال یک استیکر متحرک میتواند تلگرام شما را هک کند.
این آسیب پذیری امتیاز 9.8 از 10 گرفته و هنوز فیکس نشده است.
https://www1.ru/en/news/2026/03/28/uiazvimost-dlia-vzloma-bez-klika-nasli-v-telegram-ocenka-opasnosti-98-iz-10.html
@securation
آسیب پذیری زیروکلیک در تلگرام نسخه اندروید و لینوکس کشف شده است که مهاجم با ارسال یک استیکر متحرک میتواند تلگرام شما را هک کند.
این آسیب پذیری امتیاز 9.8 از 10 گرفته و هنوز فیکس نشده است.
https://www1.ru/en/news/2026/03/28/uiazvimost-dlia-vzloma-bez-klika-nasli-v-telegram-ocenka-opasnosti-98-iz-10.html
@securation
❤1
Security Analysis
⭕️ هک تلگرام فقط با ارسال یک استیکر متحرک! آسیب پذیری زیروکلیک در تلگرام نسخه اندروید و لینوکس کشف شده است که مهاجم با ارسال یک استیکر متحرک میتواند تلگرام شما را هک کند. این آسیب پذیری امتیاز 9.8 از 10 گرفته و هنوز فیکس نشده است. https://www1.ru/en/n…
⭕️ مسنجر تلگرام در شبکه اجتماعی توییتر وجود آسیب پذیری در بخش استیکر رو کاملا رد کرده.
باید صبر کنیم تا نتیجه ی فنی این موضوع بررسی بشه و در صورت اومدن هرگونه تحلیل اطلاع رسانی خواهد شد.
@securation
باید صبر کنیم تا نتیجه ی فنی این موضوع بررسی بشه و در صورت اومدن هرگونه تحلیل اطلاع رسانی خواهد شد.
@securation
1
⭕️ آسیبپذیری با شناسه CVE-2026-33696 در n8n گزارش شده که از نوع *Prototype Pollution* و منجر به RCE هست.
این ضعف به یک کاربر با دسترسی ایجاد/ویرایش workflow اجازه میده از طریق ورودیهای خاص، کنترل اجرای کد روی سرور n8n رو به دست بگیره.
شدت این آسیبپذیری بسیار بالاست و CVSS حدود 9.4 (Critical) هست.
سناریو حمله اینطوره که مهاجم دسترسی محدود به n8n داره پس workflow مخرب میسازه و از Prototype Pollution استفاده میکنه در نهایت به اجرای کد روی سرور میرسه.
نکته مهم:
چون n8n معمولاً به APIها، دیتابیسها و سرویسهای مختلف وصل هست، این حمله میتونه منجر به دسترسی گسترده به کل زیرساخت بشه.
اقدامات قابل انجام:
اینکه Patch فوری لازمه،
دسترسی ساخت/ویرایش workflow رو محدود کنید،
و اگر مشکوک هستید credentialهای ذخیرهشده در n8n رو rotate کنید.
@securation
این ضعف به یک کاربر با دسترسی ایجاد/ویرایش workflow اجازه میده از طریق ورودیهای خاص، کنترل اجرای کد روی سرور n8n رو به دست بگیره.
شدت این آسیبپذیری بسیار بالاست و CVSS حدود 9.4 (Critical) هست.
سناریو حمله اینطوره که مهاجم دسترسی محدود به n8n داره پس workflow مخرب میسازه و از Prototype Pollution استفاده میکنه در نهایت به اجرای کد روی سرور میرسه.
نکته مهم:
چون n8n معمولاً به APIها، دیتابیسها و سرویسهای مختلف وصل هست، این حمله میتونه منجر به دسترسی گسترده به کل زیرساخت بشه.
اقدامات قابل انجام:
اینکه Patch فوری لازمه،
دسترسی ساخت/ویرایش workflow رو محدود کنید،
و اگر مشکوک هستید credentialهای ذخیرهشده در n8n رو rotate کنید.
@securation
❤1
⭕️ هشدار بسیار مهم:
حمله به زنجیره تأمین (Supply Chain) پکیج axios در npm
در ۳۰ مارس ۲۰۲۶، پکیج Axios (بیش از ۱۰۰M دانلود هفتگی در npm) دچار حمله supply chain شد. مهاجم با دسترسی به اکانت توسعهدهنده اصلی، ایمیل ثبتشده اکانت را به یک آدرس ProtonMail تحت کنترل خودش تغییر داد و نسخههای آلوده 1.14.1 و 0.30.4 را منتشر کرد تا هم پروژههای جدید و هم قدیمی رو همزمان هدف قرار بده.
هر یک از نسخههای آلوده، پکیج plain-crypto-js نسخه 4.2.1 را به صورت مخفیانه به درخت وابستگی (dependency graph) پکیج Axios تزریق میکردند؛ بهگونهای که این پکیج در زمان اجرای npm install بهصورت خودکار دانلود و نصب میشد، بدون آنکه بهطور مستقیم در فایل package.json پروژه تعریف شده باشد.
نکته خیلی خطرناک در این حمله عدم وجود کد مخربی در خود پکیج axios میباشد، بدافزار در یک dependency قرار دارد که شما نه اون رو درخواست کردید نه مستقیم در پروژه import شده، این بدافزار بعد نصب و اجرا در عرض چند ثانیه همه ردپاهای خودش رو پاک میکند و ابزارهای npm list و npm audit پس از آلودگی هیچ نشانه مشکوکی رو نشون نمی دهد. هم چنین در فرایند نصب پکیج هم هیچ خطایی که نشون دهنده مشکلی در پکیج باشد وجود نداشته و فرایند نصب با exit code صفر به پایان می رسد. این بدافزار تنها 2 ثانیه بعد از نصب با سرور فرماندهی و کنترل C2 مهاجم ارتباط برقرار میکند.
اگر شما هر یک از این نسخه ها رو نصب کرده باشید باید فرض کنید سیستم شما به طور کامل مورد نفوذ قرار گرفته است.
@securation
حمله به زنجیره تأمین (Supply Chain) پکیج axios در npm
در ۳۰ مارس ۲۰۲۶، پکیج Axios (بیش از ۱۰۰M دانلود هفتگی در npm) دچار حمله supply chain شد. مهاجم با دسترسی به اکانت توسعهدهنده اصلی، ایمیل ثبتشده اکانت را به یک آدرس ProtonMail تحت کنترل خودش تغییر داد و نسخههای آلوده 1.14.1 و 0.30.4 را منتشر کرد تا هم پروژههای جدید و هم قدیمی رو همزمان هدف قرار بده.
هر یک از نسخههای آلوده، پکیج plain-crypto-js نسخه 4.2.1 را به صورت مخفیانه به درخت وابستگی (dependency graph) پکیج Axios تزریق میکردند؛ بهگونهای که این پکیج در زمان اجرای npm install بهصورت خودکار دانلود و نصب میشد، بدون آنکه بهطور مستقیم در فایل package.json پروژه تعریف شده باشد.
نکته خیلی خطرناک در این حمله عدم وجود کد مخربی در خود پکیج axios میباشد، بدافزار در یک dependency قرار دارد که شما نه اون رو درخواست کردید نه مستقیم در پروژه import شده، این بدافزار بعد نصب و اجرا در عرض چند ثانیه همه ردپاهای خودش رو پاک میکند و ابزارهای npm list و npm audit پس از آلودگی هیچ نشانه مشکوکی رو نشون نمی دهد. هم چنین در فرایند نصب پکیج هم هیچ خطایی که نشون دهنده مشکلی در پکیج باشد وجود نداشته و فرایند نصب با exit code صفر به پایان می رسد. این بدافزار تنها 2 ثانیه بعد از نصب با سرور فرماندهی و کنترل C2 مهاجم ارتباط برقرار میکند.
اگر شما هر یک از این نسخه ها رو نصب کرده باشید باید فرض کنید سیستم شما به طور کامل مورد نفوذ قرار گرفته است.
@securation
⭕️ یک کانال تلگرام به نام گروه هکری جوجه اردک زشت مدعی هک کردن همراه اول و سازمان صنفی رایانه ای در راستای اعتراض به اینترنت طبقاتی/پرو شده که نمونه اسنادی نیز در کانال منتشر نموده.
باید منتظر خبرهای رسمی از سوی این دو سازمان و شرکت باشیم.
@securation
باید منتظر خبرهای رسمی از سوی این دو سازمان و شرکت باشیم.
@securation
1🔥8👍3
⭕️حسادت تلگرام و توییتر و فیسبوک و اینستاگرام به روبیکا تمومی نداره!
دشمنان چشم پیشرفت روبیکا را ندارند.
ملت ایران عاشق روبیکا هستند بفرمایید 112میلیون ایرانی عضو کانال رسمی روبیکا در مسنجر روبیکا هستند.
@securation
دشمنان چشم پیشرفت روبیکا را ندارند.
ملت ایران عاشق روبیکا هستند بفرمایید 112میلیون ایرانی عضو کانال رسمی روبیکا در مسنجر روبیکا هستند.
@securation
🤣94❤2
⭕️ آسیبپذیری با شناسه CVE-2026-3854 در GitHub Enterprise Server / Git push pipeline گزارش شده که از نوع (RCE) هست.
این ضعف مربوط به نحوه پردازش git push options در مسیر داخلی پردازش push بوده؛ یعنی کاربر میتونست هنگام git push یک مقدار crafted ارسال کنه و بهخاطر sanitize نشدن کامل ورودی، داخل metadata داخلی GitHub فیلدهای اضافی تزریق کنه. ([The GitHub Blog][1])
دقیقا چی اتفاق میافته؟
در pipeline داخلی GitHub، اطلاعات push بین چند سرویس با یک فرمت metadata منتقل میشه. مشکل اینجا بود که delimiter داخلی همین metadata میتونست داخل ورودی کاربر هم بیاد. مهاجم با سوءاستفاده از این موضوع میتونست مقدارهای قابل اعتماد داخلی رو override کنه. ([The GitHub Blog][1])
سناریو حمله:
مهاجم فقط نیاز به یک حساب دارای push access روی یک repository داشت، حتی repoای که خودش ساخته باشه و یک git push با push option مخرب ارسال میکرد بعد metadata داخلی آلوده میشد و محیط پردازش push تغییر میکرد سپس sandbox مربوط به hook execution دور زده میشد و در نهایت اجرای دستور دلخواه روی سرور GitHub ممکن میشد.
نکته مهم:
این آسیبپذیری unauthenticated نبود، اما بسیار خطرناک بود چون سطح دسترسی لازم پایین بود: هر کاربری که روی یک repo امکان push داشت، میتونست مسیر exploit رو شروع کنه. در محیطهای GitHub Enterprise Server این یعنی یک کاربر داخلی، contractor، اکانت compromise شده یا حتی یک developer با دسترسی محدود میتونست به سطح اجرای کد روی سرور نزدیک بشه
ضمنا Root cause فقط یک sanitize ساده نبود؛ مسئله اصلی trust boundary failure بین ورودی کاربر و metadata داخلی سرویسها بود. مقدارهایی که باید صرفاً user-controlled محسوب میشدن، وارد کانالی شدن که downstream service اونها رو بهعنوان internal trusted fields تفسیر میکرد. این دقیقاً همون نقطهایه که injection تبدیل به RCE شد.
و اینکه GitHub اعلام کرده github.com و GitHub Enterprise Cloud در تاریخ March 4, 2026 patch شدن و بررسی forensic نشون داده exploitation عمومی رخ نداده.
برای GitHub Enterprise Server، نسخههای patch شده منتشر شده و upgrade فوری توصیه شده.
نسخههای امن GHES:
3.14.25 یا بالاتر
3.15.20 یا بالاتر
3.16.16 یا بالاتر
3.17.13 یا بالاتر
3.18.7 / 3.18.8 یا بالاتر
3.19.4 یا بالاتر
3.20.0 یا بالاتر
برای بررسی احتمال سوءاستفاده:
لاگ /var/log/github-audit.log رو بررسی کنید و دنبال push operationهایی باشید که داخل push options کاراکتر ; دارن. طبق توضیح GitHub، exploit باعث فعال شدن یک code path غیرعادی میشه که در عملیات عادی استفاده نمیشه، بنابراین برای hunting قابل اتکاست.
جمعبندی:
اگر GitHub Enterprise Server دارید، این مورد باید فوری patch بشه.
دسترسی push کاربران رو بازبینی کنید،
لاگهای audit رو بررسی کنید،
اکانتهای غیرضروری یا مشکوک رو disable کنید،
و بعد از upgrade مطمئن بشید هیچ push option مشکوکی در بازه قبل از patch ثبت نشده.
https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/
@securation
این ضعف مربوط به نحوه پردازش git push options در مسیر داخلی پردازش push بوده؛ یعنی کاربر میتونست هنگام git push یک مقدار crafted ارسال کنه و بهخاطر sanitize نشدن کامل ورودی، داخل metadata داخلی GitHub فیلدهای اضافی تزریق کنه. ([The GitHub Blog][1])
دقیقا چی اتفاق میافته؟
در pipeline داخلی GitHub، اطلاعات push بین چند سرویس با یک فرمت metadata منتقل میشه. مشکل اینجا بود که delimiter داخلی همین metadata میتونست داخل ورودی کاربر هم بیاد. مهاجم با سوءاستفاده از این موضوع میتونست مقدارهای قابل اعتماد داخلی رو override کنه. ([The GitHub Blog][1])
سناریو حمله:
مهاجم فقط نیاز به یک حساب دارای push access روی یک repository داشت، حتی repoای که خودش ساخته باشه و یک git push با push option مخرب ارسال میکرد بعد metadata داخلی آلوده میشد و محیط پردازش push تغییر میکرد سپس sandbox مربوط به hook execution دور زده میشد و در نهایت اجرای دستور دلخواه روی سرور GitHub ممکن میشد.
نکته مهم:
این آسیبپذیری unauthenticated نبود، اما بسیار خطرناک بود چون سطح دسترسی لازم پایین بود: هر کاربری که روی یک repo امکان push داشت، میتونست مسیر exploit رو شروع کنه. در محیطهای GitHub Enterprise Server این یعنی یک کاربر داخلی، contractor، اکانت compromise شده یا حتی یک developer با دسترسی محدود میتونست به سطح اجرای کد روی سرور نزدیک بشه
ضمنا Root cause فقط یک sanitize ساده نبود؛ مسئله اصلی trust boundary failure بین ورودی کاربر و metadata داخلی سرویسها بود. مقدارهایی که باید صرفاً user-controlled محسوب میشدن، وارد کانالی شدن که downstream service اونها رو بهعنوان internal trusted fields تفسیر میکرد. این دقیقاً همون نقطهایه که injection تبدیل به RCE شد.
و اینکه GitHub اعلام کرده github.com و GitHub Enterprise Cloud در تاریخ March 4, 2026 patch شدن و بررسی forensic نشون داده exploitation عمومی رخ نداده.
برای GitHub Enterprise Server، نسخههای patch شده منتشر شده و upgrade فوری توصیه شده.
نسخههای امن GHES:
3.14.25 یا بالاتر
3.15.20 یا بالاتر
3.16.16 یا بالاتر
3.17.13 یا بالاتر
3.18.7 / 3.18.8 یا بالاتر
3.19.4 یا بالاتر
3.20.0 یا بالاتر
برای بررسی احتمال سوءاستفاده:
لاگ /var/log/github-audit.log رو بررسی کنید و دنبال push operationهایی باشید که داخل push options کاراکتر ; دارن. طبق توضیح GitHub، exploit باعث فعال شدن یک code path غیرعادی میشه که در عملیات عادی استفاده نمیشه، بنابراین برای hunting قابل اتکاست.
جمعبندی:
اگر GitHub Enterprise Server دارید، این مورد باید فوری patch بشه.
دسترسی push کاربران رو بازبینی کنید،
لاگهای audit رو بررسی کنید،
اکانتهای غیرضروری یا مشکوک رو disable کنید،
و بعد از upgrade مطمئن بشید هیچ push option مشکوکی در بازه قبل از patch ثبت نشده.
https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/
@securation
The GitHub Blog
Securing the git push pipeline: Responding to a critical remote code execution vulnerability
How we validated, fixed, and investigated a critical vulnerability in under two hours, and confirmed no exploitation.
❤5👍1
⭕️یه خبر جالب از دنیای AI که سم آلتمن توییت کرده :
طبق اعلام جدید، قراره طی چند روز آینده مدل جدیدی به اسم GPT-5.5-Cyber عرضه بشه. این مدل مخصوص حوزه امنیت سایبری طراحی شده و قراره به متخصصهای امنیت کمک کنه تا بهتر بتونن از شرکتها و زیرساختهای مهم در برابر حملات سایبری محافظت کنن.
نکته مهم اینه که گفته شده برای استفاده از این مدل، با دولتها و کل اکوسیستم فناوری همکاری میکنن تا دسترسیها کاملاً امن و کنترلشده باشه.
هدف اصلیش هم اینه که سرعت شناسایی و مقابله با تهدیدهای سایبری رو بالا ببرن و امنیت سیستمها رو تقویت کنند.
@securation
طبق اعلام جدید، قراره طی چند روز آینده مدل جدیدی به اسم GPT-5.5-Cyber عرضه بشه. این مدل مخصوص حوزه امنیت سایبری طراحی شده و قراره به متخصصهای امنیت کمک کنه تا بهتر بتونن از شرکتها و زیرساختهای مهم در برابر حملات سایبری محافظت کنن.
نکته مهم اینه که گفته شده برای استفاده از این مدل، با دولتها و کل اکوسیستم فناوری همکاری میکنن تا دسترسیها کاملاً امن و کنترلشده باشه.
هدف اصلیش هم اینه که سرعت شناسایی و مقابله با تهدیدهای سایبری رو بالا ببرن و امنیت سیستمها رو تقویت کنند.
@securation
❤17👍6
⭕️ آپاچی یه آپدیت امنیتی مهم برای وبسرور خودش منتشر کرده؛ نسخه 2.4.67 که از ۴ می ۲۰۲۶ در دسترس قرار گرفته. این آپدیت برای رفع چند آسیبپذیری امنیتی اومده و مهمترینش مربوط به ماژول HTTP/2 هست؛ همون بخشی که اگر روی سرور فعال باشه، ممکنه در نسخه قبلی یعنی 2.4.66 باعث کرش کردن سرویس یا در شرایط خاص حتی اجرای کد از راه دور بشه. به زبان سادهتر، اگر کسی سروری با Apache نسخه آسیبپذیر داشته باشه و HTTP/2 هم فعال باشه، بهتره این آپدیت رو جدی بگیره.
فعلاً گفته شده اکسپلویت عمومی برای این مشکل منتشر نشده، ولی چون Apache روی تعداد خیلی زیادی از سرورها استفاده میشه، طبیعی که جامعه امنیتی سریع نسبت بهش حساس شده. توصیه اصلی هم اینه که تیمهای فنی، مخصوصاً کسایی که روی نسخه 2.4.66 هستن، وضعیت سرورهاشون رو چک کنن و در صورت نیاز سریع به 2.4.67 آپدیت کنن. اینجور باگها شاید برای همه مستقیم خطر فوری نسازن، ولی وقتی روی زیرساختهای پرتعداد و عمومی باشن، بهتره قبل از اینکه تبدیل به دردسر واقعی بشن، بسته بشن.
@securation
فعلاً گفته شده اکسپلویت عمومی برای این مشکل منتشر نشده، ولی چون Apache روی تعداد خیلی زیادی از سرورها استفاده میشه، طبیعی که جامعه امنیتی سریع نسبت بهش حساس شده. توصیه اصلی هم اینه که تیمهای فنی، مخصوصاً کسایی که روی نسخه 2.4.66 هستن، وضعیت سرورهاشون رو چک کنن و در صورت نیاز سریع به 2.4.67 آپدیت کنن. اینجور باگها شاید برای همه مستقیم خطر فوری نسازن، ولی وقتی روی زیرساختهای پرتعداد و عمومی باشن، بهتره قبل از اینکه تبدیل به دردسر واقعی بشن، بسته بشن.
@securation
❤8
⭕️ آسیبپذیری CVE-2026-32710 در MariaDB یک ضعف بحرانی از نوع Heap Out-of-Bounds است که میتواند به Privilege Escalation پایدار و در نهایت به UDF RCE منجر شود.
در این حمله، مهاجم با یک اکانت با سطح دسترسی پایین مثل SELECT-only، ساختارهای مربوط به privilege را در حافظه overwrite میکند و سطح دسترسی خود را به ALL PRIVILEGES ارتقا میدهد.
بعد از گرفتن دسترسی کامل، مهاجم از قابلیت UDF استفاده میکند تا یک shared library مخرب داخل plugin_dir قرار دهد و از طریق SQL روی سیستمعامل command اجرا کند. این یعنی compromise کامل MariaDB میتواند مستقیماً به اجرای کد روی سرور ختم شود.
ریشه مشکل در corruption حافظه و ضعف در مدیریت ساختارهای access control است که باعث میشود مرز بین کاربر محدود و ادمین از بین برود. نکته خطرناک اینجاست که exploitation فقط به escalation ختم نمیشود و میتواند persistence هم ایجاد کند.
نکته:
نسخههای 11.4.x MariaDB (تأییدشده روی 11.4.9) تحت تأثیر هستند و بروزرسانی فوری، محدود کردن FILE privilege و مانیتورینگ UDFهای جدید ضروری است.
@securation
در این حمله، مهاجم با یک اکانت با سطح دسترسی پایین مثل SELECT-only، ساختارهای مربوط به privilege را در حافظه overwrite میکند و سطح دسترسی خود را به ALL PRIVILEGES ارتقا میدهد.
بعد از گرفتن دسترسی کامل، مهاجم از قابلیت UDF استفاده میکند تا یک shared library مخرب داخل plugin_dir قرار دهد و از طریق SQL روی سیستمعامل command اجرا کند. این یعنی compromise کامل MariaDB میتواند مستقیماً به اجرای کد روی سرور ختم شود.
ریشه مشکل در corruption حافظه و ضعف در مدیریت ساختارهای access control است که باعث میشود مرز بین کاربر محدود و ادمین از بین برود. نکته خطرناک اینجاست که exploitation فقط به escalation ختم نمیشود و میتواند persistence هم ایجاد کند.
نکته:
نسخههای 11.4.x MariaDB (تأییدشده روی 11.4.9) تحت تأثیر هستند و بروزرسانی فوری، محدود کردن FILE privilege و مانیتورینگ UDFهای جدید ضروری است.
@securation
❤8👍3