🕵️ مردی که موتورولا رو بدون نوشتن حتی یک خط کد هک کرد
◀️ سال ۱۹۹۲، کوین میتنیک (یکی از معروف‌ترین هکرهای تاریخ) در حالی که از دست FBI فراری بود، تصمیم گرفت سورس‌کد گوشی موتورولا MicroTAC Ultralite رو به دست بیاره — همون گوشی پرچمدار اون دوره.

◀️ هدفش این بود که با دستکاری شماره سریال گوشی (ESN)، جلوی ردیابی خودش توسط پلیس رو بگیره. ولی راهی که برای رسیدن به این سورس‌کد انتخاب کرد، هیچ ربطی به کدنویسی یا اکسپلویت نداشت.

◀️ او فقط یه تماس تلفنی با موتورولا گرفت، خودش رو به چند بخش مختلف وصل کرد تا بالاخره به تیمی رسید که روی همون سورس‌کد کار می‌کردن، و با اعتمادبه‌نفس و لحن یه کارمند داخلی، اونا رو متقاعد کرد که خودش هم عضو همون تیمه و فوری به این فایل‌ها نیاز داره.

◀️ نتیجه؟ کمتر از بیست دقیقه بعد، کارکنان موتورولا خودشون فایل سورس‌کد رو از طریق FTP براش فرستادن — بدون اینکه حتی یک بار هویتش رو درست‌وحسابی چک کنن.
✅ این داستان دقیقاً همون چیزیه که بعد از این همه سال هنوز درسش زنده‌ست: قوی‌ترین فایروال دنیا هم فایده‌ای نداره اگه یه کارمند بشه با یه تماس تلفنی و کمی اعتمادبه‌نفس متقاعدش کرد. مهندسی اجتماعی هنوز هم موثرترین روش نفوذه، چون هدفش تکنولوژی نیست، آدماست.
#تاریخچه_هک #مهندسی_اجتماعی #Motorola #امنیت_سایبری
📱 @Abrplusdocs

t.me/abrplusdocs

🔴 زنجیره‌ای از دو باگ که یه کاربر ساده رو Admin می‌کنه

◀️ تو Keystone نسخه‌های قبل از ۲۹.۰.۲ یه سناریوی جالب کشف شده که وقتی دو تا مشکل رو با هم ترکیب کنی، نتیجه‌ش خیلی بدتر از هر کدوم به‌تنهایی می‌شه.
◀️ یه کاربر که فقط نقش Member رو تو یه پروژه داره، می‌تونه با ترکیب یه باگ Application Credential Impersonation و مکانیزم Trust های Keystone، دسترسیش رو تا سطح Admin بالا ببره.
◀️ نکته فنی جالب اینجاست: وقتی توکن جعل‌شده هویت قربانی رو حمل می‌کنه، از چک اعتبارسنجی Trustor عبور می‌کنه، ولی Keystone نقش‌های Trust رو بر اساس دیتابیس نقش‌های واقعی قربانی چک می‌کنه، نه نقش‌های توکن درخواست‌دهنده. همین ناهماهنگی راه رو باز می‌کنه.
◀️ بدتر از همه اینکه Trust ساخته‌شده مستقل باقی می‌مونه، یعنی مهاجم می‌تونه بعداً هم Trust و Credential های بیشتری بسازه تا دسترسیش رو حفظ کنه — و تمام این کارها تو لاگ‌ها به‌نام قربانی ثبت می‌شه، نه به‌نام مهاجم.

🔐 اگه از Application Credentials تو محیط چند-کاربره یا چند-پروژه‌ای استفاده می‌کنید، آپدیت به ۲۹.۰.۲ رو در اولویت بذارید؛ این نوع باگ‌ها معمولاً تو ممیزی امنیتی معمولی دیده نمی‌شن چون لاگ‌ها گمراه‌کننده‌ست.

#OpenStack #Keystone #CVE #KollaAnsible #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

⚙️ خطای عجیب vMotion که هیچ نشونه استاندارد خرابی دیسک نداشت
◀️ تو مقاله‌های Broadcom یه سناریوی جالب هست که خیلی از ادمین‌های vSAN باهاش گیج می‌شن: عملیات vMotion شکست می‌خوره و تو لاگ vmkwarning پیام خطای Checksum از LSOM دیده می‌شه (CRC محاسبه‌شده با CRC ذخیره‌شده مطابقت نداره).

