روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ 

مقدمه

این گزارش تحقیقات مربوط به واحد مرکزی مرسدس بنز را که توسط تیم ما ساخته شده است، پوشش می‌دهد. جدیدترین واحد مرکزی (سیستم اطلاعات سرگرمی) مرسدس بنز، تجربه کاربری مرسدس بنز (MBUX) نام دارد. ما آنالیز نسل اول MBUX را انجام دادیم. MBUX قبلاً توسط KeenLab تجزیه و تحلیل شده بود. گزارش آنها نقطه شروع خوبی برای بررسی عمیق در داخل MBUX و درک معماری سیستم است. در تحقیق خود ما تجزیه و تحلیل دقیقی از نسل اول زیرسیستم‌های MBUX انجام دادیم که در تحقیقات KeenLab نادیده گرفته شده‌اند: تشخیص (CAN، UDS و غیره)، اتصالات از طریق USB و IPC سفارشی. این مقاله بدون کار شگفت‌انگیز Radu Motspan، Kirill Nesterov، Mikhail Evdokimov، Polina Smirnova و Georgy Kiguradze که این تحقیق را انجام دادند، آسیب‌پذیری‌ها را کشف کردند و زمینه را برای این گزارش فراهم کردند، امکان پذیر نبود. تشکر ویژه از Mercedes-Benz Group AG برای حرفه‌ای بودن و رسیدگی سریع به تمام آسیب‌پذیری‌های شناسایی شده.

نرم افزار تشخیصی

برای نگاهی اولیه به معماری خودرو، استفاده از نرم افزار تشخیصی (که فقط برای کاربران دارای گواهینامه در دسترس است) برای اسکن واحد کنترل الکترونیکی (ECU)، شناسایی نسخه آن و آزمایش عملکرد عیب‌یابی نرم افزار مفید است. چندین ابزار تشخیصی وجود دارد که با استفاده از انواع مختلف ارتباط، اتصال به وسیله نقلیه را ممکن می‌سازد. در تحقیق خود، از ترکیبی از ابزارهای تشخیصی استفاده کردیم: یک رابط سخت افزاری خاص و یک برنامه نرم افزاری مربوطه برای برقراری ارتباط با وسیله نقلیه از طریق دستگاه سخت افزاری. این راه‌اندازی به ما امکان می‌دهد تا از طریق DoIP (پروتکل تشخیصی از طریق اینترنت) ارتباط برقرار کنیم:

ارتباط بین نرم‌افزار تشخیصی و سخت‌افزار

ارتباط TCP بین ابزار تشخیصی و دستگاه سخت افزاری تشخیصی از طریق اترنت با استفاده از پروتکل‌های سفارشی (واحد داده پروتکل، PDU) انجام می‌شود. در مرحله اول، دستگاه سخت افزاری تشخیصی از یک پروتکل سفارشی مبتنی بر ASCII (CSD) استفاده می‌کند. احراز هویت کاربر، بررسی نسخه، تنظیمات پیکربندی را انجام داده و محیط اولیه را برای پردازش پروتکل لایه بالایی (PDU) فراهم می‌کند. پروتکل لایه بالایی دارای فرمت باینری است. برای ارسال پیام‌های خدمات تشخیصی جهانی (UDS)، راه اندازی ارتباطات DoIP و غیره استفاده می شود. برای تجزیه و تحلیل این پروتکل، از یک اسکریپت نوشته شده در LUA استفاده کردیم: [pduparser.lua]. با استفاده از این اسکریپت، دستورات UDS را می‌توان به راحتی از ترافیک شبکه معمولی ارتباط بین نرم افزار تشخیصی و سخت افزار تشخیص داد:

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

 

معماری

معماری MBUX به شرح زیر است:
بخش‌های اصلی MBUX عبارتند از:

MMB (Multi Media Board) - بخش اصلی واحد اصلی (HU) که ​​شامل تمام زیرسیستم‌ها است.

BB (Base Board) - بخشی با تراشه برای ارتباطات شبکه‌های مختلف.

