پس از مرگ آسیب‌پذیری: ژوئیه ۲۰۲۳

در طول دو هفته گذشته، Metabase بدترین آسیب‌پذیری در تاریخ پروژه را داشته است. ما می‌دانیم که این آسیب‌پذیری برای شما، جامعه ما، بسیار مخرب بوده است، و به ویژه متأسفیم که مجبور شدیم دو فراخوان متوالی برای ارتقا در روز جمعه اعلام کنیم.

حالا که گرد و غبار عمدتاً نشسته است، می‌خواستیم آنچه اتفاق افتاد و چرا آنچه را که انجام دادیم انجام دادیم را بیان کنیم. ما می‌دانیم که فراخوان "اکنون ارتقا دهید" بدون هیچ توضیحی مبهم بود و نیاز به اعتماد زیادی از جامعه ما به قضاوت ما داشت. امیدواریم که با شفاف بودن درباره آنچه اتفاق افتاد (هم خوب و هم بد)، جامعه در آینده به اعتماد به ما ادامه دهد.

در مرکز داستان یک خوشه نسبتاً ناخوشایند از آسیب‌پذیری‌ها است، و برای بهترین درک رویدادها در جدول زمانی، مفید است که آسیب‌پذیری‌های واقعی در بازی را درک کنید.

فقط یک هشدار—این یک پست نسبتاً طولانی و نسبتاً فنی است که برای کسانی که Metabase را مدیریت و امن می‌کنند هدف‌گذاری شده است.

چه اتفاقی افتاد

آسیب‌پذیری

قلب این خوشه از آسیب‌پذیری‌ها پایگاه داده‌ای بود که ما پشتیبانی می‌کردیم—H2. H2 یک پایگاه داده جاسازی شده مبتنی بر JVM است. ما از H2 به عنوان یک پایگاه داده "باتری‌های شامل" برای Metabase برای ذخیره حساب‌های کاربری، تعاریف داشبورد، تنظیمات و غیره استفاده کردیم. وقتی ما راه‌های ارسال داده نمونه را ارزیابی می‌کردیم، برنده آنجا نیز شد. به عنوان بخشی از استفاده از H2 برای ارسال پایگاه داده نمونه ما، تصمیم گرفتیم که همچنین به مشتریان امکان اتصال هر پایگاه داده H2 که ممکن است در اطراف داشته باشند را بدهیم. هرگز به طور گسترده استفاده نشد، اما "رایگان آمد"، و بنابراین ما عمدتاً H2 را به عنوان یک گزینه پشتیبانی شده رها کردیم.

چون H2، از نظر عملی، عمدتاً برای جاسازی در داخل برنامه‌های دیگر استفاده می‌شود، تعداد زیادی ویژگی دارد که برای چندین کلاینت در ذهن طراحی نشده‌اند. به طور خاص‌تر، راه‌هایی برای وادار کردن H2 به اجرای مفسرها درون فرآیند وجود دارد، آرگومان‌های رشته اتصال وجود دارد که به شما امکان اجرای SQL (یا هر چیز دیگری) را می‌دهد، و به طور کلی کمبود سخت‌سازی نسبت به کلاینت‌های مخرب وجود دارد. ما قبلاً یک راه انجام این کار را پیدا و رفع کردیم (از طریق پارامترهای INIT روی رشته اتصال)، اما آسیب‌پذیری اخیر (یا واقعاً یک خوشه از سه آسیب‌پذیری مختلف) از این ناشی شد.

سه مسئله متمایز در بازی بودند:

