باز کردن قفل هر ماشین از برند X در بیشتر نقاط جهان
آدرس مقاله: https://shubs.io/unlocking-any-car-from-x-brand-in-most-of-the-world/ آدرس نظرات: https://news.ycombinator.com/item?id=50419215 امتیاز: 215 # نظرات: 75
من همیشه برای این برند خاص خودرو نقطه ضعفی داشته ام. خانواده ما در طول سالها صاحب تعدادی از آنها شدهاند و بهطور باورنکردنی به ما خدمات خوبی ارائه کردهاند. در سال 2023، من یک چهار چرخ متحرک/SUV جدید از آنها خریدم و این اولین بار بود که به پلت فرم ماشین متصل آنها دسترسی داشتم.
با نگاهی به پلتفرمهایی مانند این قبلا (کارهای قبلی)، در مورد اینکه واقعا چقدر امن هستند تردید داشتم. من مشکوک بودم که چیزی در آنجا وجود دارد، اما زندگی همچنان مانع از نگاه واقعی میشد. ژوئیه امسال، من با سام کوری همکاری کردم تا نگاهی به امنیت سیستم های خودروی متصل یک خودروساز بزرگ بیندازم. در طول این پست، من از آنها به سادگی به عنوان "خودروساز" یاد می کنم.
زمانی که شما معمولا به هک خودرو فکر می کنید، اغلب آسان است که به سمت سخت افزار چیزها بروید، اما پیشینه من کاملا در به خطر انداختن برنامه های کاربردی وب و زیرساخت های اینترنتی است. صرف نظر از همه بیتها و بابهای سختافزاری، همه آنها به سرویسی متصل میشوند که بر اساس طراحی، باید از طریق اینترنت قابل دسترسی باشد.
سفر با یک سوال ساده آغاز شد: وقتی قفل ماشین خود را از راه دور باز می کنم، برنامه با چه زیرساختی صحبت می کند؟ برای حل این مشکل، APK را دانلود کردم و آن را دیکامپایل کردم و در نهایت درخواستهای API را که در حال انجام بود بازسازی کردم.
با مرور کد، به نظر می رسید که نقطه تماس اولیه دارایی های زیر *.redacted-telematics.com.au باشد:
تقریبا هر بخش از برنامه مصرف کننده به redacted-telematics.com.au باز می گردد. چه چیز دیگری تحت این دامنه وجود داشت؟
اجرای زیرساختهای خودروی متصل میتواند بسیار پیچیده باشد و مدیریت آن به ترکیبی از ابزارهای مدیریت، مرحلهبندی، توسعهدهندگان و محیطهای QA نیاز دارد تا اطمینان حاصل شود که مشتریان تجربهای تمیز دارند. این که آیا همه اینها باید در اینترنت عمومی قرار داشته باشد و برای هر کسی که مایل به انجام برخی شناسایی اولیه است در دسترس باشد، داستان متفاوتی است.
یک دارایی بیش از بقیه توجه من را جلب کرد. admintool.redacted-telematics.com.au صفحه ای با عنوان TEST HARNESS را برگرداند. چه کسی می تواند در برابر یک زیر دامنه با ابزار مدیریت در آن مقاومت کند؟
بازدید از این زیردامنه یک صفحه ورود به سیستم بسیار ساده و خاکستری را نشان داد که با توجه به اینکه قبل از ورود به سیستم یک دکمه خروج از آن را نشان می داد، کیفیتی دقیقا منتشر نمی کرد.
من دوست دارم که اکثر برنامه های تک صفحه ای کل بسته جاوا اسکریپت خود را حتی زمانی که تنها چیزی که برای رندر کردن نیاز دارند یک صفحه ورود است ارسال می کنند. مطمئنا، برخی از فریمورکهای مدرنتر، فایلهای جاوا اسکریپت را به گونهای تقسیم میکنند که فقط به آنچه لازم است ارائه میدهند، اما در این مورد، میتوانیم بسته بزرگ جاوا اسکریپت را بررسی کنیم تا بفهمیم این «ابزار مدیریت» واقعا به شما اجازه انجام چه کاری را میدهد.
به نظر می رسد که این ابزار مدیریت به شما امکان می دهد کارهای زیادی انجام دهید. این یک API غنی داشت که به کارمندان خودروساز اجازه می داد با محدودیت های بسیار کمی با حساب های مشتریان و خودروهای تولیدی تعامل داشته باشند. با بازسازی درخواستها، متوجه شدیم که بسیاری از این APIها فراتر از کلیدهای API کدگذاریشده در بسته جاوا اسکریپت به احراز هویت نیاز ندارند.
برای مثال، میتوانیم حسابهای کاربری را با آدرس ایمیل جستجو کنیم:
اما این به اندازه کافی خوب نیست. اگر بخواهیم قفل هر یک از خودروهای آنها را از دانستن شماره پلاک باز کنیم، باید بهتر از این کار کنیم.
در استرالیا، پلاک شماره VIN (شماره شناسایی خودرو) را به راحتی از طریق سایت های جستجوی ثبت نام مبتنی بر ایالت به شما می دهد.
این واقعا یک نقص امنیتی نیست. دلایل قانونی زیادی برای درخواست VIN وجود دارد، مانند بررسی تاریخچه تعمیرات و بیمه واقعی خودرو قبل از خرید دست دوم. اگر میتوانستیم از VIN به یک مشترک یا ایمیل برویم، زنجیره را تکمیل میکردیم.
خوشبختانه، یک API وجود داشت که به شما امکان می داد دقیقا این کار را انجام دهید:
با GUID مشترک، میتوانید جزئیات کامل حساب (از جمله ایمیل کاربر از طریق نقطه پایانی /v1/account) را مانند این موارد استخراج کنید:
خب، من حدس میزنم که ما قسمت اول زنجیره خود را مرتب کردهایم. Plate -> VIN -> Subscriber GUID -> PII حساب کاربری (ایمیل) ثبت شده در پلت فرم هویت خودروساز (ForgeRock OpenIDM).
حالا چطور به هر ماشینی که بخواهیم دستور بفرستیم؟ مطمئنا این ابزار مدیریت به ما این امکان را می دهد؟ متاسفانه خیر این به ما امکان میدهد تا ویژگیهای یک خودرو را فراهم کنیم، خود را به عنوان کاربر ثانویه به حساب کاربر اضافه کنیم، و حتی کدهای دسترسی از راه دور را تولید کنیم. اما با وجود تمام این قابلیتها، هیچکدام از آنها در واقع ما را به کنترل از راه دور یک وسیله نقلیه نمیرساند.
من و سام سپس دو هفته به بررسی نحوه مدیریت سیستم هویت مرکزی خودروسازان پرداختیم: نرمافزاری که استفاده میکنند، نحوه صدور فرمانها و نحوه احراز هویت مصرفکنندگان.
هنگامی که کاربر از طریق جریان احراز هویت برای برنامه تلفن همراه خودروساز می گذرد، درخواست هایی به login.redacted-identity.com.au ارسال می شود و پس از گذراندن یک جریان MFA، در نهایت یک نشانه تأیید اعتبار مصرف کننده صادر می شود. سپس این نشانه تأیید برای درخواستهای بعدی به api.redacted-telematics.com.au (هم REST API و هم GraphQL) استفاده میشود. هنگامی که شما آن نشانه auth را داشته باشید، تقریبا بازی تمام می شود. شما می توانید ماشین کاربر را کنترل کنید (باز کردن قفل از راه دور، بوق، موتور و غیره).
بنابراین اگر بتوانیم برای هر کاربری یک توکن ایجاد کنیم، در نهایت میتوانیم ماشین متصل هر کسی را کنترل کنیم. این همان زاویه ای است که ما به آن رفتیم.
این خودروساز، کاربر سنگین نرم افزار هویت ForgeRock (OpenAM/OpenIDM) است. این سنگ بنای مکانیزم های احراز هویت آنهاست. با کشیدن زیر دامنه ها برای *.redacted-identity.com.au، ما به سرعت نمونه OpenIDM آنها را در openidm.redacted-identity.com.au پیدا کردیم. این سیستمی است که هر هویت ثبت شده در پلت فرم خودروی متصل خودروساز را مدیریت می کند.
همه اینها زمانی که فایلهای جاوا اسکریپت را در زیر *.redacted-telematics.com.au بررسی میکردیم با هم کلیک میکردیم و با یک بسته جاوا اسکریپت فروشنده کاملا نفرینشده مواجه شدیم که اعتبارنامههای مدیریت را برای OpenIDM جاسازی کرده بود.
حتی اگر قرار بود این مدارک مدیریتی برای محیط صحنه نمایش آنها باشد، با توجه به بهداشتی که تاکنون دیده بودیم، ما تقریبا مطمئن بودیم که آنها در تولید نیز کار خواهند کرد.
با نگاهی دقیقتر به OpenIDM، نمیتوانیم بگوییم که آیا خودروساز میداند چقدر شکننده است یا خیر. با این حال یک چیز واضح بود: آنها سرمایه گذاری زیادی روی قوانین WAF کرده بودند تا دسترسی به API های حساسی را که ForgeRock معمولا به شما امکان می دهد از طریق /openidm/* تماس بگیرید، مسدود کنند.
حتی با IP مبدا، هر درخواستی به /openidm/ مستقیما به عنوان یک بلوک Nginx WAF برگشت. کسی تلاش واقعی برای سخت کردن این دارایی ها انجام داده بود (علیرغم اینکه آنها از خارج قابل دسترسی هستند).
به اندازه کافی منصفانه است، و ما به سخت شدن احترام می گذاریم. اما این مقدار سرمایه گذاری در WAF معمولا به معنای دست زدن به چیزی است که به عنوان بد شناخته شده است. آنها احتمالا فهمیده بودند که افشای این دارایی چقدر بد است، و به هر حال برخی از پرونده های تجاری آن را در آنجا نگه داشتند.
مطمئن نیستم که یک قانون WAF زمانی که به اندازه کافی انگیزه داشته باشیم ما را متوقف کرده باشد، بنابراین با استفاده از ترفندهای پیمایش مسیر مطمئن خود، روزها برای یافتن راهی برای خروج از این حفاظت ها سرمایه گذاری کردیم. چقدر میتونه سخت باشه
اعتبارسنجی اعتبارنامه مدیریتی که در بسته جاوا اسکریپت یافتیم چندان سخت نبود. نمونه OpenIDM استرالیا دارای چند مسیر در لیست سفید مانند /XUI/ و /UI/ بود، و کاراکترهای پیمایش مسیر مسدود نشدند، بنابراین چیزی به سادگی /XUI/..%2fopenidm/endpoint حداقل تا حدی کار می کند:
اما هرگز نمی تواند به این سادگی باشد، درست است؟ پیمایش مسیر هنوز هم ما را به نقاط پایانی زیر /openidm/ نمی رساند، به لطف ابهامات در نحوه مدیریت OpenIDM مسیریابی. هر نقطه پایانی به این صورت خطا می کند:
در دنیای OpenIDM، هیچ سرور (یا منبع) در برابر مسیرهایی که شامل پیمایش مسیر در داخل آنها باشد، ثبت نشده است. بنابراین، حتی اگر یک JWT مدیر برای ما صادر کند، فقط خطا می کند.
ما به طرز باورنکردنی از این موضوع اذیت شدیم. یک اشتباه ساده در مکانیسم های مسیریابی (احتمالا حتی به عنوان یک ملاحظات امنیتی طراحی نشده است) زنجیره حمله کامل را از کار کردن مسدود می کرد. چند روزی ناامید نشستیم و فکر کردیم که زاویه پیمایش مسیر کار نمی کند. ما چند نقطه پایانی دیگر (برای مثال آپلود کاربر) پیدا کردیم که به نظر میرسید ممکن است کار کنند، اما به یک ویژگی عجیب دیگر، بررسی مسیر servlet، برخورد کردیم که ما را از استفاده معنیدار از آنها منع کرد.
همه اینها باعث شد که ما یک سوال متفاوت بپرسیم: اصلا چرا این نمونه های OpenIDM را به صورت خارجی در معرض دید قرار می دهیم؟ مطمئنا باید مورد استفاده مشروعی برای افشای این دارایی ها در اینترنت وجود داشته باشد؟ ما به بستههای مختلف جاوا اسکریپت که از داراییهای آنها جمعآوری کرده بودیم، برگشتیم و آنها را برای ارتباط با OpenIDM جستجو کردیم. ما به برنامه اندروید دیکامپایل شده مراجعه کردیم و موارد زیر را یافتیم:
اینها به وضوح نقاط پایانی در دارایی OpenIDM آنها بودند که از طریق برنامه Android قابل تماس بودند. بنابراین، شاید اینها بدون مانع شدن WAF در دسترس بودند؟
چه نقاط پایانی سفارشی دیگری وجود داشت؟ با برخی از اجبار و حدس زدن های بسیار سبک، ما به سرعت یک نقطه پایانی getUser پیدا کردیم. با حدس زدن پارامترها، دریافتیم که نامه، راهنما و تلفن پذیرفته شده است. همراه با اعتبار مدیریت ما، این واقعا چه کاری به ما اجازه داد؟
پاسخ با هش رمز عبور، هش کد پین، توکنهای فشار موبایل و PII شامل شماره تلفن همراه و نام کامل بازگشت. هیچ بلوک WAF در این نقطه پایانی وجود نداشت، بنابراین هیچ پیمایش مسیری مورد نیاز نبود و سرولت صحیح پاسخ داد.
اشتباه نکنید، این قبلا بسیار تأثیرگذار بود. اما گذرواژهها با PBKDF2-SHA512 هش شدهاند، و نیاز به زمان بر روی یک دستگاه هش کرک برای هر باز کردن قفل، بدون هیچ تضمینی برای موفقیت، کمی ضعیف به نظر میرسد.
برگشت به تابلوی طراحی چگونه میتوانیم با پیمایش مسیر خود به /openidm/managed/user servlet دسترسی داشته باشیم و همچنان مسیر توسط OpenIDM شناسایی شود؟ ما منبع OpenIDM را که نزدیکترین به نسخهای که روی آن آزمایش میکردیم، گرفتیم و به GPT 5.6 Sol Ultra اجازه دادیم شش ساعت خوب را روی آن صرف کند.
موفق شد. حتی اگر من و سم هر دو زمان خود را صرف دور زدن دستی این محدودیت نوجوانان کرده بودیم، اما همه ترکیبهای ممکن را امتحان نکرده بودیم.
هنگامی که من و سم /XUI%2f..%2fopenidm/ را امتحان کردیم، به 403 سختی رسیدیم، و به عنوان انسان، فرض کردیم که برای هر پیشوندی اعمال می شود. چیزی که GPT 5.6 پیدا کرد این بود که /static%2f..%2fopenidm/ به هیچ وجه توسط WAF پوشش داده نمی شد و APIهای OpenIDM را بدون مشکل سردرگمی servlet در اختیار ما قرار داد.
با این دور زدن، گرفتن یک حساب کاربری پیش پا افتاده شد. ما می توانیم یک رمز عبور جدید برای هر نمایه کاربری وصله کنیم:
خوب، بنابراین ما می توانیم رمز عبور را برای هر کاربری بازنویسی کنیم. اما در مورد احراز هویت چند عاملی چطور؟
خوب، محیط استرالیایی خودروساز یک پیکربندی نادرست دیگر داشت: مرحله چند عاملی را میتوان به طور کامل نادیده گرفت. ابتدا، ما از login.redacted-identity.com.au یک کد احراز هویت با اعطای اعتبار رمز عبور مالک منبع درخواست کردیم، که یک id_token تمیز را برگرداند که میتوانیم آن را با چیزی قابل استفاده در برنامه مصرفکننده تعویض کنیم:
ما آن را برداشتیم و به مرحله دو رفتیم و اولین نشانه را با یک جلسه مبادله کردیم:
در نهایت، ما تبادل توکن را برای یک توکن دسترسی اپلیکیشن موبایل انجام دادیم:
خیلی پیچیده است، می دانم. OAuth گاهی اوقات به طرز آزاردهنده ای سخت است. اما این مراحل به ما اجازه میدهد تا احراز هویت چند عاملی را برای هر کاربر برنامه خودروی متصل خودروساز دور بزنیم.
در این مرحله، ما خیلی به باز کردن قفل هر یک از خودروهای این خودروساز در استرالیا نزدیک بودیم. تنها چیزی که باقی مانده بود صدور فرمان درخواست های API با توکن برنامه ای بود که اکنون می توانیم برای هر کسی ایجاد کنیم.
بدیهی است که ما همه این کارها را روی خودروهایی انجام دادیم که صراحتا مالک آنها بودیم یا اجازه تعامل با آنها را داشتیم.
اما بیایید یک قدم به عقب برگردیم و به آنچه در اینجا به دست آوردیم فکر کنیم. ما میتوانیم برای هر یک از خودروهای این خودروساز در استرالیا، در هر دو برند آنها، فرمانها را تنها با دانستن شماره پلاک خودرو ارسال کنیم. زنجیره نهایی به این صورت بود:
Plate -> VIN -> Subscriber GUID -> Admin OpenIDM در بسته فروشنده JS -> Path traversal برای دور زدن WAF -> MFA bypass از طریق ROPC -> Minting Token App Consumer -> Remote command API.
در ساعت 12 صبح، وقتی زنجیره کامل در نهایت جمع شد، یک ویدیوی کوتاه از فیلمنامه در حال اجرا گرفتم. جلا داده نشده است، اما هنوز هم با دیدن کار کردن همه چیز جادویی به نظر می رسد. من قطعا برای چالش های سختی مانند این زندگی می کنم.
ممکن است تعجب کنید: شوبس، گفتی هر کدام از ماشین هایشان در دنیا. این فقط استرالیا را پوشش می دهد. چه چیزی می دهد؟
یک زنجیره بسیار پیچیدهتر وجود دارد که من و سم با هم روی آن کار کردیم، که او در وبلاگش اینجا منتشر کرده است. این کار به کار بسیار بیشتری نسبت به اقداماتی که ما برای استرالیا برداشتیم نیاز داشت، زیرا این خودروساز زمان بسیار بیشتری را برای ایمن سازی محیط های OpenIDM ایالات متحده، کانادا و اروپا صرف کرده بود.
در پایان روز، با ترکیب هر دو نوشته، میتوانیم دستورات از راه دور مانند باز کردن قفل و روشن کردن موتورها را برای هر یک از خودروهای این خودروساز در استرالیا، ایالات متحده و کانادا ارسال کنیم.
متن اصلی (انگلیسی)
Unlocking any car from X brand in most of the world
Article URL: https://shubs.io/unlocking-any-car-from-x-brand-in-most-of-the-world/ Comments URL: https://news.ycombinator.com/item?id=50419215 Points: 215 # Comments: 75