◀️ نکته عجیب اینجاست که هیچکدوم از نشونه‌های معمول خرابی دیسک دیده نمی‌شه: نه SCSI Sense Code، نه Permanent Device Loss، نه حتی گزارشی که نشون بده I/O جدید داره تو مسیر خراب می‌شه. یعنی هرکسی که فقط دنبال خطای استاندارد دیسک بگرده، هیچی پیدا نمی‌کنه.

◀️ ریشه ماجرا هم چیز غیرمنتظره‌ایه: خود دیسک‌ها کاملاً سالمن، ولی افت سیگنال فیزیکی تو Backplane یا کابل‌های SAS باعث می‌شه داده موقع عبور از این مسیر دچار تداخل بشه و وقتی LSOM داره Checksum رو چک می‌کنه، عدم تطابق پیدا کنه.

◀️ چون کنترلر دیسک اصلاً متوجه این تداخل سیگنال نمی‌شه، هیچ خطای استاندارد SCSI هم ثبت نمی‌کنه؛ یعنی مشکل درست از جایی میاد که هیچ ابزار مانیتورینگ معمولی بهش نگاه نمی‌کنه.
✅ راه‌حل واقعی، عیب‌یابی سخت‌افزاری کابل‌های SAS و Backplane با تولیدکننده سرور و تعویض قطعه معیوبه، نه هیچ تنظیم نرم‌افزاری. اگه تو محیط vSAN با خطای Checksum عجیب و بدون علامت واضح خرابی دیسک مواجه شدید، مستقیم برید سراغ لایه فیزیکی.
#VMware #vSAN #Troubleshooting #نکته_فنی
📱 @Abrplusdocs

t.me/abrplusdocs

🕵️ کمپینی که هزاران هایپروایزر ESXi رو با یه باگ دو‌ساله زمین‌گیر کرد

◀️ فوریه ۲۰۲۳، یه کمپین باج‌افزاری به اسم ESXiArgs شروع شد که به‌جای هدف قرار دادن یه کامپیوتر تک، مستقیم سراغ خود هایپروایزرهای ESXi رفت — یعنی یه حمله، همزمان چندین ماشین مجازی رو از کار می‌انداخت.
◀️ نکته تلخ ماجرا اینه که مهاجم‌ها از هیچ حفره روز صفرمی استفاده نکردن؛ آسیب‌پذیری CVE-2021-21974 تو سرویس OpenSLP بود که پچش از فوریه ۲۰۲۱ موجود بود، یعنی دقیقاً دو سال قبل از شروع حمله.
◀️ با این حال، تحقیقات Rapid7 نشون داد که بیش از ۱۸ هزار سرور ESXi روی اینترنت هنوز آسیب‌پذیر و در معرض دید بودن. نتیجه؟ طبق گزارش CISA و FBI، بیش از ۳۸۰۰ سرور در سراسر دنیا (بیشترین آسیب در اروپا) واقعاً آلوده شدن.
◀️ نکته جالب اینه که از دید مهاجم‌ها، این کمپین چندان هم موفق نبود؛ چون CISA و محقق‌های امنیتی اسکریپت‌های رایگان منتشر کردن و اکثر قربانی‌ها به‌جای پرداخت باج، از همون اسکریپت‌ها استفاده کردن.

✅ درسی که این ماجرا برای هر ادمین ESXi داره مشخصه: وقتی یه باگ رو تو هایپروایزر پچ نمی‌کنید، ریسک دیگه محدود به یه VM نیست، کل کلاسترت رو هواس

#تاریخچه_هک #VMware #ESXi #Ransomware #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

🔵 دو سال بعد از برادکام: نه مهاجرت دسته‌جمعی، نه بازگشت به روال عادی