1. می‌توانستید از unicode (به عنوان مثال، یک ï به جای یک I) استفاده کنید تا از بررسی‌های ما برای کلمه کلیدی INIT عبور کنید، چون H2 آنها را زیر کاپوت تبدیل می‌کند (تشکر از Reginaldo Silva).
2. می‌توانستید Metabase را فریب دهید تا اتصال پایگاه داده را به عنوان یک اتصال PostgreSQL درمان کند، اما درایور H2 را به جای آن توسط JDBC DriverManager بارگذاری کند با مخفی کردن یک رشته اتصال H2 در payload جزئیات (تشکر از مؤسسه پاسخ امنیتی Chaitin و bluE0).
3. گزینه TRACE_LEVEL_SYSTEM_OUT در H2 در برابر تزریق SQL آسیب‌پذیر است (تشکر از AssetNote و Maxwell Garrett).

تا اینجا، این مسائل یک مجموعه بسیار آزاردهنده از آسیب‌پذیری‌ها را تشکیل می‌دهند که به کسی که یک اتصال پایگاه داده جدید اضافه یا اعتبارسنجی می‌کند امکان نفوذ به OS میزبان در حال اجرای Metabase را می‌دهد. به طور معمول، دسترسی OS میزبان محدود به مدیران Metabase است، بنابراین در حالی که یک مشکل است که مطمئناً، یک رویداد متوقف کردن جهان نیست.

اما دو قطعه کلیدی دیگر از پازل وجود داشت.

اول، مشتریان اغلب رشته‌های اتصال را اشتباه می‌گیرند، و رایج است که یک اتصال تست قبل از تأیید ورود کسی از یک رشته اتصال انجام شود. ما یک فراخوانی API برای تسهیل این بررسی قبل از ذخیره یک اتصال پایگاه داده ارائه دادیم. در گردش معمولی پنل مدیریت برای افزودن پایگاه داده، این توسط یک بررسی API برای امتیازات مدیر محافظت می‌شد.

قطعه نهایی و شرم‌آورترین پازل: ما یک فرآیند راه‌اندازی داریم که یک حساب کاربری و یک پایگاه داده را در یک فراخوانی API ایجاد می‌کند. ما این دو عمل را در یک مرحله ترکیب کردیم و یک endpoint API غیراحراز هویت شده /api/setup/validate را در معرض نمایش گذاشتیم که سعی می‌کرد به یک رشته اتصال پایگاه داده متصل شود. این endpoint فقط در صورت استفاده با یک setup_token قابل دسترسی بود. این setup_token هرگز قرار نبود به طور عمومی در معرض نمایش قرار گیرد، و به طور معمول Metabase توکن را بلافاصله پس از اولین استفاده حذف می‌کرد. اوایل سال گذشته، با این حال، ما برخی تغییرات برای اجازه تزریق توکن از طریق یک متغیر محیطی انجام دادیم، و به طور ناخواسته توکن را به تنظیمات در معرض نمایش در /api/session/properties نشت دادیم (علاوه بر پاک کردن صحیح توکن پس از اولین استفاده).

این قطعات، ترکیب شده با توانایی وادار کردن H2 به اجرای دستورات در OS میزبان، منجر به یک اجرای کد از راه دور غیراحراز هویت شده شد، و دو جمعه متوالی را برای جامعه Metabase خراب کرد.

با قرار دادن همه اینها با هم، کسی می‌توانست:

1. /api/session/properties را فراخوانی کند تا توکن راه‌اندازی را دریافت کند.
2. از توکن راه‌اندازی برای فراخوانی /api/setup/validate استفاده کند.
3. از بررسی‌های از دست رفته استفاده کند تا H2 را وادار به اجرای دستورات روی سیستم عامل میزبان کند.
4. یک shell معکوس باز کند، حساب‌های مدیر ایجاد کند و غیره.

به طور خلاصه، این یک زنجیره حمله بسیار جدی بود.

گزارش اولیه و رفع (۱۳-۲۱ ژوئیه)

در ۱۳ ژوئیه ما یک گزارش از یک محقق خارجی درباره یک آسیب‌پذیری امنیتی در برنامه دریافت کردیم. گزارش مسیر (بسیار آسان) بالا را برای اجرای کد سفارشی در سرور Metabase بدون نیاز به احراز هویت جزئی کرد (ما این آسیب‌پذیری اولیه را آسیب‌پذیری "AssetNote" می‌نامیم، چون تیم Assetnote آن را گزارش داد).

