در چشم انداز همیشه در حال تکامل امنیت تلفن همراه، جستجوی بدافزار در اکوسیستم iOS شبیه به پیمایش در هزارتویی با دیوارهای نامرئی است. تصور کنید که یک قطب‌نمای دیجیتالی داشته باشید که نه تنها شما را در این پیچ و خم راهنمایی می‌کند، بلکه مکانیزم‌های پنهان بدافزارهای iOS را که قبلاً در هاله‌ای از رمز و راز قرار گرفته بود، آشکار می‌کند. این یک ابزار نیست، بلکه این ماهیت Forensic artifact دیجیتال است. Forensic artifactها، آبجکتهایی[1] هستند که ارزش فارنزیک دارند. درواقع artifact به معنای هر آبجکتی است که حاوی داده یا شواهدی از چیزی می‌باشد که رخ داده است (مانند لاگ‌ها و رجیستری).
ما در این پست، یک Forensic artifact خاص را بررسی خواهیم کرد که برای کشف برخی از بدافزارهای iOS و شناسایی آثار به جا مانده از تهدیدات پیچیده حائز اهمیت می‌باشند.
ما در سال‌های ۲۰۲۱ و ۲۰۲۲، این امتیاز را داشتیم که روی چند نفوذ ناشی از آلودگی بدافزار Pegasus در چندین دستگاه آیفون کار کنیم. بررسی چنین مواردی به دلیل ماهیت اکوسیستم iOS می‌تواند پیچیده، پرهزینه یا زمان بر باشد. در نتیجه، تهدیدهای مرتبط اغلب توسط عموم مردم شناسایی نمی‌شوند. تا به امروز، روش‌های رایج برای تجزیه و تحلیل نفوذ موبایل iOS یا بررسی یک نسخه پشتیبان کامل iOS رمزگذاری شده یا تجزیه و تحلیل ترافیک شبکه دستگاه صورت گرفته است. با این حال، هر دو روش زمان‌بر هستند یا به سطح بالایی از تخصص نیاز دارند، که استفاده از آنها را محدود می‌کند.
ما با تجزیه و تحلیل‌های خود، متوجه شدیم که نفوذها در یک لاگ غیرمنتظره سیستم، Shutdown.log، که یک فایل لاگ سیستم موجود در هر دستگاه iOS تلفن همراه است، ردپایی از خود به جا گذاشته‌اند. از آنجایی که روش تشخیص در چندین نفوذ که تحلیل و بررسی شده است سازگار بود، بهتر است که این فایل لاگ را با جزئیات بیشتری تشریح و درک کنیم، زیرا می‌توان از آن به عنوان روش دیگری برای شناسایی بدافزار موبایل استفاده کرد.
نمای کلی یک iOS artifact: Shutdown.log
Shutdown.log یک فایل لاگ مبتنی بر متن است که در دستگاه‌های iOS ایجاد شده است. هر رویداد راه اندازی مجدد همراه با ویژگی‌های محیطی متعدد در این فایل ثبت می‌شود. آنها می‌توانند ورودی‌های چندین سال قبل را ذخیره کرده باشند که اطلاعات زیادی ارائه می‌دهند.
هنگامی که یک کاربر دستگاه موبایل را مجددا راه اندازی می‌کند، سیستم عامل تلاش خواهد کرد تا پیش از راه اندازی مجدد، فرآیندهای در حال اجرا را به خوبی خاتمه دهد. اگر زمانی که فعالیت راه‌اندازی مجدد آغاز می‌شود، یک فرآیند «کلاینت» همچنان در حال اجرا باشد، با شناسه فرآیند ([2]PID) و مسیر سیستم فایل مربوطه ثبت می‌شود. ورودی لاگ اشاره می‌کند که این فرآیندها از راه اندازی مجدد عادی جلوگیری می‌کنند و سیستم منتظر پایان آنها است. یک مهر زمانی یونیکس برای رویداد سیستم ارائه شده است که نشان میدهد بافرهای حافظه به منظور آمادگی برای خاموش شدن (shutdown) کامل سیستم عامل پاک شده‌اند.
یک قطعه نمونه از یک فایل iOS Shutdown.log
فایل log در آرشیو sysdiagnose (sysdiag) ذخیره می شود. Sysdiag را می‌توان مجموعه‌ای از گزارش‌های سیستم و پایگاه‌های داده در نظر گرفت که می‌توانند برای اهداف دیباگینگ و عیب‌یابی تولید شوند. روش تولید sysdiag ممکن است از یک نسخه iOS به نسخه دیگر متفاوت باشد. با این وجود، این آرشیو را می‌توان در تنظیمات عمومی سیستم‌عامل، به‌ویژه در بخش ” Privacy and Analytics” یافت، اگرچه ممکن است دوباره نام مکان دقیق بین نسخه‌های iOS متفاوت باشد.
آرشیو نسبتاً سریع ایجاد می شود و معمولاً فقط چند دقیقه زمان خواهد برد. نتیجهء آن، یک فایل tar.gz. با حجمی حدود ۲۰۰-۴۰۰ مگابایت است؛ سپس این فایل را می توان به دستگاه آنالیز منتقل کرد. پس از باز شدن آرشیو، فایل Shutdown.log در دایرکتوری “\ system_logs.logarchive\Extra ” قرار می‌گیرد.
شناسایی بدافزارهای ios و درس‌های آموخته شده
هنگامی که ما برای اولین بار شروع به تجزیه و تحلیل تلفن‌های به ظاهر آلوده کردیم، آنها را با ابزار MVT که توسط سازمان عفو بین الملل توسعه یافته است آزمایش کردیم. MVT در آن زمان، با تجزیه پایگاه داده DataUsage، در میان سایر Forensic artifactها، شاخص‌های بدافزار را شناسایی کرد.
از آنجایی که بدافزارهای موبایل رو به افزایش هستند و روش‌های تشخیص آنها زمان‌بر می‌باشد، ما به دنبال روشی سریع‌تر و آسان‌تر هستیم. در حالی که تجزیه و تحلیل ترافیک شبکه می‌تواند یک روش بسیار سبک برای شناسایی نفوذ احتمالی آیفون باشد، پردازش ترافیک شبکه می‌تواند به تخصص و منابع بالایی نیاز داشته باشد. تجزیه و تحلیل تخلیه Sysdiag یک روش کم نفوذ و یک روش کم منابع برای شناسایی نفوذهای احتمالی آیفون با استفاده از artifactهای مبتنی بر سیستم است. این می‌تواند برای تکمیل شناسایی نفوذ از نقطه نظرهای مختلف مفید باشد. یک فایل لاگ نمونه متعلق به شناسایی نفوذ پگاسوس (Pegasus) در مسیر “private/var/db/com.apple.xpc.roleaccountd.staging/rolexd/” می‌باشد.
نمونه ردیابی نفوذ در ورودی Shutdown.log
پس از دریافت شاخص نفوذ در این لاگ و تایید نفوذ با استفاده از پردازش MVT سایر artifact های iOS، این لاگ اکنون بخشی از یک رویکرد جامع برای بررسی نفوذ است. از آنجایی که ما سازگاری این رفتار را با سایر نفوذهای Pegasus که تجزیه و تحلیل کردیم تأیید می‌کنیم، معتقدیم که به عنوان یک artifact قانونی قابل اطمینان برای پشتیبانی از تجزیه و تحلیل نفوذ عمل می‌کند.
ما در حین تجزیه و تحلیل نفوذهای مختلف، چندین مشاهده انجام دادیم. یکی از تلفن‌های آلوده دارای شاخص‌های نفوذ در artifact های متداول مانند پایگاه داده DataUsage بود، اما هیچ اثری در Shutdown.log وجود نداشت. تجزیه و تحلیل بیشتر نشان داد که دستگاه کاربر در روز نفوذ، راه‌اندازی مجدد نشده است. این مشاهده منطقی است، زیرا Shutdown.log فقط ورودی‌ها را پس از راه اندازی مجدد ثبت می‌کند.
یکی دیگر از مشاهدات جالبی که ما بر روی یک گوشی آلوده دیگر انجام دادیم آن بود که گاهی اوقات، زمانی که یک فرآیند ” sticky ” از راه‌اندازی مجدد مانند فرآیندهای مربوط به Pegasus جلوگیری می‌کند، فایل log نیز اعلانی را ثبت می‌کند که نشان میدهد راه‌اندازی مجدد به تأخیر افتاده است. از این رو، ما فرآیندهای مرتبط با Pegasus را در بیش از چهار اعلان تاخیر راه اندازی مجدد مشاهده کردیم. در حالی که ما شاهد نمونه‌هایی از تلفن‌های غیر آلوده با دو تا سه اخطار تاخیر راه اندازی مجدد بودیم، تأخیر بیش از حد (بیش از چهار) مورد را یکی دیگر از ناهنجاری‌های لاگ می دانیم که بایستی مورد بررسی قرار گیرند.
همانطور که به تحقیق در آرشیو sysdiag و Shutdown.log ادامه دادیم، تجزیه و تحلیل آزمایشگاه CitizenLab از Reign را خواندیم و چیزی را مشاهده کردیم که قبلا نیز با آن مواجه شده بودیم که در واقع مسیر بدافزار می‌باشد.
مسیر بدافزار Reign در سیستم فایل iOS، توسط CitizenLab شناسایی شده است
ما با مقایسه Shutdown.log برای نفوذهای Pegasus که مورد بررسی و تحلیل قرار گرفتند و artifact های مسیر Reign در بالا، متوجه شباهت‌های دیگری با این نفوذها شدیم. به نظر می‌رسد اجرای بدافزاری که از private/var/db/” /” نشات می‌گیرد و با تمام نفوذهایی که مشاهده کرده‌ایم، سازگار است، حتی اگر نام فرآیندها متفاوت باشند. این موضوع برای خانواده بدافزار موبایل دیگری که Predator نام دارد نیز صادق است، جایی که یک مسیر مشابه، private/var/tmp/” /” اغلب استفاده می‌شود.
از آنجایی که هر سه خانواده بدافزار از یک مسیر سیستم فایل مشابه استفاده می‌کردند، و از آنجایی که ما از تجزیه و تحلیل نفوذ Pegasus تأیید کردیم که چنین مسیری را می‌توان در Shutdown.log مشاهده کرد، معتقدیم که این فایل لاگ ممکن است بتواند به شناسایی آلودگی‌های این خانواده‌های بدافزاری کمک کند. اما یک هشدار بزرگ وجود دارد، این که کاربر باید تا آنجا که ممکن است راه اندازی مجدد انجام دهد. این که هر چند وقت یکبار، نیاز به راه اندازی مجدد می‌باشد، بستگی به پروفایل تهدید کاربر دارد. هر چند ساعت، هر روز و یا شاید در هر “رویداد مهم” نیاز به راه اندازی مجدد دستگاه باشد، اما مطمئن نیستیم.
اسکریپت‌های تحلیلی
ما به منظور خودکار سازی فرآیند تجزیه و تحلیل، چند اسکریپت Python3 برای کمک به استخراج، تجزیه و تحلیل و تجزیه Shutdown.log ایجاد کردیم. کاربر به عنوان یک پیش نیاز، باید یک sysdiag dump ایجاد و آرشیو را استخراج کند.
اسکریپت ۱: iShutdown_detect
اسکریپت اول در مورد تشخیص ناهنجاری‌های ذکر شده در بالا در داخل Shutdown.log است و فایل لاگ مورد نظر را در پس زمینه تجزیه و تحلیل می‌کند و هر یک از ناهنجاری‌ها را نمایش میدهد. به این اسکریپت به عنوان یک روش سبک وزن (lightweight) به منظور تجزیه و تحلیل forensic artifact برای ورودی‌های غیر معمول فکر کنید.
مثال‌های زیر برخی از نتایجی را نشان می‌دهند که انتظار دارید مشاهده کنید:
ما در حین تجزیه و تحلیل نفوذهای مختلف، چندین مشاهده انجام دادیم. یکی از تلفن‌های آلوده دارای شاخص‌های نفوذ در artifact های متداول مانند پایگاه داده DataUsage بود، اما هیچ اثری در Shutdown.log وجود نداشت. تجزیه و تحلیل بیشتر نشان داد که دستگاه کاربر در روز نفوذ، راه‌اندازی مجدد نشده است. این مشاهده منطقی است، زیرا Shutdown.log فقط ورودی‌ها را پس از راه اندازی مجدد ثبت می‌کند.
یکی دیگر از مشاهدات جالبی که ما بر روی یک گوشی آلوده دیگر انجام دادیم آن بود که گاهی اوقات، زمانی که یک فرآیند ” sticky ” از راه‌اندازی مجدد مانند فرآیندهای مربوط به Pegasus جلوگیری می‌کند، فایل log نیز اعلانی را ثبت می‌کند که نشان میدهد راه‌اندازی مجدد به تأخیر افتاده است. از این رو، ما فرآیندهای مرتبط با Pegasus را در بیش از چهار اعلان تاخیر راه اندازی مجدد مشاهده کردیم. در حالی که ما شاهد نمونه‌هایی از تلفن‌های غیر آلوده با دو تا سه اخطار تاخیر راه اندازی مجدد بودیم، تأخیر بیش از حد (بیش از چهار) مورد را یکی دیگر از ناهنجاری‌های لاگ می دانیم که بایستی مورد بررسی قرار گیرند.
همانطور که به تحقیق در آرشیو sysdiag و Shutdown.log ادامه دادیم، تجزیه و تحلیل آزمایشگاه CitizenLab از Reign را خواندیم و چیزی را مشاهده کردیم که قبلا نیز با آن مواجه شده بودیم که در واقع مسیر بدافزار می‌باشد.
فرآیندهای “Sticky ” راه اندازی مجدد را بیش از سه بار به تاخیر می اندازد
تشخیص نمونه ای از شاخص پگاسوس
تشخیص نمونه ای از شاخص Pegasus با بیش از سه تاخیر برای راه اندازی مجدد
اسکریپت ۲: iShutdown_parse
ما می‌دانیم که مواردی وجود دارند که تحلیلگران و کاربران می‌خواهند فایل‌های لاگ خود را به اشتراک بگذارند و آنها را برای اهداف مختلف تجزیه کنند. بنابراین این اسکریپت، به عنوان تلاشی برای پشتیبانی از چنین نیازی است. این اسکریپت یک آرشیو sysdiag را به عنوان آرگومان می‌گیرد و فایل Shutdown.log را از آن استخراج می‌کند. اگر دستور داده شود، آن را به یک فایل CSV تبدیل می‌کند، timestampها را رمزگشایی و خلاصه‌ای از تجزیه را ایجاد می‌کند که شامل منبع sysdiag و هش‌های Shutdown.log استخراج شده است.
از آنجایی که هر سه خانواده بدافزار از یک مسیر سیستم فایل مشابه استفاده می‌کردند، و از آنجایی که ما از تجزیه و تحلیل نفوذ Pegasus تأیید کردیم که چنین مسیری را می‌توان در Shutdown.log مشاهده کرد، معتقدیم که این فایل لاگ ممکن است بتواند به شناسایی آلودگی‌های این خانواده‌های بدافزاری کمک کند. اما یک هشدار بزرگ وجود دارد، این که کاربر باید تا آنجا که ممکن است راه اندازی مجدد انجام دهد. این که هر چند وقت یکبار، نیاز به راه اندازی مجدد می‌باشد، بستگی به پروفایل تهدید کاربر دارد. هر چند ساعت، هر روز و یا شاید در هر “رویداد مهم” نیاز به راه اندازی مجدد دستگاه باشد، اما مطمئن نیستیم.
اسکریپت‌های تحلیلی
ما به منظور خودکار سازی فرآیند تجزیه و تحلیل، چند اسکریپت Python3 برای کمک به استخراج، تجزیه و تحلیل و تجزیه Shutdown.log ایجاد کردیم. کاربر به عنوان یک پیش نیاز، باید یک sysdiag dump ایجاد و آرشیو را استخراج کند.
اسکریپت ۱: iShutdown_detect
اسکریپت اول در مورد تشخیص ناهنجاری‌های ذکر شده در بالا در داخل Shutdown.log است و فایل لاگ مورد نظر را در پس زمینه تجزیه و تحلیل می‌کند و هر یک از ناهنجاری‌ها را نمایش میدهد. به این اسکریپت به عنوان یک روش سبک وزن (lightweight) به منظور تجزیه و تحلیل forensic artifact برای ورودی‌های غیر معمول فکر کنید.
مثال‌های زیر برخی از نتایجی را نشان می‌دهند که انتظار دارید مشاهده کنید:
ما در حین تجزیه و تحلیل نفوذهای مختلف، چندین مشاهده انجام دادیم. یکی از تلفن‌های آلوده دارای شاخص‌های نفوذ در artifact های متداول مانند پایگاه داده DataUsage بود، اما هیچ اثری در Shutdown.log وجود نداشت. تجزیه و تحلیل بیشتر نشان داد که دستگاه کاربر در روز نفوذ، راه‌اندازی مجدد نشده است. این مشاهده منطقی است، زیرا Shutdown.log فقط ورودی‌ها را پس از راه اندازی مجدد ثبت می‌کند.
یکی دیگر از مشاهدات جالبی که ما بر روی یک گوشی آلوده دیگر انجام دادیم آن بود که گاهی اوقات، زمانی که یک فرآیند ” sticky ” از راه‌اندازی مجدد مانند فرآیندهای مربوط به Pegasus جلوگیری می‌کند، فایل log نیز اعلانی را ثبت می‌کند که نشان میدهد راه‌اندازی مجدد به تأخیر افتاده است. از این رو، ما فرآیندهای مرتبط با Pegasus را در بیش از چهار اعلان تاخیر راه اندازی مجدد مشاهده کردیم. در حالی که ما شاهد نمونه‌هایی از تلفن‌های غیر آلوده با دو تا سه اخطار تاخیر راه اندازی مجدد بودیم، تأخیر بیش از حد (بیش از چهار) مورد را یکی دیگر از ناهنجاری‌های لاگ می دانیم که بایستی مورد بررسی قرار گیرند.
همانطور که به تحقیق در آرشیو sysdiag و Shutdown.log ادامه دادیم، تجزیه و تحلیل آزمایشگاه CitizenLab از Reign را خواندیم. در آنجا چیزی را مشاهده کردیم که قبلا نیز با آن مواجه شده بودیم که در واقع مسیر بدافزار می‌باشد.
استخراج لاگ و خروجی تجزیه
اسکریپت ۳: iShutdown_stats
آخرین اسکریپت را می‌توان برای اهداف مختلفی استفاده کرد، مانند درک اینکه کاربر چقدر یا چه زمانی دستگاه موبایل را راه اندازی مجدد کرده است. این اسکریپت در نظر می‌گیرد که شما فایل لاگ مورد نظر را همانطور که می‌گیرد استخراج کرده‌اید و نه بایگانی sysdiag را به عنوان آرگومان.
آمار راه اندازی مجدد Shutdown.log هدف
سخن پایانی
تجزیه و تحلیل فایل Shutdown.log با جزئیات بیشتر و در پلتفرم‌های مختلف می‌بایست ادامه یابد. ما انتظار داریم بتوانیم در آینده اکتشافات بیشتری از ورودی‌های آن داشته باشیم.
برای دیدن مقالات حوزه ios میتوانید تگ IOS را انتخاب نمائید.