◀️ یه نظرسنجی تازه از CloudBolt (فوریه ۲۰۲۶، در آمریکای شمالی) نشون می‌ده: ۸۶ درصد سازمان‌ها دارن به‌طور فعال ردپای VMware رو تو زیرساخت‌شون کم می‌کنن، ولی فقط ۴ درصد کامل مهاجرت کردن.
◀️ یعنی اکثریت دارن مسیر تدریجی رو انتخاب می‌کنن، نه تعویض یک‌شبه؛ چیزی که با گزارش دیگه‌ای از سایت OpenStack هم هم‌خوانی داره: طبق تحقیق Civo، چهل و هشت درصد کاربرای فعلی یا سابق VMware الان برای همون امکانات قبلی، پول بیشتری می‌دن نزدیک نیمی از اونا هزینه‌شون دقیقاً دو برابر شده.
◀️ نکته جالب اینه که مقصد این مهاجرت‌ها هم یکسان نیست. OpenStack با پشتیبانی OpenInfra Foundation و توزیع‌هایی مثل Canonical و Mirantis، مقصد اصلی سازمان‌های بزرگ‌تر و Telco هاست، در حالی که Proxmox بیشتر تو سازمان‌های کوچیک و متوسط جا افتاده، مخصوصاً بعد از عرضه Proxmox Datacenter Manager که مشکل مدیریت چندکلاستری (رقیب vCenter) رو حل کرد.
◀️ نکته : طبق گفته OpenInfra، با ابزارهای جدید، مهاجرت مستقیم یه VM از VMware به OpenStack الان فقط چند ثانیه طول می‌کشه، نه هفته‌ها پروژه.

✅ نظر شخصی من اینه که تصمیم واقعی دیگه بین موندن یا مهاجرت کردن نیست؛ بین «یه استک واحد» یا «چند استک موازی» (VMware برای Workload های Stateful حساس، OpenStack یا Proxmox برای بقیه) هست. کسایی که این تصمیم رو عقب بندازن، دقیقاً همونایی هستن که تو نظرسنجی‌های بعدی جزو اون ۸۶ درصد «هنوز داریم فکر می‌کنیم» می‌مونن.

#OpenStack #VMware #Broadcom #تحلیل #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

📍ساعت‌ کاری جدید ادارات از اول مهر تا آخر سال اعلام شد: فعالیت از ۸ تا ۱۳

پیشی گرفتن Nutanix از VMware

Nutanix was named a Leader in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms.

@abrplusdocs

... :)
@abrplusdocs

⭕️زیرساخت OpenAI هک شد!

یک گزارش امنیتی جدید جزئیات حمله‌ای به زیرساخت داخلی OpenAI را منتشر کرده است.

طبق این گزارش، مهاجمان از ترکیب یک آسیب پذیری Heap Overflow و SSO Misconfiguration استفاده کردند و توانستند به OpenAi نفوذ کنند.

این زنجیره آسیب‌پذیری‌ها امکان دسترسی غیرمجاز به بخش‌هایی از زیرساخت داخلی را فراهم کرده است.

هدف اصلی حمله، دسترسی به Repositoryهای داخلی OpenAI عنوان شده است.

در بخش اول، یک نقص مربوط به مدیریت حافظه (Heap Overflow) مورد سوءاستفاده قرار گرفته است.
سپس یک پیکربندی نادرست در سیستم Single Sign-On (SSO) برای افزایش سطح دسترسی مورد استفاده قرار گرفته است.
در نهایت، مهاجم توانسته به منابع و مخازن کد داخلی دسترسی پیدا کند.

https://www.hacktron.ai/blog/hacking-openai
#news #hack #ai #openai
@abrplusdocs

🔰 تفاوت Virtualization با Containerization چیست؟

🔸هر دو برای استفاده بهتر از منابع و اجرای چند Workload روی یک زیرساخت مشترک استفاده می‌شن، اما روش کارشون متفاوته.
در Virtualization، یک Hypervisor چند VM ایجاد می‌کنه و هر VM سیستم‌عامل Guest خودش رو داره.

🔸در Containerization، Containerها سیستم‌عامل جداگانه ندارن و Kernel سیستم‌عامل Host رو با هم Share می‌کنن. به همین دلیل معمولاً سبک‌تر و سریع‌تر هستن.

به زبان ساده:

VM: سخت‌افزار → Hypervisor → VM → Guest OS → Application

Container: سخت‌افزار → Host OS → Container Engine → Container → Application

🔹نکته مهم اینه که این دو فناوری لزوماً رقیب هم نیستن؛ در بسیاری از زیرساخت‌های واقعی، VM و Container در کنار هم استفاده می‌شن.

