نتیجه 3 ماه باگ هانتینگ روی شرکت اپل

نتیجه 3 ماه باگ هانتینگ روی شرکت اپل

بین 6 ام جولای تا 6 ام اکتبر من، برت بور هاوس، بن صادقی‌پور، ساموئل ارب و تانر بارنز باهم روی برنامه باگ‌هانتینگ شرکت اپل کار کردیم.

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

درکل 55 آسیب پذیری کشف شد، که برای 11 عدد از آنها با شدت اثر بحرانی ، 29 عدد با شدت اثر بالا، 13 عدد با شدت اثر متوسط و 2 عدد با شدت اثر پایین گزارش ثبت شد. این شدت اثرها را به منظور خلاصه سازی اهداف و وابستگی آنها به ترکیب CVSS و همچنین دانش ما از کسب و کار مرتبط با اثرات آسیب‌پذیری‌ها را مورد ارزیابی قرار دادیم.

از تاریخ 6 اکتبر 2020، تعداد بسیار زیادی از این آسیب‌پذیری های کشف‌شده رفع و پاداش آنها پرداخت شده است. درحالت عادی طی 1الی 2 روزکاری این آسیب‌پذیری ها رفع شدند (تعدادی از آنها ظرف 4 الی 6 ساعت رفع شدند).

مقدمه

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

Zero-day in Sign in with Apple – bounty $100khttps://t.co/9lGeXcni3K

— Bhavuk Jain (@bhavukjain1) May 30, 2020

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

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

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

اکتشاف

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

ریکان شرکت اپل

مختصر بگویم: زیرساخت های اپل بسیار عظیم است.

شرکت اپل کل محدوده IP 17.0.0.0/8 را دراختیار دارد که دربرگیرنده 25000 وب سرور که 10000 تای آن تحت apple.com است، 7000 تای دیگر دامنه‌های منحصربفرد هستند و درآخر TLD خودشان (dot apple). زمان ما در درجه نخست روی  محدوده IP 17.0.0.0/8 ، .apple.com و .icloud.com صرف شد، چراکه به‌نظر می‌رسید اینجا توابع و عملکردهای جالب زیادی وجود داشته باشد.

پس از تهیه فهرستی از تمام وب سرورها، شروع به اجرای دستورات brute force روی موارد جالب تر کردیم.

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

  • سرورهای VPN تحت تاثیر خوانش فایل محلی Cisco CVE-2020-3452 در یک روز (x22)
  • لو رفتن توکن دسترسی Spotify داخل یک پیام خطا روی یک صفحه خراب

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

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

اینکار باعث شروع شدن یک سری از کشفیات شد که درطول همکاری ما با شرکت اپل ادامه داشت و به مرور درک ما را از برنامه باگ بانتی اپل افزایش داد.

آسیب پذیری ها کشف شده

در جدول پایین 12 عدد از آسیب پذیری هایی که دراین پروژه کشف کردیم را همراه با کد گزارش می‌توانید مشاهده کنید:

Report ID Date Title Severity
741765282 7/26/2020 Remote Code Execution via Authorization and Authentication Bypass Critical
747008210 9/17/2020 Authentication Bypass via Misconfigured Permissions allows Global Administrator Access Critical
743305978 8/11/2020 Command Injection via Unsanitized Filename Argument Critical
744391544 8/21/2020 Remote Code Execution via Leaked Secret and Exposed Administrator Tool Critical
741014809 7/18/2020 Memory Leak leads to Employee and User Account Compromise allowing access to various internal applications Critical
742879257 8/6/2020 Vertica SQL Injection via Unsanitized Input Parameter Critical
742693737 8/5/2020 Wormable Stored XSS allows Attacker to Fully Compromise Victim iCloud Account Critical
743695576 8/14/2020 Wormable Stored XSS allows Attacker to Fully Compromise Victim iCloud Account Critical
742909161 8/7/2020 Full Response SSRF allows Attacker to Read Internal Source Code and Access Protected Resources Critical
745400606 9/1/2020 Blind XSS allows Attacker to Access Internal Support Portal for Customer and Employee Issue Tracking Critical

 

رایت آپ های آسیب‌پذیری ها

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

  1. به خطر افتادن کامل برنامه مربیان برجسته اپل از طریق دور زدن احراز هویت و مجوز
  2. به خطر انداختن کامل اپلیکیشن DELMIA Apriso با دورزدن احراز هویت
  3. آسیب‌پذیری‌های تزریق اسکریپت ازطریق وبگاه (XSS) ذخیره‌شده Wormable به مهاجم اجازه می‌دهد داده‌های iCloud را از طریق ایمیل اصلاح‌شده سرقت کند
  4. تزریق فرمان در  ePublisherصاحب اثر
  5. SSRF پاسخ کامل روی iCloud  به مهاجم اجازه می دهد تا کدمنبع اپل را بازیابی کند
  6.  دسترسی به پنل اشکال‌زدایی ادمین Nova از طریق نشت REST Error
  7. کلیدهای مخفی AWS از طریق بنرهای PhantomJS iTunes و XSS عنوان کتاب
  8. Heap Dump در Apple eSign به مهاجم اجازه می دهد تا ابزارهای مدیریت خارجی کارکنان خارجی را به خطر بیاندازد.
  9. پردازش موجودیت خارجی XML به SSRFکور روی API مدیریت Java
  10. تزریق GBI Vertica SQL و GSF API درمعرض دید(Exposed)
  11. آسیب‌پذیری های IDOR مختلف
  12.  آسیب پذیری های XSS کور مختلف

به خطر افتادن کامل اپلیکیشن مربیان برجسته اپل از طریق دور زدن احراز هویت و مجوز

یکی از اولین سرویس‌هایی که ما زمان خود را صرف تست نفوذ آن کردیم، سایت ” Apple Distinguished Educators ” بود. این سایت متعلق به انجمن دعوتی Jive بود که در آن کاربران می توانستند با استفاده از حساب اپل خود احراز هویت کنند. نکته جالب در مورد این انجمن این بود که برخی از عملکردهای اصلی Jive برای ثبت نام در اپلیکیشن از طریق یک صفحه میان‌افزار سفارشی ساخته شده توسط اپل منتقل می‌شد که به منظور اتصال سیستم احراز هویت (IDMSA) به انجمن زیربنایی Jive که معمولاً از احراز هویت نام کاربری/گذرواژه استفاده می‌کرد ساخته شده بود .

اپلیکیشن مربیان برجسته اپل

این سرویس به این منظور فراهم کردن امکان استفاده آسان از حساب کاربری Apple برای احراز هویت در انجمن ساخته شده است تا مجبور نباشند با ایجاد یک حساب کاربری اضافی سر و کار داشته باشند. شما به راحتی می توانید از ” Sign In With Apple ” استفاده کنید و وارد انجمن شوید.

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

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

یکی از مقادیری که در صفحه داخل اپلیکیشن برای ثبت نام به جهت استفاده از انجمن پنهان شده بود، یک فیلد «رمزعبور» با مقدار «###INvALID#%!3» بود. وقتی درخواست خودتان را که شامل نام کاربری، نام و نام خانوادگی، آدرس ایمیل و نام کارفرمای شما بود، ارسال می‌کردید، یک مقدار برای «رمزعبور» هم ارسال کردید که سپس مخفیانه به حساب شما مرتبط می‌شد که منبع این رمزعبور یک فیلد ورودی مخفی در صفحه بود.

<div class="j-form-row">

<input id="password" type="hidden" value="###INvALID#%!3">

<div id="jive-pw-strength">

...

پس از مشاهده فیلد رمز عبور پیش‌فرض پنهان، بلافاصله به این فکر افتادیم که راهی برای احراز هویت دستی اپلیکیشن و دسترسی به یک حساب تایید شده برای انجمن به جای تلاش برای ورود با سیستم «Sign In With Apple» پیدا کنیم. از آنجاییکه رمز عبور برای هر یک از ما در ثبت نام های جداگانه یکسان بود، این موضوع را بررسی کردیم.

