چگونه دوباره فیس بوک را هک کردم! RCE تأیید نشده در MobileIron MDM
نسخه انگلیسی
中文 版本
سلام ، مدت طولانی از آخرین مقاله من گذشته است. این پست جدید در مورد تحقیقات من در ماه مارس است ، که در مورد چگونگی یافتن نقاط ضعف در یک محصول برجسته مدیریت دستگاه همراه است و محدودیت های زیادی را برای دستیابی به RCE غیرمجاز دور زده است. همه آسیب پذیری ها به فروشنده گزارش شده و در ژوئن رفع شده است. پس از آن ، ما شرکت های بزرگ را پیگیری کردیم تا پیشرفت کلی اصلاح را پیگیری کنیم و سپس دریافتیم که فیس بوک بیش از 2 هفته با پچ همگام نیست ، بنابراین ما پوسته ای را در فیس بوک ریختیم و به برنامه Bug Bounty آنها گزارش دادیم! [19659002] این تحقیق در HITCON 2020 نیز ارائه شده است. شما می توانید اسلایدها را در اینجا بررسی کنید
ما به عنوان یک تیم سرخ ، همیشه به دنبال مسیرهای جدید برای نفوذ به شبکه شرکت ها از خارج هستیم. درست مثل تحقیقات ما در Black Hat USA در سال گذشته ، ما نشان دادیم که چگونه می توان SSL VPN های پیشرو را هک کرد و به شبکه "عمومی" مجازی شما تبدیل شد! SSL VPN مطمئن است که امن است و تنها راه دسترسی به شبکه خصوصی شماست. اما ، اگر لوازم قابل اعتماد شما ناامن باشند چه می کنید؟
بر اساس این سناریو ، ما می خواهیم سطوح جدید حمله را بر روی امنیت شرکت جستجو کنیم و به MDM علاقه مند می شویم ، بنابراین این مقاله برای آن است!
مقاله چیست؟ MDM؟
مدیریت دستگاه موبایل ، همچنین به عنوان MDM شناخته می شود ، یک سیستم ارزیابی دارایی است که BYOD کارمندان را برای شرکت ها قابل کنترل تر می کند. در سال 2012 در پاسخ به افزایش تعداد تبلت ها و دستگاه های تلفن همراه پیشنهاد شد. MDM می تواند تضمین کند که دستگاه ها تحت سیاست شرکت و در یک محیط قابل اعتماد کار می کنند. Enterprise می تواند دارایی ها را مدیریت کند ، گواهینامه ها را نصب کند ، برنامه ها را مستقر کند و حتی دستگاه ها را از راه دور قفل / پاک کند تا از نشت داده جلوگیری کند. در زیر ما برای نشان دادن محصولات مشابه از MDM استفاده می کنیم!
هدف ما
MDM ، به عنوان یک سیستم متمرکز ، می تواند همه دستگاه های کارمندان را مدیریت و کنترل کند. این بدون شک یک سیستم ارزیابی دارایی ایده آل برای یک شرکت در حال رشد است. علاوه بر این ، MDM برای همگام سازی دستگاه ها در سراسر جهان باید به صورت عمومی قابل دسترسی باشد. یک وسیله متمرکز و افشاگر عمومی ، چه چیزی برای هکرها جذابیت بیشتری دارد؟
بنابراین ، ما این سالها شاهد سوers استفاده هکرها و گروههای APT از MDM بوده ایم! مانند قربانیان فیشینگ برای ایجاد MDM به یک سرور C&C از دستگاه های تلفن همراه خود ، یا حتی به خطر انداختن سرور MDM در معرض شرکت برای فشار دادن تروجان های مخرب به همه دستگاه ها. می توانید گزارش Malicious MDM را مطالعه کنید: بیایید این برنامه را توسط تیم Cisco Talos پنهان کنیم و اولین بار در طبیعت دیده می شود – بدافزار برای جزئیات بیشتر از MDM شرکتی به عنوان بردار حمله توسط تیم CheckPoint CPR استفاده می کند!
از موارد قبلی ، ما می دانیم که MDM یک هدف خوب برای هکرها ، و ما می خواهیم در مورد آن تحقیق کنیم. چندین راه حل MDM وجود دارد ، حتی شرکت های مشهوری مانند Microsoft ، IBM و Apple نیز راه حل MDM خود را دارند.
ما راه حل های شناخته شده MDM را لیست کرده و الگوهای مربوطه را در سراسر اینترنت اسکن کرده ایم. ما دریافتیم که رایج ترین MDM ها VMware AirWatch و MobileIron هستند!
بنابراین ، چرا ما MobileIron را به عنوان هدف خود انتخاب کردیم؟ طبق وب سایت رسمی آنها ، بیش از 20،000 شرکت MobileIron را به عنوان راه حل MDM خود انتخاب کرده اند و بیشتر مشتریان ما نیز از آن استفاده می کنند. ما همچنین می دانیم که فیس بوک از سال 2016 سرور MobileIron را در معرض دید قرار داده است. ما Fortune Global 500 را نیز مورد تجزیه و تحلیل قرار داده ایم و بیش از 15٪ را با استفاده و در معرض دید قرار دادن سرور MobileIron خود در بر داشتیم! به همین دلایل ، هدف اصلی ما شد!
از کجا شروع کنیم
از آسیب پذیری های گذشته ، ما فهمیدیم که تعداد زیادی از محققان غواصی در MobileIron وجود ندارد. شاید بردار حمله هنوز ناشناخته باشد. اما گمان می کنیم دلیل اصلی این سخت افزار برای به دست آوردن سخت افزار باشد. هنگام تحقیق در مورد دستگاه ، تبدیل یک تست BlackBox خالص به GrayBox یا آزمایش WhiteBox بسیار حیاتی است. ما زمان زیادی را برای جستجوی انواع اطلاعات در اینترنت صرف کردیم و در پایان با یک بسته RPM مواجه شدیم. این پرونده RPM قرار است بسته آزمایشی برنامه نویس باشد. این پرونده فقط روی یک WebRoot قابل فهرست نشسته و توسط جستجوی Google نمایه سازی شده است.
به هر حال ، پرونده ای برای تحقیق در اختیار ما قرار گرفت. تاریخ انتشار پرونده در اوایل سال 2018 است. به نظر می رسد کمی قدیمی است اما هنوز هم از هیچ چیز بهتر است!
P.S. ما به MobileIron اطلاع داده ایم و پرونده های حساس اکنون حذف شده است.
یافتن آسیب پذیری ها
پس از یک زمان دردناک برای حل جهنم وابستگی ، سرانجام بسته آزمایش را تنظیم کردیم. این م onلفه مبتنی بر جاوا است و سه پورت در معرض آن قرار دارد: رمزگذاری شده در TLS. Apache در جلوی قسمت وب قرار دارد و تمام اتصالات را برای پشتیبانی از پراکسی می کند ، یک Tomcat با Spring MVC در داخل.
به دلیل Spring MVC ، یافتن آسیب پذیری های سنتی مانند SQL Injection یا XSS از یک نمای واحد بنابراین ، این بار بررسی منطق و معماری هدف ماست!
در مورد آسیب پذیری صحبت می کنیم ، دلیل اصلی آن ساده است. تامکت یک وب سرویس را آشکار کرد که ورودی کاربر را با فرمت Hessian حذف می کند. با این حال ، این بدان معنا نیست که ما می توانیم همه کارها را انجام دهیم! تلاش اصلی این مقاله حل این مسئله است ، بنابراین لطفاً بهره برداری زیر را مشاهده کنید.
اگرچه می دانیم که سرویس وب ورودی کاربر را بی نیاز می کند ، اما نمی توانیم آن را فعال کنیم. نقطه پایانی در هر دو قرار دارد:
- رابط ثبت نام کاربر –
https: // mobileiron / mifs / services / - رابط مدیریت –
https: // mobileiron: 8443 / mics / services /
ما فقط می توانیم از طریق رابط مدیریت ، محرومیت زدایی را لمس کنیم زیرا رابط کاربر دسترسی به وب سرویس را مسدود می کند. این یک ضربه مهم برای ما است زیرا اکثر شرکت ها رابط مدیریتی خود را در معرض اینترنت قرار نمی دهند و آسیب پذیری فقط مدیریتی برای ما مفید نیست بنابراین ما باید تلاش بیشتری کنیم. : (
با بررسی دقیق معماری ، متوجه شدیم که Apache از طریق Rewrite Rules دسترسی ما را مسدود می کند. خوب به نظر می رسد ، درست است؟
RewriteRule ^ / mifs / services /(.*)$ https: //٪ {SERVER_NAME }: 8443 / mifs / services / $ 1 [R=307,L]
RewriteRule ^ / mifs / services [F]
MobileIron برای جلوگیری از دسترسی به وب سرویس به قوانین بازنویسی Apache متکی بود. این در مقابل معماری پروکسی معکوس است ، و backend یک وب سرور مبتنی بر جاوا است.
آیا چیزی به خاطر آورده اید؟
بله ، Breaking Parser Logic! این سطح حمله پروکسی معکوس است که من در سال 2015 پیشنهاد کردم و در Black Hat USA 2018 ارائه شد. این روش از ناسازگاری بین Apache و Tomcat برای دور زدن کنترل ACL و دسترسی مجدد به سرویس وب استفاده کنید. BTW ، این روش عالی همچنین در مورد آسیب پذیری اخیر F5 BIG-IP TMUI RCE نیز اعمال می شود!
https: // mobileiron / mifs /. ؛ / services / someService
بهره برداری از آسیب پذیری ها
بسیار خوب ، اکنون هر کجا که باشد در رابط ثبت نام یا رابط مدیریت ، می توانیم به محرومیت زدایی دسترسی پیدا کنیم. بیایید به بهره برداری ها برگردیم!
موریتس بچلر یک تحقیق عالی دارد که خلاصه آسیب پذیری هسیان را در مقاله سفید خود ، Java Unmarshaller Security خلاصه می کند. از کد منبع marshalsec ، می فهمیم که deserialization هسی باعث ایجاد hashcode () و hashcode () هنگام بازسازی HashMap همچنین می تواند را به [String() از طریق XString تحریک کند ، و ابزارهای شناخته شده تاکنون عبارتند از: ] ROME EqualsBean / ToStringBean
در محیط خود ، ما فقط می توانستیم زنجیره ابزار Spring AOP را ایجاد کرده و یک تزریق JNDI دریافت کنیم.
| نام | اثر | |||||
|---|---|---|---|---|---|---|
| x | Apache XBean | JNDI Injection | ||||
| x | رزین كوچو | JNDI تزریق | ] | ] | Spring AOP | JNDI Injection |
| x | ROM EqualsBean | RCE |
هنگامی كه تزریق JNDI انجام دهیم ، بقیه قسمت های بهره برداری آسان است! ما فقط می توانیم از Alvaro Muñoz و Oleksandr Mirosh کار ، یک سفر از JNDI / LDAP به Remote Code Execution Dream Land ، از Black Hat USA 2016 استفاده کنیم تا کد را اجرا کنیم … درست است؟
از زمان Alvaro Muñoz و Oleksandr Mirosh این مورد را روی Black Hat معرفی كردند ، می توان گفت كه این روش به تعداد بیشماری از محققان امنیتی كمك می كند و از بین بردن جاوا برای شما مفید است. آسیب پذیری در دوره جدید. با این حال ، جاوا سرانجام آخرین پازل JNDI / LDAP را در اکتبر 2018 کاهش داد. پس از آن ، همه نسخه های جاوا بالاتر از 8u181 ، 7u191 و 6u201 دیگر نمی توانند کد را از طریق بارگیری کلاس URL از راه دور JNDI دریافت کنند. بنابراین ، اگر ما در جدیدترین MobileIron از محرومیت زدایی از هسی استفاده کنیم ، باید با این مشکل روبرو شویم!
جاوا مقدار پیش فرض com.sun.jndi.ldap.object.trustURLCodebase را به تغییر داد برای جلوگیری از بارگیری مهاجم از راه دور کلاس URL برای دریافت کد اعدام. اما فقط این منع شده است. ما هنوز هم می توانیم JNDI را دستکاری کرده و مرجع نامگذاری را به یک کلاس محلی جاوا هدایت کنیم!
این مفهوم کمی شبیه به برنامه نویسی بازگشت گرا است و با استفاده از کلاس جاوا محلی موجود برای بهره برداری بیشتر. برای جزئیات بیشتر می توانید به مقاله بهره برداری از تزریق JNDI در جاوا توسط Michael Stepankin در اوایل سال 2019 مراجعه کنید. این حمله به بهره برداری های POST-JNDI و نحوه سو abuse استفاده از Tomcat's BeanFactory برای پر کردن ابزار ELProcessor برای اجرای کد را توصیف می کند. بر اساس این مفهوم ، محقق ولکین همچنین ابزار دیگری ParseClass را در Groovy ارائه می دهد. همانطور که در مقاله (چینی) وی شرح داده شده است:
除了 javax.el.EL پردازنده ， 当然 也 很多 其他 的 类 符合 条件 可以 作为 beanClass 注入 an BeanFactory 机器 利用 利用 举 个 ， 如果 目标 机器 طبقه کلاس之前 库 则 可以 结合 之前 نارنجی 师傅 发 过 en جنکینز 的 漏洞 实现 利用
به نظر می رسد بهره برداری از برنامه نویسی متا در تحقیقات قبلی من در مورد جنکینز نیز می تواند در اینجا مورد استفاده قرار گیرد. این برنامه Meta Programming را دوباره عالی می کند: D
این روش فوق العاده است و برای ما عملی به نظر می رسد. اما هر دو ابزار ELProcessor و ParseClass به دلیل قدیمی بودن کتابخانه های هدف ما در دسترس نیستند. تامکت [8] از 8.5 ELProcessor را معرفی کرد اما هدف ما 7 است. در مورد گرووی Groovy ، نسخه Groovy مورد نظر برای پشتیبانی از برنامه نویسی Meta بسیار قدیمی است (1.5.6 از سال 2008) ، بنابراین ما هنوز مجبور هستیم یک ابزار جدید توسط خودمان پیدا کنیم. در پایان یک ابزار جدید در GroovyShell پیدا کردیم. اگر علاقه مند هستید ، می توانید درخواست Pull را که من برای پروژه JNDI-Injection-Bypass ارسال کردم بررسی کنید! GroovyShell . زمان هک کردن فیس بوک است!
پیش گفته ، ما می دانستیم که فیس بوک از MobileIron از سال 2016 استفاده می کند. اگرچه پاسخ های ایندکس سرور 403 اکنون ممنوع است ، اما سرویس وب همچنان قابل دسترسی است! برای بهره برداری ما! با این حال ، چند روز قبل از حمله برنامه ریزی شده ، متوجه شدیم که یک مشکل اساسی در بهره برداری ما وجود دارد. از آخرین باری که در فیس بوک ظاهر شد ، متوجه شدیم که به دلیل نگرانی های امنیتی ، ارتباطات خروجی را مسدود می کند. اتصال خروجی برای JNDI Injection امری حیاتی است زیرا هدف این است که قربانیان را برای انجام سو further استفاده های بعدی به یک سرور مخرب متصل کنند. اما اکنون ، ما حتی نمی توانیم یک ارتباط خروجی برقرار کنیم ، نیازی به ذکر دیگران نیست.
تا کنون ، تمام سطوح حمله به تزریق JNDI بسته شده است ، ما چاره ای نداریم جز بازگشت به محروم سازی هسی. . اما به دلیل کمبود اسبابک های موجود ، باید مورد جدیدی را خودمان کشف کنیم!
قبل از کشف یک گجت جدید ، باید علت اصلی اسباب های موجود را به درستی درک کنیم. بعد از خواندن مجدد مقاله موریتس بچلر ، یک کلمه خاص من را علاقه مند کرد:
نمی توان روش Groovy's MethodClosure را بازیابی کرد همانطور که readResolve () خوانده می شود که یک استثنا را ایجاد می کند.
یک سوال به سرعت در ذهن من ایجاد شد: چرا نویسنده این مقاله را ترک کرده است اینجا کلمه؟ اگرچه به استثناها شکست خورده است ، اما باید چیز خاصی وجود داشته باشد تا نویسنده این مطلب را بنویسد.
هدف ما با یک گرووی بسیار قدیمی در حال اجرا است ، بنابراین ما حدس می زنیم که ممکن است محدودیت readResolve () هنوز به پایگاه کد اعمال نشده است! ما پرونده groovy / runtime / MethodClosure.java را بین آخرین و 1.5.6 مقایسه کردیم.
$ diff 1_5 _6 / بسته شدن روش [19659081]. java 3_0 _4 / روش بسته شدن . java
> خصوصی شی () {
> اگر ( ALLOW_RESOLVE ] {
> بازگشت
]
}
> پرتاب جدید UnsupportedOperationException ()؛
> }
بله ، حق با ماست. ALLOW_RESOLVE در Groovy 1.5.6 وجود ندارد و بعداً فهمیدیم كه CVE-2015-3253 فقط برای این منظور است. این یک تخفیف برای افزایش آسیب پذیری مایکروسافت جاوا در سال 2015 است. از آنجا که Groovy یک کتابخانه داخلی است ، اگر موارد اضطراری وجود نداشته باشد ، توسعه دهندگان آن را به روز نمی کنند. Groovy منسوخ شده همچنین می تواند یک مطالعه موردی خوب باشد تا نشان دهد چگونه یک جز بی ضرر می تواند شما را در معرض خطر قرار دهد!
البته سرانجام ما این پوسته را در فیس بوک گرفتیم. این ویدیو است:
گزارش آسیب پذیری و پچ
ما تمام تحقیقات را در ماه مارس انجام داده ایم و مشاوره را در 3/4 به MobileIron ارسال کرده ایم. MobileIron وصله را در 15/6 منتشر کرد و برای این امر به سه CVE پرداخت.
- CVE-2020-15505 – اجرای کد از راه دور
- CVE-2020-15506 – احراز هویت احراز هویت
- CVE-2020-15507 – خواندن خودسرانه پرونده
پس از وصله ، می توانید وب سایت رسمی را بررسی کنید! منتشر شده است ، ما نظارت بر اینترنت را برای پیگیری پیشرفت کلی اصلاح شروع می کنیم. در اینجا ما سربرگ آخرین اصلاح شده را در پرونده های استاتیک بررسی می کنیم تا نتیجه فقط برای اطلاعات شما باشد. (ناشناخته مخفف سرور است که هر دو پورت 443 و 8443 را بسته است)
در همان زمان ، توجهات خود را در فیس بوک نیز حفظ می کنیم. با تأیید 15 روز بدون وصله ، ما سرانجام پوسته ای ایجاد کردیم و در 7/2 به برنامه Bug Bounty آنها گزارش دادیم!
نتیجه گیری
تاکنون ، ما یک RCE کاملاً غیرمجاز در MobileIron نشان داده ایم. از نحوه دریافت سیستم عامل ، یافتن آسیب پذیری و دور زدن کاهش JNDI و محدودیت شبکه. داستان های دیگری نیز وجود دارد ، اما با توجه به گذشت زمان ، ما در اینجا موضوعاتی را برای علاقمندان ذکر کرده ایم: 2020-15506 ، یک بای پس احراز هویت جالب
امیدوارم که این مقاله بتواند توجه را به MDM و اهمیت امنیت شرکت جلب کند! با تشکر از شما برای خواندن : D
.
ببینید که چگونه من دوباره به فیس بوک نفوذ کردم ، یک آسیب پذیری اجرای کد از راه دور در MobileIron MDM!
نسخه انگلیسی
نسخه چینی
سلام! مدتهاست که نمی بینم ، این تحقیق من در ابتدای سال جاری است ، که می گوید چگونه می توان آسیب پذیری های یک محصول معروف مدیریت دستگاه تلفن همراه را پیدا کرد و لایه های محافظت را برای دستیابی به برنامه های از راه دور دور کرد داستان اجرای کد! پس از گزارش این آسیب پذیری ، پچ رسمی در ماه ژوئن منتشر شد و به مشتریان آنها فورا اطلاع داده شد. ما همچنین دریافتیم که 15 روز پس از انتشار پچ ، فیس بوک به موقع به روز نشده است ، بنابراین ما سرور را از طریق این آسیب پذیری به دست آوردیم گزارش آن را به فیس بوک گزارش دهید!
این تحقیق در HITCON 2020 نیز منتشر شده است و شما می توانید یک نمایش اسلایدی از این سخنرانی را در اینجا دریافت کنید!
ما به عنوان یک تیم قرمز حرفه ای ، همیشه به دنبال یک سریع تر هستیم بهترین راه برای ورود به اینترانت شرکتی از خارج! مانند تحقیق ما که سال گذشته در Black Hat USA منتشر شد ، SSL VPN البته در شبکه خارجی قرار می گیرد و به زیرساختی تبدیل می شود که از امنیت شبکه محافظت می کند و به کارمندان اجازه می دهد به شبکه داخلی دسترسی پیدا کنند. تجهیزات مورد اعتماد شما و مورد استفاده برای محافظت از امنیت شما دیگر ایمن نیستند ، چه کاری باید انجام دهید؟
از این طریق ، ما به دنبال آسیب پذیری های جدید شبکه های شرکتی هستیم که می تواند به عنوان حملات تیم قرمز ما محسوب شود. با نفوذ به نقطه ورود اولیه شرکت ، در طی مراحل تحقیق به MDM / UEM علاقه مند شدیم ، و این مقاله نتیجه تحقیق ایجاد شده از آن زمان است!
MDM / UEM چیست؟
مدیریت دستگاه تلفن همراه ، در حدود سال 2012 ، هنگامی که تلفن های همراه شخصی و دستگاه های رایانه لوحی شروع به ظهور می کنند ، به اختصار MDM نامیده می شود ، برای اینکه شرکت ها بتوانند دستگاه های BYOD کارمندان را بهتر مدیریت کنند ، سیستم موجودی دارایی ایجاد شد. شرکت ها می توانند از محصولات MDM برای مدیریت دستگاه های تلفن همراه کارمندان استفاده کنند. اطمینان حاصل کنید که دستگاه فقط تحت یک محیط و خط مشی قابل اعتماد اجرا می شود. شما همچنین می توانید برنامه ها را نصب کنید ، گواهینامه ها را نصب کنید و حتی از راه دور دارایی های شرکت را از سرور نقطه پایانی مرکزی برای تلفن همراه کنترل شده کنترل کنید تا دارایی های شرکت را مدیریت کند. همچنین می تواند در هنگام گم شدن دستگاه مورد استفاده قرار گیرد. برای دستیابی به حریم خصوصی شرکت و بدون نشت ، از MDM برای قفل کردن یا پاک کردن کل داده های دستگاه از راه دور استفاده کنید!
UEM (مدیریت نقطه پایان یکپارچه) اصطلاحی است که در سال های اخیر به روز شده است و هسته اصلی آن همه دستگاه های تلفن همراه است مدیریت ، اما اصطلاح UEM شامل تعریف وسیع تری از دستگاه است! ما در زیر از اصطلاح MDM برای اشاره به محصولات مشابه استفاده خواهیم کرد.
هدف ما
به عنوان یک سیستم کنترل نقطه پایانی متمرکز ، MDM می تواند تمام وسایل شخصی کارمندان خود را کنترل و مدیریت کند! این قطعاً بهترین محصول موجودی دارایی برای شرکت های در حال رشد است. بله ، این نیز برای هکرها است! برای مدیریت اتصال دستگاه های کارمند از سراسر جهان ، MDM مجبور است در معرض اینترنت قرار گیرد. دستگاهی که می تواند "دستگاه های کارمند را مدیریت کند" و "آن را در شبکه خارجی قرار دهد" بدون شک بهترین کانال نفوذ برای تمرینات تیم قرمز ما است!
علاوه بر این ، یافتن MDM از روندهای امنیتی در سال های اخیر کار دشواری نیست. به تدریج به هدف ترجیحی هکرها و سازمان های APT تبدیل شوید! قربانیان را وادار کنید که با MDM مخرب موافقت کنند تا به سرور C&C دستگاه شما تبدیل شوند ، یا به سادگی به تجهیزات MDM این شرکت در شبکه خارجی حمله کرده و اسب های تروای دستگاه همراه را برای آلوده کردن همه شرکت ها به صورت دسته ای ارسال کنند. تلفن های همراه و رایانه های کارمندان برای دستیابی به حملات بیشتر! اینها به حقیقت تبدیل شده اند. برای گزارش های دقیق ، به MDM مخرب مراجعه کنید: بیایید این برنامه را که توسط تیم Cisco Talos منتشر شده پنهان کنیم و برای اولین بار در بدافزارهای وحشی منتشر شده توسط تیم CheckPoint CPR مشاهده شود. MDM شرکتی به عنوان بردار حمله!
از موارد قبلی ، ما دریافتیم که MDM نقطه خوبی برای امنیت شرکت است ، بنابراین ما شروع به مطالعه سطح حمله مرتبط کردیم! و فروشندگان MDM زیادی در بازار وجود دارد ، تولید کنندگان عمده مختلفی از جمله مایکروسافت ، IBM و حتی اپل محصولات MDM خود را راه اندازی کرده اند. برای شروع تحقیقات خود کدام یک را انتخاب کنیم؟
بنابراین ، ما از طریق اطلاعات عمومی محصولات MDM رایج را در بازار لیست کردیم و با هر یک همکاری کردیم Home Feature در همه جای دنیا اسکن انجام داد و دریافت که MDM بیشتر مورد استفاده شرکت ها VMware AirWatch و MobileIron است! در مورد اینکه کدام یک را مطالعه کنیم؟ ما مورد دوم را انتخاب کردیم ، با این تفاوت که بیشتر مشتریان از MobileIron استفاده می کنند علاوه بر این ، یکی دیگر از مواردی که من را به خود جلب می کند این است که فیس بوک مشتری آنها نیز هست! از تحقیقات How I Hacking Facebook، and Found Someone's Backdoor Script که در سال 2016 منتشر کردیم ، دریافتیم که Facebook از MobileIron به عنوان راه حل MDM خود استفاده می کند! [19659002] طبق شرح وب سایت رسمی MobileIron ، حداقل 20000 شرکت بیش از MobileIron را به عنوان محلول MDM خود استفاده می کنند. طبق اسکن های واقعی ما در جهان ، حداقل 15٪ از شرکتهای Fortune 500 از MobileIron و در معرض اینترنت (در واقع باید موارد بیشتری وجود داشته باشد) ، بنابراین ، یافتن آسیب پذیری MobileIron به هدف اصلی ما تبدیل شده است! [19659015] نحوه شروع تحقیق
از آسیب پذیری هایی که در گذشته ظاهر شده است ، می توان فهمید که MobileIron توسط تعداد زیادی از پرسنل امنیتی مورد مطالعه قرار نگرفته است. دلیل این امر این است که بردار حمله MDM به طور گسترده ای شناخته نشده است و دلیل دیگر این است که سیستم عامل مربوط به MobileIron بسیار بزرگ است. به سختی می توان به دست آورد ، بزرگترین مشکل در مورد تحقیق در مورد دستگاه این است که چگونه از یک جعبه سیاه خالص به یک جعبه خاکستری قابل تجزیه و تحلیل یا حتی یک جعبه سفید برویم! از آنجا که نمی توان سیستم عامل را از وب سایت رسمی بارگیری کرد ، چندین روز صرف کلمات کلیدی مختلف در اینترنت کردیم در جستجوی اطلاعات عمومی موجود ، سرانجام در دایرکتوری ریشه یکی از وب سایت های عمومی نمایه شده توسط جستجوی Google یافت شد که این یک بسته RPM مشکوک است که توسط توسعه دهنده برای آزمایش استفاده شده است.
سیستم عامل بارگیری شده نسخه در ابتدای سال 2018 است. مدت زیادی از اکنون گذشته است. شاید کد اصلی نیز بسیار تغییر کرده باشد ، اما بهتر از هیچ چیز است ، بنابراین ما از این شروع می کنیم بایگانی ها شروع به مطالعه کردند.
اظهارات: وب سایت توسعه دهنده پس از اطلاع مقام رسمی MobileIron بسته شده است.
نحوه یافتن آسیب پذیری ها
کل MobileIron از جاوا به عنوان زبان اصلی توسعه استفاده می کند و درگاه های باز 443 ، 8443 ، 9997 هستند و عملکردهای مربوط به هر درگاه به شرح زیر است:
- 443 رابط ثبت دستگاه کاربر است
- 8443 رابط مدیریت دستگاه است
- 9997 یک پروتکل هماهنگ سازی دستگاه اختصاصی MobileIron است (پروتکل MI)
هر سه پورت از TLS برای محافظت از امنیت و یکپارچگی اتصال استفاده می کنند و قسمت وب از طریق Proxy Reverse Apache است این معماری اتصال را به قسمت عقب هدایت می کند ، که توسط برنامه وب مستقر شده توسط Tomcat اداره می شود و برنامه وب توسط Spring MVC توسعه یافته است.
به دلیل معماری فنی نسبتاً جدیدی كه به كار رفته است ، یافتن انواع سنتی آسیب پذیری مانند SQL Injection نیز از یك نقطه دشوارتر است. بنابراین ، شناخت منطق برنامه و همكاری با حملات سطح معماری این بار جستجوی آسیب پذیری ما شده است. هدف اصلی این زمان!
این آسیب پذیری نیز بسیار ساده است ، عمدتاً به این دلیل که وب سرویس از فرمت Hessian برای پردازش داده ها استفاده می کند و بنابراین از ضعف زدایی زدایی برخوردار است! اگرچه این آسیب پذیری را می توان با یک جمله توضیح داد ، اما کسانی که آن را می فهمند می دانند که چگونه سیستم مورد نیاز را حذف کنند این بدان معنا نیست که شما می توانید هر کاری انجام دهید ، استفاده بعدی مکان فوق العاده است!
اکنون مشخص شده است که MobileIron در پردازش وب سرویس دارای یک آسیب پذیری حذف هسی از نوع هسی است! اما وجود این آسیب پذیری به این معنی نیست که ما با این آسیب پذیری روبرو شده ایم مسیرهایی که می توانند محرومیت زدایی از هسی را تحریک کنند عبارتند از:
- رابط کاربر عمومی –
https: // mobileiron / mifs / services / - رابط مدیریت –
https: // mobileiron : 8443 / mifs / services /
رابط مدیریت در واقع مسدود نشده است ، شما می توانید به راحتی به وب سرویس دسترسی پیدا کنید ، در حالی که دسترسی به رابط کاربری عمومی وب سرویس امکان پذیر نیست ، که برای ما کشنده است یک حمله جنسی. از آنجا که بیشتر معماری شبکه سازمانی پورت رابط مدیریت را به شبکه خارجی باز نمی کند ، حمله به رابط مدیریت بسیار مفید نیست ، بنابراین ما باید راه های دیگری برای ایجاد این روزنه!
با دقت روش مسدودسازی MobileIron را مشاهده کنید و دریافت که با استفاده از قوانین بازنویسی در Apache از دسترسی به رابط کاربری عمومی وب سرویس:
RewriteRule ^ / mifs / services / ( . *) $ https: //٪ {SERVER_NAME}: 8443 / mifs / services / $ 1 [R=307,L]
RewriteRule ^ / mifs / services [F]
خوب ، عالی! از معماری Reverse Proxy استفاده کنید و در لایه جلویی است آیا مسدود می کنید ، آیا به چیزی فکر می کنید؟
درست است! این در سال 2015 کشف شد و در Black Hat USA 2018 منتشر شد جدول سطح حمله جدید برای معماری Reverse Proxy ، Breaking Parser Logic! این روش عالی اخیراً در اجرای کد از راه دور CVE-2020-5902، F5 BIG-IP TMUI نیز استفاده شده است!
از طریق Apache با درک تامکت از مسیرها متناقض است ، ما می توانیم قانون بازنویسی را دور بزنیم و با استفاده از روش های زیر دوباره به وب سرویس حمله کنیم!
https: // mobileiron / mifs /.؛ / services / someService
لمس! بنابراین حالا چه رابط مدیریت 8443 باشد یا رابط کاربری عمومی 443 ، همه ما می توانیم با رفع نیاز به هسی به وب سرویس برخورد کنیم!
نحوه استفاده از این آسیب پذیری
حال بیایید برگردیم برای استفاده از شیرین سازی هسیان! برای رفع خلع سلاح هسی ، موریتس بچلر گزارش امنیتی بسیار مفصلی را در Java Unmarshaller Security خود تهیه کرده است! از منبع منبع باز marshalsec ، ما همچنین فهمیدیم که هسیان معکوس است علاوه بر راه اندازی hashcode () و hashcode () از طریق HashMap در طی فرآیند سریال سازی ، می توانید از XString برای رشته toString () استفاده کنید ، و در حال حاضر چهار زنجیره استفاده برای شیرین سازی هسی وجود دارد: فقط AOP بهاره قابل تحریک است!
| نام | اثر | |
|---|---|---|
| x | Apache XBean | تزریق JNDI |
| x | رزین كوچو | JNDI تزریق |
| √ | Spring AOP | تزریق JNDI |
| x | ROME برابر 19659050] 19199090] چگونه ، پس از تزریق JNDI ، فقط باید از Alvaro Muñoz و Oleksandr Mirosh عبور کنیم سفری از JNDI / LDAP به اجرای کد از راه دور Dream Land که در Black Hat USA 2016 منتشر شده است می تواند اجرای کد از راه دور را بدست آورد … Gan Anai؟
از Alvaro Muñoz و Oleksandr Mirosh بعد از اینکه Black Hat این ناقل حمله جدید را منتشر کرد ، من نمی دانم که به چه تعداد هکر بزرگ و کوچک به آنها کمک کرده است. برخی حتی فکر می کنند که "اگر با لغو رفع مشکل مواجه شدید ، برای ارسال از JNDI استفاده کنید درست است! "اما از اکتبر 2018 ، جاوا سرانجام آخرین قطعه تزریق JNDI را برطرف کرد. این رفع در CVE-2018-3149 ثبت شده است. از آن زمان ، همه جاوا بالاتر از 8u181 ، 7u191 ، نسخه 6u201 نمی تواند کد را از طریق JNDI / LDAP اجرا کند ، بنابراین اگر می خواهیم حمله به آخرین نسخه MobileIron را اجرا کنیم ، حتماً با این مشکل روبرو خواهیم شد! در مورد CVE-2018-3149 ، این از طریق [19459020مقدارپیشفرض] com.sun.jndi.ldap.object.trustURLCodebase به خوشبختانه ، ما همچنان می توانیم از مرجع نامگذاری JNDI به كارخانه Class موجود این دستگاه استفاده كنیم! از طریق مفهومی مشابه برنامه نویسی بازگشت گرا ، می توانیم كلاس های موجود در classPath این دستگاه را برای استفاده بیشتر پیدا كنیم. برای جزئیات ، لطفاً به Exploiting JNDI Injections in Java منتشر شده توسط Michael Stepankin در آغاز سال 2019 مراجعه كنید ، كه به طور مفصل نحوه بارگیری به نظر می رسد این جاده صاف است ، اما در واقع کمی بدتر است. از آنجا که
استفاده کنید. ClassPath هدف فقط Groovy را دارد! بنابراین ما برنامه نویسی Meta را دوباره عالی کردیم: D با این حال ، در واقع ، نسخه Groovy در سرور هدف 1.5.6 است ، نسخه ای که برای پشتیبانی از برنامه نویسی Meta ده سال پیش خیلی قدیمی است ، بنابراین ما سرانجام یک نسخه را بر اساس کد Groovy پیدا کردیم زنجیره بهره برداری در آماده شد ، فقط مدیون باد! فقط چند روز قبل از این که قصد حمله به فیس بوک را داشته باشیم ، ناگهان فکر کردیم که از آخرین باری که وارد سرور فیس بوک شدیم ، به دلیل ملاحظات امنیتی ، به نظر می رسد فیس بوک تمام ارتباطات غیرقانونی با خارج را ممنوع می کند. این درست است. حمله تزریق JNDI ما تأثیر مهمی دارد! اول از همه ، هسته اصلی تزریق JNDI اتصال به یک سرور مخرب است که توسط مهاجم از طریق قربانی کنترل می شود و یک سری سو explo استفاده های ناشی از مرجع نامگذاری مخرب را دریافت می کند. اما اکنون حتی اتصال اولیه به سرور مخرب مهاجم نیز امکان پذیر نیست ، چه رسد به استفاده بعدی. از آن زمان ، راه تزریق JNDI به طور كامل مسدود شده است ، ما فقط می توانیم به محرومیت زدایی Hessian برگردیم و تجدید نظر كنیم! و زنجیره استفاده موجود نمی تواند به اجرای كد از راه دور دست یابد ، بنابراین ما برای پیدا کردن یک زنجیره استفاده جدید ، ابتدا باید اصول و دلایل زنجیره استفاده موجود را عمیقا درک کنیم. پس از بازخوانی مقاله امنیت Java Unmarshaller ، من در مورد یک جمله کنجکاو شدم:
اوه ، چرا نویسنده این جمله را به طور خاص اضافه کرده است؟ من شروع کردم به حدس زدن:
با شروع این حدس ، گرچه زنجیره استفاده از Groovy ما Groovy-1.5.6 را با آخرین نسخه واقع در می توان دریافت که در واقع هیچ محدودیتی در سرانجام ، البته! ما با موفقیت اطلاعات سرور فیس بوک را به دست آوردیم شل ، ویدئو زیر است: اعلان آسیب پذیری و تعمیر ما در ماه مارس کل تحقیق درباره آسیب پذیری را به اتمام رساندیم و نتایج تحقیق را در تاریخ 4/3 در یک گزارش نوشتیم و از طریق
پس از انتشار رسمی پچ ، ما همچنین شروع به نظارت بر وضعیت تعمیر همه شرکت های استفاده کننده از MobileIron در جهان کردیم. در اینجا فقط پرونده های استاتیک را بررسی می کنیم در همان زمان ، ما همچنین به نظارت بر فیس بوک ادامه می دهیم ، و پس از 15 روز تأیید عدم وصله ، آنها با موفقیت در 7/2 وارد سرور فیس بوک شده و برنامه Facebook Bug Bounty را گزارش دادند! نتیجه گیریتاکنون ، ما با موفقیت نشان داده ایم که چگونه یک آسیب پذیری را در سرور MDM پیدا کنیم! از دور زدن سطح حفاظت از سطح زبان جاوا و محدودیت های شبکه ، تا نوشتن برنامه های حمله و بهره برداری موفقیت آمیز از برنامه Bug Bounty! به دلیل طولانی بودن مقاله ، هنوز داستان های زیادی وجود دارد که برای به اشتراک گذاشتن خیلی دیر است ، در اینجا فقط لیستی از افرادی است که علاقه مند به ادامه تحصیل هستند!
امیدوارم این مقاله بتواند توجه عموم را به سطح حمله MDM و اهمیت امنیت شرکت برانگیزد! با تشکر برای تماشای: D [19659134]. |