#Virtualization #Containerization #VM #Container #Hypervisor #Docker #Kubernetes #DevOps #CloudComputing #ITInfrastructure #Networking #CyberSecurity #Technology
@abrplusdocs

Snapshot Consolidation

تا حالا به این فکر کرده‌اید که VMware vSphere چطور فرآیند Snapshot Consolidation را انجام می‌دهد، بدون اینکه Performance ماشین مجازی تحت تأثیر قرار بگیرد؟
از vsphere 6 به بعد،
مکانیزمی به نام Snapshot Mirror Driver معرفی شد که نقش مهمی در بهینه‌سازی فرآیندهای Snapshot Consolidation و Storage vMotion ایفا کرد.

اما چه چیزی این مکانیزم را قدرتمند می‌کند؟

✅ کاهش نیاز به Helper Diskها
دیگر نیازی به ایجاد تعداد زیادی دیسک موقت برای انجام Consolidation نیست؛ در نتیجه فضای Datastore کمتر درگیر می‌شود.

✅ Single-Pass Consolidation
حتی بدون استفاده از Helper Diskهای متعدد، فرآیند Consolidation می‌تواند در یک Pass انجام شود و از عملیات تکراری جلوگیری شود.

✅ حفظ ترتیب صحیح Writeها
در زمان Consolidation، تغییرات ماشین مجازی همچنان روی Active VMDK نوشته می‌شوند و در عین حال یکپارچگی داده‌ها حفظ می‌شود.

✅ Dual-Write Mechanism
در فرآیند Consolidation، Writeها به‌صورت هم‌زمان روی Active Disk و Base Disk اعمال شده و پس از دریافت Acknowledgement ادامه فرآیند انجام می‌شود؛ رویکردی که برای جلوگیری از Data Loss طراحی شده است.

🎯 نتیجه چیست؟
در معماری vSphere، این مکانیزم کمک می‌کند عملیات‌هایی مانند:
🔹 Snapshot Cleanup
🔹 Snapshot Consolidation
🔹 Storage vMotion
با پیچیدگی و Overhead کمتری انجام شوند و تأثیر عملیات روی ماشین‌های مجازی کاهش پیدا کند.

💡 یکی از نکات جالب در VMware این است که بخش قابل‌توجهی از Performance و Reliability، نه فقط در لایه Hypervisor، بلکه در مکانیزم‌های به‌ظاهر کوچک و داخلی مانند Snapshot Mirror Driver مدیریت می‌شود.


@abrplusdocs

همه در مورد GPU دارن صحبت میکنن
🔺اما یه سوال خیلی مهم وجود داره
وقتی GPU برا زیرساختت آماده شد Network و Storage هم آماده شده از قبل؟

توی معماری جدید AI Infra دیگه فقط تعداد GPU تعیین کننده نیست
🔺اگه دیتا با سرعت کافی به GPU نرسه
🔺اگه Storage تو زمان check point دچار Latency بشه
🔺یا Network تو زمان Data movement دچار یه باتلنک بشه
این GPU گران قیمت شما عملا می‌تونه منتظر بمونه؟

مخصوصا در مقیاس بزرگ Check pointing و Data movement میتونه باعث GPU Stall بشن
پس وقتی از AI Infrastructure صحبت میکنیم بهتر یه نگاه به این زنجیره مهم شبکه و استوریج هم داشته باشیم
شاید درسته نباشه که بپرسیم
چند GPU داریم؟؟
بهتره بپرسیم :
آیا کل Data path ما برای GPU طراحی شده؟

@abrplusdocs

🔴 چهار آسیب‌پذیری همزمان تو CephX که کل زیرساخت احراز هویت Ceph رو زیر سوال می‌بره