اگر کسی با استفاده از این سیستم درخواست داده بود و عملکردی وجود داشت که می‌توانستید با آن به صورت دستی احراز هویت را انجام دهید، می‌توانستید به سادگی با استفاده از رمز عبور پیش‌فرض وارد حساب کاربری خود شوید و ورود با سیستم « Sign In With Apple » را به‌طور کامل دور بزنید.

درنگاه نخست، به نظر نمی رسید که بتوان به صورت دستی احراز هویت کرد، اما پس از چند جستجوی گوگل، اندپوینت “cs_login” را شناسایی کردیم که برای ورود با نام کاربری و رمز عبور به اپلیکیشن‌های Jive طراحی شده بود. هنگامی که به صورت دستی درخواست آزمایشی HTTP را برای احراز هویت در برنامه Apple Distinguished Developers ایجاد کردیم، متوجه شدیم که با نمایش یک خطای رمز عبور نادرست سعی در احراز هویت ما داشته است. وقتی از حساب‌های خودمان استفاده می‌کردیم که قبلاً با آن‌ها درخواست داده بودیم، برنامه با خطا مواجه شد و به ما اجازه احراز هویت نداد زیرا هنوز تأیید نشده بودیم. اگر خواستار احراز هویت بودیم، باییستی نام کاربری یکی از اعضای مورد تأیید قبلی را پیدا می‌کردیم.

در این مرحله، ما درخواست HTTP را در متجاوز (intruder) Burp Suite بارگذاری کردیم و سعی کردیم از طریق لاگین و رمز عبور پیش‌فرض، نام‌های کاربری بین 1 تا 3 کاراکتر را Brute force کنیم.

پس از حدود دو دقیقه، ما یک پاسخ 302 دریافت کردیم که نشان می‌دهد با استفاده از رمز عبور پیش‌فرض که قبلا پیدا کرده‌ایم، یک کاربر با نام کاربری 3 کاراکتری با موفقیت وارد سیستم شده است. ما وارد شده بودیم! از این نقطه به بعد، هدف بعدی ما احراز هویت به عنوان فردی با مجوزهای سطح بالا بود. ما از دسترسی خود چند اسکرین شات گرفتیم و روی لیست «کاربران» کلیک کردیم تا ببینیم کدام یک از کاربران مجوز سطح ادمین دارند. به اولین حسابی که در لیست دیدیم وارد شدیم تا ثابت کنیم می‌توانیم از طریق عملکرد مدیریتی به اجرای کد از راه دور دست پیدا کنیم، با این حال، هنوز چند مانع دیگر در پیش داشتیم.

هنگام تلاش برای مرور “/admin/” (کنسول مدیر Jive) به عنوان حساب مدیریتی، اپلیکیشن به سمت صفحه ورود هدایت شد به صورتیکه که انگار هنوز احراز هویت نشده‌ایم. این عکس‌العمل عجیب بود، چراکه  این رفتار مختص اپلیکیشن Jive بود و هیچ یک از ما قبلاً این رفتار را مشاهده نکرده بودیم. حدس ما این بود که اپل برای اینکه اطمینان حاصل کند که اپلیکیشن هرگز به طور کامل به خطر نیفتاده است، کنسول مدیریت را بر اساس آدرس IP محدود کرده بود.

استفاده از هدر X-Forwarded-For برای دور زدن محدودیت فرضی یکی از اولین کارهایی بود که ما امتحان کردیم، و متأسفانه شکست خوردیم. مورد بعدی که امتحان کردیم این بود که شکل دیگری از “/admin/” را بارگیری کنیم در صورتی که اپلیکیشن برای دسترسی به کنسول مدیریت دارای لیست های سیاه مسیر خاص بود.

تنها پس از چند درخواست HTTP دیگر، متوجه شدیم که “GET /admin;/” به مهاجم اجازه می دهد تا به کنسول مدیریت دسترسی داشته باشد. ما این دور زدن را با تنظیم یک قانون Burp Suite که در درخواست‌های HTTP ما به طور خودکار «GET/POST /admin/» را به «GET/POST /admin;/» تغییر می‌دهد ، اتومیشن سازی کردیم.

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

در این مرحله، به این فکر کردیم که دقیقا کجا قرار گرفته ایم و متوجه شدیم که حسابی که به آن احراز هویت کردیم ممکن است مدیر «هسته» اپلیکیشن نباشد. جلوتر رفتیم و 2-3 حساب دیگر را احراز هویت کردیم تا در نهایت به عنوان مدیر اصلی احراز هویت شویم و تابعی را پیدا کنیم که امکان اجرای کد از راه دور را فراهم می کند.

یک مهاجم می تواند (1) با احراز هویت دستی با استفاده از یک قابلیت‌ ورود به سیستم پیش‌فرض پنهان، احراز هویت را دور بزند، سپس (2) از طریق ارسال یک مسیر HTTP تغییر یافته در درخواست، به کنسول مدیریت دسترسی پیدا کند، و در نهایت (3) با استفاده از یکی از بسیاری از قابلیت های ” baked in RCE ” مانند آپلود پلاگین، الگوسازی یا مدیریت فایل، برنامه را به طور کامل به خطر بیاندازید.

درکل، مهاجم می توانست از این آسیب پذیری برای موارد زیر سواستفاده کنید…

  • دستورات دلخواهش را در وب سرور ade.apple.com اجرا کند
  • به سرویس داخلی LDAP برای مدیریت حساب های کاربری دسترسی داشته باشد.
  • به بخش اعظمی از شبکه داخلی شرکت اپل دسترسی داشته باشد.

در این مرحله، گزارش را تمام کردیم و همه چیز را ثبت کردیم.

به خطر انداختن کامل اپلیکیشن DELMIA Apriso با دور زدن احراز هویت

چیزی که ما در حین تست نفوذ اپل به آن فکر می کردیم این بود که آیا آنها خدمات قابل دسترسی مرتبط با تولید و توزیع محصولات خود دارند یا نه. همانطور که مشخص شد، برنامه ای به نام “DELMIA Apriso” وجود داشت که یک “سوئیت تولید جهانی” شخص ثالث بود که درظاهر راه حل های مختلف برای انبارداری ارائه می‌کرد .

متأسفانه، به نظر نمی‌رسد تعامل دردسترس زیادی برای این فناوری وجود داشته باشد، زیرا شما فقط می‌توانید از رابط‌های دردسترس «ورود» و «بازنشانی رمز عبور» استفاده کنید.

پس از تلاش برای یافتن آسیب‌پذیری‌ها در تعداد محدودی از صفحات، اتفاق عجیبی افتاد: ما بر اساس نواری که در قسمت سمت راست بالای سایت ظاهر می‌شد، به‌عنوان کاربری به نام «Apple No Password User» احراز هویت شدیم.

اتفاقی که افتاده بود این بود که با کلیک بر روی “Reset Password”، ما به طور موقت به عنوان کاربری که “مجوز (Permission)” استفاده از صفحه را داشت احراز هویت شدیم.

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

ما برای بالاتر بردن سطح مجوزهایمان کارهای مختلفی انجام دادیم، اما برای مدت طولانی چنین به نظر می رسید که نتوانتسه‌ایم به جایی برسیم. پس از مدتی، یک درخواست HTTP به اندپوینت OAuth ارسال کردیم تا یک حامل مجوز ایجاد کنیم و از آن برای کاوش API بتوانیم استفاده کنیم. اینکار موفقیت آمیز بود!

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

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

متأسفانه ما به اکثر فراخوانی‌های API دسترسی نداشتیم، اما برخی از این بخش‌ها مانند «عملیات» تعداد زیادی از توابع و عملکردهای موجود را فاش کردند.