CSB (Country Specific Board) - بخش توسعه یافته‌ای که از طریق اترنت داخلی با MMB ارتباط برقرار می‌کند.

RH850 - ماژول طراحی‌شده برای برقراری ارتباط بین باس‌های سطح پایین.

اطلاعات کامل در مورد معماری MBUX را می‌توان در تحقیق KeenLab یافت.

تنظیمات تست

برای تحقیق خود از دو تنظیم تست استفاده کردیم:

 

یک ماشین واقعی - مرسدس B180؛

یک بستر آزمایشی - پلتفرم خودمان برای آزمایش سخت افزار و نرم افزار، که برای هدف این مطالعه طراحی کردیم.

ضد سرقت

هنگام مدل‌سازی بستر آزمایش، باید ویژگی اصلی ضد سرقت را دور بزنیم، زیرا پس از راه‌اندازی خودرو واقعی، واحد مرکزی روی گذرگاه CAN منتظر احراز هویت می‌ماند. همانطور که در تحقیقات KeenLab ذکر شد، دستورات خاصی باید از طریق CAN برای بیدار کردن سیستم ارسال شوند. ما نمی‌توانستیم این را در تنظیماتمان تقلید کنیم، بنابراین یونیت سر وارد حالت ضد سرقت می‌شد و کاربر نمی‌توانست با آن ارتباط برقرار کند. با اتخاذ یک رویکرد تجربی، متوجه شدیم که برخی از پیام‌های CAN واحد مرکزی را مجبور می‌کند تا وضعیت ضد سرقت را بازنشانی کند. در واقع این پیام‌ها چک ضد سرقت را راه اندازی می‌کنند. به عنوان مثال، هنگامی که هد یونیت سعی می کند نمایشگر را خاموش کند، پیام CAN بررسی ضد سرقت را آغاز می کند و یونیت سر را برای چند ثانیه همچنان در دسترس باقی می‌گذارد. برای بررسی یکپارچه و پایدار، ما یک اسکریپت ایجاد کردیم که به طور مداوم این پیام را در یک حلقه ارسال می‌کرد.

 در نتیجه، یونیت سر برای مدت طولانی قابل دسترسی است و بین حالت احراز هویت و حالت ضد سرقت تغییر می‌کند.

 

سیستم عامل

MMB روی لینوکس اجرا می شود و فایل سیستم های آن در eMMC قرار دارند. ما باید eMMC را از روی برد مدار چاپی با لحیم کاری خارج کنیم. در داخل، چندین پارتیشن وجود دارد:

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

به روز رسانی را باز کنید

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

 

فایل‌هایی با \*ALL\*، حاوی فایل‌های *.CFF، *.SMR-F و *.bin.

فایل‌هایی با \*CFF\*، که فقط حاوی فایل‌های *.CFF هستند.

فایل هایی با \*SMR-F\* که فقط حاوی فایل های *.SMR-F هستند.

به طور کلی فایل های *.bin محفظه هایی با ساختار فایل سفارشی هستند. آنها را می توان با zlib یا روش های دیگر رمزگذاری کرد.

*فایل های SMR-F فشرده شده‌اند و همچنین ساختار فایل سفارشی دارند. علاوه بر ابرداده در متن ساده، آنها همچنین حاوی داده‌های رمزگذاری‌شده هستند که ابزار تشخیصی از کتابخانه‌های مشترک خود برای رمزگشایی استفاده می‌کند. پس از رمزگشایی، فایل به دست آمده حاوی فراداده و یک ظرف است، درست مانند فایل های *.bin.

 

*فایل‌های CFF حاوی همان محتوای محتوی فایل‌های *.SMR-F هستند، اما فشرده نشده‌اند. این قالب برای نسل های قبلی واحد سر استفاده می شد.

 

IPC سفارشی

در داخل یونیت سر، سرویس‌های سفت‌افزار از پروتکل‌های IPC سفارشی برای ارتباط بین رشته‌های خود، سایر سرویس‌ها و سایر ECU‌ها استفاده می‌کنند. سه پروتکل اصلی پرکاربرد وجود دارد:

thriftme

MoCCA

GCF

این پروتکل‌ها را می‌توان همزمان استفاده کرد. علاوه بر این، هر سرویس می تواند از همه آنها به طور همزمان استفاده کند. با دانستن داخلی و API این پروتکل ها، درک گردش کار سرویس ها آسان تر است.

 thriftme

این پروتکل RPC بر اساس پروتکل منبع باز Apache Thrift است. ویژگی متمایز اصلی آن این است که thriftme به مشترکین اجازه می دهد تا از رویدادهای خاص مطلع شوند. سوکت یونیکس، TCP، UDP، SSL و غیره می تواند به عنوان یک انتقال برای این پروتکل استفاده شود. عملکرد اصلی این پروتکل در کتابخانه libthriftme.so.2.7.2 پیاده سازی شده است.

 

کلس پایه در RPC thriftme "thrift::TServiceBroker" است که ارتباط با انتقال و رابط های تماس سرویس ها و مشتریان را جدا می کند. در thriftme، نسخه بروکر سرویس نمونه “thrift::lisa::CTLisaServiceBroker” است که از “thrift::TServiceBroker” به ارث می‌رسد.

 

خدمات در thriftme از "thrift::lisa::TLisaServerBase" (که به نوبه خود از "thrift::TServiceProcessor" به ارث می رسد) به ارث می رسد. خدمات از طریق "Trift::TServiceProcessor::registerService" در کارگزار خدمات ثبت می شود. حمل و نقل مورد استفاده مشتریان از طریق "Trift::lisa::CTLisaServiceBroker::addServers" ثبت می شود (که عبارت "thrift::TServiceBroker::addServer" را در بر می گیرد). توابع رابط سرویس از طریق "Trift::TServiceProcessor::tmRegisterCallback" ثبت می شوند. کنترل کننده به صورت آرگومان به این تابع صادرات ارسال می شود و در حین پردازش درخواست مشتری فراخوانی می شود. بنابراین نمونه سرویس در حافظه به صورت زیر است:
فیلد «interface1» شامل توابعی است که API سرویس و بسته‌بندی‌های آن‌ها را که قبلاً از طریق «thrift::TServiceProcessor::tmRegisterCallback» ثبت شده‌اند، پردازش می‌کنند. قسمت "interface2" شامل توابعی است که برای اطلاع مشترکین از این سرویس فراخوانی می شود.

 

مشتریان در thriftme از "thrift::lisa::TLisaClientBase" (که به نوبه خود از "thrift::TClient" به ارث می‌رسد) به ارث می‌رسد. در واقع، نمونه های مشتری زمانی توسط کارگزار خدمات ایجاد می شوند که حمل و نقل با موفقیت ایجاد شود. در مورد ما، کارگزار خدمات از کارخانه یک مشتری استفاده می کند که از طریق "thrift::TServiceBroker::tmRegCli" در کارگزار خدمات ثبت شده است. این کارخانه به مشتریان کمک می کند تا از طریق "Trift::TClient::tmRegisterCallback"، کنترل کننده ها را برای اطلاع رسانی در مورد رویدادها ثبت کنند. نمونه طرح‌بندی یک کلاینت thriftme به شرح زیر است:

فیلد "interface1" حاوی کنترل کننده پس از اتصال حمل و نقل فراخوانی می شود. معمولاً از این کنترل کننده برای راه اندازی عملیات اشتراک برای دریافت اعلان های رویداد استفاده می شود. فیلد "interface2" حاوی توابعی است که درخواست ها را به API سرویس ارسال می کند. فیلد "interface3" شامل توابعی است که قبل از شروع عملیات "اطلاع رسانی به مشترکین" این سرویس فراخوانی می شوند. بسته‌بندی‌های آنها قبلاً از طریق "Trift::TClient::tmRegisterCallback" ثبت شده بود.

 

MoCCA