◀️ طبق یادداشت امنیتی رسمی OpenStack (شماره OSSN-0108)، چهار تا آسیب‌پذیری جدا تو مکانیزم CephX (همون سیستم احراز هویت با کلید مشترک Ceph) کشف شده که هر سرویس OpenStack با یه CephX Keyring — یعنی Nova، Cinder، Glance و Manila — رو تحت تأثیر قرار می‌ده.
◀️ عمق ماجرا از یه اشتباه رمزنگاری میاد: یه Vector مقداردهی اولیه (IV) به‌صورت ثابت تو کد گذاشته شده بود، یعنی متن‌های یکسان همیشه رمزنگاری یکسانی تولید می‌کردن. کنار این، نبود HMAC هم امکان دستکاری بیت‌به‌بیت داده‌های رمزشده (CBC Bit-Flipping) رو باز می‌ذاشت.
◀️ نتیجه عملیش اینه که اگه یه مهاجم به هر شکلی (حتی از طریق شنود ترافیک شبکه) به یه کلید CephX دسترسی پیدا کنه، می‌تونه سطح دسترسی یه Ticket رو بدون اینکه ردی از خودش بذاره تغییر بده و برای سرویس‌های با دسترسی بالاتر Credential جعل کنه.
◀️ نکته مهم برای کاربرای Nova: اگه از RBD برای Cinder استفاده می‌کنید، این یه ریسک داخلیه (چون خود VM به کلید CephX دسترسی نداره)، ولی اگه از Manila با CephFS مستقیم (نه NFS-Ganesha) استفاده می‌کنید، خود Tenant هم می‌تونه این آسیب‌پذیری رو اکسپلویت کنه.

🔐 راه‌حل، آپدیت به Ceph نسخه ۲۰.۲.۴ یا ۱۹.۲.۶ هست، ولی نکته مهم ترتیب کاره: باید اول کل کلاینت‌های Ceph تو سرورهای OpenStack آپدیت بشن، بعد Keyring ها Rotate بشن، و در آخر VM ها Restart یا Live Migrate بشن تا کلید جدید رو بارگذاری کنن. جابه‌جا کردن این ترتیب می‌تونه سرویس رو قطع کنه.

#OpenStack #Ceph #CephX #CVE #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

🕵️ شرکتی که در عرض دوازده ساعت با یه اکانت AWS از بین رفت

◀️ سال ۲۰۱۴، یه شرکت به اسم Code Spaces (سرویس میزبانی کد و ابزارهای همکاری برای برنامه‌نویسا) بعد از هفت سال فعالیت موفق، تو کمتر از یه روز کاملاً نابود شد.
◀️ ماجرا با یه حمله DDoS شروع شد، ولی خیلی زود مشخص شد این فقط ظاهر قضیه‌ست: یه مهاجم ناشناس به پنل مدیریتی EC2 این شرکت دسترسی پیدا کرده بود و از طریق پیام‌هایی روی همون پنل، درخواست باج کرد.
◀️ وقتی Code Spaces به‌جای پرداخت باج تصمیم گرفت رمز عبور رو عوض کنه تا کنترل رو پس بگیره، مهاجم که از قبل چند تا حساب کاربری پشتیبان برای خودش ساخته بود، متوجه این تلاش شد و شروع کرد به حذف تصادفی همه‌چیز.
◀️ نتیجه؟ تمام Snapshot های EBS، باکت‌های S3، تصاویر AMI و چندین Instance ماشینی پاک شدن یعنی هم داده اصلی، هم بک‌آپ‌ها، هم پیکربندی سرورها، همه با هم از بین رفتن. شرکتی که خودش بک‌آپ کامل رو تبلیغ اصلیش می‌کرد، بک‌آپش هم روی همون پنل هک‌شده بود.

✅ نکته ای که بعد از این حادثه به یه اصل استاندارد Cloud تبدیل شد: بک‌آپ باید همیشه از محیط اصلی جدا باشه (Immutable یا Air-Gapped)، و روی هر اکانت مدیریتی با دسترسی بالا، احراز هویت چندمرحله‌ای (MFA) باید اجباری باشه، نه اختیاری. یه رمز عبور به‌تنهایی هیچوقت کافی نیست.

#تاریخچه_هک #AWS #CloudSecurity #Backup

📱 @Abrplusdocs
t.me/abrplusdocs

🔥 صفر تا صد Subnetting در IPv4

@abrplusdocs

⚙️ وقتی رشد کلاستر باعث ناپایداری ساخت VM می‌شه
◀️ تو یکی از تیکت‌های پشتیبانی Red Hat OpenStack (باگ ۱۸۴۸۶۰۵)، یه تیم زیرساخت گزارش داده بود که با بزرگ‌تر شدن کلاستر، ساخت VM ناپایدار شده بود — گاهی موفق، گاهی بدون دلیل مشخص Timeout می‌خورد.