اگر اندپوینت “/Apriso/HttpServices/api/platform/1/Operations” را بزنید، فهرستی نزدیک به 5000 فراخوانی API مختلف را نشان می دهد. هیچ یک از این موارد فراتر از حامل مجوز اولیه ای که در ابتدا ارسال کردیم، به احراز هویت نیاز نداشت. عملیات افشا شده اینجا دربرگیرنده مواردی مانند …

  • ایجاد و اصلاح محموله‌ها
  •  ایجاد و اصلاح روزپرداخت حقوق و دستمزد کارکنان
  • ایجاد و اصلاح اطلاعات موجودی
  • اعتبار سنجی نشان های کارکنان
  • صدها عملیات مرتبط با انبار

موردی که بیشتر به آن توجه کردیم “APL_CreateEmployee_SO” بود.

شما می توانید یک درخواست GET به یک عملیات خاص ارسال کنید و پارامترهای مورد انتظار را با استفاده از فرمت زیر دریافت کنید:

GET /Apriso/HttpServices/api/platform/1/Operations/operation HTTP/1.1

Host: colormasters.apple.com


با پاسخ HTTP زیر:

{

  "InputTypes": {

    "OrderNo": "Char",

    "OrderType": "Integer",

    "OprSequenceNo": "Char",

    "Comments": "Char",

    "strStatus": "Char",

    "UserName": "Char"

  },

  "OutputTypes": {},

  "OperationCode": "APL_Redacted",

  "OperationRevision": "APL.I.1.4"

}


اینکار کمی زمانبر بود، ولیکن پس از مدتی متوجه شدیم که برای فراخوانی API باید یک درخواست POST با داده های JSON در قالب زیر ارسال کنیم:

{

  "inputs": {

    "param": "value"

  }

}


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

نزدیک به 6 ساعت برای درک نحوه تشکیل فراخوانی API وقت صرف کرده بودم، اما بعد از اینکه متوجه نحوه کار شدیم، همه چیز بسیار راحت و آسان شده بود. تابع ” ایجاد کارمند” به پارامترهای مختلفی نیاز داشت که به UUID ها متکی بودند، اما ما توانستیم این پارامترها را از طریق یک “عملیات” دیگر بازیابی کنیم و در ادامه آنها را پر کنیم.

حدود دو ساعت دیگر، در نهایت درخواست API زیر را تشکیل دادیم:

POST /Apriso/HttpServices/api/platform/1/Operations/redacted HTTP/1.1

Host: colormasters.apple.com

Authorization: Bearer redacted

Connection: close

Content-Type: application/json

Content-Length: 380

{

  "inputs": {

    "Name": "Samuel Curry",

    "EmployeeNo": "redacted",

    "LoginName": "yourloginname123",

    "Password": "yourpassword123",

    "LanguageID": "redacted",

    "AddressID": "redacted",

    "ContactID": "redacted",

    "DefaultFacility": "redacted",

    "Department": "",

    "DefaultMenuItemID": "redacted",

    "RoleName": "redacted",

    "WorkCenter": ""

  }

}


پس از ارسال این فراخوان API، اکنون می‌توانیم به‌عنوان یک مدیر سراسری (global administrator) برای اپلیکیشن احراز هویت کنیم. این امر به ما نظارت کاملی بر نرم افزار مدیریت انبار و احتمالاً RCE از طریق برخی توابع پذیرفته شده را فراهم کرد.

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

آسیب‌پذیری‌های تزریق اسکریپت ازطریق وبگاه (XSS) ذخیره‌شده Wormable به مهاجم اجازه می‌دهد داده‌های iCloud را از طریق ایمیل اصلاح‌شده سرقت کند

یکی از بخش‌های اصلی زیرساخت اپل، پلتفرم iCloud این شرکت است. این وب‌سایت به‌عنوان مکانیزم ذخیره‌سازی خودکار عکس‌ها، فیلم‌ها، اسناد و داده‌های مربوط به برنامه برای محصولات اپل کار می‌کند. علاوه بر این، این پلتفرم خدماتی مانند Mail و Find my iPhone را هم ارائه می دهد.

سرویس پست الکترونیکی یک پلتفرم ایمیل کامل است که کاربران می توانند ایمیل هایی مشابه جیمیل و یاهو را از طریق آن ارسال و دریافت کنند. علاوه بر این، یک برنامه ایمیل در iOS و Mac وجود دارد که به طور پیش فرض روی محصولات نصب شده است. سرویس پست الکترونیکی در کنار سایر خدمات مانند ذخیره سازی فایل و اسناد در “www.icloud.com” میزبانی می‌شود.

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

نحوه کار اپلیکیشن ایمیل بسیار ساده است. هنگامی که این سرویس یک ایمیل دریافت می‌کند و کاربر آن را باز می‌کند، داده‌ها در یک حباب JSON پردازش می‌شوند که توسط جاوا اسکریپت پاکسازی شده و جدا می‌شود و سپس به کاربر نمایش داده می‌شود.

این بدان معنی است که هیچ پردازشی در سمت سرور ایمیل ها از نظر پاکسازی محتوا وجود ندارد و تمام عملکرد واقعی برای ارائه و پردازش متن‌نامه در جاوا اسکریپت است که در سمت کلاینت انجام می‌شود. این لزوماً چیز بدی نیست، اما فرآیند شناسایی XSS را با درک اینکه دقیقاً چه چیزی را باید در کد منبع بدست بیاوریم، آسانتر می‌کند.

XSS ذخیره شده با استفاده از گمراه کردن تگ استایل

هنگام تست این تابع، یکی از چیزهایی که در نهایت من را گمراه کرد، تگ “<style>” بود. این تگ جالب است زیرا DOM این عنصر را فقط با یک تگ “</style>” لغو می کند. این به این معناست که اگر «<style><script>alert(1)</script></style>» را بنویسیم و آن به طور کامل در DOM رندر شود، هیچ اعلان هشداری وجود نخواهد داشت زیرا محتوای تگ کاملاً CSS است و تگ اسکریپت درون تگ پر شده قرار دارد و خارج از تگ بسته شده نیست.

از نقطه نظر پاکسازی، تنها چیزی که اپل اینجا باید از آن نگران باشد یک تگ استایل پایانی یا درصورت وجود اطلاعات حساس در صفحه ، تزریق CSS از طریق زنجیره واردات است.

تصمیم گرفتم بدون اینکه اپل متوجه شود یکراست سراغ تگ استایل بروم، زیرا در صورت امکان، یک XSS ذخیره شده سرراست می‌توانست درخود داشته باشد.

من برای مدتی سعی کردم جایگشت های مختلفی را با این مورد امتحان کنم و در نهایت چیز جالبی مشاهده کردم: وقتی دو تگ استایل در ایمیل داشته باشید، محتویات تگ های استایل داخل یک تگ استایل به هم متصل می‌شوند. این بدان معناست که اگر بتوانیم “</sty” را به تگ اول و “le>” را به تگ دوم وارد کنیم، می‌توانیم برنامه را فریب دهیم تا فکر کند تگ ما هنوز باز است در حالی که واقعاً اینطور نیست.

برای اینکه تست کنم ببینم آیا این روش جواب می دهد یا نه، پی لود زیر را ارسال کردم:

<style></sty</style>

<style>le><script>alert(1)</script></style>


ایمیل داخل صندوق ورودی ایمیل من ظاهر شد. روی آن کلیک کردم. یک هشدار بود! کار کرده بود!

DOM صفحه به صورت زیر بود:

<style></style><script>alert(1)</script></style>

از آنجایی که برنامه ایمیل در «www.icloud.com» میزبانی می‌شود، این بدان معناست که ما مجوزهای مرورگر برای بازیابی پاسخ‌های HTTP برای APIهای مربوطه برای سرویس iCloud را داریم (درصورتیکه بتوانیم به جاوا اسکریپت مخفیانه وارد شده و به آنها دسترسی پیدا کنیم).