این چارچوب RPC توسط هارمن توسعه داده شده است و بر اساس چارچوب منبع باز DSI است. عملکرد اصلی در کتابخانه "/opt/sys/lib/libSysMoCCAFrameworkSharedSo.so.11" پیاده سازی شده است. این چارچوب به طور گسترده برای ارتباطات بین رشته‌ای استفاده می‌شود. در هنگام راه‌اندازی، سرویس نمونه‌های مؤلفه را از طریق توابع کارخانه ایجاد می‌کند، برای مثال «CHBApplicationBuilder::theCDiagnosisComponentCreator». این نمونه از کلاس "CHBComponent" به ارث می رسد. متغیر جهانی "CHBComponentInfo::spMap" شامل نقشه برداری بین اطلاعات اضافی در مورد اجزا و نام آنها است. این چارچوب به کامپوننت‌ها اجازه می‌دهد تا نام مستعار خود را داشته باشند تا از طریق "CHBComponentInfo::addComponentMapping": "CHBComponentInfo::addComponentMapping(&unk_581498، "FsActionHandler", "FilesystemMainActionHandler") به اجزای دیگر دسترسی داشته باشند. کامپوننت‌ها می‌توانند شامل چندین سرویس و کلاینت باشند و می‌توانند با سرویس‌های خود یا سایر خدمات مؤلفه ارتباط برقرار کنند. معماری اجزا به شرح زیر است:

نمونه‌ای از یک شی کلاینت "CTraceServiceClientBase" است که از "CHBClientBase" به ارث می‌رسد و از شیء پراکسی "CTraceServiceProxy" برای انتقال استفاده می‌کند. شی پراکسی از "CHBProxyBase" به ارث می رسد و از طریق روش کارخانه "CTraceServiceProxy::findOrCreateInstance" ایجاد می شود. سعی می کند از اشیاء پروکسی ایجاد شده در داخل این مؤلفه مجدداً استفاده کند. طرح کلی یک شی کلاینت به شرح زیر است:

 

رابط "IHBEventConsumer" برای پردازش رویدادهای پاسخ در "CTraceServiceClientBase" استفاده می شود. نقطه ورود برای پردازش روش "processEvent" است. برای یافتن یک کنترل کننده از دو مقدار استفاده می کند که به صورت زیر نامیده می شوند:

از فیلد "وضعیت" برای شناسایی پاسخ استفاده کنید: پاسخ استاندارد یک سرویس، پاسخ ناموفق یا نامعتبر. برای شناسایی تابع API از فیلد "internalID" استفاده کنید.

در سمت سرویس در مثال ما از کلاس "CTraceServiceStub" استفاده کردیم. در زیر طرح آن است:

رویداد درخواست در روش "processEvent" پردازش می شود. کنترل کننده تابع API را با استفاده از فیلد "internalID" شناسایی می کند و کنترل کننده شناسایی شده را فراخوانی می کند.

 

GCF

GCF یک پروتکل سفارشی است که برای RPC استفاده می‌شود. این اجازه می‌دهد تا خدمات در روتر ثبت شوند. روتر پیام‌های زیر را از سرویس‌ها و کلاینت‌ها مدیریت می‌کند:

 

پیام کنترل ("CTRL"):

"REGS" - برای ثبت خدمات استفاده می شود.

"REGF" - برای ثبت عملکرد سرویس RPC استفاده می شود.

"EVNT" - توسط سرویس برای اطلاع رسانی به مشتریان در مورد رویداد استفاده می شود.

"CALL" - توسط مشتریان برای فراخوانی عملکرد سرویس استفاده می شود.

و غیره

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

همانطور که در تحقیقات KeenLab ذکر شد، برخی از نقاط تست روی یونیت سر وجود دارد که توسط CSB برای اتصال به MMB استفاده می شود. اتصال پیش فرض را حذف کردیم و کابل RJ45 را برای دسترسی به شبکه داخلی یونیت هد وصل کردیم. این اتصال که با عنوان eth0 برچسب‌گذاری شده است، همانطور که در قوانین فایروال مربوطه در "firewall_prd.policy" بیان شده است، دارای محدودیت هایی است:

 دسترسی به خدمات در MMB از طریق یک آدرس IP ایجاد می‌شود که یک آدرس پیش فرض برای اتصال CSB به MMB است. نتایج اسکن پورت‌های TCP در MMB به شرح زیر است:

پس از اتصال به نقطه آزمایش، یک سطح حمله عظیم و دسترسی به زیرسیستم Diagnostic Log and Trace (DLT) دریافت کردیم که هنگام تست و اشکال زدایی بسیار مفید است:

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

 

آسیب‌پذیری‌های شناسایی‌شده

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

 

CVE-2024-37600 (MoCCA)

سرویس "سرویس کارگزار" بخشی از چارچوب DSI است که در MoCCA استفاده می شود. این سرویس برای نظارت بر خدمات و مشتریان استفاده می‌شود.

سرورهای HTTP را با استفاده از پورت های TCP راه اندازی می کند. چندین دستور POST وجود دارد که می توان آنها را پردازش کرد. یکی از آنها قطع است که یک رشته را به عنوان آرگومان می گیرد.

 

کد موجود در تابع setup() سعی می کند این دستور را با توابعی تجزیه کند که دسترسی بیش از حد غیر ضروری به حافظه را فراهم می کند. با توجه به کد جدا شده، عملیات خواندن را با استفاده از sscanf روی یک بافر پشته انجام می دهد. در نتیجه، ممکن است سرریز پشته بافر وجود داشته باشد:
CVE-2023-34404 (GCF)

"MonitorService" سرویسی است که از طریق پروتکل GCF قابل دسترسی است. این سرویس در سرویس "scp" راه اندازی شده و راه اندازی می شود. دومی به نوبه خود یک سرویس systemd است که با پیکربندی زیر شروع می شود:

"MonitorService" از فایل پیکربندی زیر "/var/opt/swmp/pss_config.cfg" برای تنظیم دقیق عملکرد خود استفاده می کند:

 

متغیر "MonitorService.Port" تعداد پورت TCP را که توسط سرور استفاده می شود کنترل می کند. متغیر "MonitorService.ReceiveEnable" تعیین می کند که آیا سرور قادر به رسیدگی به درخواست های مشتریان است یا خیر. بر این اساس، "MonitorService" حاوی پیکربندی واحد سر، می‌تواند پیام های GCF را از مشتری دریافت کرده و آنها را از طریق روتر GCF منتقل کند.

 

لیست خدمات ثبت‌شده در روتر GCF شامل "NetworkingService" می‌شود. این کنترل کننده‌های ثبت شده زیر را دارد:

 

کنترل‌کننده "NWS_PF_setMacAddrExceptionIP" قوانینی را به خط مشی فایروال اضافه می کند. از آرگومان های زیر استفاده می کند:

 

macAddress – آدرس مک برای قانون؛

جهت - جهت قانون را مشخص می کند: ورودی یا خروجی.

سرنوشت - نوع قانون را تعریف می‌کند: اجازه یا رد.

فرمان – اقدامی که باید انجام شود: قانون را اضافه یا آن را از خط مشی حذف کنید.

جریان کنترل برای پردازش این درخواست در باینری های زیر قرار دارد: "MonitorService"، "libwicome_monitorservice.so" و "libwicode_gcf_core.so". پشته تماس به شرح زیر است:
هنگام پردازش درخواست، آدرس MAC نه بررسی می شود و نه محدود می شود. این بدان معناست که یک مهاجم می تواند تزریق دستور را در طول اجرای دستور iptables انجام دهد.

 

تشدید امتیازات