تا ۱۴ ژوئیه، ما یک رفع برای این آسیب‌پذیری نوشتیم، تست کردیم و ساختیم. ما آن را به ۲۰۰۰+ سرور که به نمایندگی از مشتریان Metabase Cloud میزبانی می‌کنیم فشار دادیم.

با این حال، در این نقطه ما کمی مشکل با آنچه باید بعد انجام دهیم داشتیم. ما صدها مشتری میزبانی خود داریم که مسئولیت قراردادی و اخلاقی برای محافظت از آنها داشتیم. ما همچنین یک جامعه از ۵۰,۰۰۰+ سازمان داریم که Metabase را روی سرورهای خود اجرا می‌کنند. سوء استفاده از آسیب‌پذیری پس از دانستن وجود آن پیش پا افتاده است، و در حالی که آسیب‌پذیری نیاز به برخی مهارت‌های خاص برای دسترسی به انبار داده زیربنایی با استفاده از آن دارد، سوء استفاده برای DDoS، اسپم و استخراج رمزارز تقریباً نیاز به هیچ مهارت یا تلاشی ندارد. ما همچنین راهی برای مجبور کردن هیچ کسی به ارتقا نداریم، یا حتی راهی برای ارسال ایمیل به کسانی که سرورهای Metabase را اجرا می‌کنند.

گزینه استاندارد این بود که یک وصله صادر کنیم، به جهان درباره وصله اطلاع دهیم، و به هر کسی که به ما پول نمی‌دهد تا سرورهای آنها را مدیریت کنیم اجازه دهیم از خود دفاع کنند. اگر این آسیب‌پذیری یک مسئله معمولی بود که به هیچ کسی در هر جای جهان امکان دسترسی به داده کاربر در هر نمونه Metabase را نمی‌داد، ما فقط آن را انجام می‌دادیم.

ما واقعاً می‌خواستیم بهتر از آن عمل کنیم. پس از کمی فکر، ما با یک برنامه سه مرحله‌ای به پایان رسیدیم.

1. باینری‌های وصله شده را به مشتریان پرداخت کننده خود بدهیم. ما به آن مشتریانی که forkهای سفارشی اجرا می‌کنند وصله منبع واقعی را تحت NDA ارائه می‌دهیم.
2. پس از یک هفته، یک رفع را بدون کد منبع به طور عمومی منتشر کنیم. به جامعه خود اطلاع دهیم که یک RCE (اجرای کد از راه دور) غیراحراز هویت شده بود، و که ارتقای فوری ضروری است.
3. پس از یک هفته اضافی، رفع را در مخزن اصلی و عمومی خود ادغام کنیم، و یک CVE منتشر کنیم، همه کسانی که به ما کمک کردند این را پیدا و رفع کنند را نسبت دهیم.

در این برنامه، ما یک معامله بسیار خاص انجام می‌دادیم. ما می‌دانستیم که یک JAR Clojure می‌تواند decompile شود و کد منبع JVM decompile شده بررسی شود (Clojure به طور خاص اغلب منبع را در jar شامل می‌شود). ما باینری‌های وصله شده خود را از این کد منبع نیز جدا کردیم. در طول این فرآیند انتشار، ما می‌دانستیم که ارائه یک رفع بدون اطلاع دادن به یک محقق یا مهاجم پیچیده از اینکه باگ چیست و چگونه بهره‌برداری شود غیرممکن است. اما ما امیدوار بودیم که بتوانیم به پایه نصب خود تا حد امکان روز برای ارتقا بخریم قبل از اینکه بهره‌برداری وارد گردش عمومی شود.

عجله کنید و صبر کنید (۱۸-۲۱ ژوئیه)

در ۱۸ ژوئیه، ما باینری‌های وصله شده و جدا شده را در جای خود داشتیم و به مشتریان میزبانی خود اعلام کردیم.