◀️ چیزی که پشت این رفتار عجیب بود، به مقیاس کلاستر برمی‌گشت: تنظیمات پیش‌فرض ارتباط بین Neutron و OVSDB برای یه محیط کوچیک کافی بودن، ولی وقتی تعداد پورت‌ها و Flow ها زیاد می‌شه، همون Timeout های پیش‌فرض شروع می‌کنن به شکست خوردن، بدون اینکه خطای واضحی تو لاگ بندازن.

◀️ راه‌حلی که این تیم استفاده کرد، تنظیم چهار پارامتر بود: افزایش ovsdb_timeout و of_inactivity_probe به ۳۰ ثانیه تو فایل‌های تنظیمات L3 Agent و OVS Agent، تغییر ovsdb_interface به حالت vsctl، و دستی تنظیم‌کردن inactivity_probe روی همه نودهای Controller و Compute.

◀️ بعد از اعمال این تغییرات و ریستارت سرویس‌های neutron_ovs_agent، neutron_metadata_agent و neutron_l3_agent، مشکل کاملاً برطرف شد.
✅ اگه کلاستر شما داره بزرگ می‌شه و شروع کردید به دیدن خطاهای گاه‌به‌گاه و بی‌دلیل تو ساخت VM یا اتصال شبکه، قبل از اینکه سراغ دیباگ عمیق‌تر برید، همین چهار پارامتر رو تو تنظیمات ML2/OVS Agent چک کنید؛ خیلی وقتا مشکل مقیاس‌پذیریه، نه باگ.
#OpenStack #Neutron #KollaAnsible #نکته_فنی
📱 @Abrplusdocs

t.me/abrplusdocs

🟡 باگی که یادآوری می‌کنه چرا امنیت کانتینر هم برای زیرساخت ابری مهمه

◀️ چون تو Kolla-Ansible همه سرویس‌های OpenStack (از Nova تا Neutron و Keystone) داخل کانتینرهای Docker اجرا می‌شن، امنیت خود کانتینر (runc) مستقیم رو زیرساخت شما تاثیر داره و یه نمونه خوب برای یادآوری این موضوع باگ‌ معروف به Leaky Vessels هست.
◀️ جدی‌ترینش CVE-2024-21626 بود: یه نشتی File Descriptor داخلی تو runc باعث می‌شد وقتی یه کانتینر جدید ساخته می‌شه (یا با runc exec وارد یه کانتینر می‌شید)، مسیر Working Directory اون پردازش اشتباهی به فضای فایل‌سیستم هاست اشاره کنه، نه فضای خود کانتینر.
◀️ نتیجه این نشتی، دور زدن کامل مرز Container Isolation بود؛ یعنی یه Image مخرب یا یه Dockerfile آلوده می‌تونست از همین مسیر به فایل‌سیستم هاست دسترسی پیدا کنه و حتی باینری‌های سیستم رو Overwrite کنه.

◀️ نکته مهم برای محیط‌های OpenStack: چون در Kolla-Ansible معمولاً همه سرویس‌ها از Image های رسمی از پیش ساخته‌شده استفاده می‌کنن (نه Build کردن Image دلخواه)، ریسک مستقیم این باگ کمتره، ولی اگه Image های سفارشی یا پروژه‌های جانبی داخل همون Docker Runtime اجرا می‌کنید، این دقیقاً همون موضوعیه که باید مراقبش باشین

✅ نکته کلی : کانتینر یه چیز کاملاً ایزوله نیست، فقط یه مرز نرم‌افزاریه برای محیط پروداکشن، همیشه Docker Engine و runc رو به‌روز نگه دارید، حتی اگه فکر می‌کنید فقط Image های "امن" اجرا می‌کنید.

#Docker #Containers #KollaAnsible #امنیت_زیرساخت #نکته_فنی

📱 @Abrplusdocs
t.me/abrplusdocs

🕵️ یه تماس چند دقیقه ای که ۱۰۰ هایپروایزر ESXi رو نابود کرد