واحد اصلی از سیستم قدیمی Polkit استفاده می‌کند که در برابر CVE-2021-4034 آسیب پذیر است. این یک آسیب‌پذیری افزایش امتیاز محلی است که می‌تواند منجر به دستیابی کاربران غیرمجاز به حقوق مدیریتی روی ماشین هدف شود. بسیاری از اکسپلویت‌های عمومی در دسترس هستند که آن را هدف قرار می‌دهند، که اجرای دستورات دلخواه را به عنوان «تلفن» کاربر گروه «comm» امکان‌پذیر می‌سازند. پس از بهره‌برداری موفقیت‌آمیز از این آسیب‌پذیری، مهاجم می‌تواند دستوراتی را برای اصلاح رابط‌های شبکه، نصب سیستم‌های فایل و انجام سایر فعالیت‌های ممتاز اجرا کند. اگرچه برخی محدودیت‌ها اعمال می‌شوند، یک مهاجم بالقوه می‌تواند به فرمان systemd دسترسی پیدا کند تا امتیازات خود را افزایش دهد. پارتیشن با فایل سیستم ریشه به عنوان یک فایل سیستم فقط خواندنی نصب شد. همانطور که در تحقیقات KeenLab ذکر شد، واحد اصلی هیچ ویژگی محافظت از یکپارچگی دیسک فعال ندارد. این بدان معنی است که سیستم فایل را می توان با حقوق خواندن و نوشتن مجدداً نصب کرد و اسکریپت های bash که در هنگام راه اندازی اجرا می شوند را می توان تغییر داد.

 

USB

USB محبوب ترین بردار حمله از نظر دسترسی فیزیکی است. واحد اصلی بر روی یک معماری میکروسرویس ساخته شده است، جایی که هر سرویس نسبتاً ایزوله است و از طریق یک API ارتباط برقرار می کند. هر میکروسرویس واحد مرکزی برخی از عملکردهای داخلی و یک یا چند سرویس صرفه جویی را ارائه می دهد که از طریق آن سایر میکروسرویس ها می توانند با آن ارتباط برقرار کنند. این واقعیت شبیه سازی یک زیرسیستم USB را با استفاده از نسخه حالت کاربر QEMU امکان پذیر می کند.

آماده‌سازی

سرویس «DeviceManager» مسئول رسیدگی به رویدادهای USB است: افزودن، حذف، نصب یا به‌روزرسانی. سایر سرویس‌ها می‌توانند در «DeviceManager» مشترک شوند و از تماس‌های اعلان برای انجام اقدامات در هنگام رخ دادن رویدادهای USB استفاده کنند. به عنوان مثال، چنین سرویسی می تواند زمانی که سیستم فایل USB نصب شده است، جستجوی فایل های خاصی را آغاز کند. سرویس "GDVariantCodingService" پیشانی از کدنویسی های مختلف است. سایر سرویس ها از آن برای شناسایی پارامترهای هد یونیت و خودرو استفاده می‌کنند. هر دوی این سرویس‌ها باید برای اجرای یک زیرسیستم USB خود میزبان شبیه سازی شوند. این کار را می توان با شبیه سازی سرویس های مربوطه thriftme انجام داد. بنابراین، برای شبیه سازی موفق، باید اقدامات زیر را انجام دهیم:

 

• شبکه را برای آدرس های IP استفاده شده توسط سرویس ها آماده کنید.
• سرویس‌های «DeviceManager» و «GDVariantCodingService» از سوکت‌های یونیکس برای انتقال استفاده می‌کنند. برای شبیه‌سازی آنها، استفاده از سوکت‌های TCP آسان‌تر است تا به سیستم فایل وابسته نباشیم. انجام فوروارد با استفاده از socat.
• سرویس های thriftme شبیه سازی شده را اجرا کنید. در مورد ما، devicemgr.py، automjet.py و varcoding.py را ایجاد کردیم. در devicemgr.py، نصب فایل سیستم USB به مسیر "/opt/sys/bin/aaaaa" شبیه سازی می شود.
• از شبیه سازی کاربر QEMU به شیوه ای "شفاف" استفاده کنید.
• در محیط chroot پوشه ها و دستگاه ها را آماده کنید.
• زیرسیستم USB شبیه سازی شده است.
•  

شبیه‌سازی اکسپورت، واردات و ردیابی داده‌ها