این وصله اولیه:

• کاملاً endpoint آسیب‌پذیر را از استفاده مسدود کرد اگر قبلاً نمونه را راه‌اندازی کرده بودید (یعنی گردش راه‌اندازی را تکمیل کرده بودید).
• برخی رشته‌هایی که به رشته اتصال پایگاه داده منتقل می‌شدند که این حمله اول را در هر دو endpoint /api/setup/validate (عمومی، نیازی به احراز هویت برای آن ندارید) و /api/database (خصوصی، نیاز به احراز هویت دارید) ممکن می‌کرد را تشخیص داد. اگر پیدا می‌شدند، اینها به جای انتقال آنها به H2 یک خطا برمی‌گرداندند.

ما باینری‌های وصله شده تمام نسخه‌های تحت تأثیر را با این مشتریان به اشتراک گذاشتیم، اما منبع را نگه داشتیم. برای مشتریان با یک fork سفارشی، ما از آنها خواستیم که مستقیماً با ما تماس بگیرند، و ما وصله را تحت NDA به آنها دادیم. تقریباً بیست مشتری forkهای سفارشی اجرا می‌کردند و با ما تماس گرفتند.

تا اینجا خوب بود.

در طول سه روز بعدی، برخی رویدادها اتفاق افتاد که برنامه‌های ما را تغییر داد.

صبر کنید و تماشا کنید (۲۱-۲۷ ژوئیه)

ما به ظاهر دو گزارش مستقل از مشتریان دریافت کردیم که اظهار داشتند که قبلاً از آسیب‌پذیری اطلاع داشتند. در آن زمان، بسیار تعجب‌آور بود، چون آسیب‌پذیری بیش از یک سال قبل از پیدا شدن وجود داشت، و بهره‌برداری نیاز به استفاده نسبتاً خاص از تعدادی شکاف در محصول ما داشت. ما کمی عمیق‌تر کاوش کردیم و یاد گرفتیم که هر دو مشتری توسط تیم تحقیقاتی اصلی که آسیب‌پذیری را کشف کرده بود مطلع شده بودند (هر دو مشتری یک bug bounty روی مسائل امنیتی Metabase ارائه می‌دهند).

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

در ۲۱ ژوئیه، ما توییت کردیم، وبلاگ خود را به‌روزرسانی کردیم، در LinkedIn پست کردیم، و یک ایمیل به کل فهرست ایمیل Updates خود که چند ده هزار نفر برای آن ثبت‌نام کرده بودند ارسال کردیم.

ما شروع به نظارت بر رسانه‌های اجتماعی کردیم تا ببینیم آیا چیزی ظاهر می‌شود، اما برای روزها هیچ چیز مرتبطی وجود نداشت، از جمله در Hacker News. برای تعدادی روز، کمی علاقه وجود داشت، اما خبری از decompile کردن و بازسازی بهره‌برداری توسط هیچ کسی نبود.

در ۲۶ ژوئیه، ما یک گزارش امنیتی دیگر دریافت کردیم (آسیب‌پذیری "Qing" از این به بعد)، که جزئیات نحوه دور زدن کنترل‌ها روی endpoint /api/database (که به مدیران احراز هویت شده محدود است) با استفاده از یک کلید جداگانه در جزئیات اتصال (نه همه در همان رشته اتصال) را جزئی کرد، و همچنین یک تغییر از آسیب‌پذیری AssetNote که از یک اتصال به یک پایگاه داده خارجی برای اجرای دستورات استفاده می‌کرد.

در حالی که نگران‌کننده بود، این اکتشافات نیاز به یک مدیر وارد شده داشت، و تا زمانی که باینری‌های وصله شده قبلی مستقر بودند، هیچ RCE غیراحراز هویت شده‌ای ممکن نبود.