◀️ سپتامبر ۲۰۲۳، گروه هکری Scattered Spider (که به BlackCat/ALPHV هم وصل بود) با یه روش عجیب‌طور ساده وارد شبکه MGM Resorts (یکی از بزرگ‌ترین شرکت‌های کازینو و هتل داری دنیا) شد؛ بدون هیچ اکسپلویت فنی خاصی.
◀️ کارشون این بود: اسم یه کارمند رو از لینکدین پیدا کردن، بعد به Help Desk خود شرکت زنگ زدن و با وانمود کردن به اون کارمند، درخواست ریست رمز و MFA کردن. طبق گزارش‌ها، در کمتر از ده دقیقه به Credential های حیاتی دسترسی پیدا کردن.
◀️ از همونجا شروع کردن به افزایش سطح دسترسی، تا جایی که به دسترسی Global Admin روی Okta و حتی روی Tenant Azure شرکت رسیدن یعنی عملاً کلید کل زیرساخت هویتی MGM دستشون بود.
◀️ وقتی MGM از پرداخت باج خودداری کرد، مهاجم‌ها باج‌افزار BlackCat رو روی بیش از صد هایپروایزر ESXi اجرا کردن و همه رو رمزنگاری کردن
بعدش چی شد؟ سیستم کارت‌های هتل، دستگاه‌های اسلات و حتی سایت شرکت از کار افتاد، و خسارت نهایی حدود صد میلیون دلار تخمین زده شد.

✅ نکته‌ای که این ماجرا نشون می‌ده اینه که قوی‌ترین لایه امنیتی یه محیط مجازی‌سازی، خود ESXi یا vCenter نیست؛ زنجیره هویتیه که بهش وصله. وقتی Help Desk بدون احراز هویت قوی، MFA یه حساب Admin رو ریست می‌کنه، هیچ پچ یا فایروالی نمی‌تونه جلوی اتفاقی که بعدش میفته رو بگیره.

#تاریخچه_هک #ESXi #ransomware #CloudSecurity #مهندسی_اجتماعی

📱 @Abrplusdocs
t.me/abrplusdocs

ویدیویی خیره‌کننده از ابرکامپیوتر اسپیس‌ایکس در ممفیس

شرکت SpaceX ویدئویی از زیرساخت محاسباتی عظیم خود در منطقه ممفیس منتشر کرد. مرکز اصلی این مجموعه Colossus نام دارد و برای آموزش مدل‌های بزرگ هوش مصنوعی و توسعه هوش مصنوعی گراک طراحی شده است.

ساخت نخستین نسخه Colossus برخلاف برآورد ۲۴ ماهه، تنها در چهار ماه تکمیل شد. شرکت SpaceX برای این پروژه یک نیروگاه دائمی با ظرفیت ۱٫۲ گیگاوات در ساوتهیون در حال ساخت است. مدیریت انرژی در این مجموعه با استفاده از بیش از ۲۰۰ باتری Tesla Megapack انجام می‌شود. هدف نهایی SpaceX AI رسیدن به ظرفیت یک میلیون GPU تا سال ۲۰۲۶ است.
@abrplusdocs

🟢 نسخه جدید اوپن‌استک، Hibiscus، همین روزها منتشر می‌شه
◀️ طبق برنامه رسمی OpenStack، نسخه ۲۰۲۶.۲ با نام Hibiscus قراره دقیقاً همین امروز (۳۰ سپتامبر) منتشر بشه
◀️ این نسخه یه ریلیز معمولیه، نه SLURP
◀️ نکته جالب برای کسایی که کامیونیتی رو دنبال می‌کنن: کامیونیتی OpenStack اسم نسخه بعدی یعنی ۲۰۲۷.۱ رو هم همین اواخر انتخاب کرد و روش گذاشتن Indri که اون یکی SLURP خواهد بود.
◀️ تو همین نسخه، یه تغییر مهم برای کسایی که با Ironic کار می‌کنن هم اتفاق افتاده: نسخه ۳۶ از Ironic منتشر شده، در کنار آپدیت‌های استاندارد کتابخانه‌های Oslo و OpenStack SDK.

✅ اگه رو نسخه ۲۰۲۶.۱ Gazpacho هستید، عجله‌ای برای آپگرید به Hibiscus نکنید؛ چون این نسخه معمولی، مسیر مستقیم SLURP نداره. ولی اگه دنبال یه برنامه آپگرید بلندمدت هستید، بهتره منتظر ۲۰۲۷.۱ Indri بمونید که قراره نسخه بعدی باشه.

#OpenStack #Hibiscus #KollaAnsible #اخبار

📱 @Abrplusdocs
t.me/abrplusdocs