توضیح پی‌لود فوق به شرح زیر است:

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

ما یک سند اثبات مفهوم منظم ساختیم که آدرس‌های اینترنتی عکس‌ها را از API iCloud برمی‌گرداند، آن‌ها را در تگ‌های تصویر می‌چسباند و سپس فهرستی از مخاطبین را برای حساب کاربری زیر آن‌ها اضافه می‌کرد. این نشان داد که امکان بازیابی مقادیر وجود دارد، اما برای استخراج آنها باید یک CSP را دور بزنیم که این به این معنی بود که هیچ درخواست HTTP خارج از محدوده به هیچ چیز دیگری جز “.apple.com” و چند دامنه دیگر نمی توان به آسانی ارسال کرد.

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

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

XSS ذخیره شده با استفاده از گمراه کردن هایپرلینک

سپس یک آسیب‌پذیری تزریق اسکریپت ازطریق وبگاه (XSS) را پیدا کردم که به روشی مشابه روی ایمیل‌ها تاثیرگذار بود.

یکی از مواردی که من همیشه در این نوع اپلکیشن‌های نیمه HTML بررسی می‌کنم این است که چگونه از لینک‌ها استفاده می‌کنند. به نظر می رسد تبدیل خودکار یک URL علامت گذاری نشده به یک هایپرلینک، مستقیما قابل درک باشد، اما اگر به درستی پاکسازی نشود یا با سایر عملکردها ترکیب شود، ممکن است بهم‌ریختگی به‌بار بیاورد.

دومین کارکرد جالب برای این XSS حذف کامل تگ های خاصی مانند «<script>» و «<iframe>» است. این یکی شسته رفته است چراکه چیزهای خاصی به کاراکترهایی مانند فاصله، برگه‌ها و خطوط جدید متکی هستند، در حالی که فضای خالی باقی مانده از تگ‌های حذف شده می‌تواند آن کاراکترها را بدون گفتن به تجزیه‌کننده جاوا اسکریپت فراهم کند. این بی تفاوتی ها به مهاجمان اجازه می دهد تا اپلیکیشن را گمراه کنند و کاراکترهای مخربی که می توانند XSS را فراخوانی کنند را پنهان کنند.

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

https://domain.com/abc">https://www.domain.com/abc#<script></script>https://domain.com/abc

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

<a href="https://www.domain.com/abc#<a href=" https:="" www.domain.com="" abc="&quot;" rel="noopener noreferrer">https://www.domain.com/abc</a>

درابتدا جالب به نظر می‌رسید، ولیکن بهره برداری از آن کمی سخت تر بود. تعریف ویژگی‌های درون تگ آسان است (مانند src، onmouseover، onclick، و غیره) اما ارائه مقادیر دشوار خواهد بود، چراکه هنوز باید URL regex را مطابقت دهیم تا از عملکرد هایپرلینک خودکار فرار نکند. پی‌لود که در نهایت بدون ارسال نقل‌قول‌های سینگل، مضاعف، پرانتز، فاصله‌ها یا بک‌تیک‌ها کار می‌کرد به شرح زیر بود:

https://www.icloud.com/mail/#<script></script>https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//

پی‌لود این مورد را در DOM تولید کرد:

<a href="https://www.icloud.com/mail#<a href=" https:="" www.icloud.com="" onmouseover="location=/javascript:alert%28document.domain%29/.source;//&quot;">https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//</a>

و این هشدار زیبا را به ما نشان داد:

باگ هانتینگ

این پی‌لود از یک راه حل CTF توسط @Blaklis_ برداشته شده بود. در ابتدا  من فکر می کردم که ممکن است یک XSS غیرقابل بهره برداری باشد، اما به نظر می رسد همیشه راه حلی برای XSS لب مرزی هم وجود داشته باشد.

?age=19;location=/javascript:alert%25281%2529/.source; :>

— Blaklis (@Blaklis_) May 7, 2019

بهترین توضیح من اینجا این است که (1) هنگام بارگیری URL اولیه، کاراکترهای درون «<script></script>» در فرآیند پیوند خودکار قابل قبول بودند و آن را خراب نکردند، سپس (2) حذف تگ‌های اسکریپت بدون بستن عملکرد هایپرلینک‌های اولیه  و در آخر (3) هایپرلینک دوم نقل قول اضافی را اضافه کرد که هم برای خارج شدن از href و هم برای ایجاد کنترل کننده رویداد onmouseover از آن استفاده شد.

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

درکل، مهاجم با بهره برداری از این آسیب پذیری به موارد زیر میتوانست دسترسی داشته باشد…

  • ایجاد یک کرم (Worm)که قابلیت این را دارد که خیلی بی‌سروصدا اطلاعات iCloud را استخراج کند یا تغییر دهد، ازجمله تصاویر و ویدیوها
  • بی سروصدا کد HTML و JavaScript دلخواه را داخل مرورگر قربانی اجرا کند

تزریق فرمان در   ePublisher صاحب اثر

یکی از ویژگی های اصلی اپل قابلیت آپلود و فروش کتاب، فیلم، برنامه های تلویزیونی و آهنگ است. فایل‌هایی که آپلود می‌کنید در سرویس‌های مختلف اپل مانند iTunes منتشر می‌شوند، جایی که مردم می‌توانند آن‌ها را دانلود یا خریداری کنند. به‌نظر میرسید این قابلیت یک مسیر خوب برای XSS مشتری و XSS کور در برابر کارمندان باشد.

برای آپلود فایل‌ها، ابتدا باید برای دسترسی به سرویس در iTunes Connect درخواست می‌دادیم.

ما با مشکل جالبی مواجه شدیم که به آی‌پد یا آیفون دسترسی نداشتیم، اما همچنان به دنبال راه‌هایی برای استفاده از این سرویس بودیم. پس از کمی جست و جو و بررسی، ابزاری به نام Transporter را کشف کردیم.

Transporter  یک برنامه جاوا است که می تواند برای تعامل با یک API jsonrpc برای آپلود انبوه فایل ها با استفاده از چند سرویس فایل مختلف استفاده شود.

در همان زمان، همچنین در حال جستجوی اسناد راهنمای iTunes Connect Book بودیم و صفحه‌ای پیدا کردیم که چند روش مختلف برای آپلود کتاب‌ها از جمله یک وب سرویس آنلاین را توضیح می‌داد: https://itunespartner.apple.com/books/articles/submit-your-ebook-2717

این اتفاق مارا به سرویس  Apple Books for Authors هدایت کرد.

این سرویس چند ویژگی دارد:

  • ورود/ ثبت نام
  • آپلود تصویر به عنوان کاور کتاب
  • آپلود فایل ePub کتاب
  • آپلود فایل ePub نمونه کتاب

اولین کاری که انجام دادیم این بود که نمونه فایل های epub را دانلود و آپلود کردیم. نتیجه اولیه به اندازه کافی خنده دار بود، اولین فایل epub که برداشتیم فرمت epub نسخه 1 با xhtml نامعتبر بود. ابزار انتشار (Publish tool) دیوار بزرگی از متن خطاها را بیرون ریخت تا به ما اطلاع دهد که چرا بارگذاری/اعتبارگذاری ناموفق بود.

درخواست HTTP:

POST /api/v1/validate/epub HTTP/1.1

Host: authors.apple.com

{"epubKey":"2020_8_11/10f7f9ad-2a8a-44aa-9eec-8e48468de1d8_sample.epub","providerId":"BrettBuerhaus2096637541"}

پاسخ HTTP:

[2020-08-11 21:49:59 UTC] <main> DBG-X:   parameter TransporterArguments = -m validateRawAssets -assetFile /tmp/10f7f9ad-2a8a-44aa-9eec-8e48468de1d8_sample.epub -dsToken **hidden value** -DDataCenters=contentdelivery.itunes.apple.com -Dtransporter.client=BooksPortal -Dcom.apple.transporter.updater.disable=true -verbose eXtreme -Dcom.transporter.client.version=1.0 -itc_provider BrettBuerhaus2096637541

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