در ۲۷ ژوئیه، یک مهندس ("Reginaldo" از این به بعد) موفق به مهندسی معکوس وصله ما شد و یک حمله جدید روی endpoint عمومی /api/setup/validate کشف کرد. این حمله که از یک کاراکتر diacritic (glyph اضافه شده به یک حرف) برای دور زدن برخی کنترل‌هایی که ما در جای خود داشتیم استفاده می‌کرد، اما آسیب‌پذیری فقط نمونه‌های غیرراه‌اندازی شده (نمونه‌هایی که در حالت راه‌اندازی بودند) را تحت تأثیر قرار می‌داد، و آسیب‌پذیری دیگری که همچنین endpoint /api/database (خصوصی) را تحت تأثیر قرار می‌دهد، که سرور H2 را به عنوان یک پایگاه داده خارجی که می‌توانید دستورات را روی آن اجرا کنید باز می‌کند.

این کمی شرط را بالا برد، چون اکنون یک RCE غیراحراز هویت شده علیه یک نمونه وصله شده ممکن بود—اگرچه فقط برای چند دقیقه زمانی که یک نمونه برای اولین بار در حال راه‌اندازی است.

عجله به یک انتشار عمومی (۲۸-۳۱ ژوئیه)

بعد از آن روز (شب در مناطق زمانی US)، یک گروه چهارم از محققان امنیتی یک پست وبلاگ بدون تماس قبلی با ما منتشر کردند. این پست شامل جزئیات درباره آسیب‌پذیری "AssetNote" بود، که منجر به انتشار یافته‌های AssetNote شد (چون گربه از کیسه خارج شده بود).

بیدار شدن به آن در ۲۸ ژوئیه، ما دیدیم که این پست شامل دیگری، حمله "مخفی" بود که نویسندگان "برای خواننده برای کشف باقی گذاشتند". ما با آنها تماس گرفتیم، و آنها به ما درباره یک وسیله قبلاً ناشناخته برای رسیدن به H2 از طریق JDBC DriverManager اطلاع دادند.

ما از این حمله جدید در لحظه دقیق ساخت نسخه 46.6.3 (وصله‌ای که آسیب‌پذیری‌های "Qing" و "Reginaldo" را رفع کرد) مطلع شدیم.

ما آن وصله را منتشر کردیم، اما همچنین، برای احتیاط، تصمیم گرفتیم یک انتشار نقطه دیگر (46.6.4) که H2 را به عنوان یک پایگاه داده پشتیبانی شده برای تحلیل حذف کرد منتشر کنیم. همانطور که واضح بود که جامعه امنیتی گسترده‌تر از علل ریشه زیربنایی آسیب‌پذیری آگاه است، ما همچنین یک پست وبلاگ قرار دادیم و یک ایمیل به مشتریان و کاربران OSS خود برای ارتقا، یا مسدود کردن تمام endpointهای مرتبط تا زمانی که بتوانند ارتقا دهند ارسال کردیم.

در حالی که همه اینها در حال انجام بود، ما مشکل را روی سرورهای خود برای مشتریان Metabase Cloud کاهش دادیم. به محض اطلاع از هر بهره‌برداری، ما مسدودهای سطح شبکه را روی تمام endpointهای API مرتبط تنظیم کردیم، فروشگاه خود را برای ثبت‌نام‌های جدید بستیم، و فرآیند سرگرم‌کننده ممیزی هر تکه لاگ که داشتیم را آغاز کردیم. تا اواخر شب شنبه (۲۹ ژوئیه)، ما هر سروری که هر فراخوانی به endpointهای آسیب‌پذیر داشت را به طور فردی ممیزی کردیم، و هیچ مدرکی از دستکاری پیدا نکردیم. ما هنوز مراقب هر فعالیت مشکوکی هستیم، و گفتگوهای داخلی زیادی درباره آنچه باید از این یاد بگیریم داریم.

در ۳۱ ژوئیه، ما یک توییت و پست Linkedin دیگر به جامعه خود ارسال کردیم.

