پهپادهای مصرفی که امکان تصویربرداری هوایی حرفهای را فراهم میکنند، نویدبخش تحول در صنعت لجستیک هستند و هماکنون نیز در عملیات امداد انسانی و حتی در درگیریهای مسلحانه مورد استفاده قرار میگیرند. با وجود پذیرش گسترده و محبوبیت بالای آنها، ورود آسان به حوزه جابهجایی هوایی (که به طور سنتی به شدت تحت مقررات سختگیرانه قرار دارد) خطرات و تهدیدات متعددی برای ایمنی، امنیت و حریم خصوصی ایجاد میکند. به عنوان مثال؛ تهدیدکنندگان و عوامل مخرب (Malicious parties) میتوانند از پهپادها برای اهدافی مانند نظارت غیرمجاز، حمل کالاهای غیرقانونی یا ایجاد خسارت اقتصادی از طریق ورود به حریم هوایی بسته، مانند فضای بالای فرودگاهها، سوءاستفاده کنند. تولیدکنندگان پهپاد به منظور جلوگیری از این آسیبها، مجموعهای از اقدامات کنترلی را بهکار میگیرند تا استفاده ایمن و امن از پهپادها تضمین شود؛ به عنوان مثال، محدودیتهای نرمافزاری در سرعت و ارتفاع اعمال میکنند یا با استفاده از ژئوفنسینگ یا حصار جغرافیایی (geofencing) مناطق پرواز ممنوع مانند اطراف فرودگاهها یا زندانها را پیادهسازی میکنند. در کنار این تدابیر سنتی، پهپادهای شرکت پیشرو بازار DJI پروتکلی برای ردیابی با نام DroneID به کار میگیرند که برای ارسال موقعیت مکانی هم پهپاد و هم اپراتور آن به نهادهای مجاز (مانند نیروهای انتظامی یا اپراتورهای زیرساختهای حیاتی) طراحی شده است.
در این مقاله، ما امنیت و حریم خصوصی پهپادها را با تمرکز بر تولیدکننده پیشرو یعنی DJI با سهم بازار ۹۴ درصد مورد تحلیل قرار میدهیم. ابتدا سطح حمله (attack surface) پهپادها را به صورت نظاممند بررسی کرده و مهاجمی را در نظر میگیریم که قادر به شنود ترافیک بیسیم دادههای پهپاد باشد. بر اساس مهندسی معکوس میانافزار DJI (یا reverse engineering of DJI firmware)، یک رمزگشا (decoder) برای پروتکل ردیابی اختصاصی این شرکت با نام DroneID طراحی و پیادهسازی میکنیم که تنها با استفاده از سختافزارهای تجاری ارزانقیمت (COTS) قابل اجرا است. نشان میدهیم که دادههای ارسال شده رمزگذاری نشدهاند و برای هر فرد قابل دسترسی میباشند که این موضوع حریم خصوصی اپراتور پهپاد را در معرض خطر قرار میدهد.
در گام دوم، یک تحلیل جامع از امنیت پهپاد به انجام میرسانیم. ما با ترکیبی از مهندسی معکوس، یک رویکرد جدید فازینگ (fuzzing) متناسب با پروتکل ارتباطی DJI و تحلیل سختافزاری، چندین نقص بحرانی در میانافزار پهپادها کشف میکنیم که به مهاجمان اجازه میدهد دسترسی سطح بالا (privileged access) روی دو پهپاد DJI و کنترلکننده آنها به دست آورند. این دسترسی ریشه (root access) امکان غیرفعالسازی یا دور زدن مکانیزمهای حفاظتی و سوءاستفاده از پهپادها را فراهم میآورد. در مجموع، ۱۶ آسیبپذیری شناسایی گردید که از اختلال در سرویس (denial of service) تا اجرای کد دلخواه (arbitrary code execution) را شامل میشوند. ۱۴ مورد از این باگها (Bug) از راه دور و از طریق تلفن هوشمند اپراتور قابل فعالسازی هستند که میتواند منجر به سقوط یا از کار افتادن پهپاد در حین پرواز شود.
۱. مقدمه (Introduction)
پهپادهای غیرنظامی یکی از عناصر شاخص قرن بیستویکم محسوب میشوند. هزینه پایین و قابلیت تصویربرداری با کیفیت بالای آنها، نوآوریهایی را در حوزههایی مانند عکاسی هوایی برای روزنامهنگاری و صنعت فیلم، نقشهبرداری از مناطق و زمینهای غیرقابل دسترس [1]، جمعآوری اطلاعات در شرایط بحرانی و بلایای طبیعی [2]، و عملیات امداد انسانی با استفاده از حسگرهای حرارتی [3] ممکن ساخته است. شرکتهایی مانند آمازون (Amazon) برنامهریزی کردهاند تا تحویل بستهها را از طریق پهپادهای هوایی انجام دهند [4]، و رویدادهایی مانند مراسم افتتاحیه المپیک توکیو نیز از نمایشهای نوری مبتنی بر پهپاد بهرهمند شدهاند [5].
در عین حال و در تضادی آشکار با این فرصتهای متنوع، پهپادهای مصرفی خطر قابلتوجهی از سوءاستفاده در سناریوهای با انگیزههای مجرمانه ایجاد میکنند. برای مثال، پهپادها میتوانند به راحتی از موانع فیزیکی مانند دیوارهای زندان یا حصارهای مرزی ملی عبور کنند [6]. از این رو، آنها یک بردار جدید برای انتقال کالاهای غیرقانونی مانند مواد مخدر فراهم میکنند [7, 8] که با تحرکپذیری بالا و احتمال پایین شناسایی همراه است. پرواز در داخل یا نزدیک حریم هوایی محدود نیز میتواند خسارات اقتصادی قابلتوجهی ایجاد کند. برای نمونه، مقررات ایجاب میکنند که فرودگاهها به محض گزارش مشاهده یک پهپاد، فعالیت خود را متوقف سازند؛ موضوعی که هزینههای مالی بالایی به همراه داشته و میتواند بر هزاران نفر تأثیر بگذارد [9].
به منظور کاهش خطرات ناشی از این سناریوهای سوءاستفاده، تولیدکنندگان پهپاد معمولاً از مجموعهای از اقدامات کنترلی استفاده میکنند: حصار جغرافیایی (geofencing) از ورود پهپادها به حریمهای هوایی ممنوع جلوگیری میکند، در حالی که محدودیتهای نرمافزاری مانع از پرواز با سرعت یا ارتفاع بیش از حد مجاز میشوند.
فراتر از جلوگیری فعال از اقدامات مخرب، پهپادهای شرکت پیشرو بازار DJI به صورت دورهای موقعیت مکانی خود و اپراتور را از طریق یک پروتکل اختصاصی به نام DroneID ارسال میکنند؛ این قابلیت به نهادهای انتظامی یا اپراتورهای زیرساختهای حیاتی اجازه میدهد تا پهپادها و همچنین اپراتورهای آنها را شناسایی و ردیابی کنند.
اگرچه این قابلیت امکان شناسایی و دستگیری مؤثر اپراتورهای مخرب را فراهم میکند، اما انتقال دادههای حساس مکانی مانند زمانی که نهادهای انتظامی از پهپادها برای اهداف نظارتی استفاده کنند، میتواند مشکلساز باشد. علاوه بر این، در درگیریهای اخیر در اروپا، نیروهای نظامی و غیرنظامیان از پهپادهای مصرفی برای ردیابی حرکت و موقعیت نیروهای متخاصم یا هدایت حملات توپخانهای استفاده کردهاند. در هر دو حالت، کاربران پهپاد به این موضوع متکی هستند که دادههای حساس مکانی آنها برای دیگران قابل دسترسی نباشد.
با وجود این خطرات بالقوه در حوزه امنیت، ایمنی و حریم خصوصی، و همچنین سوءاستفادههای موجود از پهپادهای مصرفی، تنها تعداد محدودی از کارهای پژوهشی به ارزیابی امنیت و حریم خصوصی پهپادهای غیرنظامی پرداختهاند. Nassi و همکارانش [10] وضعیت موجود در ادبیات پژوهشی را بهصورت نظاممند در این زمینه تحلیل کردهاند. جنبههای مختلفی مانند جعل GPS (GPS spoofing) [11] و حملات اخلال در احراز هویت (de-authentication attacks) [12, 13, 14] پیشتر مورد بررسی قرار گرفتهاند.
با این حال، بهطور انتقادی بایستی اذعان داشت که جنبههای امنیتی در سطح سیستمِ پهپادهای موجود هنوز به صورت جامع ارزیابی نشدهاند. اغلب پژوهشهای موجود یا بر پهپادهای کمهزینه یا متنباز تمرکز داشتهاند که به اندازه پهپادهای تجاری پیشرفته و پرکاربرد رایج نیستند. تعداد معدودی از کارهایی که به پهپادهای پرکاربرد مانند محصولات DJI پرداختهاند، محدود به بررسی برنامه DJI Go 4 [15] بوده و یا تنها تحلیلهای ابتدایی از پهپادهای Phantom 3 [16, 17] یا Phantom 4 [18] ارائه کردهاند. تا جایی که ما مطلع هستیم، تلاشهای بیشتری برای بررسی دقیق در سطح نرمافزار یا سختافزار این سیستمها انجام نشده است.
ما در این کار، یک تحلیل جامع از ادعاهای امنیتی و حریم خصوصی پهپادهای مصرفی پیشرفته شرکت DJI ارائه میدهیم؛ این شرکت از نظر میزان فروش [19, 20] و همچنین تدابیر امنیتی بهکاررفته [21]، به عنوان رهبر بازار پهپادهای مصرفی شناخته میشود. ما دو مدل تهدید (threat model) را در نظر میگیریم:
(۱) یک مهاجم غیرفعال که ترافیک منتقل شده به صورت بیسیم را شنود میکند، و
(۲) سناریویی که در آن مهاجم فعال به پهپاد یا دستگاه متصل به آن دسترسی فیزیکی دارد.
در حالت اول، تمرکز ویژه ما بر پروتکل DroneID شرکت DJI و تأثیر آن بر حریم خصوصی اپراتور است. باور عمومی گسترده (که تا حدی تحت تأثیر بیانیههای فروشنده که اخیراً نیز از وبسایت آنها حذف شدهاند [22] شکل گرفته است) این است که دادههای موقعیت مکانی منتقل شده رمزگذاری شدهاند و تنها توسط نهادهای انتظامی یا اپراتورهای زیرساختهای حیاتی قابل رمزگشایی و تفسیر میباشند.
ما هم میانافزار (firmware) و هم نرمافزار مرتبط با لایه فیزیکی ارتباط بیسیم را مهندسی معکوس کردیم تا بررسی کنیم بستههای حاوی DroneID چگونه مدوله (modulate) و کدگذاری میشوند. با استفاده از بینشهای به دستآمده از مهندسی معکوس، یک خط لوله (pipeline) کامل برای دریافت، دمدولهسازی (demodulate) و رمزگشایی بستههای DroneID ساختیم و نشان دادیم که این پروتکل رمزگذاری نشده است. بر اساس استفاده صرف از اجزای استاندارد مانند رادیوی تعریف شده توسط نرمافزار (Software Defined Radio – SDR)، نتایج ما نشان میدهد که این بستهها به طور دقیق موقعیت مکانی پهپاد و مهمتر از آن، نقطه بازگشت (home point) و موقعیت اپراتور را افشا میکنند.
ما روشی برای غیرفعالسازی انتقال این دادهها شناسایی کرده و نشان میدهیم که همچنین امکان جعل موقعیت اپراتور با استفاده از یک برنامه کاربردی آمادهی جعل GPS (GPS spoofing) نیز وجود دارد. فراتر از یک مهاجم غیرفعال که ترافیک ارسال شده از طریق رابط رادیویی را شنود میکند، ما یک مهاجم فعال را نیز در نظر میگیریم که به پهپاد، کنترل از راه دور یا تلفن هوشمند متصل به آن دسترسی فیزیکی دارد.
ما کل پشتهی سیستم (system stack) را، شامل سختافزار و نرمافزار خود پهپاد و همچنین کنترل از راه دور، مورد تحلیل قرار میدهیم. به منظور انجام یک تحلیل پویا (dynamic analysis) از میانافزار پهپاد، یک فازر جعبهسیاه (black-box fuzzer) با یک دستور زبان سفارشی از پروتکل ارتباطی اختصاصی پهپاد با نام DUML طراحی و پیادهسازی میکنیم.
فازینگِ یک سیستم سایبر-فیزیکی پیچیده مانند پهپاد چالشبرانگیز است، زیرا معمولاً دسترسی کامل به میانافزار نداریم و از این رو، نمیتوانیم از فازرهای موجود که متکی بر ابزارگذاری (instrumentation) هستند استفاده کنیم. علاوه بر این، خطاها الزاماً به شکل کرش (Crash) کامل ظاهر نمیشوند، بلکه اغلب تنها به صورت یک وضعیت متناقض (inconsistent state) بروز میکنند. در نهایت، ما مکانیزم جدید اوراکل خطا (bug oracle) را ارائه میدهیم که تغییرات ظریف اما غیرمنتظره در اپلیکیشن اندرویدی DJI متصل به کنترل از راه دور را پایش میکند.
این روش به ما امکان میدهد الگوهای نادرست را به طور مؤثر شناسایی کرده و خطاهایی را که منجر به ایجاد وضعیت متناقض (inconsistent state) میشوند را کشف کنیم؛ خطاهایی که فازرهای متداول قادر به تشخیص آنها نیستند. ما با استفاده از این رویکرد، موفق به شناسایی چندین آسیبپذیری امنیتی بحرانی شدیم که به مهاجم اجازه میدهند دسترسی سطحبالا (privileged access) به دست آورد؛ دسترسی که پیشنیاز غیرفعالسازی بسیاری از مکانیزمهای حفاظتی، اجرای کد دلخواه (arbitrary code execution) یا جعل هویت از طریق دستکاری شمارهسریال پهپاد است.
تحلیل ما همچنین یک بردار حمله از راه دور و بحرانی از نظر ایمنی را آشکار میکند که در آن میتوان پهپاد را در حین پرواز از کار انداخت یا ساقط کرد. علاوه بر این، تحلیل ایستای میانافزار آسیبپذیریهای بحرانی بیشتری را نشان میدهد که امکان اجرای دستورات دلخواه را فراهم میکنند. ما در مجموع، ۱۶ آسیبپذیری با شدتهای کم تا بحرانی را در چهار مورد از پنج دستگاه DJI مورد آزمایش شناسایی کردیم.
مشارکتها. به طور خلاصه، مهمترین مشارکتهای ما عبارتاند از:
- تحلیل امنیتی (Security Analysis). ما یک تحلیل امنیتی جامع از پهپادهای مصرفی شرکت پیشرو بازار، یعنی DJI، ارائه میدهیم. این تحلیل شامل سختافزار، نرمافزار و لایه فیزیکی بیسیمِ خود پهپاد و همچنین کنترل از راه دور آن است. بررسیهای ما چندین آسیبپذیری امنیتی بحرانی را آشکار میکند که امکان اجرای دستورات دلخواه، دور زدن مکانیزمهای حفاظتی، و حتی از کار انداختن یا سقوط پهپاد در حین پرواز از راه دور را فراهم میکنند.
- DroneID. ما هم میانافزار و هم لایه فیزیکی بیسیم پهپادهای جدید DJI را مهندسی معکوس میکنیم تا پروتکل انتقال اختصاصی این شرکت با نام OcuSync را مورد ارزیابی و تحلیل قرار دهیم. بر اساس این یافتهها، ترکیبی از یک گیرنده، دمدولهکننده (demodulator) و رمزگشا برای بستههای DroneID شرکت DJI را ارائه میدهیم که قادر است اطلاعات حساسی، از جمله موقعیت زنده پهپاد و همچنین اپراتور آن را آشکار کند.
- فازینگ پهپاد (Drone Fuzzing). ما یک فازر جعبهسیاهِ تولیدی (generational black-box fuzzer) سفارشی طراحی و پیادهسازی میکنیم که یک دستور زبان اختصاصی مربوط به DJI را با یک مکانیزم جدید اوراکل خطا (bug oracle) ترکیب میکند تا نقصهای موجود در پهپادها و کنترلکنندههای آنها را شناسایی کند. فازر ما کرشهای (Crash) امنیتی بحرانی را کشف میکند که میتوان از آنها برای بهدستآوردن دسترسی ریشه (root access) یا از کار انداختن پهپاد در حین پرواز استفاده کرد.
ما به منظور حمایت از پژوهشهای آتی در این حوزه، چارچوب فازینگ و گیرنده DroneID خود را به صورت متنباز در گیتهاب (https://github.com/RUB-SysSec/DroneSecurity) منتشر کردهایم. شرکت DJI نیز در چارچوب فرایند افشای مسئولانه، تمامی آسیبپذیریهای گزارش شده را برطرف کرده است.
۲. مقدمهای بر پهپادهای DJI (Primer on DJI Drones)
ما در گام نخست، مروری بر مهمترین جنبههای پهپادهای مصرفی مدرن خواهیم داشت و بهطور ویژه بر پهپادهای شرکت DJI متمرکز میباشیم. این شرکت در سال ۲۰۲۱ بزرگترین تولیدکننده پهپادهای تجاری در جهان بود و حدود ۵۴ درصد از سهم بازار جهانی بر اساس تعداد فروش (تا اواخر سال ۲۰۲۱) و ۹۴ درصد از بازار پهپادهای مصرفی را به خود اختصاص داد [19].
علاوه بر این، DJI یک مقاله (whitepaper) درباره مکانیزمهای امنیتی و ایمنی خود منتشر کرده است [21] که مبنایی قابل اتکا از نظر امنیت و ایمنی فراهم میکند. با توجه به اهمیت عملی محصولات DJI، در این پژوهش بر پهپادهای مصرفی این شرکت با وزن بین ۲۰۰ گرم تا ۱ کیلوگرم تمرکز داریم. ما در این پژوهش، از سه مدل مختلف پهپاد DJI و کنترلکنندههای متناظر آنها (Remote Controls یا RCs) برای تحلیل امنیتی استفاده کردیم:
- DJI Mini 2, RC: RC231
- Mavic Air 2, RC: RC231
- Mavic 2 Pro / Zoom, RC: RC1B
علاوه بر این، یافتههای خود را روی جدیدترین پهپاد DJI، یعنی Mavic 3 نیز بازتولید کردیم (پهپادی که در زمان تحلیل اولیه در دسترس نبود). نتایج ارائه شده در این بخش بر پایه تحلیل چندین پهپاد جدید DJI و مهندسی معکوس تصاویر مختلف میانافزار (firmware images) به دست آمدهاند.
۲.۱ رابطهای ارتباطی و پروتکلها (Communication Interfaces and Protocols)
در ادامه، مروری بر رابطها و پروتکلهای ارتباطی یک پهپاد معمولی ارائه میدهیم. این جنبهها بهطور خاص اهمیت دارند، زیرا مستقیماً در معرض دسترسی مهاجمان قرار میگیرند.
شکل ۱ نمای کلی از رابطهای مختلف یک پهپاد شرکت DJI و نحوه استفاده آنها برای ارتباط بین پهپاد، کنترل از راه دور (Remote Control یا RC) و یک رایانه را نشان میدهد. در حالی که پهپاد و کنترلکننده در حین عملیات پرواز با یکدیگر در ارتباط هستند، رایانه تنها برای تحلیل، بهروزرسانی یا دسترسی به فایلهای موجود روی پهپاد یا کنترلکننده مورد استفاده قرار میگیرد.
USB. هم پهپادها و هم کنترلکنندهها (RCs) معمولاً دارای یک رابط USB هستند که برای انواع مختلف کلاسهای دستگاه و کاربردهای گوناگون استفاده میشود. کاربرد اصلی این رابط، انتقال دادههایی مانند فایلهای رسانهای از حافظه داخلی یا لاگهای پرواز از سیستم ثبت پرواز است.
رابط USB در دستگاههای DJI، همچنین برای ارسال دستورات زبان نشانهگذاری جهانی DJI (یا به اختصار DUML – یک پروتکل ارتباطی اختصاصی طراحی شده توسط DJI) به کار میرود. این دستورات برای کنترل تنظیمات داخلی دستگاه یا آغاز به روزرسانی میانافزار مورد استفاده قرار میگیرند. علاوه بر این، در فرآیند بوت شدن (Boot) دستگاه یک بوتلودر (bootloader) نیز در معرض دسترس قرار میگیرد که میتوان آن را از طریق بستههای USB خاص فعال کرد.
همچنین در کنترلکنندهها (RCs – مدل RC231)، دو رابط USB وجود دارد: یکی برای اتصال تلفن هوشمند به کنترلکننده جهت استفاده از اپلیکیشن DJI Fly و دیگری برای شارژ کنترلکننده. پورت شارژ نیز میتواند برای اتصال کنترلکننده به رایانه مورد استفاده قرار گیرد.
UART. رابط UART (فرستنده–گیرنده همهمنظوره ناهمزمان یا Universal Asynchronous Receiver-Transmitter) عمدتاً در میکروکنترلرها (micro-controllers) برای ارتباطات سیمی مورد استفاده قرار میگیرد. چنین رابطهایی در پهپادهای DJI نیز یافت میشوند؛ برای مثال در فرستنده-گیرنده (transceiver) Sparrow S1 (که با نام S1 System on a Chip یا SoC شناخته میشود)؛ برای جزئیات بیشتر به بخش 4.3.2 مراجعه شود. در فرآیند تحلیل سختافزاری، مشاهده کردیم که این رابط تنها به مدت حدود دو ثانیه پس از راهاندازی (startup) فعال میشود و در این بازه، صفحه بوتِ بوتلودر (boot screen of the bootloader) را نمایش میدهد.
لایه فیزیکی بیسیم: Bluetooth،WiFi و OcuSync. پهپادهای جدید شرکت DJI از پروتکلهای بیسیم مختلفی مانند Bluetooth و WiFi جهت انجام کارهای مختلفی همچون انتقال تصاویر ثبت شده توسط دوربین پهپاد به تلفن هوشمند از طریق اپلیکیشن DJI Fly پشتیبانی میکنند. اتصال WiFi همچنین در پهپادهای قدیمیتر مانند Mavic Pro یا Mavic Air وجود دارد، اما در این مدلها برای لینک فرماندهی و کنترل (Command & Control یا C2) جهت هدایت پهپاد از طریق تلفن هوشمند استفاده میشود. این ارتباط در پهپادهای جدیدتر DJI، جای خود را به پروتکل رادیویی اختصاصی این شرکت با نام OcuSync داده است که عملکرد به مراتب بهتری داشته و کمتر در معرض تداخل سیگنال (interference) قرار میگیرد.
DUML. فرمت DUML (زبان نشانهگذاری جهانی DJI) یک پروتکل ارتباطی اختصاصی است که توسط شرکت DJI مورد استفاده قرار میگیرد؛ برای مثال، برای ارسال دستورات و دادهها بین ماژولهای داخلی و همچنین بین کنترلکننده (RC) و پهپاد بهکار میرود [23]. DUML برای تنظیم و تغییر پارامترهای پهپاد استفاده میشود؛ از جمله پارامترهای پرواز مانند حداکثر ارتفاع، یا پارامترهای سرعت نظیر حداکثر سرعت صعود و فرود.
از آنجا که فرایند تجزیه (parsing) این پروتکل مستعد خطا است، DUML یک هدف مهم و جذاب برای تحلیلهای امنیتی بیشتر محسوب میشود. از این رو در ادامه، یک مرور دقیق از این پروتکل اختصاصی ارائه میدهیم.
شرکت DJI دو نسخه از پروتکل DUML را متمایز میکند: V1 و Logic. پروتکل Logic برای ارتباط داخلی بین ماژولهای (module) مختلف پهپاد استفاده میشود، در حالی که نسخه V1 برای ارتباط بین رایانه و پهپاد از طریق USB بهکار میرود. DJI مستندات عمومی درباره دستورات قابل استفاده در این پروتکل ارائه نمیدهد، اما بسیاری از این دستورات توسط جامعه مهندسی معکوس DJI مستندسازی شدهاند [24]. ما نیز بخشهای مختلف میانافزار را مهندسی معکوس کردیم تا ساختار این پروتکل را تأیید کنیم.
ساختار یک بسته DUML، همانطور که در شکل ۲ نشان داده شده است، میتواند به چهار بخش تقسیم شود: هدر (header)، بخش انتقال (transit)، دستور (command) و پیلود (payload). هدر شامل یک بایت جادویی (magic byte) با مقدار ثابت 0x55 است که در ادامه آن طول بسته، شماره نسخه و یک جمعآزمای (checksum) هدر (Header) از نوع CRC-8 قرار میگیرد.
پس از هدر، بخش دادههای انتقال (transit data) قرار دارد که برای تعیین فرستنده و گیرنده دستور DUML استفاده میشود. بر اساس کارهای پیشین [24]، در مجموع ۳۲ نوع شناخته شده از فرستنده و گیرنده وجود دارد (برای مثال: PC، برنامه کاربردی موبایل، برد مرکزی و WiFi). بخش انتقال علاوه بر مبدأ و مقصد، شامل یک شماره توالی (sequence number) یکتا نیز هست که برای حفظ ترتیب چندین بسته متوالی مورد استفاده قرار میگیرد.
بخش سوم یک بسته DUML، خود دستور (command) است. در این بخش، فیلدهای commandtype، commandset و commandid تعریف میشوند. بر اساس commandtype، نوع تأییدیه (acknowledgment)، نوع بسته (packet type) و نوع رمزگذاری (encryption type) تعیین میشود. Commandset نیز مشخص میکند که برای تفسیر commandid از کدام مجموعه دستورات استفاده شود. در مجموع ۱۷ مجموعه دستور شناخته شده بر اساس مرجع [24] وجود دارد که میتوان از آنها استفاده کرد؛ برای مثال: دستورات عمومی (general)، کنترلکننده پرواز (flight controller)، WiFi یا باتری. ما این یافتهها را بر اساس نتایج مهندسی معکوس خود نیز تأیید کردهایم. در نهایت، آخرین بخش بسته شامل پیلود (payload) و یک جمعآزما (checksum) CRC-16 است که روی کل بسته محاسبه میشود. به منظور افزایش کارایی، از یک روش کدگذاری اختصاصی استفاده شده است که در آن اطلاعات به صورت فشرده (tightly packed) ذخیره میشوند. این روشِ رمزگذاری و رمزگشایی بهترتیب در لیستهای ۱۴ و ۱۵ در پیوست مقاله خلاصه شده است. در ادامه، آزمایشهای امنیتی پویای (dynamic security tests) ما بر اساس ساختار بازیابی شده DUML انجام میشود و از آن برای ساخت یک چارچوب فازینگ سفارشی استفاده خواهیم کرد (برای جزئیات بیشتر به بخش ۴.۴ مراجعه شود).
برنامه کاربردی DJI Fly / DJI Go 4 (DJI Fly / DJI Go 4 App). شرکت DJI یک اپلیکیشن مختص سیستمعاملهای iOS و Android ارائه میدهد که برای نمایش ویدئوی زنده (live video feed) و ارائه کنترلهای اضافی مورد استفاده قرار میگیرد. در پهپادهای جدید، از برنامه کاربردی DJI Fly استفاده میشود، در حالی که پهپادهای قدیمیتر از برنامه کاربردی DJI Go 4 بهره میبرند. هر دو برنامه کاربردی عملاً قابلیتهای مشابهی ارائه میدهند؛ از جمله نمایش ویدئوی زنده پهپاد، امکان گرفتن عکس و ضبط ویدئو، تغییر تنظیمات مختلف پهپاد، بهروزرسانی میانافزار (firmware)، و بررسی وضعیت کلی دستگاه.
نتیجه یک تحلیل امنیتی در سال ۲۰۲۰ توسط Synacktiv حاکی از آن بود که برنامه کاربردی DJI Go 4 دارای برخی قابلیتهای بحثبرانگیز است؛ از جمله یک مکانیزم بهروزرسانی خودکار (auto-updater) که به ادعای این گزارش، ممکن است قوانین و شرایط سرویس فروشگاه Google Play را نقض کند [15]. شرکت DJI در پاسخ اعلام کرد که این قابلیت به حفظ یکپارچگی مناطق پرواز ممنوع (no-fly zones) کمک میکند [25]. این برنامه کاربردی در سال ۲۰۲۱ بدون توضیح رسمی از Google Play Store حذف (unlisted) گردید و از آن پس وبسایت DJI به عنوان کانال اصلی توزیع آن مورد استفاده قرار میگیرد. نصب یا به روزرسانی این برنامه مستلزم آن است که کاربران اجازه نصب از منابع غیرمعتبر (untrusted third parties) را فعال کنند؛ قابلیتی که به صورت پیشفرض به دلایل امنیتی غیرفعال است. بهطور خاص، این فرآیند میتواند از برخی سازوکارهای امنیتی و حریم خصوصی اعمال شده توسط فروشگاههای نرمافزاری عبور کند.
۲.۲ میانافزار پهپاد (Drone Firmware)
بسته به میزان پیچیدگی، پهپادهایی که ما تحلیل کردهایم از سیستمعاملهای (OS) متفاوتی استفاده میکنند. در بیشتر پهپادهای DJI، سیستمعامل بر پایه اندروید (Android) است که در نسخههای قدیمیتر کنترلکنندههای آنها (مانند Mavic Pro RC مدل GL200) نیز استفاده شده است. سری DJI Mini از یک لینوکس ۳۲ بیتی مبتنی بر Buildroot [26] استفاده میکند. برای عملیاتهایی که به زمان و عملکرد حساس میباشند، از سیستمعاملهای بلادرنگ (Real-Time Operating Systems – RTOS) استفاده میشود؛ برای مثال، کنترلکننده پرواز و کنترلکنندههای جدیدتر مانند RC231 از دو RTOS در فرستنده-گیرنده (transceiver) برای مدیریت ارتباط رادیویی (RF) استفاده میکنند (یکی برای بخش برنامه کاربردی و دیگری برای پردازش ارتباطات).
میانافزار این RTOSها در فرستنده-گیرنده به صورت باینریهای رمزگذاری شده برای هر دو پردازنده ارائه میشود. سیستمعاملها (به جز میانافزار RTOS) بر پایه مجموعه نرمافزاری BusyBox میباشند که به طور رایج در سیستمهای نهفته (embedded systems) مورد استفاده قرار میگیرند. DJI، میانافزار خود را در یک قالب (Format) اختصاصی بستهبندی میکند که با AES رمزگذاری و با RSA امضا شده است. ماژولها، فایلها و موارد استفاده مختلف مانند بهروزرسانی میانافزار یا انتقال داده از کلیدهای رمزگذاری متفاوتی استفاده میکنند. برخی از این کلیدها توسط افراد جامعه DJI فاش شدهاند و ما نیز صحت آنها را برای رمزگشایی بخشی از میانافزار تأیید کردهایم.
۲.۳ سختافزار پهپاد (Drone Hardware)
در ادامه، مروری بر اجزای سختافزاری معمول مورد استفاده در پهپادهایی که ما تحلیل کردهایم ارائه شده است. شکل ۳ یک نمای کلی از اجزای اصلی چنین پهپادی را با استفاده از DJI Mini 2 به عنوان نمونه نشان میدهد. این شکل همچنین نحوه اتصال اجزای مختلف به یکدیگر و چگونگی ارتباط آنها با هم را نمایش میدهد. این نمای کلی و توضیحات مرتبط با آن قابل تعمیم به سایر مدلهای پهپاد DJI است که تنها در عملکرد اجزا یا اضافه بودن برخی حسگرهای بیشتر با یکدیگر تفاوت دارند.
کنترلکننده پرواز (Flight Controller). کنترلکننده پرواز مهمترین بخش یک پهپاد است و باید در تمامی شرایط، قابل اعتماد، قابل پیشبینی و قطعی (deterministic) عمل کند. به منظور تضمین این ویژگیها، این بخش از یک سیستمعامل بلادرنگ (RTOS) استفاده میکند. این کنترلکننده، رفتار پرواز را با جمعآوری داده از حسگرهایی مانند واحد اندازهگیری اینرسی (IMU)، قطبنما، GPS یا سیستم موقعیتیابی بصری (VPS) نظارت میکند. کنترلکننده سپس با استفاده از این اطلاعات، پایداری پرواز را حفظ کرده و دستوراتی را به کنترلکنندههای کنترل سرعت الکترونیکی (ESC) ارسال میکند؛ این کنترلکنندهها سرعت چهار موتور را تنظیم میکنند.
علاوه بر این، کنترلکننده پرواز مسئول تأیید شرایط پرواز و اجازهدادن به برخاست (takeoff) است؛ این کار با بررسی وضعیت ESCها، باتری و سایر ماژولها انجام میشود. همچنین، این بخش پایگاهداده داخلی مناطق پرواز ممنوع (No-Fly Zones – NFZ) را بررسی میکند تا مشخص شود آیا پرواز در یک منطقه خاص از حریم هوایی مجاز انجام میشود یا خیر. در نهایت، کنترلکننده پرواز دستورات کنترلی را از طریق فرستنده-گیرنده (در اینجا S1 SoC) دریافت کرده و به ورودیهای کاربر که از این SoC دریافت میشود واکنش نشان میدهد.
علاوه بر این، کنترلکننده پرواز، اطلاعات دریافتی از ماژولها و حسگرهای مختلف را به فرستنده-گیرنده (transceiver) ارسال میکند.
سامانه روی تراشه (SoC) پردازش ویدئو و جلوگیری از برخورد (Video Encoding & Collision Avoidance SoC). این SoC (System on Chip) مسئول پردازش حسگر تصویر و رمزگذاری ویدئو است. این بخش، دادههای ویدئویی و تصویری را از دوربین دریافت کرده، آنها را پردازش میکند و سپس به فرستنده-گیرنده (transceiver) ارسال میکند. در صورت وجود حسگرهای اضافی برای جلوگیری از برخورد (collision avoidance)، دادههای این حسگرها نیز در همین SoC پردازش میشوند. این SoC علاوه بر ارسال دادههای ویدئویی به فرستنده-گیرنده، از رابطهای USB برای ذخیره تصاویر یا ویدئوها روی حافظه داخلی یا کارت SD استفاده میکند. در نهایت، این بخش مسئول مدیریت فرایند بهروزرسانی میانافزار پهپاد نیز هست. این SoC در پهپادهای DJI معمولاً از یک سیستمعامل مبتنی بر لینوکس (Linux) یا اندروید (Android) استفاده میکند.
کنترل از راه دور (Remote Control). کنترل از راه دور (RC) وظیفه کنترل پهپاد و دوربین را از طریق لینک فرماندهی و کنترل (C2) بر عهده دارد. ورودیهای کاربر از طریق کنترلکننده و تلفن هوشمند به فرستنده-گیرنده (transceiver) ارسال میشود؛ این ماژول، سیگنال را مدوله کرده (modulate) و از طریق پروتکل OcuSync ارسال میکند. علاوه بر این، کنترلکننده، دادههای downlink را نیز از پهپاد دریافت میکند که شامل دادههای دور سنجی یا تلهمتری (telemetry) و جریان ویدئوی زنده است؛ سپس این دادهها به تلفن هوشمند منتقل میشوند. کنترلکننده مدل RC231 که از SoC موسوم به S1 بهعنوان فرستنده-گیرنده استفاده میکند، توسط جدیدترین پهپادهای شرکت DJI مانند DJI Mini 2، Mavic Air 2، Mavic Air 2s و DJI Mavic 3 پشتیبانی میشود. این پهپادها از پروتکل انتقال OcuSync برای ارتباط C2 و downlink استفاده میکنند. نسخه OcuSync بسته به مدل پهپاد متفاوت است و میتواند OcuSync 2.0، 3.0 یا 3+ باشد.
فرستنده-گیرنده (Transceiver). ترنسیور ترکیبی از فرستنده (transmitter) و گیرنده (receiver) برای ارتباط رادیویی است و یکی از اجزای حیاتی پهپاد به شمار میآید. این بخش میتواند از طریق یک پروتکل اختصاصی یا استانداردهای بیسیم مانند Bluetooth یا WiFi کار کند. در برخی از جدیدترین پهپادهای شرکت DJI، از فرستنده-گیرنده موسوم به Sparrow S1 برای انتقالهای OcuSync استفاده میشود. این فرستنده-گیرنده، یک SoC اختصاصی مبتنی بر پردازنده ARM Cortex-M میباشد که در مدلهای DJI Mini 2 و Mavic Air 2 به کار رفته است. پهپادهای Mavic Air 2s و DJI Mavic 3 از فرستنده-گیرنده دیگری به نام SoC P1 (Pigeon) استفاده میکنند. تمرکز ما در این پژوهش، بر روی SoC مدل S1 است.
این SoC به عنوان فرستنده-گیرنده برای OcuSync استفاده میشود و شامل دو سیستمعامل بلادرنگ (RTOS) است؛ یکی برای پردازنده برنامه کاربردی (application processor) و دیگری برای پردازنده ارتباطی (communication processor). میانافزارِ این RTOSها با نام Sparrow Firmware یا میانافزار Sparrow شناخته میشود و هم در فایلهای بهروزرسانی کنترل از راه دور (RC) و هم در سیستم فایل پهپاد قابل مشاهده است. فرستنده-گیرنده در پهپاد، دادههای تلهمتری و سایر گزارشها را از کنترلکننده پرواز (flight controller) و همچنین دادههای ویدئویی را از SoC رمزگذاری ویدئو دریافت میکند. سپس تمام این دادهها به سیگنال رادیویی (RF) مدوله شده (modulate) و از طریق آنتنها ارسال میشوند. علاوه بر این، فرستنده-گیرنده، لینک C2 (فرماندهی و کنترل) را از کنترلکننده از راه دور دریافت کرده و این دادهها را به کنترلکننده پرواز منتقل میکند.
تراشههای WiFi / Bluetooth. تراشه یا Chipهای WiFi یا Bluetooth میتوانند به عنوان یک فرستنده–گیرنده (transceiver) مورد استفاده قرار گیرند و امکان برقراری ارتباط با یک کنترلکننده RC یا تلفن هوشمند را برای کنترل پهپاد فراهم آورند. با این حال، این پیکربندی دارای این نقطهضعف است که برد ارتباطی و قابلیت اطمینان آن در مقایسه با پروتکلهای رادیویی اختصاصی (proprietary radio protocols) پایینتر است. پهپادهای DJI Mini 2 و Mavic 3 به یک تراشه WiFi و Bluetooth اضافی مجهز میباشند که به کاربران اجازه میدهد به سادگی به فایلهای چندرسانهای ذخیره شده روی پهپاد دسترسی داشته باشند.
حسگرهای اضافی و سایر سختافزارها (Additional Sensors and Other Hardware). اغلب پهپادهای مصرفی امروزی، مجهز به یک دوربین با وضوح بالا هستند که بر روی یک گیمبال (gimbal) نصب شده است. این گیمبال وظیفه جبران حرکات پهپاد را بر عهده دارد و موجب تثبیت تصویر و تولید خروجی پایدار میشود. پهپادها علاوه بر دوربین اصلی، میتوانند از دوربینهای اضافی نیز برای جلوگیری از برخورد (collision avoidance) استفاده کنند. حسگرهای دیگر میتوانند شامل حسگرهای مادون قرمز (infrared) یا اولتراسونیک (ultrasonic) برای اندازهگیری ارتفاع پهپاد یا شتابسنجها (accelerometers) و حسگرهای ژیروسکوپی (gyroscopic sensors) برای اندازهگیری شتاب و شیب (میزان زاویه/تغییر وضعیت (tilt)) باشند.
۲.۴ لایه فیزیکی بیسیم (Wireless Physical Layer)
پهپادهای نسل جدید شرکت DJI از پروتکل اختصاصی OcuSync برای انتقال بیسیم در باندهای بدون مجوز ISM با فرکانس 2.4 گیگاهرتز و 5 گیگاهرتز استفاده میکنند. پهپاد یک جریان ویدیویی زنده با پهنایباند بالا را به واحد کنترل از راه دور (RC) ارسال میکند و این جریان سپس به تلفن هوشمند متصل منتقل میشود. همچنین، کنترل پهپاد توسط کنترلکننده از طریق سیگنالهای C2 صورت میپذیرد. طبق اعلام DJI، هر دو مسیر ارتباطی uplink و downlink با استفاده از رمزگذاری AES-256 محافظت میشوند [21]. بُرد ارتباطی OcuSync در باندهای 2.4 و 5 گیگاهرتز حدود 15 کیلومتر گزارش شده است [27]. بر اساس پایگاه داده شناسه FCC، این تجهیزات در مسیر downlink (از پهپاد به کنترلکننده) از کانالهایی با پهنای 20 مگاهرتز و مدولاسیون OFDM (Orthogonal Frequency Division Multiplexing) استفاده میکنند. در مقابل، لینک uplink کنترل از روش پرش فرکانسی (frequency hopping) با سیگنالهای باریکتر بهره میبرد [28]. پهپادهای نسلهای قبلی از فناوری «Enhanced WiFi» یا نسخه سفارشیسازیشده از پروتکل WiFi استفاده میکردند که امکان شنود (sniffing) آن با استفاده از کارتهای شبکه WiFi وجود داشت. در مقابل، در معماری OcuSync هیچ گیرنده متنباز یا در دسترس عمومی وجود ندارد که بتواند سیگنالهای ارسال شده از پهپاد یا کنترلکننده را رمزگشایی و دریافت کند.
۳. تحلیل امنیتی بدون دسترسی فیزیکی (Security Analysis without Physical Access)
پهپادها سامانههای سایبر–فیزیکی (Cyber-Physical Systems) پیچیدهای هستند که از ماژولهای متعددی تشکیل شدهاند و هر یک از این ماژولها، مطابق آنچه در شکل ۳ نشان داده شده است، رابطهای (interfaces) گوناگونی را در اختیار یک مهاجم قرار میدهند. تعامل میان اجزا و رابطهای مختلف، مستلزم نظاممندسازی (systematization) قابلیتهای دسترسی است تا بتوان یک تحلیل امنیتی جامع از پهپادها ارائه داد. این رابطها را میتوان به دو دسته کلی شامل رابطهای بیسیم و رابطهایی که نیازمند دسترسی فیزیکی هستند، تقسیمبندی کرد.
۳.۱ مدل تهدید ۱: مهاجم منفعل (Threat Model 1: Passive Attacker)
ما در بخش نخست از تحلیل امنیتی، سناریویی را مورد بررسی قرار میدهیم که در آن مهاجم هیچگونه دسترسی فیزیکی به پهپاد یا واحد کنترل از راه دور (RC) ندارد. در نتیجه، دامنه فعالیت مهاجم صرفاً به لینکهای بیسیم و سیگنالهای پخش همگانی (broadcast signals) محدود میشود. مهاجم در این چارچوب، به صورت منفعل (passive) اقدام به شنود لایه فیزیکی ارتباطات بیسیم میکند تا بتواند موقعیت مکانی پهپاد و همچنین کنترلکننده متناظر آن (یعنی خلبان) را شناسایی و ردیابی نماید. ما در بخش ۴ نیز، این فرض محدودکننده را تضعیف کرده و سناریویی را بررسی میکنیم که در آن مهاجم به پهپاد دسترسی فیزیکی دارد و در نتیجه از قابلیتهای بسیار گستردهتری برای بهرهبرداری از عملکردها و استخراج اطلاعات حیاتی برخوردار است.
۳.۲ پیوند بیسیم (Wireless Link)
پیوند بیسیم یکی از مهمترین بردارهای حمله محسوب میشود؛ زیرا کنترل پهپاد را بر عهده داشته و امکان دسترسی به آن از راه دور وجود دارد. پهپادهای DJI از پروتکل اختصاصی OcuSync برای کنترل پهپاد و همچنین انتقال جریان ویدئویی (Video Stream) به کنترلکننده از راه دور (Remote Controller) استفاده میکنند. شرکت DJI همچنین سامانهای با نام Aeroscope را عرضه کرده است که به نهادهای مجری قانون امکان میدهد پهپادهای DJI و اپراتورهای آنها را مکانیابی کنند. بهمنظور انجام این فرایند مکانیابی، سامانه Aeroscope به یک سیگنال ویژه موسوم به DroneID گوش میدهد که توسط تمامی پهپادهای DJI بهصورت پخش همگانی (Broadcast) ارسال میشود.
متأسفانه، نه پروتکل OcuSync و نه DroneID به صورت عمومی مستندسازی نشدهاند و هیچ گیرنده متنبازی برای آنها در دسترس نیست. در یک گزارش رسانهای (media repor) [22] ادعا شده بود که بستههای DroneID در نسل فعلی این فناوری رمزگذاری شدهاند؛ ادعایی که شرکت DJI نیز در دو نوبت آن را تأیید کرده بود. با این حال، این ادعا در نسخهای بعدی از همان مقاله (که بخشی از آن بر اساس نتایج پژوهش ما اصلاح شده بود) تصحیح شد. این موضوع نشان میدهد که در عمل، این باور که DroneID و دادههای ارسالی به سامانه Aeroscope به صورت رمزگذاری شده منتقل میشوند، بهطور گستردهای رواج داشته است. همچنین، سند «راهنمای امنیت» (Security Whitepaper) شرکت DJI [21] هیچ اشاره صریحی به ارسالهای DroneID، قابلیتها یا محتوای آنها ندارد. در این بخش، نتایج تلاشهای خود در زمینه مهندسی معکوس (Reverse Engineering) پیامهای پخشی DroneID را ارائه میکنیم و نشان میدهیم که چگونه میتوان اطلاعات حساسی نظیر موقعیت جغرافیایی پهپاد و اپراتور کنترلکننده آن را با موفقیت استخراج کرد. مهمتر از همه، نتایج ما ادعای رمزگذاری این پروتکل را رد کرده و نادرستی آن را آشکار میسازد.
ما با پایش و اسکن باندهای فرکانسی مختلف، پخشهای رادیویی را شناسایی کردیم که از جریانهای ویدئویی با پهنای باند بالا و همچنین کانال کنترل بالارونده (Uplink Control Channel) مجزا بودند. این سیگنالها دارای بستههایی با اندازه بسیار کوچک بوده و بهصورت دورهای (Periodic) ارسال میشدند. بر همین اساس، این فرضیه مطرح شد که این پخشها همان پیامهای DroneID هستند که برای مکانیابی و شناسایی پهپادها مورد استفاده قرار میگیرند. بررسیهای ما نشان میدهد که شرکت DJI حداقل از سال ۲۰۱۷ این قابلیت را در محصولات خود حفظ کرده است. در همین راستا، مقررات مرتبط با پهپادها که انتشار اطلاعات مکانی را از طریق استانداردهای باز و عمومی (مبتنی بر فناوریهای Wi-Fi یا Bluetooth) الزامی میکنند، در حال حاضر در مرحله تدوین و توسعه قرار دارند؛ با این حال، این مقررات هنوز نهایی و تصویب نشدهاند (برای بحث تفصیلی در این زمینه، به بخش ۵ مراجعه شود).
ازاینرو، فرض میکنیم که نسل جدید پهپادهای DJI از پروتکل OcuSync برای ارسال اینگونه پیامهای پخشی استفاده میکنند. در این پژوهش، بستههای ارسالی را با هدف پاسخ به دو پرسش اساسی مورد تحلیل قرار میدهیم: (۱) چه نوع دادههایی در نسخههای فعلی DroneID گنجانده شدهاند و (۲) آیا این سازوکار دارای ویژگیهای امنیتی خاص یا غیرمنتظرهای است یا خیر.
همانگونه که پیشتر اشاره شد، این پروتکل بیسیم فاقد مستندات عمومی است و تحلیل آن مستلزم انجام فرایند مهندسی معکوس میباشد. بررسی و تحلیل سازوکار DroneID در پروتکل OcuSync نخستین گام در مسیر فراهمسازی بستر لازم برای تحلیلهای عمیقتر و جامعتر این پروتکل ارتباطی به شمار میرود.
گیرنده DroneID (DroneID Receiver). ما یک گیرنده زنده و بلادرنگ (Live Receiver) برای DroneID پیادهسازی کردیم که از یک رادیوی نرمافزارمحور (Software-Defined Radio – SDR) برای دریافت سیگنالها و از یک زنجیره پردازش مبتنی بر زبان پایتون (Python) برای تحلیل دادهها استفاده میکند. پیادهسازی نمونه ما شامل تمامی مراحل اصلی پردازش سیگنال است؛ از جمله دریافت سیگنال (Signal Acquisition)، دمدولاسیون (Demodulation) یا استخراج اطلاعات از سیگنال مدوله شده، رمزگشایی (Decoding) و اعتبارسنجی دادهها از طریق یک جمعآزمای CRC (CRC Checksum). تمرکز اصلی ما بر انجام یک تحلیل گامبهگام به منظور استخراج و شناسایی پارامترهای ناشناخته یک پروتکل اختصاصی از روی سیگنالهای رادیویی است؛ مسئلهای که به خودی خود یک چالش فنی و پژوهشی پیچیده در حوزه مهندسی معکوس پروتکلهای بیسیم به شمار میآید.
پیادهسازی ارائه شده قادر است بستههای DroneID را به صورت بلادرنگ دریافت و رمزگشایی کند. افزون بر این، سامانه ما یک چالش مستقل و مهم دیگر را نیز برطرف میسازد؛ بدین صورت که پهپادها به صورت پویا بین باندهای فرکانسی ۲.۴ گیگاهرتز و ۵.۷ گیگاهرتز جابهجا میشوند. از این رو، سامانه به طور مداوم هر دو باند فرکانسی را برای شناسایی فریمهای کاندید (Candidate Frames) پایش میکند و فریمهای شناسایی شده را به مراحل دمدولاسیون و رمزگشایی ارسال مینماید. شکل ۴ ساختار کلی و اجزای گیرنده توسعه یافته را به همراه فرایند پردازش داخلی دادههای دریافتی نشان میدهد. این فرایند شامل مراحل جستوجوی فرکانس (Frequency Search)، پردازش سیگنال (Signal Processing)، دمدولاسیون (Demodulation) و رمزگشایی (Decoding) است. جزئیات فنی و نحوه عملکرد هر یک از این بخشها در ادامه به صورت مفصل تشریح میشود.
در پیادهسازی ما از یک رادیوی نرمافزارمحور USRP B200mini SDR استفاده شده است که به یک لپتاپ متصل میگردد. این SDR قادر است بهصورت همزمان تا ۵۶ مگاهرتز پهنای باند را در بازههای فرکانسی بین ۷۰ مگاهرتز تا ۶ گیگاهرتز ثبت و نمونهبرداری کند. گیرنده، هر باند فرکانسی را به مدت ۱.۳ ثانیه و با پهنای باند ۵۰ مگاهرتز اسکن میکند که در نتیجه، در هر باند، مجموعههای دادهای (Batch) با اندازه تقریبی ۴۹۶ مگابیت تولید میشود. پس از شناسایی فریمها، سامانه روی باند مربوطه قفل میشود (Band Lock) تا بتواند به صورت پیوسته فریمهای DroneID را ثبت کند. بازگشت به حالت اسکن تنها زمانی انجام میشود که پهپاد، کانال خود را تغییر داده باشد و در چندین چرخه متوالی، هیچ بسته جدیدی دریافت نشود.
تحلیل طیف (Spectrum Analysis). همانگونه که پیشتر اشاره شد، مشخصات فنی پروتکلهای OcuSync و DroneID به صورت عمومی منتشر نشدهاند. با این حال، بر اساس تحلیلهای انجام شده، مشخص گردید که این پروتکلها از تکنیکهای مدولاسیون (modulation) و پارامترهایی مشابه با LTE استفاده میکنند. در ادامه، تمامی پارامترهای مرتبط به صورت گامبهگام از طریق فرایند مهندسی معکوس (Reverse Engineering) استخراج و بازسازی شدند. شکل ۵ طیف یک فریم رادیویی منفرد از DroneID را نشان میدهد. هر بسته شامل ۹ نماد (Symbol) است که از جمله آنها میتوان به دو نماد همگامسازی Zadoff–Chu (ZC) در نمادهای ۴ و ۶ اشاره کرد. سایر نمادها از نوع نمادهای دادهای OFDM هستند که دارای ۶۰۱ زیرحامل (Subcarriers) میباشند (شامل ۶۰۰ زیرحامل داده و ۱ زیرحامل DC). فاصله بین زیرحاملها نیز برابر با ۱۵ کیلوهرتز است. در ادامه، به منظور اعمال تبدیل فوریه سریع (Fast Fourier Transform – FFT) در مرحله بعدی پردازش، به توان بعدی دو افزایش مییابند (padded to the next power of two). این فرآیند منجر به تشکیل مجموعاً ۱۰۲۴ زیرحامل با پهنای باند کلی ۱۵.۳۶ مگاهرتز (با احتساب باندهای محافظ یا Guard Bands) میگردد.
مشاهدات ما حاکی از آن است که این بستهها بهصورت تکرارشونده هر ۶۴۰ میلیثانیه پخش همگانی (broadcast) میشوند. همچنین مشاهده کردیم که برخی پهپادها (از جمله Mavic 2 و سایر پهپادهای قدیمیتر مجهز به OcuSync) نماد اول (Symbol 1، مطابق شکل ۵) را ارسال نمیکنند. این موضوع منجر به کاهش طول فریم و رسیدن آن به ۵۷۶ میکروثانیه میشود. سایر پارامترهای سیستم بدون تغییر باقی میمانند.
دمدولاسیون (Demodulation). فرآیند تبدیل سیگنالهای رادیویی به دادههای دودویی (بیتها و بایتها) شامل چندین مرحله است: (۱) همگامسازی زمانی (Time Synchronization) برای تعیین مرزهای نمادهای OFDM، و همچنین همگامسازی فرکانسی (Frequency Synchronization) برای همتراز شدن با زیرحاملهای OFDM که پیلود (Payload) را حمل میکنند؛ (۲) تخمین کانال (Channel Estimation) به منظور جبران اعوجاجها (distortions) و تغییرات ایجاد شده در طول انتقال رادیویی؛ و (۳) دمدولاسیون زیرحاملها (Subcarrier Demodulation)، یعنی نگاشت زیرحاملهای OFDM به بیتها. در این بخش، بهطور خلاصه مراحل انجام شده برای دمدولاسیون را تشریح میکنیم.
همگامسازی زمانی از طریق پیشوندهای چرخشی (Time Synchronization via Cyclic Prefixes). نمادها (Symbols) نمیتوانند به صورت پشتسرهم و بدون فاصله به یکدیگر متصل شوند. از این رو، به منظور کاهش تداخل بیننمادی (Inter-Symbol Interference – ISI) نیاز به فاصلهگذاری بین آنها وجود دارد. این فاصله میان نمادها در ساختار DroneID، با استفاده از پیشوند چرخشی (Cyclic Prefix – CP) پر میشود؛ به این صورت که یک نسخه از بخش انتهایی هر نماد، در ابتدای نماد مربوطه اضافه میگردد. این سازوکار امکان اعمال روش همگامسازی زمانی Schmidl–Cox را فراهم میسازد. در این روش، همبستگی (Correlation) بین دو بلوک که به اندازه یک طول نماد از یکدیگر جابهجا شدهاند و دارای طولی برابر با پیشوند چرخشی هستند، محاسبه میشود. این اصل در شکل ۶ نشان داده شده است.
طول پیشوند چرخشی (Cyclic Prefix) برابر با ۷۲ نمونه (samples) است، به جز در نمادهای ۱ و ۹ که در آنها از یک پیشوند چرخشی توسعهیافته با طول ۸۰ نمونه استفاده شده است. اوج یا قلههای (peak) مشاهده شده در تابع همبستگی (Correlation) در شکل ۶، بیانگر نقطه شروع هر نماد در حوزه زمان میباشد. با در اختیار داشتن اطلاعات دقیق از محل شروع نمادها، میتوان آنها را با استفاده از تبدیل فوریه سریع (FFT) به حوزه فرکانس منتقل کرد؛ بهطوریکه ۱۰۲۴ نمونه در حوزه زمان منجر به ۱۰۲۴ زیرحامل در حوزه فرکانس میشود. پس از انجام مرحله همگامسازی، پیشوند چرخشی دیگر مورد نیاز نیست و از سیگنال حذف (Discard) میشود.
تصحیح انحراف یا آفست فرکانسی با استفاده از دنبالههای Zadoff–Chu (Frequency Offset Correction via Zadoff-Chu Sequences). ما دریافتیم که نمادهای ۴ و ۶ همواره شامل دنبالههای Zadoff–Chu (ZC) با ریشههای ۶۰۰ و ۱۴۷ میباشند. در ادامه، دنبالههای ZC تولید شده به صورت محلی (Locally Generated) با نماد دریافتی متناظر همبسته (Correlate) میشوند. این فرایند امکان استخراج میزان آفست فرکانس حامل (Carrier Frequency Offset – CFO) را فراهم میسازد. سپس، یک شیفت فرکانسی (Frequency Shift) بر اساس مقدار برآورد شده اعمال میگردد تا این آفست تصحیح شود.
دمدولاسیون زیرحاملها و تخصیص بیت (Subcarrier Demodulation and Bit Assignment). زیرحاملهای OFDM با استفاده از مدولاسیون QPSK (Quadrature Phase Shift Keying) مدوله شدهاند؛ به این معنا که سیگنال حامل با یکی از چهار زاویه فاز ممکن تغییر فاز میدهد تا پیام سیگنال را در قالب دو بیت مدوله (modulate) کند. شکل ۷، چهار تغییر فاز مختلف را نشان میدهد که در صورت نمایش به صورت اعداد مختلط (Complex Number Representation)، منجر به تشکیل چهار خوشه (Cluster) مجزا میشوند و هر خوشه متناظر با یک نگاشت بیت مشخص میباشد. هرچه همگامسازی و تصحیح خطا بهتر انجام شود، گروهبندی دقیقتر خواهد بود. مراحل بعدی رمزگشایی نشان خواهند داد که آیا تخصیص بیتها بهدرستی انجام شده است یا خیر.
رمزگشایی (Decoding). مراحل پیشین، سیگنال رادیویی را به یک جریان بیت (Bitstream) تبدیل میکنند که از طریق آن میتوان پیلود (payload) واقعی DroneID را بازیابی کرد. با تحلیل میانافزار (Firmware) S1، دریافتیم که دادهها به دو صورت پردازش شدهاند: (۱) ابتدا دادهها با استفاده از یک دنباله طلایی (Gold Sequence) دچار درهمریزی (Scrambling) شدهاند و ما بذر (Seed) مربوط به ثَبات انتقال با بازخورد خطی (Linear-Feedback Shift Register – LFSR) زیرساخت این دنباله را شناسایی کردهایم. همچنین، (۲) دادهها با استفاده از یک رمزگذار توربو (Turbo Encoder)، کدگذاری شدهاند که در آن از همان جدول جایگشت (Permutation Table) برای جایگذاری زیر-بلوکها (Sub-block Interleaving) مطابق با مشخصات LTE استفاده شده است [29, 30].
ما عملیات رفع درهمسازی (Descrambling) و رمزگشایی توربو (Turbo Decoding) را بر روی جریان بیت اعمال و دادههای حاصل را به ساختار DroneID (رجوع شود به فهرست ۱۳ در پیوست A) نگاشت میکنیم؛ ساختاری که از طریق مهندسی معکوس در میانافزار (Firmware) پهپاد شناسایی کردهایم. مقدار جمعآزمای CRC (CRC Checksum) موجود در هر بسته با مقدار محاسبه شده توسط ما مطابقت دارد که نشان میدهد دادهها بهدرستی بازیابی شدهاند. شکل ۸ یک نمونه از پیلود (Payload) DroneID را نشان میدهد که با موفقیت استخراج شده است.
عملکرد (Performance). ما پخشهای همگانی (broadcast) DroneID را در پهپادهای مختلف شرکت DJI از جمله Mini 2 ،Mavic Air 2 و Mavic 2 Pro / Zoom مورد بررسی قرار دادیم؛ تمامی این مدلها از پروتکل OcuSync 2.0 استفاده میکنند. ما گیرنده را در فضای باز با پهپادهای در حال پرواز آزمایش کردیم. در این آزمایش، هم پهپاد و هم اپراتور به صورت متحرک نگه داشته شدند تا بستههای DroneID غیرایستا (Non-static) تولید شود. ما توانستیم پخشهای ارسالی از تمامی این مدلها را با موفقیت رمزگشایی کنیم. پخشهای رمزگشایی شده نشان میدهند که تمام اطلاعات مکانی در هر بسته دقیق و بهروز هستند و امکان بازسازی کامل مسیر پرواز را فراهم میکنند. ما با موفقیت توانستیم پخشهای تمام این مدلها را رمزگشایی کنیم. پخشهای رمزگشایی شده نشان میدهند که فقط یک بسته DroneID برای یافتن پهپاد و خلبان (اپراتور) مورد نیاز است.
هرچه تعداد بستههای قابل رمزگشایی بیشتر باشد، وضوح مسیر پرواز (Flight Path Resolution) بالاتر خواهد بود. ما درصد فریمهای شناسایی شده (Detected Frames)، تلاشهای رمزگشایی (Decoding Attempts) و رمزگشاییهای موفق (که دارای مقدار CRC منطبق هستند) را محاسبه کرده و آن را با تعداد مورد انتظار (بر اساس بازه زمانی ارسال DroneID برابر با ۶۴۰ میلیثانیه) مقایسه میکنیم. اندازهگیریهای اولیه ما نشان میدهد که برای تمام پهپادهای آزمایش شده، حدود ۳۷ درصد از بستههای مورد انتظار بهدرستی رمزگشایی میشوند؛ به این معنا که به روزرسانیهای موقعیت تقریباً هر دو ثانیه یکبار دریافت میگردد. این نتیجه بیانگر آن است که حتی پیادهسازی نمونه (Prototype) ما از گیرنده، روشی کارآمد برای ثبت زنده و بلادرنگ (Live Recording) مسیر کامل پرواز محسوب میشود.
نتایج (Results). برد عملیاتی گیرنده ما به حدود ۱۰ متر محدود است و نسبت به تداخلهای محیطی، مانند حضور ایستگاههای مجاور Wi-Fi، حساسیت نشان میدهد. این اثر را میتوان به این موضوع نسبت داد که زنجیره گیرنده ما عمدتاً با هدف مهندسی معکوس سیگنال طراحی شده است و برای کارایی بالا یا افزایش برد ارتباطی بهینهسازی نشده است. آزمایشهای ما نشان میدهد که میتوانیم در محدوده عملکرد گیرنده، به صورت موفق و پایدار سیگنالهای اختصاصی DroneID شرکت DJI را دریافت، دمدوله (demodulate) و رمزگشایی (decode) کنیم. نکته مهم آن است که نتایج ما نشان میدهد این سیگنالها رمزگذاری نشدهاند. همچنین مشاهدات ما بیانگر آن است که DroneID اطلاعات مکانی مربوط به پهپاد، نقطه خانه (Home Point) و خلبان یا اپراتور کنترلکننده (pilot) را به صورت دقیق فاش میکند.
بستههای دریافت شده DroneID نشان دادند که فرضیات ما درباره ساختار بستهها در لایه فیزیکی بیسیم صحیح بوده و با ساختارهایی که از طریق مهندسی معکوس در میانافزار پهپاد استخراج کرده بودیم، مطابقت دارند. علاوه بر این، بستههای رمزگشاییشده تأیید کردند که ما توانستهایم شماره سریال پهپاد (رجوع شود به بخش ۱۹) را با موفقیت تغییر دهیم؛ قابلیتی که میتواند به یک کاربر مخرب امکان دهد هویت خود را مبهم (Obfuscate) کند. شکل ۸ نمونهای از اطلاعات کامل DroneID را نشان میدهد.
اکنون که امکان مشاهده و رمزگشایی بستههای DroneID برای ما فراهم شده است (که قبلاً بدون دسترسی به گیرنده Aeroscope شرکت DJI میسر نبود)، میخواهیم آزمایش کنیم که آیا غیرفعال کردن DroneID یا جعل موقعیت ارسالی امکانپذیر است یا خیر. ما در این راستا، دو آزمایش انجام میدهیم:
(۱) جعل موقعیت جغرافیایی اپراتور (Pilot Location Spoofing)، (۲) غیرفعالسازی DroneID از طریق دستورات مستندسازی نشده DUML (DJI Universal Markup Language).
ما برای مورد اول (جعل موقعیت اپراتور)، از یک گوشی اندرویدی بدون دسترسی ریشه (Non-rooted) و برنامه کاربردی «Fake GPS» از فروشگاه Google Play [31] استفاده کردیم. پس از تنظیم موقعیت جعلی در این برنامه کاربردی، به برنامه DJI سوئیچ کرده، پهپاد را راهاندازی و گیرنده را فعال نمودیم. گیرنده شروع به یافتن و رمزگشایی بستههای معتبر DroneID میکند که در آنها موقعیت پهپاد به درستی تنظیم شده است، اما مختصات ارسالی خلبان از راه دور روی موقعیت جعلی تنظیم شده است. این اپلیکیشن همچنین امکان شبیهسازی حرکتهای تصادفی را فراهم میکند که این رفتار نیز در بستههای دریافت شده DroneID قابل مشاهده و تأیید بود. فاصله بین پهپاد، نقطه خانه (Home Point) و موقعیت جعلی GPS اپراتور تأثیری بر عملکرد سیستم نداشت. از این رو، نتیجه میگیریم که هیچگونه بررسی سازگاری (Consistency Check) بین مختصات انجام نمیشود و موقعیت جغرافیایی اپراتور کنترلکننده میتواند با موفقیت جعل شود.
علاوه بر این، ما در جریان تحلیل امنیتی خود، به یک دستور DUML (DJI Universal Markup Language) دست یافتیم که در منابع عمومی مستندسازی نشده بود و به نظر میرسید امکان پیکربندی و حتی غیرفعالسازی مقادیر مختلف DroneID را فراهم میکند. بر اساس اعلام شرکت DJI، این دستور بخشی از یک API داخلی (Internal API) است که نباید از طریق محیط خارجی در دسترس قرار گیرد. این مسئله در مدلهای جدیدتر برطرف شده است. ما با استفاده از رمزگشای بلادرنگ (Live Decoder) توسعهیافته برای DroneID، توانستیم تأیید کنیم که این دستور در عمل، ارسال بستههای DroneID را غیرفعال نمیکند؛ بلکه به جای آن، مقادیر متناظر درون بسته را با مقدار جعلی جایگزین میکند.
به طور خلاصه، ما در این پژوهش، پخشهای همگانی (broadcast) اختصاصی DroneID شرکت DJI را با استفاده از مهندسی معکوس تحلیل کرده و موفق به استخراج ساختار آنها شدیم. نتایج نشان میدهد که این دادهها رمزگذاری نشدهاند و همچنین نشان دادیم که ابزارهای رایج موجود برای رمزگشایی این اطلاعات کافی هستند؛ اطلاعاتی که شامل موقعیت جغرافیایی پهپاد و اپراتور کنترل کننده آن نیز میشود. این یافتهها با تصور عمومی فعلی در تضاد است؛ تصوری که فرض میکند چنین اطلاعات حساس مرتبط با حریم خصوصی به صورت محافظت شده منتقل میشوند [22]. در نتیجه، این موضوع میتواند بهعنوان یک خطر برای حریم خصوصی (Privacy Risk) کاربران پهپاد تلقی شود، بهویژه در مواردی که کاربران از این نحوه عملکرد آگاهی ندارند. در بررسی اینکه آیا دادههای موقعیت مکانی در برابر تلاشهای جعل (Spoofing) محافظت شدهاند یا خیر، مشخص شد که هیچگونه مکانیزم حفاظتی در این خصوص وجود ندارد.
۴. تحلیل امنیتی با دسترسی فیزیکی (Security Analysis with Physical Access)
تمرکز ما تا این مرحله، صرفاً بر روی یک مهاجم منفعل (Passive Attacker) بوده است که لایه فیزیکی بیسیم را پایش و شنود میکند. در این بخش، فرض را بر وجود یک مهاجم فعال (Active Attacker) قرار میدهیم.
۴.۱ مدل تهدید ۲: مهاجم فعال (Active Attacker)
در ادامه، سناریوهایی را در نظر میگیریم که در آن مهاجم به دسترسی فیزیکی به پهپاد، کنترلکننده از راه دور (RC) و تلفن همراه متصل به RC دسترسی دارد. فرض میکنیم هدف این مهاجم ایجاد اختلال در سرویس (Denial of Service) یا دور زدن مکانیزمهای حفاظتی اعمال شده توسط DJI بر روی پهپاد است. برای مثال، مهاجم ممکن است قصد داشته باشد پهپاد را در حین پرواز دچار سقوط کند، DroneID را غیرفعال سازد، حصار جغرافیایی (Geofencing) را دور بزند، یا سایر محدودیتهای نرمافزاری را غیرفعال کند تا امکان پرواز در مناطق محدود شده فراهم گردد. نخستین گام در راستای دستیابی به این اهداف، امکان استخراج میانافزار (Firmware) اجرا شده بر روی پهپاد و سپس ارتقای سطح دسترسی (Privilege Escalation) است.
تأکید میکنیم که با وجود فرض دسترسی فیزیکی به پهپاد، این فرض عمدتاً صرفاً برای تسهیل فرآیند تحلیل در نظر گرفته شده است. همانطور که نشان خواهیم داد، پس از شناسایی دستورات مهم، تقریباً تمامی آنها را میتوان از راه دور (Over-the-Air) به پهپاد ارسال کرد. به بیان دیگر، ما همچنین گونهای دیگر از مدل مهاجم فعال را مورد بررسی قرار میدهیم: مهاجمی که تنها تلفن همراه هوشمند کاربر متصل به کنترلکننده از راه دور (RC) را به دست گرفته (که در حین پرواز یک وضعیت متداول است) است اما هیچگونه دسترسی فیزیکی به خود پهپاد ندارد.
۴.۲ نمای کلی (Overview)
از آنجا که پهپادها سامانههای پیچیده سایبر-فیزیکی (Cyber-Physical Systems) با رابطهای متعدد، فایلهای میانافزار (Firmware) گوناگون و معماریهای متنوع هستند، لازم است انواع مختلفی از روشهای تحلیل برای بررسی آنها بهکار گرفته شود. Nassi و همکارانش [10]، شش هدف متمایز را که میتوانند مورد حمله قرار گیرند شناسایی کردند: سختافزار پهپاد (Drone hardware)، شاسی و بسته پهپاد (drone chassis and package)، ایستگاه کنترل زمینی (ground control station)، کانال ارتباط رادیویی (radio communication channel)، خلبان (اپراتور – pilot) و خدمات ابری (cloud services). Nassi و همکارانش در پژوهش خود از اصطلاح «سختافزار پهپاد یا drone hardware» برای اشاره به خودِ پهپاد، اجزای آن و همچنین میانافزار (Firmware) استفاده کردهاند. ما در این پژوهش، میان سختافزار و میانافزار تمایز قائل میشویم و هر دو را به صورت مجزا و با جزئیات بیشتری مورد تحلیل قرار میدهیم.
ما پیش از آنکه بتوانیم از روشهای تحلیل پویای (dynamic analysis) خودکار مانند فازینگ (Fuzzing) استفاده کنیم، که نقش بسیار مهمی در یافتن مؤثر باگ (Bug) در نرمافزار [32] و میانافزار [33، 34] ایفا کردهاند، میبایست جزئیات و پیچیدگیهای هدف مورد آزمون را درک کنیم. به عنوان مثال، شناسایی رابطهای ارتباطی و پروتکلهای مورد استفاده ضروری است. ما به منظور تحقق این هدف، به صورت دستی اقدام به انجام تحلیل ایستا (Static Analysis) بر روی میانافزار کرده و همچنین سختافزار پهپاد را مورد بررسی قرار دادیم. این فرآیند، علاوه بر فراهمسازی اطلاعات حیاتی برای تحلیل پویای خودکار، منجر به کشف چندین آسیبپذیری امنیتی مهم نیز شد. ما سپس با تکیه بر پروتکل ارتباطی شناسایی شده DUML، یک فازر (Fuzzer) طراحی کردیم تا به صورت خودکار به جستوجوی آسیبپذیریهای بیشتر بپردازد که در نتیجه آن، تعداد قابل توجهی آسیبپذیری جدید کشف شد. تمامی یافتهها به صورت مسئولانه به شرکت DJI گزارش گردید و توسط این شرکت مورد تأیید قرار گرفت.
برای تحلیل تفصیلی خود، دستگاههای سختافزاری DJI شامل DJI Mini 2، Mavic Air 2 و Mavic 2 Pro / Zoom را مورد بررسی قرار میدهیم. علاوه بر این، کنترلکنندههای از راه دور RC231 / RC-N1 (که در پهپادهای جدید DJI از جمله DJI Mini 2، Mavic Air 2 و Mavic 3 مورد استفاده قرار میگیرند) نیز مطالعه شدهاند. همچنین، برخی از آسیبپذیریهای کشف شده را بر روی جدیدترین پهپاد DJI، یعنی Mavic 3 بازتولید (Replicate) کردیم.
۴.۳ تحلیل دستی اولیه و دسترسی تعاملی (Initial Manual Analysis and Interactive Access)
پیش از بهکارگیری هرگونه روش تحلیل خودکار، مانند فازینگ (Fuzzing)، لازم است هدف مورد بررسی بهطور دقیق درک شود.
۴.۳.۱ تحلیل ایستای دستی (Manual Static Analysis)
ما از تحلیل ایستای دستی (Manual Static Analysis) بر روی بخشهای مختلف میانافزار پهپاد، از جمله کنترلکننده پرواز (Flight Controller)، استفاده میکنیم و به اطلاعات کلیدی درباره قابلیتها و عملکردهای مختلف پهپاد دست مییابیم. در این تحلیل از ابزارهای استاندارد استفاده شده است؛ به ویژه Ghidra [35]، Binwalk [36]، یک ویرایشگر هگز (Hex Editor)و مجموعه ابزارهای dji-firmware-tools [37]. مهمتر از همه، تحلیل ایستای دستی ما اطلاعاتی درباره ساختار پروتکل DUML آشکار میسازد که مبنای تحلیل پویای ما در بخش بعدی را فراهم میکند. علاوه بر ارائه اطلاعات ضروری برای درک و تحلیل پهپادها، این تحلیل منجر به کشف یک آسیبپذیری نیز میشود که امکان دور زدن امضای میانافزار (Firmware Signing) شرکت DJI و دسترسی به یک شل با دسترسی سطح بالا (Privileged Shell) بر روی دستگاه را فراهم میسازد.
دور زدن تأیید امضای میانافزار S1 SoC. میانافزار مربوط به S1 SoC در پهپاد با نام sparrow_firmware در دستگاه قابل مشاهده است و همچنین در بستههای به روزرسانی میانافزار که به صورت آنلاین در دسترس قرار دارند یافت میشود. این بسته از چندین فایل باینری مختلف تشکیل شده است.
بخشی از این بسته میانافزار شامل فایلهایی موسوم به پیکربندیهای SDRH میباشد. این فایلها از نظر طراحی، نه امضا شدهاند و نه رمزگذاری میشوند. تحلیل ایستای دستی ما بر روی بوتلودر (bootloader) نشان میدهد که این فایلها وظیفه تعیین آدرسهای حافظه و مقادیر متناظر آنها را بر عهده دارند. ما فرض میکنیم که DJI از این سازوکار برای اعمال وصلهها (Patch) در میانافزار فرستنده/گیرنده (transceiver) استفاده میکند، بدون آنکه نیاز به فلش مجدد (Reflash) میانافزار باشد. با این حال، DJI هیچگونه توضیحی درباره این فایلها ارائه نکرده و در سند امنیتی (Security Whitepaper) [21] نیز به آنها اشارهای نشده است.
بوتلودر (bootloader)، این فایلها را پردازش کرده و مقادیر مشخص شده را در آدرسهای حافظه تعیین شده در RAM سیستمعامل بلادرنگ (RTOS) اعمال میکند. استفاده از فایلهای SDRH دستساز، این امکان را فراهم میآورد تا در مرحله بوت (Boot)، پس از انجام فرآیند اعتبارسنجی امضای میانافزار، تغییرات در میانافزار اعمال شوند. این رویکرد عملاً منجر به دور زدن کامل فرآیند تأیید امضای میانافزار (Firmware Signing Verification Bypass) میشود و به مهاجمی که قادر به تولید فایلهای SDRH دستکاری شده باشد اجازه میدهد تغییرات دلخواهی در کد میانافزار ایجاد کند.
جدول ۱، پهپادها و کنترلکنندههای از راه دور (RC) که تحت تأثیر این دور زدن امضا (ستون Sig. Bypass) قرار گرفتهاند را فهرست میکند. مدلهایMavic 3 و Mavic 2 Pro تحت تأثیر این آسیبپذیری قرار ندارند، زیرا از یک فرستنده/گیرنده (transceiver) متفاوت نسبت به S1 آسیبپذیر استفاده میکنند. در چارچوب فرآیند افشای مسئولانه (Responsible Disclosure)، شرکت DJI این آسیبپذیری را با سطح شدت بحرانی (Critical) طبقهبندی کرد.
تحویل فایلهای SDRH از طریق Fastboot (SDRH File Delivery via Fastboot). ما در جستوجوی یک سازوکار برای انتقال فایلهای SDRH به پهپاد، باینریهای مختلف سیستم را مورد بررسی قرار دادیم. در این فرایند مشخص شد که میانافزار از طریق یک سازوکار مشابه Fastboot در حافظه RAM روی SoC فلش (flash) میشود. این مکانیزم مستلزم آن است که بوتلودر در وضعیت مناسبی قرار داشته باشد تا بتواند دستورات Fastboot را دریافت و پردازش کند. با انجام مهندسی معکوس بر روی باینریهای مربوط به مقداردهی اولیه سیستم (System Initialization) در سیستمفایل (filesystem) پهپاد، دریافتیم که بوتلودرِ (bootloader) فرستنده/گیرنده (transceiver) را میتوان با ارسال بستههایی با قالببندی صحیح (Correctly-formatted packets) فعال کرد.
ارسال چنین بستههایی به کنترلکننده از راه دور (RC) در هنگام بوت از طریق USB، منجر به فعالسازی حالت Fastboot میشود. با فعالسازی اولیه این حالت، امکان استفاده از آن برای بارگذاری فایلهای میانافزار فرستنده/گیرنده (transceiver) (امضا شده) بههمراه فایلهای SDRH (امضا نشده) فراهم میگردد. این موضوع به یک مهاجم اجازه میدهد تا یک فایل SDRH مخرب را در کنار فایلهای میانافزار اصلی قرار داده و جریان کنترل (Control Flow) میانافزار فرستنده/گیرنده را منحرف سازد. بارگذاری این فایلهای SDRH نیازی به احراز هویت ندارد و تنها مستلزم دسترسی فیزیکی به پهپاد یا کنترلکننده از راه دور است.
ایجاد دربِ پشتی در میانافزار فرستنده/گیرنده Sparrow(Backdooring the Sparrow Transceiver Firmware). در مرحله بعد، میانافزار فرستنده/گیرنده Sparrow را تحلیل کرده و به یک رابط UART دست مییابیم. میانافزار فرستنده/گیرنده از طریق این رابط، یک شل (Shell) را در دسترس قرار میدهد. با این حال، مشخص میشود که این شل (Shell) در دستگاههای تولیدی (Production Devices) غیرفعال شده است. بررسیهای سختافزاری نشان میدهد که وضعیت تولید (Production State) از طریق یک بیت فیوز (Fuse Bit) به میانافزار اعلام میشود. ما کد مربوط به بررسی این بیت را در میانافزار پهپاد شناسایی کردیم. با بارگذاری یک فایل SDRH سفارشی که بخشی از کد میانافزار را برای غیرفعالکردن این بررسی اصلاح میکند، موفق شدیم شل UART را در منطق میانافزار دوباره فعال میکنیم.
جدول ۱: پهپادهای تحت تأثیر دور زدن امضای میانافزار و اجرای کد دلخواه که از طریق تحلیل ایستای دستی شناسایی شدهاند:
۴.۳.۲ تحلیل سختافزاری (Hardware Analysis)
برای تطبیق نتایج حاصل از تحلیل ایستای دستی، سختافزار پهپاد را از نظر رابطهای ارتباطی، از جمله رابط UART که پیشتر به آن اشاره شد، مورد بررسی قرار میدهیم. هدف ما اعتبارسنجی یافتههای نرمافزاری در سطح سختافزار و دستیابی به یک شل تعاملی (Interactive Shell) بر روی میانافزار فرستنده/گیرنده است. در این تحلیل از یک ایستگاه کاری سختافزاری مبتنی بر PCB سفارشی (رجوع شود به شکل ۱۱) استفاده میکنیم که امکان کاوش (Probe) اتصال کنندههای (connector) مختلف را فراهم میسازد. همچنین از تحلیلگر منطقی (Logic Analyzer) و نوسان سنج (Oscilloscope) برای شناسایی رابط UART موجود در میانافزار بهره میبریم.
از آنجا که میانافزار Sparrow در پهپادهای جدید DJI مانند DJI Mini 2 و Mavic Air 2 و همچنین در کنترلکنندههای از راه دور آنها مشترک است، این دستگاهها را به عنوان هدف تحلیل انتخاب میکنیم. در این میان، تحلیل سختافزاری کنترلکننده از راه دور (RC) دسترسپذیرتر بوده و حتی در حالی که دستگاه روشن است نیز قابل آزمون میباشد. ما در بررسی سختافزار کنترلکننده RC231، مشاهده میکنیم که پورت UART مورد استفاده میانافزار فرستنده/گیرنده، تنها در دو ثانیه ابتدایی پس از روشن شدن دستگاه فعال است.
ما با استفاده از یافتههای پیشین حاصل از تحلیل ایستای دستی، یعنی وصلهگذاری (Patching) فایلهای میانافزار، موفق شدیم میانافزار فرستنده/گیرنده را وادار کنیم که اتصال UART را به صورت نامحدود باز نگه دارد. این امر امکان اتصال به شل UART فرستنده/گیرنده (transceiver UART shell) را برای ما فراهم میسازد. در این شل، دستورات مربوط به خواندن و نوشتن دلخواه در حافظه (Arbitrary Memory Read/Write) و همچنین دستوری برای ایجاد یک شل Spawn (Spawn Shell) شناسایی شد که منجر به دسترسی سطح بالا (Elevated Privileges) میگردد؛ دسترسی که پیشنیاز غیرفعالسازی مکانیزمهای حفاظتی و محدودیتهای اعمال شده توسط نرمافزار است.
۴.۴ تحلیل پویا – فازینگ (Dynamic Analysis – Fuzzing)
با توجه به درک و بینش حاصل از تحلیل ایستای دستی در بخشهای پیشین، اکنون میتوانیم یک رویکرد خودکار برای شناسایی باگها (Bugs) پیادهسازی کنیم. فازینگ (Fuzzing)، یکی از مؤثرترین تکنیکها برای کشف آسیبپذیریها است؛ روشی خودکار برای شناسایی خطاهای نرمافزاری از طریق ارائه ورودیها (احتمالاً نامعتبر) به سامانه تحت آزمون. موفقیت چشمگیر این روش منجر به شکلگیری مسیرهای پژوهشی متعدد برای بهبود جنبههای مختلف فازینگ شده است. یکی از مهمترین نوآوریها در این حوزه، معرفی مفهوم بازخورد پوشش (Coverage Feedback) میباشد [38]؛ در این رویکرد، هدف آزمون بهگونهای ابزارگذاری (Instrumentation) میشود که مشخص کند هر ورودی کدام بخشهای کد را اجرا کرده است.
این امر به فازر (Fuzzer) اجازه میدهد تا مشاهده کند هر ورودی به صورت مجزا چگونه بر جریان کنترل (Control Flow) تأثیر میگذارد و در نتیجه، مسیر اجرای فرایند فازینگ را هدایت میکند. فازرهای مدرن معمولاً به ابزارگذاری (Instrumentation) در مرحله کامپایل متکی هستند و در نتیجه نیازمند دسترسی به کد منبع (Source Code) میباشند. در شرایطی که کد منبع در دسترس نباشد، امکان ابزارگذاری فایل اجرایی باینری (Binary) از طریق روشهایی مانند ابزارگذاری باینری پویا (Dynamic Binary Instrumentation – DBI) [39, 40]، بازنویسی باینری (Binary Rewriting) [41, 42] یا استفاده از قابلیتهای سختافزاری نظیر ردگیری پردازنده اینتل (Intel PT یا Intel Processor Trace) [43, 44, 45] وجود دارد.
با این حال، این روشها یا به سختافزارهای خاصی (مانند پردازندههای Intel) وابسته هستند، یا فرضیاتی را در خصوص محیط اجرا در نظر میگیرند (به عنوان مثال، بر وجود رابطهای مشخصی که توسط سیستمعامل فراهم میشوند تکیه دارند). متأسفانه، میانافزارهای اجراشده بر روی سامانههای نهفته (Embedded Devices) معمولاً چنین رابطهایی را در اختیار قرار نمیدهند. برای فازینگ اینگونه باینریهای میانافزار (Firmware Blobs) که غالباً منوط به پیکربندیهای سختافزاری ویژهای هستند، پیشرفتهترین روشهای فازینگ عمدتاً بر میزبانی مجدد (Re-hosting) متکی میباشند [33, 34]؛ بدین معنا که محیط اجرای میانافزار به طور کامل یا جزئی شبیهسازی میشود. دلیل این امر آن است که اجرای فازینگ روی سختافزار واقعی اغلب دارای راهاندازی پیچیدهای میباشد، بازخورد محدودی فراهم میکند و از نظر مقیاسپذیری نیز کارآمد نیست. با این وجود، دسترسی به خود میانافزار همچنان یک پیشنیاز ضروری برای انجام این نوع تحلیلها به شمار میآید.
طراحی فازر پهپاد (Drone Fuzzer Design). اگرچه فازینگ یک پهپاد مشخص، رویکردی طبیعی و منطقی برای تحلیل امنیت آن به نظر میرسد، اما با مانعی که پیشتر به آن اشاره شد مواجه هستیم: ما به کد منبع و نه به تمام میانافزار دسترسی نداریم. در نتیجه، رویکردهای متداول و امروزی فازینگ (Contemporary Fuzzing Approaches) در مورد پهپادهای DJI قابل اعمال نیستند. ازاینرو، ناچاریم فرایند فازینگ را مستقیماً بر روی سختافزار واقعی انجام دهیم و در عین حال به اطلاعات پوشش کد (Coverage Information) نیز دسترسی نخواهیم داشت.
پروتکل DUML را به عنوان یک هدف مناسب برای فازینگ (Fuzz Target) شناسایی کردیم؛ پروتکلی که برای پیکربندی و مدیریت تمامی بخشهای پهپاد مورد استفاده قرار میگیرد. افزون بر این، این پروتکل توسط تمامی اجزای پهپاد به منظور ارتباطات داخلی بهکار گرفته میشود و از طریق رابط USB نیز به سادگی در دسترس مهاجمانی قرار دارد که به دستگاه دسترسی فیزیکی دارند. به دلیل نقش این پروتکل در یکپارچهسازی و برقراری ارتباط میان اجزای مختلف سامانه، جایگیری عمیق آن در هسته عملکردی پهپاد و پیچیدگی بالای ناشی از این جایگاه، DUML یک هدف جذاب برای حملات بالقوه محسوب میشود. به بیان دیگر، وجود یک آسیبپذیری در این سامانه میتواند یک قابلیت بهرهبرداری قدرتمند اولیه (Powerful Primitive) در اختیار مهاجم قرار دهد و زمینه سوءاستفاده از کل پهپاد را فراهم سازد.
پروتکل DUML(DUML Protocol). ما بر اساس تحلیل انجام شده بر روی پروتکل DUML (بخش ۲.۱)، یک فازر جعبه سیاه مولد (Generational Black-Box Fuzzer) طراحی کردیم که از یک دستور زبان سفارشی (Custom Grammar) بهره میبرد. به عبارت دیگر، این فازر از مشخصات و ساختار ورودیهای مورد انتظار آگاهی دارد و بر اساس آن ورودی تولید میکند، اما فرآیند تولید ورودیهای آن توسط بازخورد پوشش (Coverage Feedback) هدایت نمیشود. از آنجایی که ما به کد منبع، کل میانافزار یا یک شبیهساز (Emulator) که قادر به بازآفرینی سختافزار اختصاصی DJI باشد، دسترسی نداریم، میبایست فرایند فازینگ را مستقیماً بر روی خود پهپاد به انجام رسانیم. با توجه به اینکه پهپادها و کنترلکنندههای از راه دور DJI دارای یک رابط USB میباشند که از طریق آن امکان برقراری ارتباط با استفاده از پروتکل DUML وجود دارد، این رابط را به عنوان نقطه تزریق ورودیهای فازر انتخاب کرده و رفتار سامانه را در پاسخ به این ورودیها مورد مشاهده و تحلیل قرار میدهیم.
از آنجا که ما به بازخورد پوشش (Coverage Feedback) دسترسی نداریم، فازر ما در یک سناریوی جعبه سیاه (Black-Box) عمل میکند؛ بدین معنا که تنها میتوانیم رفتار پهپاد را از بیرون مشاهده و ارزیابی کنیم. ما به طور مشخص، قادر هستیم وقوع کرش (Crash) را در پهپاد تشخیص دهیم، زیرا در چنین حالتی اتصال برقرار شده با آن بازنشانی میشود. به منظور بهبود شناسایی خطاهایی که به کرش منجر نمیشوند، مکانیزم اوراکل خطا (Bug Oracle) جدید مبتنی بر اختلافات موجود در رابط کاربری (UI) نرمافزار تلفن همراه را پیشنهاد میدهیم. این نرمافزار به کنترلکننده از راه دور (RC) متصل است و به عنوان واسط نمایش اطلاعات پیکربندی پهپاد، دادههای حسگرها و همچنین جریان ویدئویی دوربین عمل میکند. به عنوان مثال، چنانچه فازر موفق شود شماره سریال دستگاه را تغییر دهد، اوراکل پیشنهادی ما قادر خواهد بود این تغییر رفتار را به صورت خودکار شناسایی و به عنوان یک رخداد غیرعادی علامتگذاری کند.
برقراری ارتباط از طریق DUML مستلزم پایبندی به مشخصات این پروتکل است. ورودیهای فازینگی که با مشخصات پروتکل سازگار نباشند، به احتمال زیاد در مراحل اولیه تجزیه (Parsing) رد میشوند و در نتیجه منطق واقعی برنامه مورد آزمون قرار نخواهد گرفت. از این رو، فازر خود را به صورت یک فازر مبتنی بر دستور زبان (Grammar-Based Fuzzer) طراحی کردیم که از مشخصات پروتکل زیربنایی آگاهی دارد. همانگونه که در بخش ۲.۱ بیان شد، هر دستور DUML از فیلدهای src، dest ،cmdType ،cmdSet و cmdID تشکیل شده است که هر یک از آنها یک بایت را اشغال میکنند. یکی از راهکارهای ممکن برای فازر آن است که تمامی ۲۵۶ مقدار ممکن را برای هر یک از این بایتها پیمایش کند. با این حال، چنین رویکردی بسیار زمانبر بوده و تعداد زیادی دستور غیرضروری یا حتی نامعتبر و تعریف نشده را مورد آزمون قرار خواهد داد. به منظور جلوگیری از این مشکل، دامنه مقادیر ممکن برای این فیلدها را به مجموعه مقادیر شناخته شده مرتبط با مبدأها (Sources)، مقصدها (Destinations) و مجموعهدستورات (Command Sets) محدود میکنیم.
این رویکرد به ما امکان میدهد تا دستورات باقیمانده را به طور جامع (Exhaustive) و روشی قطعی (Deterministic) مورد آزمون قرار دهیم. بدین منظور، ما تمامی دستورات DUML ممکن را بر اساس مجموعه دستورات شناسایی شده تولید کرده و تمام ۲۵۶ مقدار ممکن را برای فیلد commandID آزمایش میکنیم. تنها بخش دستور که میتواند شامل دادههای دلخواه باشد، پیلود (Payload) آن است که طول آن صرفاً توسط اندازه بسته DUML محدود میشود. ما برای این فیلد، یک پیلود تصادفی تولید و آن را ثبت میکنیم تا امکان بازپخش قطعی (Deterministic Replay) دستورات آزمایش شده در مراحل بعدی فراهم شود.
پیش از ارسال بسته، مقدار جمعآزمای (Checksum) صحیح آن را محاسبه میکنیم تا اطمینان حاصل شود که بسته از مرحله اعتبارسنجی جمعآزما عبور کرده و منطق برنامه در بخشهای پس از آن مورد آزمون قرار میگیرد. با استفاده از این روش، میتوان هر دستور DUML که موجب کرش کردن (Crash) پهپاد، قطع ارتباط (Disconnection) یا سایر اختلالات فیزیکی قابل مشاهده در عملکرد آن میشود را شناسایی کرد. با این حال، باید توجه داشت که تمام باگها به صورت کرش یا رفتارهای فیزیکی قابل مشاهده بروز نمیکنند. برخی دستورات ممکن است منجر به خطاهای داخلی شوند یا دادههای دیگر موجود در دستگاه را تخریب (Corruption) کنند.
اوراکل رابط کاربری (UI Oracle). ما به منظور غلبه بر این محدودیت، یک اوراکل (مکانیزم) دقیقتر برای کشف باگ (Bug) معرفی میکنیم وآن هم اوراکل رابط کاربری (UI Oracle) است. پهپادهای DJI به طور تنگاتنگ با یک تلفن همراه در ارتباط هستند که خود به کنترلکننده از راه دور متصل است. این تلفن همراه برای نمایش جریان ویدئویی دوربین پهپاد به کار میرود و همچنین امکان مشاهده مقادیر مختلف، مانند خوانش حسگرها، یا تغییر تنظیمات را برای کاربر فراهم میکند (رجوع شود به بخش ۲.۱). در راستای رویکردهای آزمایشی گسترده، مانند آنچه توسط چارچوبهایی همچون سلنیوم (Selenium) پیادهسازی شده است، میتوان در طول یک کمپین فازینگ به صورت خودکار در رابط کاربری پهپاد پیمایش کرد تا رفتارهایی را شناسایی کنیم که بهصورت نامحسوس از حالت عادی منحرف میشوند، اما منجر به کرش کردن سیستم نخواهند شد. به عنوان مثال، میتوان تشخیص داد که فازر تنظیمات را تغییر داده یا خطاهای مربوط به تجزیه (Parser Errors) را فعال کرده است؛ خطاهایی که در رابط کاربری به صورت پیامهای هشدار (Warning Messages) نمایش داده میشوند.
بلوکهای ورودی (Input Blocks). با توجه به اینکه ارتباط (درخواست–پاسخ) با پهپاد کُند است، ورودیهای فازینگ، یعنی دستورات، بدون انتظار برای دریافت پاسخ ارسال میشوند. در مقایسه با یک چرخه معمول فازینگ، چرخه اوراکل رابط کاربری (UI Oracle) که شامل پیمایش رابط کاربری و شناسایی خطاهایی جُزکرش میباشد، زمانبر محسوب میشود. ازاینرو، برای کاهش سربار، تعداد فراخوانیهای اوراکل UI به حداقل ممکن محدود میگردد. بنابراین، به جای بررسی ورودیها به صورت تکتک، فازر فضای ورودی تمامی دستورات ممکن را به بلوکهای ورودی (Input Blocks) تقسیم میکند؛ بهطوری که هر بلوک ورودی شامل ۱۳۰٬۰۰۰ دستور است.
حلقه فازینگ (Fuzzing Loop). فازر سپس این ورودیها را به صورت تکتک و جداگانه از طریق رابط USB سریال به هدف فاز (fuzz target) ارسال میکند ((۱) در شکل ۹). پهپاد هر دستور را پردازش کرده و با کنترلکننده از راه دور (RC) همگام میشود (۲)؛ برای مثال، دادههای وضعیت را بهروزرسانی میکند. در صورتی که فازر کرش (Crash) در میانافزار پهپاد را مشاهده کند (۳)، امکان نسبت دادن مستقیم این رخداد به آخرین دستور ارسال شده وجود ندارد، زیرا برای هر دستور منتظر پاسخ نمیمانیم. در نتیجه، برای شناسایی دستور مشکلساز، ۵٬۰۰۰ دستور آخر مجدداً مورد آزمون قرار میگیرند تا دستور ایجادکننده خطا مشخص گردد. به منظور بهینهسازی این فرایند، از یک الگوریتم جستوجوی باینری (Binary Search) مطابق با الگوریتم ۲ استفاده میکنیم. ما با داشتن یک مجموعه از دستورات (C)، این مجموعه را به صورت متوالی به دو زیرمجموعه هماندازه (CA) و (CB) تقسیم میکنیم. پس از آن که تمامی دستورات موجود در زیرمجموعه اول اجرا گردید، بررسی میکنیم که آیا دستوری که موجب کرش کردن میانافزار پهپاد شده بود در این مجموعه قرار دارد یا خیر. چنانچه پاسخ مثبت باشد، فرایند را روی همان زیرمجموعه اول تکرار میکنیم. اگر پاسخ منفی باشد، این زیرمجموعه کنار گذاشته شده و فرایند روی زیرمجموعه دوم ادامه مییابد. این روند تا زمانی ادامه پیدا میکند که تنها یک دستور (یعنی دستور فعالسازی (Trigger Command)) باقی بماند و به عنوان خروجی بازگردانده شود. به این ترتیب، میتوان دستور ایجادکننده کرش را در زمان log(n) شناسایی کرد.
چنانچه هیچگونه کرشی (Crash) مشاهده نشود و تمام دستورات موجود در یک بلوک ورودی ارسال شده باشند، همچنان لازم است رفتارهای غیرمنتظره بررسی شوند. برای این منظور، فازر از اوراکل رابط کاربری (UI Oracle) برای بررسی وجود انحراف از رفتار مورد انتظار (۴) کوئری (queries) میگیرد. در صورتی که اوراکل UI یک انحراف را شناسایی کند، باز هم امکان نسبتدادن مستقیم این مشاهده به یک دستور خاص وجود ندارد. بنابراین، لازم است بلوک ورودی آخر مجدداً با استفاده از الگوریتم ۲ مورد آزمون قرار گیرد؛ با این تفاوت که بهجای بررسی کرش، از اوراکل UI پرسوجو (query) شده و بررسی میشود که آیا انحراف رابط کاربری قابل مشاهده است یا خیر. بهطور خلاصه، بسته به نوع خطای شناسایی شده، یا از اوراکل کرش (Crash Oracle) سنتی برای تشخیص وقوع کرش استفاده میکنیم، یا از اوراکل رابط کاربری برای بررسی وجود انحراف در UI.
پیادهسازی (Implementation). فازر و اوراکل رابط کاربری (UI Oracle) با حدود ۴۰۰۰ خط کد پایتون پیادهسازی شدهاند. فازر ما دارای دو روش کار است: میتواند (۱) پهپاد را از طریق اتصال سریال و یا (۲) از راه دور (Over-the-Air) در حالی که به رابط سریال RC متصل است، فاز کند. حالت دوم این امکان را فراهم میسازد تا کرشهایی که از راه دور قابل فعالسازی هستند نیز شناسایی شوند. فازر در حالت فازینگ از طریق شبکه بیسیم، به صورت دورهای بررسی میکند که آیا پهپاد همچنان فعال است یا خیر؛ این کار از طریق یک دستور مشخص با مقدار بازگشتی از پیشتعریف شده انجام میشود. علاوه بر این، فازر بررسی میکند که آیا دستگاههای ADB دیگری به جز تلفن اندرویدی مورد استفاده برای اوراکل UI متصل میباشند یا خیر. وجود هر دستگاه اضافی میتواند نشانهای قوی مبنی بر این باشد که سرویس ADB بر روی پهپاد توسط یکی از دستورات ارسال شده توسط فازر فعال شده است؛ در این حالت، دسترسی ADB فعال امکان دسترسی در سطح ریشه (Root Access) به پهپاد را فراهم میسازد.
Algorithm: FindOffendingCmd
Input: Set of commands C
Result: Error causing command c
# Exit when C contains only one command
if |C| == 1 then
Execute(c := C[0])
if Oracle() == “error observed” then
return c
else
return ⊥
# Split commands into equal-sized subsets
CA ∪ CB := C with |CA| − |CB | ≤ 1
# Execute all commands in CA
forall c ∈ CA do
Execute(c)
# Continue with subset CA or CB
if Oracle() == “error observed” then
return FindOffendingCmd(CA)
else
return FindOffendingCmd(CB )
اوراکل رابط کاربری (UI Oracle) ما از ابزارهای داخلی اندروید مانند ADB و uiautomator برای تعامل خودکار با اپلیکیشن DJI استفاده میکند تا مشخص شود آیا وضعیت اپلیکیشن و دادههای نمایش داده شده در رابط آن با مقادیر مورد انتظار مطابقت دارند یا خیر. هرگونه انحراف (Deviation) نشان دهنده آن است که فازر موفق به شناسایی یک دستور جالب و قابل توجه شده است. ما اوراکل UI را به گونهای طراحی کردهایم که تمامی مقادیر قابل بررسی از پیش تعریف شوند. این امر از ایجاد مثبتهای کاذب (False Positives) ناشی از مقادیر متغیر و در حال تغییر مانند سطح باتری (battery level) جلوگیری میکند.
تنظیمات آزمایش (Experiment Setup). ما فازر خود را بر روی سه پهپاد مختلف DJI و یک کنترلکننده از راه دور که در جدیدترین پهپادهای DJI مورد استفاده قرار میگیرد، آزمایش کردیم:
- Mavic Air 2، میانافزار: 01.01.0610
- DJI Mini 2، میانافزار: 01.03.0000
- Mavic 2 Pro، میانافزار: 01.00.0770
- RC231 (RC) + Mavic Air 2، میانافزار: 01.01.0610
کامپیوتر میزبان که فازر بر روی آن اجرا میشود باید در همان شبکه WiFi با تلفن اندرویدی قرار داشته باشد و پهپاد نیز باید به آن کامپیوتر متصل باشد. ما برای آزمایش از هاتاسپات WiFi (WiFi hotspot) تلفن هوشمند استفاده کردیم. فازر در اجرای اولیه، باید تلفن هوشمند را مقداردهی اولیه کرده، سرویس ADB را راهاندازی کند و اتصال ADB از طریق WiFi را پیکربندی نماید. برای استفاده از تلفن به عنوان اوراکل رابط کاربری (UI Oracle)، لازم است تلفن به کنترلکننده از راه دور (RC) متصل باشد و ارتباط بین RC و پهپاد (OcuSync) نیز برقرار شود. ما از یک تلفن اندرویدی OnePlus 8 روت شده (Root) با سیستمعامل Android 11 و اپلیکیشن DJI Fly (نسخه 1.6.6) استفاده کردیم؛ اپلیکیشنی که هم برای Mavic Air 2 و هم برای DJI Mini 2 مورد استفاده قرار میگیرد.
ما چهار کمپین مستقل فازینگ را اجرا میکنیم:
- Mavic Air 2 به همراه RC231 متصل با استفاده از اوراکل رابط کاربری (UI Oracle).
- DJI Mini 2 به همراه RC231 متصل با استفاده از اوراکل رابط کاربری (UI Oracle).
- Mavic 2 Pro بدون استفاده از اوراکل رابط کاربری.
- RC231 + Mavic Air 2 در حالت معکوس، به طوری که کنترلکننده (RC) فاز شده و پهپاد از طریق OcuSync متصل است.
ما پهپادهای Mavic Air 2 و DJI Mini 2 را با استفاده از اوراکل رابط کاربری (UI Oracle) خود مورد آزمایش قرار میدهیم. از آنجا که Mavic 2 Pro از یک اپلیکیشن قدیمی و متفاوت استفاده میکند، در حال حاضر امکان بهکارگیری اوراکل رابط کاربری برای آن وجود ندارد؛ زیرا این اوراکل به طور خاص برای اپلیکیشن مدرن DJI طراحی شده است. به منظور کاهش بار مسئوليت مهندسی (engineering burden)، از تطبیق اوراکل با اپلیکیشن قدیمی که منسوخ شده است صرفنظر میکنیم. کمپین فازینگ چهارم نیز بررسی میکند که آیا فازینگ پهپاد از راه دور (Over-the-Air) و از طریق کنترلکننده از راه دور (RC) امکانپذیر است یا خیر.
همچنین این امکان وجود دارد که کنترلکننده به دلیل ورود به یک وضعیت نامعتبر یا کرش کردن فرستنده/گیرنده (transceiver) پهپاد، سیگنال پهپاد را از دست بدهد. چنین وضعیتی که در آن دستگاه همچنان دستورات را از طریق رابط سریال دریافت میکند اما ارتباطی با کنترلکننده برقرار نیست، تنها زمانی قابل تشخیص است که اوراکل رابط کاربری (UI Oracle) برنامه را بررسی کند.
در صورتی که اوراکل UI تشخیص دهد که هیچ پهپادی متصل نیست، فازر تلاش میکند هدف فازینگ را مجدداً راهاندازی (Reboot) کند. در نهایت، خود اوراکل رابط کاربری نیز دارای محدودیتها و الزامات خاصی است: لازم است تمامی مقادیر مهمی که باید در طول کمپین فازینگ بررسی شوند از پیش تعریف گردند. همچنین میبایست خطاهای رایج و غیربحرانی (مانند پیامهایی که در شرایط ضعف سیگنال GPS رخ میدهند) در نظر گرفته شوند تا به عنوان مثبت کاذب (False Positive) تلقی نگردند.
نتایج (Results). ما یک رویکرد پیشنهادی را پیادهسازی کردیم که امکان آزمون سیستماتیک دستگاههای مختلف DJI (یعنی هم پهپادها و هم کنترلکنندههای از راه دور) را از طریق رابط USB برای شناسایی آسیبپذیریهای بالقوه فراهم میسازد. نکته قابل توجه آن است که این روش بر روی تمامی پهپادها و کنترلکنندههای DJI موجود قابل اجرا میباشد. در مجموع، حدود ۷.۸ میلیون دستور را مورد آزمون قرار دادیم که از طریق پیمایش کامل دستورات مطابق با روش توضیح داده شده در بالا تولید شدهاند. به طور متوسط، در حالتی که خود پهپاد مورد فازینگ قرار گیرد، میتوان حدود ۴۰۰ دستور در ثانیه را آزمایش کرد. این موضوع بدون در نظر گرفتن کرشها (crash) یا چرخههای رابط کاربری (UI cycles) منجر به زمان خام فازینگ در حدود ۵.۵ ساعت میشود.
با این حال، هر بار که پهپاد دچار کرش (Crash) میشود، این زمان افزایش مییابد، زیرا لازم است پهپاد مجدداً راهاندازی شود. علاوه بر این، وقفههای مربوط به اوراکل رابط کاربری (UI Oracle) و همچنین فرایند یافتن دستور ایجادکننده یک خطای مشاهده شده نیز زمان بیشتری به کل فرایند اضافه میکنند. ما در عمل مشاهده کردیم که هر اجرای کامل فازینگ حدود ۹ ساعت به طول میانجامد. در شکل ۱۰، میزان زمان صرف شده توسط فازر در مراحل مختلف فازینگ پهپاد Mavic Air 2 نشان داده شده است. اوراکل رابط کاربری حدود ۲۵ درصد از کل زمان اجرا را به خود اختصاص میدهد. جالب توجه است که تنها حدود نیمی از این زمان صرف خود چرخه UI میشود (مانند بررسی مقادیر، پیمایش در بخشهای مختلف رابط کاربری، بازنشانی برنامه کاربردی و بررسی اتصال صحیح تلفن از طریق TouchEngine). باقی مانده زمان، صرف راهاندازی مجدد پهپاد و انتظار برای تکمیل فرایند مقداردهی اولیه میشود. بهطور کلی، یافتن دستوری که منجر به انحراف در رابط کاربری (UI Deviation) میشود نسبت به یافتن دستوری که موجب کرش میگردد هزینهبرتر است؛ زیرا در این حالت لازم است پهپاد و برنامه کاربردی چندین بار راهاندازی مجدد شوند و رابط کاربری نیز برای شناسایی انحراف مورد جستوجو قرار گیرد.
جدول ۲: یافتههای یکتا (Deduplicated) شناساییشده در طول فازینگ:
در اجرای چهارم فازینگ، که در آن بهجای پهپاد، کنترلکننده RC231 مورد فازینگ قرار گرفت، نرخ اجرای بسیار پایینتری در حدود ۲۱ دستور در ثانیه مشاهده شد. تکمیل این اجرای فازینگ با چنین سرعتی، حدود ۱۰۴ ساعت زمان نیاز دارد. ازاینرو، مجموعه دستورات فازر را به زیرمجموعهای از مبدأها (sources)، مقصدها (destinations) و مجموعهدستورات (command sets) محدود کردیم که در سایر کمپینهای فازینگ دارای آسیبپذیری بودهاند؛ به این ترتیب، تعداد دستورات مورد آزمون به ۱٬۰۷۳٬۱۱۱ مورد کاهش یافت. اگرچه این اجرای فازینگ کامل نیست، اما به عنوان یک اثبات مفهوم (Proof of Concept) نشان میدهد که اجرای دستورات از راه دور (Over-the-Air) نیز امکانپذیر است؛ زیرا کنترلکننده، دستورات را به پهپاد منتقل میکند. همچنین، در صورت ارسال دستوری که موجب خطای تقسیمبندی (Segmentation Fault) در کنترلکننده پرواز شود، مهاجم میتواند پهپاد را از کار بیندازد؛ به این معنا که پهپاد در حین پرواز سقوط خواهد کرد.
ما در مجموع، ۱۵ خطای نرمافزاری (پس از حذف موارد تکراری به صورت دستی) شناسایی کردیم که منجر به کرش (Crash) یا سایر انواع رفتارهای غیرمنتظره در سیستم میشوند. یک خلاصه تفصیلی از این یافتهها در جدول ۲ ارائه شده است که شامل طبقهبندی و سطح شدت تعیین شده توسط DJI در فرآیند افشای مسئولانه (Responsible Disclosure) نیز میشود. نکته قابل توجه این است که اغلب کرشها در کنترلکننده پرواز (Flight Controller) رخ میدهند؛ بخشی که از منظر عملکرد پروازی پهپاد، جزو اجزای حیاتی به شمار میآید.
فراتر از قابلیت کرش پهپاد، فازر ما موفق به کشف امکان تغییر شماره سریال ظاهراً غیرقابل تغییر (باگ شماره ۱۵)، اجرای کد دلخواه (باگ شماره ۱۴)، و همچنین یک درب پشتی (Backdoor) شد که سرویس ADB را با دسترسی سطح ریشه (Root Privileges) فعال میکند(باگ شماره ۱). دو آسیبپذیری اول (شمارهها ۱۴ و ۱۵) تنها با استفاده از اوراکل رابط کاربری (UI Oracle) قابل شناسایی هستند، زیرا منجر به کرش کردن فوری نمیشوند. این موضوع برای مورد شانزدهم نیز صدق میکند، جایی که فازر نام پهپاد را تغییر میدهد. با این حال، این اطلاعات از نظر DJI غیرحیاتی تلقی میشود و رفتار مخرب قابل توجه دیگری نیز از این تغییر مشاهده نشده است؛ بنابراین این مورد به عنوان یک یافته بیخطر (Benign Finding) در نظر گرفته میشود. شماره ۱، از این جهت خاص است که مستلزم آن است که فازر پس از پردازش هر بلوک ورودی، وجود سرویس فعال ADB را بررسی کند. از آنجا که این مورد مستلزم دسترسی فیزیکی است، تنها یافتهای میباشد که امکان بهرهبرداری از آن از راه دور وجود ندارد.
برای تمام یافتههای دیگر، میتوان دستورات متناظر را از طریق کنترلکننده از راه دور (RC) اجرا کرد؛ این دستورات سپس توسط پروتکل بیسیم OcuSync به پهپاد منتقل میشوند. این امر امکانپذیر است زیرا پروتکل DUML به عنوان یک پروتکل Bus عمل کرده و تمامی اجزای یک پهپاد DJI را به یکدیگر متصل میکند. در نتیجه، این معماری اجازه میدهد دستورات بدون نیاز به اتصال فیزیکی مستقیم به پهپاد ارسال شوند. این موضوع پیامدهای مهمی دارد و بردارهای حمله جدیدی را ایجاد میکند: آسیبپذیریهایی که در جریان فازینگ از طریق USB کشف شدهاند (برای مثال دستوری که موجب کرش کردن میانافزار پهپاد میشود) میتوانند به صورت از راه دور و با ارسال آنها به RC نیز فعال شوند. در این حالت، خطاهایی که در سناریوی اتصال مستقیم به پهپاد روی زمین صرفاً باعث کرش کردن پهپاد میشدند، در صورت فعال شدن در حین پرواز و به صورت از راه دور، پیامدهای بهمراتب جدیتری خواهند داشت و میتوانند حداقل منجر به عدم دسترسپذیری سرویس (Denial of Service – DoS) و حتی آسیب یا نابودی پهپاد شوند.
از آنجا که DJI برخی از این آسیبپذیریها را بهعنوان سرریز بافر (Buffer Overflow) طبقهبندی کرده است، این موارد میتوانند بطور بالقوه قابل بهرهبرداری باشند. تنها پیشنیاز این است که مهاجم به کنترل کننده از راه دور (RC) از طریق یک دستگاه تحت کنترل خود دسترسی داشته باشد. نکته قابل توجه این است که اگرچه فازینگ ما از طریق درگاه ارتباطی RC انجام شده، پیامهای DUML همچنین میتوانند از طریق پورت USB نیز ارسال شوند؛ پورتی که در طول پرواز عادی، تلفن هوشمند خلبان به آن متصل است. در این حالت، تلفن اندرویدی خلبان از طریق درگاه USB-C در قسمت بالایی کنترلکننده RC231 متصل میشود و با استفاده از پروتکل Android Open Accessory (AOA) به عنوان یک فروع و ضمايم USB عمل میکند، در حالی که RC نقش میزبان USB (USB Host) را بر عهده دارد. این رفتار در حالت عادی برای نمایش اطلاعات وضعیت پرواز در اپلیکیشن DJI ضروری است؛ با این حال، همین سازوکار میتواند به یک سطح حمله (Attack Surface) تبدیل شود، به طوری که مهاجمی که تلفن هوشمند کاربر را آلوده کرده باشد، قادر خواهد بود پهپاد را کنترل یا حتی آن را از کار بیندازد. از آنجا که DJI، برنامه کاربردی خود را تنها از طریق وبسایت رسمی و نه از فروشگاه Google Play توزیع میکند، کاربران ناچارند تنظیمات امنیتی گوگل را تغییر داده و نصب برنامه از منابع غیر از Google Play Store را فعال کنند؛ این موضوع به طور بالقوه سطح حمله دستگاههای کاربر را افزایش میدهد.
مطالعات موردی (Case Studies). در ادامه، سه نمونه را برجسته میکنیم تا نشان دهیم چگونه یک کرش (Crash) یا تغییر در مقادیر داخلی پهپاد که توسط فازر ایجاد میگردد، میتواند به مشکلات مرتبط با امنیت منجر شود.
(۱) اجرای دستورات دلخواه (باگ شماره ۱۴). ابتدا به یک باگ میپردازیم که در نگاه اول بیخطر به نظر میرسد، اما با بررسی دقیقتر مشخص میشود که در واقع یک آسیبپذیری کامل از نوع تزریق دستور در سیستمعامل (OS Command Injection – CWE-78 [46]) است که میتواند به مهاجم دسترسی سطح بالا بر روی پهپاد بدهد. این آسیبپذیری با استفاده از اوراکل رابط کاربری (UI Oracle) شناسایی گردید؛ جایی که یک انحراف در رابط کاربری برنامه کاربردی گزارش شد: نام SSID شبکه WiFi که برای انتقال ویدئو و تصاویر بین پهپاد و تلفن هوشمند استفاده میشود، با مقادیر تصادفی (بایتهای نامعتبر) جایگزین شده بود. این موضوع نشان میدهد که فازر موفق شده است دستوری را پیدا کند که امکان جایگزینی نام SSID با ورودی کنترل شده توسط کاربر را فراهم میکند. فازر با استفاده از رویکردی که پیشتر توضیح داده شد، به صورت خودکار توانست دستور مشخص DUML مسئول این عملیات را شناسایی کند. تحلیل دستی بعدی برای یافتن علت ریشهای نشان داد که پهپاد، این رشته را در چندین تابع مختلف پردازش میکند. از آنجا که محل قرارگیری این رشته در یک دستور شل (Shell Command) به درستی سنیتایز (Sanitize) نشده است، مهاجم میتواند دستورات دلخواه خود را در آن تزریق کند. با این حال، یک نکته محدودکننده وجود دارد: تابع آسیبپذیر شامل یک بررسی طول (Length Check) است، بنابراین طول دستور تزریق شده محدود خواهد بود. برای غلبه بر این محدودیت، مهاجم میتواند به سادگی یک اسکریپت اکسپلویت شامل دستورات موردنظر خود ایجاد کرده و آن را به صورت تکهتکه و جداگانه (chunkwise) به پهپاد منتقل کند. پس از انتقال، مهاجم این اسکریپت را به عنوان یک فایل اجرایی علامتگذاری میکند که در نتیجه، امکان بهرهبرداری از یک آسیبپذیری اجرای کد دلخواه (Arbitrary Code Execution) بدون محدودیت طول فراهم میشود. DJI این باگ را به عنوان یک آسیبپذیری اجرای کد دلخواه تأیید کرده است. جدول ۱ دستگاههای تحت تأثیر را نشان میدهد (ستون Code Exec).
(۲) شماره سریال دلخواه (باگ شماره ۱۵). دستگاههای DJI دارای چندین شماره سریال برای ماژولهای سختافزاری مختلف مانند دوربین، باتری یا کنترلکننده پرواز میباشند. شماره سریال کنترلکننده پرواز برای احراز هویت و شناسایی هواگرد استفاده میشود. در سند امنیتی DJI آمده است که این شماره سریال باید منحصر بهفرد و غیرقابل تغییر (immutable) بوده و در یک فضای ذخیرهسازی امن نگهداری شود [21]. در حین فازینگ پهپاد DJI Mini 2، اوراکل رابط کاربری (UI Oracle) تشخیص داد که فازر موفق به تغییر شماره سریال کنترلکننده پرواز شده است (رجوع شود به شکل ۱۲ در پیوست A). مهاجم میتواند از این قابلیت برای جعل هویت (spoofing identity) استفاده کند، زیرا همین شماره سریال در پیامهای DroneID نیز منتقل میشود.
(۳) باز نمودن شل ADB با دسترسی ریشه (Unlocking ADB Root shell – باگ شماره ۱).
در جریان فازینگِ پهپاد DJI Mini 2، بررسی دورهای ADB توسط فازر فعال شد و جستوجوی خطا با استفاده از الگوریتم ما، دستوری را گزارش کرد که یک شل ADB با دسترسی ریشه (Root Shell) را روی پهپاد اجرا میکند. بررسیهای بیشتر نشان داد که برای این کار در واقع به دو دستور نیاز است: ابتدا دستور موسوم به «DJI Assistant Unlock» و سپس دستور شناساییشده توسط فازر. فازر همواره دستور اول را برای باز کردن کامل ارتباط DUML ارسال میکند. با تحلیل دستی این آسیبپذیری مشخص میشود که یک نقص منطقی (Logical Flaw) در سیستم مبتنی بر چالش–پاسخ (Challenge-and-Response) وجود دارد که برای فعالسازی یک قابلیت دیباگ (Debug) در باینری dji_sys استفاده میشود. کنترلکننده پرواز که مسئول اعتبارسنجی چالش است، به نظر میرسد هر مقداری را میپذیرد و در نتیجه، همواره این حالت دیباگ را فعال (Unlock) میکند.
موانع و محدودیتهای فازینگ (Roadblocks and Limitations of Fuzzing). فازینگ دستگاههای نهفته (Embedded Devices) با موانع و محدودیتهای متعددی همراه است. یکی از این محدودیتها، تمام شدن باتری در شرایطی است که دستگاه در طول کمپین فازینگ به منبع تغذیه دائمی متصل نباشد. این مسئله منجر به وقفههای متعدد برای تعویض و شارژ باتری میشود و میزان خودکارسازی فرایند فازینگ را کاهش میدهد. از آنجا که دستگاهها ممکن است بر اثر ورودیهای فازینگ وارد وضعیتهای نامعتبر شوند، میانافزار پهپاد یا کنترلکننده از راه دور ممکن است دچار از کار افتادن (Brick) دستگاه شود و دیگر به فازر پاسخ ندهد. در چنین حالتی، فازر این وضعیت را به عنوان کرش (Crash) در نظر گرفته و منتظر بازگشت دستگاه به حالت آنلاین میماند؛ حال آنکه این بازگشت ممکن است هرگز رخ ندهد. در صورتی که چنین از کار افتادن (Brick) نرمافزاری رخ دهد و دستگاه حتی با اقداماتی مانند خارج کردن باتری نیز قابل بازنشانی و تنظیم مجدد (reset) نباشد، لازم است تا میانافزار مجدداً فلش گردد تا دستگاه «از حالت Brick خارج شود (Un-brick)». این اتفاق یکبار در مراحل اولیه پیادهسازی فازر رخ داده است.
۵. بحث و درسهای آموخته شده (Discussion and Lessons Learned)
ما در بخشهای پیشین، ریسکهای امنیتی و حریم خصوصی مرتبط با پهپادهای مصرفی را مورد بررسی قرار دادیم. تمرکز ما بر پهپادهای شرکت DJI بوده است، زیرا این شرکت به عنوان تولیدکننده پیشرو در بازار پهپادها شناخته میشود. علاوه بر این، سند امنیتی DJI نیز یک چارچوب و مبنای نسبتاً مستحکم برای تحلیل فراهم میکند. ما در ادامه، یافتههای اصلی خود را مورد بحث قرار داده و پیامدهای آنها را شرح میدهیم.
وضعیت فعلی امنیت پهپادها (Current State of Drone Security). یافتههای ما حاکی از آن است که مکانیزمهای امنسازی (Hardening) بهکاررفته، تحلیل پهپاد را دشوارتر میکنند، اما آن را غیرممکن نمیسازند. ما با استفاده از تحلیل ایستا (Static Analysis)، موفق شدیم آسیبپذیریهایی را کشف کنیم که از طریق فایلهای پیکربندی به صورت ویژه دستکاری شده و امکان اجرای کد دلخواه بر روی S1 SoC را فراهم میکنند. این آسیبپذیریها هم در پهپاد و هم در کنترلکننده از راه دور (RC) قابل مشاهده بودند. ما با استفاده از فازر DUML، آسیبپذیریهای بیشتری را شناسایی کردیم که امنیت دستگاه را در انواع مختلف پهپادها به خطر میاندازند. مهمتر از آن، چندین نقص ایمنی-حیاتی (Safety-Critical) نیز یافت شد و توانستیم پهپاد را در هنگام فازینگ کنترلکننده، در حین پرواز دچار کرش (Crash) کنیم. علاوه بر این، ارزیابی امنیتی ما نشان میدهد که امکان فلش کردن میانافزار دلخواه روی فرستنده/گیرنده (transceiver) وجود دارد؛ موضوعی که بیانگر آن است که سازوکار بهروزرسانی امن مبتنی بر امضای دیجیتال و رمزگذاری به درستی پیادهسازی نشده است. در نهایت، پیشنهاد میکنیم تولیدکنندگان، این یافتهها را مدنظر قرار داده و آزمونهای بیشتری (برای مثال در قالب فازینگ) انجام دهند تا تعداد باگهای قابل بهرهبرداری کاهش یابد. ما همچنین قصد داریم با DJI برای بهبود ویژگیهای امنیتی و ایمنی پهپادهای مورد مطالعه همکاری کنیم.
مقررات اتحادیه اروپا و ایالات متحده برای شناسایی پهپادها (EU and US Regulations for Drone Identification). نهادهای تنظیمگر، شناسایی و مکانیابی را به عنوان یک قابلیت ایمنی برای پهپادهای مصرفی در نظر میگیرند که در ارزیابی آن، مزایای ایمنی بر ریسکهای بالقوه حریم خصوصی برای خلبانان (اپراتورها) از راه دور برتری دارد. در زمان انجام این تحلیل، دو استاندارد سازگار در مرحله پیشنویس قرار داشتند: EN 4709 (اتحادیه اروپا) و F3411-19 (ایالات متحده) [47, 48]. هر دو استاندارد، پهپادها را ملزم میسازند تا اطلاعاتی شامل موقعیت پهپاد و خلبان، مسیر پرواز (Trajectory) و شماره شناسایی پهپاد را به صورت پخش همگانی (Broadcast) ارسال کنند.
این استانداردها استفاده از تبلیغات بلوتوث (Bluetooth Advertisements) یا قابلیتهای شبکههای آگاه از همسایگی WiFi (Neighborhood-Aware Networking) را پیشبینی میکنند و طبق الزامات، بدون هیچگونه رمزنگاری عمل خواهند کرد. این استانداردها قرار بود به صورت الزامی از اواسط سال ۲۰۲۳ در اروپا و از ۱۶ سپتامبر ۲۰۲۳ در ایالات متحده اجرایی شوند. در مقایسه با راهکار اختصاصی DJI، هر تلفن هوشمند سازگار قادر خواهد بود این پیامهای پخش شده را از طریق WiFi یا Bluetooth دریافت کند، هرچند در بردی به مراتب کمتر. پیادهسازیهای متنباز این استانداردها نیز هماکنون به صورت کتابخانه یا اپلیکیشن اندروید در دسترس قرار دارند [49, 50].
اگرچه ما از این استانداردهای در حال توسعه آگاه هستیم، اما بهطور شگفتآوری مشخصکردن اینکه پهپادهای کنونی که هنوز تحت پوشش استانداردهای باز قرار ندارند، دقیقاً چه اطلاعاتی را در قالب پروتکلهای اختصاصی خود منتقل میکنند، دشوار بود. تحلیل دقیق ما نشان میدهد که پروتکل DroneID در DJI اطلاعاتی را از جمله موقعیت پهپاد و موقعیت خلبان (اپراتور) از راه دور بدون رمزگذاری منتقل میکند، در حالی که در بیانیههای رسمی DJI ادعا شده بود که این اطلاعات رمزگذاری میشوند [21, 22]. DJI پس از این ماجرا، ادعای خود را اصلاح کرد [51]. با این حال، ما قویاً معتقدیم که چنین قابلیتهایی میبایست بخشی از سند امنیتی بوده و به صورت شفاف به کاربران اطلاع داده شوند. خصوصا به دلیل خطرات ذاتی حریم خصوصی که در اثر انتشار عمومی موقعیت اپراتور ایجاد میشود.
مهاجم فعال بدون دسترسی فیزیکی (Active Attacker without Physical Access). تحلیل ما از DroneID را میتوان به عنوان نخستین گام در جهت درک پروتکلهای ارتباطی مورد استفاده در پهپادهای DJI در نظر گرفت. با توجه به یافتههای حاصل از این تحلیل، بر این باوریم که یک مهاجم فعال ممکن است بتواند بستههای DroneID جعلی خود را تزریق کرده و موقعیت پهپاد را جعل کند (spoofing). با این حال، این موضوع خارج از محدوده این پژوهش قرار دارد و به عنوان یک مسیر جالب برای تحقیقات آینده مطرح میشود.
یکپارچکی و تمامیت دادهها (Data Integrity). با توجه به اینکه DJI سیستم AeroScope را به عنوان تجهیزات ردیابی پهپادها و خلبانان از راه دور عرضه میکند، انتظار میرفت که صحت، یکپارچگی و تمامیت دادههای موقعیت GPS با استفاده از مکانیزمهای مقابلهای تضمین شود. با این حال، تحلیل ما نشان میدهد که دادههای GPS را میتوان به سادگی غیرفعال یا جعل (Spoof) کرد؛ در نتیجه، اطلاعات موقعیت گزارش شده توسط این سیستمها به نهادهای مسئول ممکن است قابل اتکا یا قابل اقدام نباشد. بنابراین، لازم است مکانیزمهای مناسب حفاظت از تمامیت دادهها به صورت سراسری در تمامی دستگاهها اعمال شوند.
تعمیمپذیری به سایر تولیدکنندگان (Applicability to Other Vendors). اگرچه در این مقاله تمرکز ما بر پهپادهای تولید شده توسط DJI بوده است، اما تولیدکنندگان دیگری نیز در بازار وجود دارند (به عنوان مثال سهم بازار Autel، حدود ۷٪ [19]است. با توجه به پذیرش نسبتاً پایین این شرکتها و این واقعیت که (تا آنجا که ما میدانیم) هیچ سند عمومی در مورد اقدامات امنیتی و ایمنی آنها وجود ندارد، این دسته از سیستمها اهداف کمتری برای تجزیه و تحلیل محسوب میشوند.
با این حال، رویکرد اصولی ارائه شده در این کار را میتوان به سایر پهپادها نیز تعمیم داد: سختافزار (hardware)، میانافزار (firmware) و نرمافزار (software) آنها قابل تحلیل بهصورت ایستا (statically) و پویا (dynamically) هستند، همچنین امکان بررسی لایه فیزیکی ارتباطات بیسیم نیز وجود دارد. بسته به پروتکلهای مورد استفاده، ممکن است لازم باشد روش فازینگ ما تطبیق داده شود (برای مثال، با استفاده از یک اوراکل رابط کاربری مشابه رویکرد ما). از آنجا که DroneID یک پروتکل اختصاصی مربوط به DJI است، انتظار نمیرود نتایج مشابهی در این حوزه برای سایر تولیدکنندگان حاصل شود؛ با این وجود، سایر پروتکلهای اختصاصی میتوانند اهداف مناسبی برای تحلیلهای مشابه باشند.
ملاحظات اخلاقی و آثار و خروجیهای پژوهشی (Ethical Considerations and Research Artifacts). پهپادها به طور ذاتی مجموعهای از ملاحظات اخلاقی را به همراه دارند، بهویژه با توجه به امکان سوءاستفاده از آنها در درگیریها یا کاربرد احتمالی آنها به عنوان ابزارهای نظارتی. ما تلاش کردهایم در این پژوهش از پرداختن به این جنبهها اجتناب کنیم و تمرکز خود را صرفاً بر تحلیل فنی ابعاد امنیتی و حریم خصوصی قرار دهیم. ما بر این باور هستیم که صرفنظر از اینکه پهپاد توسط چه کسی مورد استفاده قرار میگیرد، باید مطابق با استانداردهای امنیتی وعده داده شده توسط تولیدکننده عمل کند و اطمینان حاصل شود که یکپارچگی (Integrity) مکانیزمهای حفاظتی آن دچار خدشه نخواهد شد. آسیبپذیریهای شناسایی شده نیز به صورت مسئولانه و از طریق فرآیند افشای هماهنگ (Coordinated Disclosure) با تولیدکننده به اشتراک گذاشته شدهاند. علاوه بر این، قصد داریم تمامی آثار و خروجیها و ابزارهای پژوهشی مرتبط با این کار را پس از رفع آسیبپذیریها منتشر کنیم.
درسهای آموخته شده (Lessons Learned). به منظور حمایت بیشتر از پژوهشهای آتی، در این بخش درسهای روششناختی و فرایندی به دستآمده در زمینه تحلیل پهپادها را ارائه میدهیم. ما بهطور خاص، بر اهمیت یک تحلیل جامع و میانرشتهای از میانافزار، پردازش سیگنال و مهندسی معکوس سیگنالهای RF تأکید میکنیم. این رویکرد برای دستیابی به درک عمیقتر از پهپاد به عنوان یک سامانه یکپارچه ضروری است. تمرکز صرف بر یک جنبه واحد، منجر به ایجاد زمینه تحلیلی محدود شده و قابلیت تعمیمپذیری یافتههای احتمالی را کاهش میدهد.
برای مثال، جهت بازیابی اطلاعات نهایی رمزگشایی شده در DroneID، لازم است ساختار بایتی زیربنایی آن مشخص باشد. این ساختار تنها از طریق مهندسی معکوس میانافزار قابل استخراج است. ترکیب این دو نوع تحلیل امکان بازسازی ساختار پروتکل و در نتیجه رمزگشایی بستهها را فراهم میآورد.
بهطور مشابه، ما قویاً توصیه میکنیم که از ترکیب چندین تکنیک استفاده شود: در حالی که فازینگ برای کشف انواع مختلف خطاهای نرمافزاری بسیار مؤثر واقع شد، اما نیازمند درک عمیق پروتکل DUML بود تا بتوان یک هدف معقول برای فازر تعریف کرد. ورودیهای تصادفی که به پهپاد ارسال میشوند، به احتمال بسیار زیاد شبیه یک بسته واقعی نیستند و بنابراین توسط پهپاد در همان مراحل اولیه پردازش کنار گذاشته میشوند.
در همین راستا، ایجاد کرش (Crash) در پهپاد یا مشاهده تغییرات در رفتار رابط کاربری نیازمند تحلیل ایستای دستی است تا بتوان اثرات و پیامدهای هر یافته را به درستی درک کرد. در مطالعه ما، فازر موفق شد نام SSID شبکه WiFi را تغییر دهد؛ بررسی دستی این رفتار غیرعادی نشان داد که این تغییر میتواند منجر به اجرای کد دلخواه (Arbitrary Code Execution) روی پهپاد شود. در مقابل، بدون استفاده از فازر، شناسایی بسیاری از این آسیبپذیریها تقریباً غیرممکن بود، زیرا تعداد بسیار زیاد دستورات DUML و تعاملات پیچیده آنها با اجزای مختلف سیستم، امکان بررسی دستی کامل را از بین میبرد.
در نهایت، تحلیل سامانههای پیچیده و ناشناخته با کد بسته (closed-source) مانند پهپادها، در حال حاضر بدون تحلیل دستی عملاً امکانپذیر نیست. هیچ ابزار یا تکنیکی به تنهایی قادر به مهندسی معکوس خودکار و «درک» کامل پیچیدگیهای این سامانهها نمیباشد؛ سامانههایی که شامل اجزای سختافزاری مختلف، میانافزار و پروتکلهای ارتباطی متنوعی هستند. با این حال، همانطور که فازر ما نشان میدهد، پس از به دست آوردن یک درک اولیه، میتوان تکنیکهای موجود را تطبیق داده و در جهت خودکارسازی بخشی از فرایند تحلیل به کار گرفت. بهطور خلاصه، درسهای آموخته شده ما بیانگر آن میباشند که تحلیل سامانههای پیچیده مانند پهپادها نیازمند (۱) یک رویکرد جامع و میانرشتهای، (۲) استفاده ترکیبی از چندین تکنیک تحلیلی و (۳) بهرهگیری هدفمند از تحلیل دستی در موارد ضروری است.
۶. کارهای مرتبط (Related Work)
پژوهش ما بر چندین سطح مختلف از سامانه متمرکز است و در ادامه بهطور خلاصه ارتباط آن را با کارهای پیشین مرور میکنیم.
پژوهشهای مرتبط با پهپادها (Drone Research). پژوهشهای پیشین در حوزه امنیت پهپاد عمدتاً بر جنبههایی مانند عدم دسترسپذیری سرویس (Denial of Service – DoS)، جعل موقعیت GPS (GPS spoofing) [11]، حملات حذف احراز هویت (De-authentication attacks) [12, 13, 14]، یا شناسایی حملات نقض حریم خصوصی توسط پهپادها [52, 53] متمرکز بودهاند. خوانندگان علاقهمند میتوانند به منظور مرور جامع و عالی اهداف مختلف پهپادها، روشهای حمله و راهکارهای مقابله، به پژوهش Nassi و همکارانش [10] مراجعه کند. با این حال، تاکنون کارهای محدودی به جنبههای امنیت سیستم (System Security) پرداختهاند. برای مثال، فازینگ عمدتاً برای کشف آسیبپذیریها در پروتکلهای (متنباز) [54] یا برای آزمون پورتهای باز در پهپادهای کنترل شده از طریق WiFi [55] مورد استفاده قرار گرفته است.
کاری که ما انجام دادیم، تحلیل نرمافزار امنسازی شدهای (Hardening) بود که پهپادهای DJI را قدرت میبخشد و یک رویکرد فازینگ سفارشی ارائه میدهد که الزامات خاص پهپادها را در نظر میگیرد. برخی پژوهشهای دیگر نیز تحلیل طیفی با استفاده از SDR را برای ارزیابی امنیت لینک ارتباطی بین پهپاد و کنترلکننده از راه دور پیشنهاد کردهاند [56]. ما نیز از SDR برای دریافت بستههای اختصاصی DroneID استفاده کردهایم تا امکان مهندسی معکوس آنها فراهم شود. توجه داشته باشید که اغلب پژوهشهای موجود بر پهپادهای ارزانقیمت تمرکز دارند؛ پهپادهایی که معمولاً رابطهای کنترلی محدودتری ارائه میدهند و اغلب از نرمافزارها و پروتکلهای متنباز استفاده میکنند، و در نتیجه اهداف کمچالشتری برای تحلیل به شمار میآیند.
با این حال، برخی کارهای پیشین نیز محصولات DJI را مورد تحلیل قرار دادهاند: برای مثال؛ یک تحلیل امنیتی، اپلیکیشن DJI Go 4 را بررسی میکند [15]، در حالی که برخی دیگر به مطالعه Phantom 3 [16, 17] یا Phantom 4 [18] پرداختهاند. این تحلیلها نسبتاً ابتدایی هستند، تنها بر یک پهپاد خاص تمرکز دارند و هیچ تلاشی برای ارزیابی امنیت کل سامانه از ابتدا تا انتها (end-to-end system security) انجام نمیدهند.
فازینگ (Fuzzing). در حوزه فازینگ، حجم بزرگی از کارهای پژوهشی وجود دارد؛ برای مثال فازرهای جعبه خاکستری (Grey-box) مانند AFL [38] و مشتقات آن [32, 57, 58, 59] که علیرغم سادگی ظاهری خود، موفق به کشف تعداد زیادی از باگها در انواع مختلف نرمافزار شدهاند. در ادامه این پژوهش، مجموعهای از تکنیکهای متنوع توسعه یافته است. تا مدتها، اکثر این تکنیکها بر بهبود قابلیت کشف باگها از طریق روشهای پیچیدهتر تمرکز داشتند. از میان این روشها، اجرای نمادین (Symbolic Execution) [60, 61, 62]و ردگیری آلودگی داده (Taint Tracking) [63] رایجترین تکنیکها میباشند که با استفاده از حلکنندههای SMT (SMT solver) و تحلیل جریان داده، عملکرد فازرها را بهبود میبخشند.
با این حال، اغلب این تکنیکها وجود سیستمعاملی را فرض میکنند که رابط یکپارچهای (Unified Interface) برای فازر جهت تعامل با هدف تحت آزمون فراهم میسازد. تلاش قابل توجهی به منظور غلبه بر این محدودیت، صورت گرفته تا تکنیکهای «کلاسیک» فازینگ برای اهدافی به کار گرفته شوند که مانند سیستمهای نهفته (Embedded Systems) با پیکربندیهای عملاً نامحدود، چنین رابط یکپارچهای ندارند.
در حالی که برخی رویکردها پیشنهاد میکنند فازینگ مستقیماً روی خود دستگاهها انجام شود [64, 65]، اما مشخص شد که برای مقیاسپذیر کردن آزمون این سیستمها، استفاده از شبیهسازی (Emulation) بخشهایی از سیستم نهفته ضروری است. این رویکرد که با عنوان Re-hosting یا میزبانی مجدد شناخته میشود (یعنی اجرای (بخشی از) میانافزار در یک محیط شبیهسازی شده [33, 34, 66]) در حال حاضر به عنوان یک روش استاندارد پیشرفته در این حوزه در نظر گرفته میشود. با توجه به تعامل پیچیده بین پهپاد و کنترلکننده از راه دور، امکان استفاده از این تکنیکها برای ما وجود نداشت؛ بنابراین یک موتور فازینگ سفارشی توسعه دادیم که نتایج مهندسی معکوس مرتبط با پروتکل DUML را در نظر میگیرد.
دو کار پژوهشی اخیر، یعنی IoTFuzzer [67] و Diane [68] نیز از برنامههای کاربردی گوشی هوشمند برای بهبود فرآیند فازینگ بهره میبرند. مشابه کار ما، ایده اصلی آنها این است که برنامه کاربردی موبایل مرتبط با یک دستگاه میتواند اطلاعات مفیدی درباره خود دستگاه فراهم کند. Chen و همکارانش در خصوص IoTFuzzer، اطلاعات مربوط به پروتکل ارتباطی مورد استفاده برای تعامل با دستگاه را استخراج میکنند که این امر امکان تولید ورودیهای مؤثر برای فازینگ را بدون نیاز به تعریف دستی پروتکل فراهم میسازد. Redini و همکارانش نیز مشاهده کردند که این برنامههای کاربردی اغلب ورودیها را سنیتایز (sanitize) میکنند، که این موضوع رویکرد تولید ورودی IoTFuzzer را به تولید ورودیهای صرفاً معتبر محدود میکند. آنها این محدودیت را با استخراج نقاط کد جبران میکنند تا بتوانند ورودیهای معتبر اما با محدودیت کمتر تولید کنند. در مقابل، رویکرد ما از برنامه کاربردی برای استخراج اطلاعات جهت تولید ورودی استفاده نمیکند، بلکه از اپلیکیشن گوشی هوشمند به عنوان یک اوراکل خطا (Bug Oracle) بهره میبرد؛ امری که به ما امکان میدهد مشکلات ظریف غیرمنجر به کرش (non-crashing issues) را شناسایی کنیم.
۷. نتیجهگیری (Conclusion)
در این مقاله، امنیت و حریم خصوصی پهپادهای مدرن شرکت DJI (به عنوان رهبر بازار) را مورد بررسی و تحلیل قرار دادیم. همچنین مروری بر سطح حمله (Attack Surface) پهپادها ارائه کردیم و دو مدل مهاجم را در نظر گرفتیم: (۱) یک مهاجم منفعل بدون دسترسی فیزیکی که قادر به شنود ترافیک بیسیم پهپاد است، و (۲) یک مهاجم فعال که به سختافزار پهپاد دسترسی فیزیکی دارد. ما با مهندسی معکوس بستههای اختصاصی DroneID در پروتکل ردگیری DJI، دریافتیم که این پروتکل موقعیت پهپاد، نقطه بازگشت (Home Point) و موقعیت اپراتور را بهصورت پخش همگانی (Broadcast) ارسال میکند.
از سوی دیگر، ما نشان دادیم که چگونه میتوان DroneID را غیرفعال کرد یا موقعیت ارسالی را جعل (Spoof) نمود، که این موضوع اعتبار آن را برای نهادهای مجری قانون زیر سؤال میبرد. با در نظر گرفتن یک مهاجم فعال، یک فازر به همراه یک اوراکل رابط کاربری (UI Oracle) جدید طراحی کردیم که هر دو بهطور خاص برای پهپادهای DJI توسعه یافتهاند و موفق به کشف چندین آسیبپذیری امنیتی حیاتی در سه دستگاه مختلف DJI شدند. بررسی دقیقتر این آسیبپذیریها نشان داد که یافتههای ما میتوانند برای اجرای کد دلخواه (Arbitrary Code Execution) یا تغییر شماره سریال دستگاه (که به عنوان یک مقدار غیرقابل تغییر (immutable) در نظر گرفته میشد) مورد استفاده قرار گیرند. علاوه بر این، دریافتیم که مهاجم میتواند پهپاد را با ارسال پیلود (payload) از راه دور (Over-the-Air) در حین پرواز دچار کرش (Crash) کند.
قدردانیها (Acknowledgements)
از Daniele Antonioli به عنوان راهنمای پژوهش (shepherd) و داوران ناشناس به دلیل نظرات و پیشنهادهای ارزشمندشان صمیمانه سپاسگزاریم. همچنین از Daniel Klischies بابت بازخوردهای مفیدش قدردانی میکنیم. علاوه بر این، از شرکت DJI به دلیل همکاری در فرآیند افشای مسئولانه (Responsible Disclosure) و رفع سریع آسیبپذیریهای گزارش شده تشکر میکنیم. این پژوهش با حمایت مالی بنیاد پژوهشی آلمان (DFG, German Research Foundation) تحت طرح «استراتژی تعالی آلمان – EXC 2092 CASA – 390781972» و همچنین وزارت فدرال آموزش و پژوهش آلمان (BMBF) در قالب پروژههای CPSec – 16KIS1564K و KMU-Fuzz – 16KIS1523 انجام شده است.
منابع
[1] Stuart Thornton. Data Drones. https://www.nationalgeographic.org/article/data-drones/, 2014.
[2] Matt McFarland. In Nepal, a Model for Using Drones for Humanitarianism Emerges. https://www.washingtonpost.com/news/innovations/wp/2015/10/07/in-nepal-a-model-for-using-drones-for-humanitarianism-emerges/, 2015.
[3] Marzena Półka, Szymon Ptak, and Łukasz Kuziora. The Use of UAV’s for Search and Rescue Operations. Procedia Engineering, 192:748–752, 2017.
[4] Ryan Mac. Amazon Proposes Drone Highway As It Readies For Flying Package Delivery. https://www.forbes.com/sites/ryanmac/2015/07/28/amazon-proposes-drone-highway-as-it-readies-for-flying-package-delivery/, 2015.
[5] Antoni Slodkowski, Elaine Lies, and Kiyoshi Takenakac. Olympics-Superstar Osaka lights Flame as Japan’s COVID-hit Games Open. https://www.reuters.com/lifestyle/sports/slimmed-down-ceremony-open-pandemic-hit-tokyo-games-2021-07-23/, 2021.
[6] Michael S. Rosenwald. Prisons Try to Stop Drones from Delivering Drugs,Porn and Cellphones to Inmates. https://www.washingtonpost.com/local/prisons-try-to-stop-drones-from-delivering-drugs-porn-and-cellphones-to-inmates/2016/10/12/645fb102-800c-11e6-8d0c-fb6c00c90481_story.html, 2016.
[7] BBC News. Drugs, weapons ’smuggled to prisoners by drone’. https://www.bbc.com/news/world-us-canada-60262715, 2022.
[8] Sean Hollister. A Tiny DJI Drone Smuggled its Own Weight in Drugs over the US border Wall. https://www.theverge.com/2022/2/3/22916246/dji-mini-2-drone-smuggle-meth-us-mexico-border-wall, 2022.
[9] Benjamin Mueller and Amie Tsang. Gatwick Airport Shut Down by ‘Deliberate’ Drone Incursions. https://www.nytimes.com/2018/12/20/world/europe/gatwick-airport-drones.html, 2018.
[10] Ben Nassi, Ron Bitton, Ryusuke Masuoka, Asaf Shabtai, and Yuval Elovici. SoK: Security and Privacy in the Age of Commercial Drones. In IEEE Symposium on Security and Privacy (S&P), 2021.
[11] Jabang Aru Saputro, Esa Egistian Hartadi, and Mohamad Syahral. Implementation of GPS Attacks on DJI Phantom 3 Standard Drone as a Security Vulnerability Test. In International Conference on Information Technology, Advanced Mechanical and Electrical Engineering (ICITAMEE), 2020.
[12] Carlos Augusto Tovar Bonilla, Octavio José Salcedo Parra, and Jhon Hernán Díaz Forero. Common Security Attacks on Drones. International Journal of Applied Engineering Research, 13(7), 2018.
[13] Nualrath Pojsomphong, Vasaka Visoottiviseth, Wudhichart Sawangphol, Assadarat Khurat, Shigeru Kashihara, and Doudou Fall. Investigation of Drone Vulnerability and its Countermeasure. In Symposium on Computer Applications Industrial Electronics (ISCAIE), 2020.
[14] Juhwan Noh, Yujin Kwon, Yunmok Son, Hocheol Shin, Dohyun Kim, Jaeyeong Choi, and Yongdae Kim. Tractor Beam: Safe-Hijacking of Consumer Drones with Adaptive GPS Spoofing. ACM Trans. Priv. Secur., 22(2), 2019.
[15] The Team synacktiv.com. DJI Android GO 4 application security analysis. https://www.synacktiv.com/en/publications/dji-android-go-4-application-security-analysis.html, 2020.
[16] Fernando Trujano, Benjamin Chan, and Reece Rivera May. Security Analysis of DJI Phantom 3 Standard. Technical report, Massachusetts Institute of Technology, 2016.
[17] Thomas Edward Allen Barton and M. A. Hannan Bin Azhar. Forensic analysis of popular UAV systems. In International Conference on Emerging Security Technologies (EST), 2017.
[18] Vishal Dey, Vikramkumar Pudi, Anupam Chattopadhyay, and Yuval Elovici. Security Vulnerabilities of Unmanned Aerial Vehicles and Countermeasures: An Experimental Study. In International Conference on VLSI Design and International Conference on Embedded Systems, 2018.
[19] Ishveena Singh. DroneAnalyst report reveals dramatic drop in DJI’s commercial drone market share . https://dronedj.com/2021/09/14/droneanalyst-dji-market-share-2021/, 2021.
[20] Daniel Slotta. China’s Thriving Drone Industry. https://www.asiaperspective.com/china-thriving-drone-industry/, 2022.
[21] DJI. System Security, A DJI Technology White Paper V2.0. https://security.dji.com/data/resources/, 2022.
[22] Sean Hollister. DJI drones, Ukraine, and Russia — what we know about AeroScope. https://www.theverge.com/22985101/dji-aeroscope-ukraine-russia-drone-tracking, 2022.
[23] Mefistotelis. DJI-Firmware-Tools. https://github.com/o-gs/dji-firmware-tools/wiki/Abbreviations, 2020.
[24] Original Gangsters Mefistotelis. comm_mkdupc.py. https://github.com/ogs/dji-firmware-tools/blob/master/comm_mkdupc.py, 2019.
[25] DJI. DJI Statement On Recent Reports From Security Researchers. https://www.dji.com/newsroom/news/dji-statement-on-recent-reports-from-security-researchers, 2020.
[26] Buildroot Association. Buildroot Making Embedded Linux Easy. https://buildroot.org/.
[27] DJI. DJI Mavic 3 - Specs. https://www.dji.com/mavic-3/spec
[28] Federal Communications Commission. FCC ID SS3-MT2WD2007. https://fccid.io/SS3-MT2WD2007.
[29] Jung-Fu Cheng, Ajit Nimbalker, Yufei W. Blankenship, Brian K. Classon, and Keith T. Blankenship. Analysis of Circular Buffer Rate Matching for LTE Turbo Code. IEEE Vehicular Technology Conference, 2008.
[30] etsi.org. ETSI TS 136 212 V10.0.0. https://www.etsi.org/deliver/etsi_ts/136200_136299/136212/10.00.00_60/ts_136212v100000p.pdf, 2011.
[31] Lexa. Google Play – Fake GPS Location. https://play.google.com/store/apps/details?id=com.lexa.fakegps, 2022.
[32] Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. AFL++: Combining Incremental Steps of Fuzzing Research. In USENIX Workshop on Offensive Technologies (WOOT), 2020.
[33] Bo Feng, Alejandro Mera, and Long Lu. P2IM: Scalable and Hardware-independent Firmware Testing via Automatic Peripheral Interface Modeling. In USENIX Security Symposium, 2020.
[34] Tobias Scharnowski, Nils Bars, Moritz Schloegel, Eric Gustafson, Marius Muench,Giovanni Vigna, Christopher Kruegel, Thorsten Holz, and Ali Abbasi. Fuzzware:Using Precise MMIO Modeling for Effective Firmware Fuzzing. In USENIX Security Symposium, 2022.
[35] National Security Agency. Ghidra. https://github.com/NationalSecurityAgency/ghidra/releases.
[36] ReFirmLabs. Binwalk. https://github.com/ReFirmLabs/binwalk.
[37] Original Gangsters Mefistotelis. DJI-Firmware-Tools. https://github.com/ogs/dji-firmware-tools, 2021.
[38] Michał Zalewski. American Fuzzy Lop. http://lcamtuf.coredump.cx/afl/,2013.
[39] Marc Heuse. AFL-DynamoRIO. https://github.com/vanhauser-thc/afl-dynamorio, 2018.
[40] Marc Heuse. AFL-PIN. https://github.com/vanhauser-thc/afl-pin, 2018.
[41] Sushant Dinesh, Nathan Burow, Dongyan Xu, and Mathias Payer. RetroWrite: Statically Instrumenting COTS Binaries for Fuzzing and Sanitization. In IEEE Symposium on Security and Privacy (S&P), 2020.
[42] Stefan Nagy, Anh Nguyen-Tuong, Jason D. Hiser, Jack W. Davidson, and Matthew Hicks. Breaking Through Binaries: Compiler-quality Instrumentation for Better Binary-only Fuzzing. In USENIX Security Symposium, 2021.
[43] Robert Swiecki. Security-oriented Fuzzer with Powerful Analysis Options. https://github.com/google/honggfuzz.
[44] Sergej Schumilo, Cornelius Aschermann, Robert Gawlik, Sebastian Schinzel, and Thorsten Holz. kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels. In USENIX Security Symposium, 2017.
[45] Cornelius Aschermann, Sergej Schumilo, Tim Blazytko, Robert Gawlik, and Thorsten Holz. RedQueen: Fuzzing with Input-to-State Correspondence. In Symposium on Network and Distributed System Security (NDSS), 2019.
[46] Mitre. CWE-78: Improper Neutralization of Special Elements used in an OS Command (OS Command Injection). https://cwe.mitre.org/data/definitions/78.html.
[47] ASTM. Standard Specification for Remote ID and Tracking. https://www.astm.org/f3411-19.html.
[48] ASD-STAN. ASD-STAN prEN 4709-002 P1. https://asd-stan.org/downloads/asd-stan-pren-4709-002-p1/.
[49] opendroneid. OpenDroneID Android receiver application. https://github.com/opendroneid/receiver-android.
[50] opendroneid. Open Drone ID Core C Library. https://github.com/opendroneid/opendroneid-core-c.
[51] Sean Hollister. DJI insisted drone-tracking AeroScope signals were encrypted now it admits they aren’t. https://www.theverge.com/2022/4/28/23046916/dji-aeroscope-signals-not-encrypted-drone-tracking, 2022.
[52] Ben Nassi, Raz Ben-Netanel, Adi Shamir, and Yuval Elovici. Drones’ Cryptanalysis - Smashing Cryptography with a Flicker. In IEEE Symposium on Security and Privacy (S&P), 2019.
[53] Raz Ben Netanel, Ben Nassi, Adi Shamir, and Yuval Elovici. Detecting Spying Drones. IEEE Security & Privacy, 19(1):65–73, 2021.
[54] Karel Domin, Iraklis Symeonidis, and Eduard Marin. Security Analysis of the Drone Communication Protocol: Fuzzing the MAVLink Protocol. In Symposium on Information Theory, 2016.
[55] David Rudo, Dr Zeng, et al. Consumer UAV Cybersecurity Vulnerability Assessment Using Fuzzing Tests. arXiv preprint arXiv:2008.03621, 2020.
[56] Hocheol Shin, Kibum Choi, Youngseok Park, Jaeyeong Choi, and Yongdae Kim. Security Analysis of FHSS-type Drone Controller. In International Workshop on Information Security Applications, 2015.
[57] Marcel Böhme, Van-Thuan Pham, Manh-Dung Nguyen, and Abhik Roychoudhury. Directed Greybox Fuzzing. In ACM Conference on Computer and Communications Security (CCS), 2017.
[58] Shuitao Gan, Chao Zhang, Xiaojun Qin, Xuwen Tu, Kang Li, Zhongyu Pei, and Zuoning Chen. Collafl: Path Sensitive Fuzzing. In IEEE Symposium on Security and Privacy (S&P), 2018.
[59] Marcel Böhme, Van-Thuan Pham, and Abhik Roychoudhury. Coverage-based Greybox Fuzzing as Markov Chain. IEEE Transactions on Software Engineering, 45(5), 2017.
[60] Insu Yun, Sangho Lee, Meng Xu, Yeongjin Jang, and Taesoo Kim. QSYM: A Practical Concolic Execution Engine Tailored for Hybrid Fuzzing. In USENIX Security Symposium, 2018.
[61] Nick Stephens, John Grosen, Christopher Salls, Andrew Dutcher, Ruoyu Wang, Jacopo Corbetta, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna. Driller: Augmenting fuzzing through selective symbolic execution. In Symposium on Network and Distributed System Security (NDSS), 2016.
[62] Christian Cadar, Daniel Dunbar, and Dawson R. Engler. KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs. In Symposium on Operating Systems Design and Implementation (OSDI), 2008.
[63] Peng Chen and Hao Chen. Angora: Efficient Fuzzing by Principled Search. In IEEE Symposium on Security and Privacy (S&P), 2018.
[64] Karl Koscher, Tadayoshi Kohno, and David Molnar. SURROGATES: Enabling Near-Real-Time Dynamic Analyses of Embedded Systems. In USENIX Workshop on Offensive Technologies (WOOT), 2015.
[65] Jonas Zaddach, Luca Bruno, Aurelien Francillon, Davide Balzarotti, et al. AVATAR: A Framework to Support Dynamic Security Analysis of Embedded Systems’ Firmwares. In Symposium on Network and Distributed System Security (NDSS), 2014.
[66] Eric Gustafson, Marius Muench, Chad Spensky, Nilo Redini, Aravind Machiry, Yanick Fratantonio, Davide Balzarotti, Aurélien Francillon, Yung Ryn Choe, Christopher Kruegel, et al. Toward the Analysis of Embedded Firmware through Automated Re-hosting. In Symposium on Recent Advances in Intrusion Detection (RAID), 2019.
[67] Jiongyi Chen, Wenrui Diao, Qingchuan Zhao, Chaoshun Zuo, Zhiqiang Lin, XiaoFeng Wang, Wing Cheong Lau, Menghan Sun, Ronghai Yang, and Kehuan Zhang. IoTFuzzer: Discovering Memory Corruptions in IoT Through App-based Fuzzing. In Symposium on Network and Distributed System Security (NDSS), 2018.
[68] Nilo Redini, Andrea Continella, Dipanjan Das, Giulio De Pasquale, Noah Spahn, Aravind Machiry, Antonio Bianchi, Christopher Kruegel, and Giovanni Vigna. Diane: Identifying Fuzzing Triggers in Apps to Generate Under-constrained Inputs for IoT Devices. In IEEE Symposium on Security and Privacy (S&P), 2021.
پیوست الف (Appendix A)
ساختار رساله. این رساله شامل پژوهشهایی است که زیربنای آن را تشکیل میدهند:
بخش اول: چالشهای حل نشده حوزه فازینگ: دامها، نقاط کور و درسهای آموخته شده از دنیای واقعی
بخش دوم: SoK: مطالعه نظاممند یکپارچهسازی و بازتولید دستاوردهای پژوهشی فازینگ در ++AFL
بخش سوم: نوآوری یافت نشد: بررسی سایهسازی ورودی در فازینگ از طریق راهاندازی مجدد فازر تطبیقی