ما درخواست را در آپلود بعدی پیگیری و تفسیر کردیم و آن را با مورد زیر جایگزین کردیم:

"providerId":"BrettBuerhaus2096637541||test123"

و خروجی زیر را بدست آوردیم:

/bin/sh: 1: test123: not found

در ادامه اسکرین شاتی که خروجی ” ls /” را نشان می‌دهد را مشاهده می‌کنید:

درکل، مهاجم با بهره برداری از این آسیب پذیری به موارد زیر میتوانست دسترسی داشته باشد…

  • اجرای دستورات دلخواه روی وب سرور authors.apple.com
  • دستیابی به شبکه داخلی شرکت اپل

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

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

SSRF پاسخ کامل روی iCloud  به مهاجم اجازه می دهد تا کدمنبع اپل را بازیابی کند

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

چیزی تا پایان زمان همکاری مان نمانده بود که سرانجام به یکی از آنها برخورد کردیم که به نظر می رسید دسترسی زیادی به شبکه داخلی داشت.

در حین تست برنامه iCloud متوجه شدیم که می‌توانیم پیوست‌های خاصی را از اپلیکیشن ایمیل iCloud در اپلیکیشن iCloud pages از طریق تابع «open in pages» باز کنیم. وقتی  فرم را برای انجام این کار ارسال کردیم، آن یک درخواست HTTP حاوی یک پارامتر URL که، شامل URL فایل پیوست، فایل ایمیل در درخواست است را ارسال می‌کند. اگر بخواهید این URL را به چیز دلخواهی تغییر دهید، این درخواست با شکست مواجه می‌شود و خطای «400 Bad Request» می‌دهد. این فرآیند یک “job” ایجاد می کند که در آن پاسخ درخواست HTTP به یک سند Apple Pages تبدیل می شود و سپس در یک تب جدید باز می‌شود.

به نظر می‌رسد که فقط URL‌های دامنه «p37-mailws.icloud.com» مجاز هستند، صفحات را با چیزی جز یک پاسخ HTTP 200 OK تبدیل نمی‌کند، همچنین به دلیل اینکه فرایند تبدیل ازطریق درخوست های HTTP چندگانه و یک صف job انجام می‌شود، تست آن کمی سخت است.

چیزی که برای بهره برداری از این کار مفید بود، اضافه کردن «@ourdomain.com» بعد از دامنه لیست سفید بود که درخواست را به دامنه ما نشان می داد. این فرآیند، HTML خام را به فایلی از صفحات اپل تبدیل می کند و سپس آن را در یک پنجره جدید برای ما نمایش می دهد. عیب یابی این کمی آزاردهنده بود، بنابراین Brett در نهایت از یک اسکریپت پایتون برای خودکار کردن و جمع کردن این فرآیند استفاده کرد.

https://gist.github.com/samwcyo/f8387351ce9acb7cffce3f1dd94ce0d6

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

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

ما URL داخلی maven را که در یک ری‍‍‍پازیتوری Github فاش شده بود، پیدا کرده بودیم.

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

درکل، مهاجم با بهره برداری از این آسیب پذیری به موارد زیر میتوانست دسترسی داشته باشد…

  • خواندن فایل های مختلف  کدمنبع iOS داخل ریپازیتوری maven
  • دسترسی داشتن به تمام چیزهای در دسترس داخل شبکه داخلی شرکت اپل
  • درمعرض خطر قرار دادن تمام Session قربانیان ازطریق آسیب پذیری Cross-site Scripting صرفا به دلیل کوکی های فاش شده HTTP داخل درخواست HTTP

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

باگ هانتینگ

دسترسی به پنل اشکال‌زدایی ادمین Nova از طریق نشت REST Error

در حالی که فهرستی از تمام زیردامنه های اپل را یکجا مرور می کردیم، از “concierge.apple.com”، “s.apple.com” و “events.apple.com” عملکردهای جالبی کشف کردیم.

با چرخ زدن در گوگل، متوجه شدیم که ارسال یک درخواست خاص به “s.apple.com” شما را با یک توکن احراز هویت در “events.apple.com” می برد.

درخواست HTTP :

GET /dQ{REDACTED}fE HTTP/1.1

Host: s.apple.com

پاسخ HTTP :

HTTP/1.1 200

Server: Apple

Location: https://events.apple.com/content/events/retail_nso/ae/en/applecampathome.html?token=fh{REDACTED}VHUba&a=1&l=e

با اجرای تکنیک‌های استاندارد ریکان، فایل‌های جاوا اسکریپت را برداشتیم و شروع به جستجوی اندپوینت‌ها و مسیرهای API کردیم.

با کشف اندپوینت /services/public/account، شروع به بازی با آن کردیم. ما به سرعت متوجه شدیم که عبور از یک پارامتر marketCode نامعتبر منجر به بازگشت خطای استثنا REST توسط سرور می شود.

درخواست HTTP :

پاسخ HTTP :

از پیام خطا می توان مشاهده کرد که سرور در حال باز ارسال (هدایت ، Forwarding ) یک درخواست API به موقعیت زیر است:

https://nova-admin.corp.apple.com/services/locations/searchLocation?locationName=t&rtm=1

همچنین می‌توانیم ببینیم که برخی از سربرگ‌های درخواست/پاسخ از جمله یک کوکی nova-admin و یک توکن احراز هویت که سرور برای درخواست‌ها، به درخواست‌های API nova-admin.corp.apple.com ارسال می‌کند، فاش کرده است.

این نکته هم جالب است که اندپوینت  /services/ مشابه اندپوینت‌های  API /services/public/ برای اپلیکیشن رویدادها است. ما نتوانستیم به اندپوینت‌های رویداد از مرورگر به سرور درخواست عملیاتی بفرستیم و به nova-admin.corp.apple.com دسترسی نداشتیم. با بازگشت به داده‌های ریکان خودمان متوجه شدیم که یک دامنه به نام nova.apple.com وجود دارد.

در زمان تلاش برای استفاده از توکن و کوکی تأیید اعتبار به دست آمده، متوجه شدیم که اطلاعات شناسایی کاربر معتبر هستند، چراکه دیگر به idsmac auth هدایت نمی شدیم، اما همچنان با 403 forbidden مواجه بودیم.

با کمی عیب یابی کردن متوجه شدیم که می‌توانیم از /services/debug.func.php از مرورگر به سرور درخواست عملیاتی ارسال کنیم.

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

درخواست HTTP:

پاسخ HTTP:

این پورتال حاوی ده ها گزینه وهمچنین شامل صدها پارامتر و مقادیر متعلق به تنظیمات پیکربندی بود.

همچنین یکی از مقادیر حاوی یک کلید مخفی AWS و دیگری حاوی crontabهای سرور بود. داشتن قابلیت به روز رسانی این مقادیر برای اثبات تزریق فرمان کافی بود.

درکل، مهاجم با بهره برداری از این آسیب پذیری به موارد زیر میتوانست دسترسی داشته باشد…

  • اجرای فرمان های دلخواه روی وب سرور apple.com
  • دسترسی به شبکه داخلی شرکت اپل

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

باگ هانتینگ

کلیدهای مخفی AWS از طریق بنرهای PhantomJS iTunes و XSS عنوان کتاب

ما وب سایت سازنده بنر iTunes را چند هفته قبل از یافتن این آسیب پذیری کشف کردیم. زمانی که کتابی را از طریق iTunes Connect اضافه کردیم، ویژگی جالبی  در سازنده بنر کشف کردیم.

براساس مقادیر طول و عرض مشخص شده چندین قالب تصویر بنر وجود دارد. ما متوجه شدیم که تصویر بنر “300×250” نام کتاب را هم دربرمیگیرد.