یونیت سر این قابلیت را دارد که فایل‌های نمایه کاربر (موقعیت صندلی، ایستگاه‌های رادیویی مورد علاقه و غیره) را به یا از یک حافظه USB وارد یا صادر کند. این وظیفه توسط سرویس "UserData" انجام می شود - به طور دقیق تر، توسط سرویس thriftme "CSystemProfileServiceImpl".

بک‌آپ گرفتن از پروفایل‌های کاربر مانند پوشه‌ای با ساختار دایرکتوری زیر است:

برخی از فایل‌ها توسط خود "UserData" تولید می‌شوند، اما بیشتر آنها توسط سرویس‌های دیگری مانند "CAPServer" تولید و پردازش می‌شوند. مهمترین مؤلفه فرآیندهای واردات و صادرات داده، سرویس thriftme "UserDataExchangeService" در "UserData" است. خدمات برای اطلاعیه‌های مربوط به واردات و صادرات داده در UserDataExchangeService مشترک می‌شوند.

"CSystemProfileServiceImpl" هنگام صدور نسخه پشتیبان از پروفایل ها، گردش کار زیر را انجام می دهد:

• تایمر را به مدت 100 ثانیه اجرا کنید.
• خدمات مشتری را از طریق «UserDataExchangeService» با استفاده از رویدادهایی که درخواست صادرات داده را دارند، اطلاع دهید. چنین رویدادهایی حاوی اطلاعات مربوط به داده‌های صادر شده است.
• سرویس‌ها توابع API را فراخوانی می کنند که موفقیت صادرات داده را تأیید می‌کند. آرگومان های آنها یک کلید داده و یک مسیر به فایل است.
• "UserData" همه فایل‌های دریافتی را جمع آوری می کند، آنها را رمزگذاری  و آنها را در سیستم فایل USB نصب‌شده ذخیره می‌کند.

این طرح برای واردات پشتیبان نمایه مشابه است:

 

• "UserData" فایل ها را از USB به سیستم محلی کپی و آنها را رمزگشایی می‌کند.
• خدمات مشتری را از طریق رویدادهایی که درخواست وارد کردن داده‌ها می‌کنند، مطلع می‌سازد.
• اگر سرویس مشتری کلید داده را مدیریت و داده‌ها را وارد می‌کند.
• سرویس‌ها توابع API را فراخوانی می‌کنند که موفقیت واردات داده را تأیید می‌کنند.

 آسیب‌پذیری‌های شناسایی شده. آسیب‌پذیری‌های زیر بر روی یک ماشین واقعی آزمایش شده است.

CVE-2024-37601

فرآیند رمزگشایی فایل‌ها با پسوند *.ud2 حاوی آسیب‌پذیری سرریز بافر هیپ است.

"UserData" داده‌های رمزگذاری شده را از طریق شی "CHBString" نشان می دهد که داده ها را به عنوان یک رشته UTF پردازش می‌کند. سپس کاراکترهای رمزگشایی خاص UD2 باید حذف شوند و شاخص های آنها ثابت بماند. برای این کار از تابع "CHBString::const_iterator::incrementSteps" برای دریافت نشانگر روی کاراکتر مورد نظر و "CHBString::remove" برای حذف کاراکتر از رشته استفاده کردیم. "CHBString::const_iterator::incrementSteps" به اشتباه کاراکتر را با کد 0xe7 پردازش می‌کند: به صورت 1 بایت رمزگشایی می‌شود. اما طبق جدول "UTF8LookUpTable" که در "CHBString::remove" و "CHBString::CHBString" استفاده می‌شود، کاراکتر با کد 0xe7 با 3 بایت کدگذاری می‌شود.

در نتیجه، هنگام اجرای تابع "CHBString::remove"، نشانگر محاسبه شده می‌تواند پس از رمزگشایی UTF با "UTF8LookUpTable" خارج از بافر اختصاص داده شده باشد. تابع memmove با آرگومان سوم (اندازه بافر) برابر با 1- فراخوانی می‌شود.

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

 

CVE-2023-34402

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