در مجموع، ما موفق شدیم تقریباً یک هفته از تلاش‌های مبهم‌سازی خود بین زمانی که نسخه وصله شده عمومی خود را منتشر کردیم و زمانی که آسیب‌پذیری وارد دانش عمومی شد به دست آوریم. ایده‌آل نیست، اما امیدواریم که به افراد بیشتری نسبت به آنچه در غیر این صورت قادر بودند زمان برای ارتقا داد.

وضعیت فعلی

خلاصه: اگر میزبانی خود را انجام می‌دهید و آخرین ارتقا قبل از ۲۸ ژوئیه ۲۰۲۳ بود، فوراً ارتقا دهید.

اگر یک مشتری Metabase Cloud هستید، تحت تأثیر نیستید.

اگر میزبانی خود را انجام می‌دهید و آخرین باینری‌ها (46.6.4 در این زمان) را اجرا می‌کنید، در امان هستید.

اگر در نسخه Metabase از 43-45 هستید، و به آخرین نسخه‌های جزئی 43.7.3، 44.7.3، 45.4.3 یا بالاتر ارتقا نداده‌اید شما آسیب‌پذیر هستید.

اگر 42 یا پایین‌تر را اجرا می‌کنید، تحت تأثیر این آسیب‌پذیری نیستید. اما در معرض بسیاری از مسائل امنیتی و باگ‌های دیگر هستید، بنابراین ما توصیه می‌کنیم که در اسرع وقت ارتقا دهید.

از این قسمت چه یاد گرفتیم؟

خوب، ما یاد گرفتیم که اگر یک باینری وصله شده بدون هیچ اطلاعاتی منتشر کنید، حداکثر پنج روز طول می‌کشد تا bytecode decompile شود، و آسیب‌پذیری زیربنایی شناسایی و بازسازی شود.

ما یاد گرفتیم که رشته‌های اتصال ارائه شده توسط کلاینت باید با بررسی بیشتر درمان شوند، و که درایورهای JDBC قابل اعتماد نیستند. ما در ابتدا به ویژه درباره استفاده از setup_token برای ایجاد کاربران مدیر اضافی پارانویا داشتیم، و یاد گرفتیم که باید به همان اندازه درباره هر چیزی که یک اتصال پایگاه داده را باز می‌کند پارانویا داشته باشیم.

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

ما هنوز در حال انجام post-mortem هستیم، و بدون شک چیزهای بیشتری در روزهای آینده یاد خواهیم گرفت.

ضمیمه

• چگونه بدانم آیا تحت تأثیر هستم/بودم
• نحوه دانستن چقدر عمیق مهاجم رفت و آیا اطلاعاتی استخراج شد
• نحوه دانستن اینکه آیا مهاجم یک shell معکوس باز کرده است
• در مورد این چه باید بکنم؟
• این آسیب‌پذیری به طور فعال بهره‌برداری می‌شود

چگونه بدانم آیا تحت تأثیر هستم/بودم

اگر یک مشتری Metabase Cloud هستید، شما به هیچ طریقی که ما قادر به پیدا کردن بودیم تحت تأثیر نبودید. ما تمام آسیب‌پذیری‌ها را به محض دریافت گزارش‌ها وصله و مسدود کردیم. تمام نمونه‌ها در podهای Kubernetes ما بازیافت و از تصاویر امن شناخته شده بازسازی شده‌اند. ما لاگ‌های تمام مشتریان خود را به چند هفته قبل بررسی کردیم و چیزی برای ایجاد شک به بهره‌برداری پیدا نکردیم. ما به نظارت بر زیرساخت خود ادامه خواهیم داد تا مطمئن شویم شما محافظت می‌شوید.

اگر Metabase را میزبانی خود می‌کنید:

این آسیب‌پذیری‌ها از می ۲۰۲۲ وجود داشته‌اند، بنابراین، در صورتی که لاگ‌های نمونه Metabase خود را ذخیره کرده‌اید، یا یک load balancer/reverse proxy در مقابل نمونه Metabase خود دارید، باید الگوی زیر را بررسی کنید:

اگر در لاگ‌ها می‌بینید که یک فراخوانی API POST به /api/setup/validate در هر زمانی بعد از راه‌اندازی اولیه نمونه شما که یک وضعیت 2xx یا 400 برمی‌گرداند دریافت کرده‌اید، و در نسخه‌ای که ما در ۱۸ ژوئیه ۲۰۲۳ منتشر کردیم نبودید، پس نمونه شما ممکن است به خطر افتاده باشد (یعنی: نمونه شما ممکن است تحت کنترل یک مهاجم باشد).

نحوه دانستن چقدر عمیق مهاجم رفت و آیا اطلاعاتی استخراج شد

۲ نوع حمله وجود دارد:

• اگر یک فراخوانی دیدید که وضعیت 2xx برمی‌گرداند، پس قادر به دیدن کدی که مهاجم روی نمونه شما اجرا کرد نخواهید بود، بنابراین باید بدترین سناریو را در نظر بگیرید: یک مهاجم به سرور وارد شد، اعتبارنامه‌های پایگاه داده برنامه را دریافت کرد و قادر به اتصال به آن بود، و آنها اعتبارنامه‌های انبار داده متصل شما را استخراج کردند.
• اگر یک فراخوانی دیدید که وضعیت 400 برمی‌گرداند، پس لاگ‌های Metabase کدی که مهاجم روی نمونه شما اجرا کرد را چاپ می‌کنند. به عنوان مثال،

از این نقطه، مهاجم قادر به دریافت رشته اتصال به پایگاه داده برنامه Metabase خواهد بود، که به نوبه خود شامل رشته اتصال به انبار داده شما است.

نحوه دانستن اینکه آیا مهاجم یک shell معکوس باز کرده است

اگر top را در سرور یا کانتینر در حال اجرای Metabase اجرا کنید و یک فرآیند bash با پارامترها (مانند echo، یک پارامتر رمزگذاری شده و غیره) در حال اجرا ببینید، نمونه یک shell معکوس باز دارد (به عنوان مثال، PID 3763 در اسکرین‌شات زیر).

اگر netstat -antp را در سرور یا کانتینر در حال اجرای Metabase اجرا کنید و اتصالات فعال برای پورت‌هایی که Metabase استفاده نمی‌کند ببینید، و اتصال یک وضعیت ESTABLISHED دارد (به عنوان مثال، اتصال از آدرس خارجی 172.23.0.2:9001 در اسکرین‌شات زیر).

اگر shell برای مدتی خارج شده باشد، ممکن است همچنین اتصالات در وضعیت FIN_WAIT2 ببینید، مانند در این مثال

در مورد این چه باید بکنم؟

اگر مشکوک هستید که ممکن است تحت تأثیر قرار گرفته باشید، ما توصیه می‌کنیم:

1. نمونه خود را به آخرین باینری‌ها، با استفاده از یک نمونه سرور تازه ارتقا دهید.
2. اعتبارنامه‌های انبار داده خود را بچرخانید.
3. دسترسی IP به انبار داده خود را از میزبان‌های ناشناس محدود کنید.
4. بررسی کنید که هیچ حساب کاربری ناآشنا در نمونه Metabase شما وجود ندارد.
5. توکن‌های اعتبارنامه Slack و SMTP استفاده شده در Metabase را بچرخانید.

این آسیب‌پذیری به طور فعال بهره‌برداری می‌شود

ما آگاه هستیم که برخی توسعه‌دهندگان بدافزار/botnet کد بهره‌برداری را در حملات خود شامل کرده‌اند. ما همچنین از حداقل یک نمونه از حمله به سرورهای Metabase برای استخراج رمزارز و استفاده از سرورها به عنوان یک node برای حملات DDoS آگاه هستیم.

ما از هیچ آسیب‌پذیری دیگری در endpointهای ذکر شده آگاه نیستیم.