همچنین متوجه شدیم که آن در برابر اسکریپت‌های بین سایتی آسیب‌پذیر است، چراکه زیر نام کتاب با عنصر “<u>” تزریق شده ما که هنگام ثبت کتاب در اتصال iTunes تنظیم کرده بودیم، خط‌‌ کشیده شده بود.

تصویر URL:

https://banners.itunes.apple.com/bannerimages/banner.png?pr=itunes&t=catalog_black&c=us&l=en-US&id=1527342866&w=300&h=250&store=books&cache=false

قبلاً متوجه شده بودیم که پیمایش مسیر و تزریق پارامتر در تعدادی از پارامترهای درخواست مانند “pr” وجود دارد. برای مثال:

https://banners.itunes.apple.com/bannerimages/banner.png?pr=itunes/../../&t=catalog_black&c=us&l=en-US&id=1527342866&w=300&h=250&store=books&cache=false

نتایج در تصویری از صفحه خطای AWS S3:

از اینجا ما این فرض را ایجاد کردیم که آنها از یک سرویس گیرنده مرورگر بدون هدر برای گرفتن اسکرین شات از فایل های HTML داخل یک سطل S3 استفاده می کنند. بنابراین گام بعدی ما ایجاد یک کتاب با <script src=””> در قسمت نام بود تا در فرآیند تولید تصویر شروع به بازی با XSS کنیم.

زمانی که لاگ درخواست عملیاتی از مرورگر وارد سرور ما شد، اولین چیزی بود که متوجه شدیم:

54.210.212.22 - - [21/Aug/2020:15:54:07 +0000] "GET /imgapple.js?_=1598025246686 HTTP/1.1" 404 3901 "http://apple-itunes-banner-builder-templates-html-stage.s3-website-us-east-1.amazonaws.com/itunes/catalog_white/index.html?pr=itunes&t=catalog_white&c=us&l=en-US&id=1528672619&w=300&h=250&store=books&cache=false" "Mozilla/5.0 (Unknown; Linux x86_64) AppleWebKit/538.1 (KHTML, like Gecko) PhantomJS/2.1.1 Safari/538.1"

این باکت یا تصویر S3 درخواست عملیاتی از مرورگر به سرور برای تولید تصویر بود:

http://apple-itunes-banner-builder-templates-html-stage.s3-website-us-east-1.amazonaws.com/itunes/catalog_white/index.html?pr=itunes&t=catalog_white&c=us&l=en-US&id=1528672619
&w=300&h=250&store=books&cache=false

و این هم عامل – کاربر است:

PhantomJS/2.1.1

خوشبختانه همکارما Brett  دقیقاً چند سال قبل از این مورد بهره برداری کرده بود:

Escalating XSS in PhantomJS Image Rendering to SSRF/Local-File Read https://t.co/PDwuM45QS7

— Brett Buerhaus (@bbuerhaus) June 29, 2017

اولین کار، نوشتن پی‌لود JS XSS برای انجام حملات جعل درخواست سمت سرور (SSRF) بود. یک روش خوب برای انجام این کار و ارائه داده ها با عنصر <iframe> است.

https://gist.github.com/ziot/ef5297cc1324b13a8fae706eeecc68a5

از آنجایی که ما متوجه وجود چنین حالتی در AWS هستیم، سعی می کنیم URI ابرداده AWS را طی درخواست عملیاتی از مرورگر به سرور منتقل کنیم:

https://banners.itunes.apple.com/bannerimages/banner.png?pr=itunes&t=catalog_black&c=us&l=en-US&id=1528672619%26cachebust=12345%26url=http://169.254.169.254/latest/meta-data/
identity-credentials/ec2/security-credentials/ec2-instance%26&w=800&h=800&store=books&cache=false

یک تصویر بنر جدید با کلیدهای مخفی کامل AWS برای نقش ec2 و iam ارائه شد:

به نظر می رسد بیشتر زیرساخت های جالب اپل در /8 IP CIDR این شرکت با نام “Applenet” قرار گرفته باشد، اما  در AWS ec2/S3 هم مقدار زیادی هاست و سرویس دارند. ما می‌دانستیم با بازخوانی‌ای که انجام دادیم، SSRF بسیار جالب نخواهد بود، زیرا بیشتر اهداف سازمانی به دربخور در Applenet هستند، نه AWS.

درکل، مهاجم با بهره برداری از این آسیب پذیری به موارد زیر میتوانست دسترسی داشته باشد…

  • خواندن محتوا از محیط وب سرویس آمازون داخلی اپل
  • دسترسی داشتن و استفاده از کلیدهای AWS ec2 افشا شده در صفحه فراداده داخلی

Heap Dump در Apple eSign به مهاجم اجازه می دهد تا ابزارهای مدیریت خارجی کارکنان خارجی را به خطر بیاندازد.

در طول مرحله ریکان اولیه و جمع‌آوری زیر دامنه‌ها و کشف سطح عمومی اپل، دسته‌ای از سرورهای «esign» را پیدا کردیم.

  • https://esign-app-prod.corp.apple.com/
  • https://esign-corpapp-prod.corp.apple.com/
  • https://esign-internal.apple.com
  • https://esign-service-prod.corp.apple.com
  • https://esign-signature-prod.corp.apple.com
  • https://esign-viewer-prod.corp.apple.com/
  • https://esign.apple.com/

پس از بارگیری زیر دامنه، بلافاصله به یک پوشه /viewer هدایت می شوید. هنگامی که از جریان احراز هویت Apple idmsa عبور می کنید، به خطای “شما مجاز به ورود نیستید” باز می گردد.

ما به هیچ پیوند یا فایل js جالب توجهی از این صفحه دسترسی نداشتیم، بنابراین فهرست‌های کلمات اساسی را امتحان کردیم تا ببینیم آیا می‌توانیم اندپوینتی از اپلیکیشن را پیدا کنیم یانه. از اینجا متوجه شدیم که /viewer/actuator به تمام اندپوینت‌های محرک از جمله نقشه برداری و heapdump پاسخ می دهد.

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

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

ما heapdump را بااستفاده از Eclipse Memory Analyzer بارگزاری کردیم و تمام رشته های خروجی را روی CSV ریختیم تا با grep آن را غربالگری کنیم.

از آنجا متوجه شدیم که کوکی احراز هویت برنامه “acack” است. داخل heapdump به دنبال گشتیم تاجاییکه یک کوکی session معتبر و مجاز پیدا کردیم. دراین مرحله مطمئن بودیم که این توکن متعلق به یکی از کارمندان اپل است و نه مشتری، درغیراینصورت از آن برای تست استفاده نمی‌کردیم. با بارگذاری آن، ما توانستیم به اپلیکیشن دسترسی پیدا کنیم.

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

این به ما امکان دسترسی به بیش از 50 اندپوینت اپلیکیشن را داد، از جمله برخی از اندپوینت‌های ادمین مانند “setProxy” که احتمالاً به راحتی به یک SSRF یا RCE داخلی تبدیل می شدند. همچنین متوجه این نکته شدیم که کوکی acack هویت ما را به آسانی در سایر اپلیکیشن ها هم تایید می‌کرد.

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

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

پردازش موجودیت خارجی XML به SSRFکور روی API مدیریت Java

درطول انجام تست، متوجه یک API با چندین تابع تایید نشده شدیم که بعد از کشف ” application.wadl” آشکارشده روی یکی از چند هاست 17.0.0.0/8، همگی ” application/xml ” را مصرف می‌کردند.

یک فایل application.wadl اندپوینت‌های استفاده شده توسط سرویس‌ها را مشخص می‌کند. این یک نمونه آزمایشی از سرویسی بود که به صورت طبیعی مسدود شده و غیر قابل دسترس است.

ما می‌توانیم از پی لود XSS کور برای نشان دادن SSRF کور استفاده کنیم.