فایل vt_ab.xml حاوی فایل دیگری است که توضیح می‌دهد کدام سرویس در حین پردازش حذف می شود. برای این کار حاوی نام فایلی است که باید رها شود. این عمل در تابع "UserDataExchangeServiceClient::unpackVoiceTagArchiveOptimized" انجام می شود:

• دریافت محتوای فایل که توضیح می‌دهد چه چیزی را رها کنید.
• نام فایل مورد نظر را دریافت کرده و حذف را انجام دهید.

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

CVE-2023-34399

پس از رمزگشایی، فایل uapreds.ud2 در پوشه نمایه "MyMercedesBackup/udxprofiles/profile0" شکل uapreds.db را به خود می گیرد. سیستم آن را به عنوان یک پایگاه داده SQLite می‌شناسد که در سرویسی که از یادگیری ماشین برای ایجاد مسیرهای کارآمد استفاده می‌کند، تجزیه می‌شود. فایل رمزگشایی شده در "capthrift::CapServer::requestImportBinaryData" پردازش می شود، سپس "capthrift::CapServer::setProfile" را برای بارگیری پایگاه داده فراخوانی می‌کند.

تمام مقادیر موجود در جداول پایگاه داده SQLite به عنوان یک بایگانی سریال می شوند تا با کتابخانه تقویت کننده مطابقت داشته باشند. فرمت این آرشیو می تواند XML یا متن ساده باشد. ما از حالت متن ساده استفاده کردیم. در اینجا نمونه ای از آرشیو در ردیف Learn_kernel جدول kvpair_table آورده شده است:
یادداشت‌های اکسپلویت

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

 

• با کنترل id، ما می توانیم نشانگر را حرکت دهیم (با حرکت دادن آن به آفست های منفی نسبت به ابتدای آرایه در پشته).
• با حرکت دادن اشاره‌گر، به آدرسی می رسیم که آدرس دیگری حاوی یک شی برای bis_ptr است.
• آدرس bis_ptr باید حاوی آدرس جدول تماس مجازی باشد. 

با کنترل صرف آفست شی مربوطه، باید به آدرسی در پشته برسیم که حاوی یک اشاره گر به اشاره گر با جدول مجازی مرتبط است. ما می‌توانیم چنین سناریویی را با استفاده از یک اسپری از ورودی‌های DDL در داخل پایگاه داده SQLite که می‌توانیم کنترل کنیم، پیاده‌سازی کنیم. برای چنین اسپری، ما باید جدول های زیادی با نام‌های طولانی ایجاد کنیم. در نتیجه ساختارهایی با فرمت مناسب در پشته ظاهر می‌شوند و یک شاخص منفی به ما امکان می‌دهد به این ساختارها برسیم.

بُردارهای حمله

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

 

سازش بستر آزمایش دارای سه مورد استفاده بالقوه است:

• مجرمی که می‌خواهد حفاظت ضد سرقت را در یک واحد سر سرقت شده غیرفعال کند.
• مالک خودرو در حال تنظیم و باز کردن خدمات پیش پرداخت در وسیله نقلیه خود است.
• یک پنتستر که برای یافتن آسیب‌پذیری‌های جدید تحقیق می‌کند.

در مورد یک ماشین واقعی، آسیب‌پذیری‌های شناسایی‌شده می‌توانند از طریق یک سرویس USB در معرض دید که در دسترس کاربر عمومی است، ایجاد شوند.

 

لیست آسیب‌پذیری

در طی فرآیند افشای آسیب‌پذیری با فروشنده، شناسه‌های CVE زیر اختصاص داده شد:

 

CVE-2024-37602

CVE-2024-37600

CVE-2024-37603

CVE-2024-37601

CVE-2023-34406

CVE-2023-34397

CVE-2023-34398

CVE-2023-34399

CVE-2023-34400

CVE-2023-34401

CVE-2023-34402

CVE-2023-34403

CVE-2023-34404

 

جزئیات CVE در اینجا منتشر خواهد شد: https://github.com/klsecservices/Advisories.

 

کسپرسکی آنلاین (ایدکو)

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