متأسفانه، به دلیل نسخه جاوای استفاده شده در این دستگاه (به طور کامل وصله شده، از بارگذاری XXE کور 2 مرحله ای جلوگیری می کند) نتوانستیم به طور کامل از این برای خواندن فایل ها در این دستگاه یا دریافت پاسخ از SSRF استفاده کنیم. علاوه بر این، ما ساختار قالب XML مورد انتظار (جهت جلوگیری از یک سوء استفاده XXE غیر کور) را نمی دانستیم.

این آسیب‌پذیری جالب بود زیرا اپل به شدت به XML وابسته است و به نظر می‌رسد که نمونه‌های بیشتری از XXE با تعداد درخواست‌هایی که از آن استفاده کرده‌ایم پیدا کرده‌ایم. بهره‌برداری از این آسیب پذیری ابسیار هیجان‌نگیز بود، زیرا در مقایسه با همه روش‌های پیچیده‌ای که در طول زمان برای شناسایی آن تلاش کرده بودیم؛ دستیابی به XXE کور بسیار ساده بود.

اگر بخواهیم ازاین آسیب پذیری برای دستیابی به خواندن فایل محلی یا پاسخ کامل SSRF استفاده کنیم، احتمالاً از طریق یافتن قالب XML مناسب برای خود API به منظور انعکاس مستقیم محتویات فایل در مقابل دستیابی به استخراج کور خواهد بود.

درکل، مهاجم می توانست از این آسیب پذیری برای موارد زیر سواستفاده کنید…

  • آنچه را که اساساً کلیدهای اپلیکیشن‌های مختلف داخلی و خارجی کارمندان است به دست آورد
  • افشای اسرار مختلف (اطلاعات شناسایی کاربران پایگاه داده، اسرار OAuth، کلیدهای خصوصی) از اپلیکیشن های مختلف esign.apple.com

تزریق GBI Vertica SQL و GSF API درمعرض دید(Exposed)

تلاش‌های اولیه ما شامل گرفتن اسکرین شات از تمام دامنه‌ها و آدرس‌های IP متعلق به اپل بود که با یک بنر HTTP پاسخ می‌دادند. چند سرور پیدا کردیم که شبیه این بودند:

از اینجا شروع به سر و کله زدن با برخی از اپلیکیشن‌ها مانند “/depReports” کردیم. می‌توانیم آنها را احراز هویت کنیم و از طریق درخواست‌های API به یک API در مسیر “/gsf/” به برخی از داده‌ها دسترسی پیدا کنیم. همه اپلیکیشن‌هایی که در این هاست به آنها دسترسی پیدا کردیم، درخواست‌ها را از طریق آن سرویس GSF هدایت کردند.

درخواست به صورت زیر است:

POST /gsf/partShipment/businessareas/AppleCare/subjectareas/acservice/services/batch HTTP/1.1

Host: gbiportal-apps-external-msc.apple.com

{

    "executionType": "parallel",

    "requests": [{

        "queryName": "redacted",

        "filters": {

            "redacted_id": ["redacted"],

            "redacted": [""]

        }

    }, {

        "queryName": "redacted",

        "filters": {

            "redacted_id": ["redacted"],

            "redacted": [""],

            "redacted": [""],

            "redacted": [""],

            "redacted": [""],

            "redacted": [""],

            "redacted": ["service_notification_number"],

            "redacted": ["desc"]

        }

    }, {

        "queryName": "redacted",

        "filters": {

            "redacted_id": ["redacted"],

            "redacted": [""],

            "redacted": [""],

            "redacted": [""],

            "redacted": [""],

            "redacted": [""],

            "redacted": ["service_notification_number"],

            "redacted": ["desc"],

            "redacted": ["100"],

            "redacted": ["0"]

        }

    }]

}


تقریباً بلافاصله می توانید ببینید که برخی از شاخص های واقعاً قوی اینجا وجود دارد که با SQL در تعامل هستند. کلید واژه‌ها: کوئری، محدودیت، انحراف، نام ستون‌ها، فیلتر و … . با ایجاد یک تغییر کوچک برای دیدن اینکه چه اتفاقی می افتد، نتایج زیر را دریافت کردیم:

(به شدت ویرایش شده، خطای کوئری را که شامل نام ستون ها، نام جدول، نام پایگاه داده و غیره می شود را پوشش می دهد). قطعه مهم:

exception is java.sql.SQLException: java.sql.SQLSyntaxErrorException: [Vertica][VJDBC](4856) ERROR: Syntax error at or near \"adesc\""}]}]}

درنهایت روی کار تزریق به توافق رسیدیم. برخی از بخش‌های مهم عبارت بودند از «*/*/» اضافی در بسته شدن نظرات به دلیل انباشته شدن کوئری‌ها. همچنین مجبور شدیم از /**/ بین FROM و جدول استفاده کنیم ، چراکه vSQL دارای از برخی محافظت‌ها در برابر تزریق SQL استفاده می‌کند.

هچ vSQLMap ی وجود ندارد، بنابراین تلاش دستی زیادی برای تزریق کار انجام شد:

هنگامی که از آن استفاده کردیم، تصمیم گرفتیم برای سهولت کار آن را در اسکریپت بنویسیم. خلاصه ای از آن را در Github آپلود کردیم:

https://gist.github.com/ziot/3c079fb253f4e467212f2ee4ce6c33cb

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

https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/SQLReferenceManual/Functions/VerticaFunctions/s3export.htm

اگر با کلیدهای AWS پیکربندی شده باشد، می توانید از تزریق SQL برای بیرون کشیدن کلیدهای مخفی AWS از سرور استفاده کنید. در مورد ما، این تنظیمات برای AWS پیکربندی نشده بود، بنابراین ما قادر به انجام آن نبودیم.

دراین نقطه اطلاعات کافی برای گزارش تزریق SQL داشتیم. به محض اینکه متوجه شدیم امکان دارد ACL از این هاست برداشته شود و دیگر درمعرض دید عموم قرار نگیرد، تصمیم گرفتیم تا API “/gsf/” بیشتر بررسی کنیم.

به سرعت آشکار شد که GSF API به ماژول “GSF” دسترسی دارد که اطلاعات زیادی را در مورد ریزبرنامه‌های GSF در معرض دید قرار می‌دهد. این مورد دربرگیرنده برخی از اندپوینت‌های API برای کشیدن داده های خوشه (Cluster)، داده های اپلیکیشن و احتمالاً حتی استقرار خوشه ها و اپلیکیشن‌های های جدید است.

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

درکل، مهاجم می توانست از این آسیب پذیری برای موارد زیر سواستفاده کنید…

  • به احتمال زیاد اپلیکیشن‌های داخلی مختلف را از طریق پورتال GSF که به طور عمومی در معرض دید قرار می گیرد، به خطر بیاندازد
  • کوئری های دلخواه Vertica SQL را اجرا و اطلاعات پایگاه داده را استخراج کند.

آسیب‌پذیری های IDOR مختلف

در طول انجام تست روی اپل، ما انواع آسیب‌پذیری IDOR را کشف کردیم که بر قسمت های مختلف اپل تاثیرگذار بودند. اولین مورد در اپلیکیشن App Store Connect  یافت شد که برای مدیریت برنامه ها در اپ استور استفاده می شد.

اتصال به اپ استور (App Store Connect)

پس از ثبت نام در سرویس توسعه دهنده، اولین کاری که انجام دادیم کاوش برنامه App Store Connect بود که به توسعه دهندگان اجازه می داد اپلیکیشن‌های خود را که روی اپ استور داشتند یا قصد داشتند در اپ استور منتشر کنند را مدیریت کنند.

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

یک پارامتر “itemId” در URL ارسال می شد که یک مقدار عددی بود که تعیین می کرد کدام تنظیمات اپلیکیشن را تغییر می‌دهید. با تغییر عدد، می‌توانیم به لیدر-بورد هر برنامه دسترسی داشته باشیم و آن را تغییر دهیم. این به مهاجم اجازه می‌دهد تا تنظیمات مرکز بازی را به طور کامل از اپلیکیشن حذف یا دستکاری کند.

درکل، مهاجم می توانست از این آسیب پذیری برای موارد زیر سواستفاده کنید…

  • نمایش و تغییر ابرداده هر اپلیکیشنی روی اپ استور
  • تغییر داده های داخل صفحه اطلاعات مرکز بازی هر اپلیکیشن

IDOR در iCloud Find my Friends

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

اگر یکی از والدین یک حساب کاربری برای فرزند ایجاد یا اضافه کند، به محض ایجاد حساب کاربری فرعی به انجام اقدامات خاصی، مانند بررسی مکان دستگاه کودک، محدود کردن استفاده از دستگاه و مشاهده عکس‌ها و ویدیوهای ذخیره شده دسترسی خواهد داشت. مدیریت کاربر عمدتاً از طریق برنامه iOS انجام می‌شد که درآن‌صورت بدون پیدا کردن یک بای‌پس پین SSL نمی توانستیم آن را رهگیری کنید، بنابراین تصمیم گرفتیم به اپلیکیشن های دیگری مثل Find my Friends و Photos که توابع فرعی را برای روابط والد/فرزندی یکپارچه می‌کنند، نگاهی بیندازیم.

عملکردهای تحت « Find my Friends» وجود داشت که می‌توانید اعضای خانواده‌تان را انتخاب کنید، سپس روی «اشتراک‌گذاری موقعیت مکانی من (Share My Location)» کلیک کنید و از آنجایی که این یک رابطه قابل اعتماد بین اعضای خانواده بود، بلافاصله مکان خود را با اعضای خانواده به اشتراک بگذارید بدون اینکه آنها درخواست را بپذیرند و آنها این امکان را ندارند که موقعیتی که شما به اشتراک گذاشته اید را از اپلیکیشن خودشان پاک کنند. خوشبختانه برای ما، این درخواست HTTP برای انجام این عمل قابل رهگیری بود و می‌توانستیم ببینیم که استدلال‌های موجود چگونه به نظر می‌رسند.

پارامتر JSON ” dsIds ” به‌عنوان آرایه‌ای از IDهای کاربر برای اشتراک‌گذاری موقعیت مکانی شما استفاده شد. داخل پاسخ HTTP، ایمیل اعضای خانواده بازگردانده شد. من بیشتر جلو رفتم و این مقدار را به ID  کاربر دیگری تغییر دادم و در کمال تعجب ایمیل آنها را دریافت کردم.

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

درکل، مهاجم می توانست از این آسیب پذیری برای موارد زیر سواستفاده کنید…

  • هر آدرس ایمیل کاربر اپل را از طریق یک شناسه عددی افزایشی که به طور دائم به حساب آنها متصل است را بازیابی کنید.
  • حساب کاربری اپل مهاجم را با حساب قربانی مرتبط کنید تا مهاجم بتواند اعلان‌هایی برای آنها ارسال کند، موقعیت مکانی خود را در تلفن قربانی نشان دهد و از صفحه Find my Friends حذف نشود.

پشتیبانی از  IDOR

یکی از چالش‌برانگیزترین بخش‌های فهمیدن اینکه به چه چیزی نفوذ کرده‌اید، تفسیرترافیک HTTP iOS بود. اپلیکیشن ها و APIهای بسیار جالبی روی دستگاه واقعی وجود داشت، ولیکن بسیاری از دامنه‌های متعلق به اپل SSL pinned شده بودند و هیچ یک از ما سابقه کار با  تلفن همراه قوی و زمان قابل توجهی برای جدا کردن دستگاه‌های  iOS واقعی نداشتیم.

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

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

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

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

درکل، مهاجم می توانست از این آسیب پذیری برای موارد زیر سواستفاده کنید…

  • فراداده های مورد پشتیبانی مانند شماره سریال دستگاه و اطلاعات پشتیبانی برای همه موارد پشتیبانی اپل را فاش می کند

IDOR روی mfi.apple.com

اپلیکیشن دیگری که زمان زیادی روی آن صرف کردیم “mfi.apple.com” بود. این سرویس برای کارمندان شرکت هایی طراحی شده بود که لوازم جانبی الکترونیکی سوم‌شخص تولید می‌کنند که برای بازپس‌گیری اسناد و پشتیبانی از فرایند تولیدشان باید با آیفون ارتباط برقرار کنند.

پس از پرکردن اپلیکیشن، مشاهده کردیم که یک درخواست HTTP با یک پارامتر ID عددی به “getReview.action” ارسال شده است. جلوتر رفتیم و پارامتر را “منفی یک” کاهش دادیم و متوجه شدیم که با این کار می‌تاونیم به اپلیکیشن های سایر شرکت ها دسترسی داشته باشیم.

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

درکل، مهاجم می توانست از این آسیب پذیری برای موارد زیر سواستفاده کنید…

  • تمام اطلاعات حساب کاربری  را برای هر کسی که برای استفاده از پورتال MFi اپل درخواست داده است فاش کند

آسیب پذیری های XSS کور مختلف

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

  • دسترسی به session کارمندان داخل یک اپلیکیشن داخلی برای مدیریت اطلاعات آدرس نقشه های اپل
  • دسترسی به session کارمندان داخل یک اپلیکیشن داخلی برای مدیریت اطلاعات انتشار کتاب های اپل
  • دسترسی به session کارمندان داخل یک اپلیکیشن داخلی برای مدیریت تیکیت های پشتیبانی از مشتری و فروشگاه اپل

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

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

اسکرین شات هایی که در ادامه آمده است، پنل های ویرایش شده‌ای که ما قادر به استخراج آنها باااسکرین شات های HTML5 DOM hc از طریق XSS hunter شدیم را نمایش می‌دهد:

 

 

 

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

نتیجه گیری

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

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

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

نگارش این پست هم فرایند جالبی بود چراکه از انجام دادن آن زیاد مطمئن نبودیم. اگر بخواهم صادقانه بگویم، باتوجه به اطلاعات رندومی که آنجا بود، هرباگی که پیدا می‌کردیم به خودی خود این قابلیت را داشت که به یک رایت آپ کامل تبدیل شود. سیستم احراز هویتی که اپل از آن استفاده می‌کند بسیار پیچیده است، اینکه بخواهیم با 1 یا 2 جمله آن را توصیف کنیم، اینگونه به نظر می‌رسد که با اطلاعات غلط قصد فریب دادن مخاطب را داریم. درمورد عناصر زیرساخت اپل مثل iCloud، اپل استور و پلتفرم توسعه دهندگان هم نظر مشابهی داریم.

تاکنون تا تاریخ 8 اکتبر 2020، در ازای آسیب‌پذیری‌های مختلف 32 پرداخت به ارزش کلی 288.500$ دریافت کرده‌ایم.

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

برای انتشار این اطلاعات از تیم امنیتی اپل ([email protected]) اجازه گرفتیم و بنابه صلاحدید آنها این کار را انجام دادیم. تمام آسیب‌پذیری‌هایی که دراین پست افشا شده‌اند، رفع شده و دوباره مورد تست و بررسی قرار گرفته‌اند. لطفاً اطلاعات مربوط به امنیت اپل را بدون اجازه  این شرکت فاش نکنید.

منابع پشتیبانی

الحاقیه

از افراد زیر هم متشکر و قدردان هستم:

  • Kane Gamble
  • Nick Wright (@FaIIenGhouI) for the cover photo
  • Jack Cable
  • Dan Ritter
  • Nathanial Lattimer
  • Jasraj Bedi
  • Justin Rhinehart
  • تمام افراد شاغل در تیم امنیت محصولات اپل که به نسبت به گزارش های ما مسئولانه و با دقت رفتار می‌کردند

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *