چگونه مهاجمان برای نفوذ به PagerDuty از تأیید هویت دومرحله‌ای گذر کردند

در جولای سال ۲۰۱۵، شرکت مدیریت عمل‌کرد PagerDuty به مشتریان خود توصیه کرد تا گذرواژه‌های خود را تغییر دهند، چرا که آن‌ها متوجه شدند به سامانه‌هایشان نفوذ شده است.
به تازگی، کشف شده است که مهاجمان به کارگزارهای PagerDuty از طریق پنل مدیریتی Linode (که ارائه‌کننده‌ی فضای ابری آن است) دسترسی پیدا کرده‌اند. مهاجمان برای این کار باید کنترل‌های تأیید هویت دو مرحله‌ای (۲FA) را دور می‌زدند. در نتیجه‌ی این نفوذ، گزارش شده است که PagerDuty به یک ارائه‌دهنده فضای ابری دیگر کوچ کرده است.
Linode در یکی از پست‌های وبلاگ خود به شرح نتایج تحقیقات خود در مورد این نفوذ پرداخته است. علاوه بر این از PagerDuty در این گزارش به صراحت نام برده نشده است، اما شباهت‌هایی که در جزئیات و تاریخ‌ها وجود دارند، هیچ شکی برای شناخت قربانی باقی نمی‌گذارند. این وبلاگ از سوی جامعه‌ی امنیت به عنوان ترکیبی عجیب از افشاگری و پنهان‌کاری دیده می‌شود. از یک طرف، به نظر می‌رسد که به ارائه‌ی بسیاری از حقایق ناشناخته می‌پردازد، اما از طرف دیگر نمی‌تواند آن‌ها را به صورت یک داستان منسجم به یک‌دیگر متصل کند. تاکنون سعی شده تا شکاف‌ها برطرف شوند.

گذرواژه‌های مبتنی بر زمان (TOTP)
لینود از الگوریتم رمزهای عبور مبتنی بر زمان به نام TOTP یا Time-based One-Time Password به عنوان دومین عامل تأیید هویت مشتریان استفاده می‌کند. در ویکی‌پدیا TOTP به این شکل معرفی شده است: «در یک نرم‌افزار تأیید هویت دو عامله‌ی مرسوم،‌ نحوه‌ی تأیید هویت کاربر به این شکل است:‌ یک کاربر نام کاربری و رمز عبور خود را در یک وب‌گاه و یا یک کارگزار وارد می‌کند و یک رمز عبور یک‌بار مصرف برای کارگزاری که با استفاده از اجرای TOTP روی گوشی هوشمند و یا دستگاه خود در حال اجرا است، دریافت می‌کند و این رمز را در کارگزار خود وارد می‌کند. سپس کارگزار TOTP را اجرا می‌کند تا یک گذرواژه‌ی یک‌بار مصرف را تأیید کند. برای این کار ساعت‌های دستگاه کاربر و کارگزار باید هم‌زمان‌سازی شده باشند (کارگزار معمولاً رمزهای عبوری را خواهد پذیرفت که در فاصله‌ی زمانی یک ساعت قبل و بعد از مبداء زمانی مشتری باشند). یک کلید مخفی که متعاقب آن برای همه‌ی بخش‌های تأیید هویت استفاده می‌شود، باید میان کارگزار و دستگاه کاربر روی یک کانال امن جلوتر به اشتراک گذاشته شده باشد.»
امنیت الگوریتم TOTP به محرمانه‌بودن کلید به اشتراک گذاشته شده، بستگی دارد. اگر این کلید در معرض خطر قرار گیرد،‌ چه از طرف وب‌گاه میزبان و چه از طرف مشتری، TOTP بی‌ارزش خواهد شد، چرا که مهاجم می‌تواند یک رمز عبور یک‌بار مصرف را به همین شیوه تولید کند.
در مورد نفوذ به PagerDuty مهاجمان اعتبارنامه‌های Linode را به عنوان یک کارگزار PagerDuty به خطر انداختند که شامل احراز هویت دو مرحله‌ای از طریق دسترسی به رابط کاربری مدیریت Linode می‌شد. با استفاده از این رابط کاربری مهاجمان توانستند به کارگزارهای میزبان Linode دسترسی پیدا کنند.
PagerDuty متقاعد شده بود که منبع احراز هویت‌ به خطر افتاده از سمت مشتری نیست (مثلاً از جانب یک بدافزار تلفن همراه) و یک کارمند به خصوص نمی‌توانسته رمزهای دوعامله را در اختیار داشته باشد، چرا که تلفن همراه او ماه‌ها قبل از این حادثه از بین رفته بود.
در پی آن، PagerDuty، Linode را از این حادثه باخبر کرد و می‌توانست نشانی‌های آی‌پی کارگزار حمله را نشان دهد. با کمال تعجب، کارگزار مهاجم بر روی Linode نیز میزبانی می‌شد، که Linode را قادر می‌ساخت تا تصویری کامل از آن را در اختیار داشته باشد.
هنگامی که به Linode‌ به بررسی این تصویر پرداخت، آن‌ها دریافتند که مهاجمان همه‌ی ابزارها و اطلاعات لازم برای نفوذ به الگوریتم TOTP‌ را در اختیار داشته‌اند و همچنان‌که در پستی در وبلاگ خود اشاره می‌کنند:‌ «ما نرم‌افزاری را کشف کردیم، که در صورتی که کلید TOTP را در اختیار داشته باشد، قادر به تولید کدهای TOTP‌ است. ما نرم‌افزاری را یافتیم که به رمزگشایی روشی که ما برای امن کردن کلیدهای TOTP استفاده می‌کردیم، می‌پرداخت و همین‌طور کلید مخفی که ما برای رمزگذاری آن‌ها استفاده می‌کردیم، رمزگشایی می‌کرد. علاوه بر این ما دستوراتی را در تاریخچه‌ی Bash یافتیم که به طور موفقیت‌آمیزی یک کد یک بار مصرف تولید می‌کرد.»
معمولاً حمله به یک ارائه‌دهنده‌ی سرویس ابری، از یک ماشین به میزبانی همان ارائه‌دهنده‌ ایده‌ی بسیار بدی است، چرا که ارائه‌دهنده را قادر می‌سازد تا ماشین حمله را بررسی کند (همان‌طور که Linode این کار را انجام داد). اگر ماشین مهاجمان از سوی یک ارائه‌دهنده‌ی دیگر میزبانی بشود، احتمال این‌که چنین تجزیه و تحلیل‌هایی ممکن نباشد، بسیار بیشتر است. بنابراین ما باید فرض کنیم که مهاجم دلایل خاصی برای انجام حمله از طریق کارگزار میزبانی Linode داشته تا بتواند کار خود را انجام دهد.
یکی از این دلایل ممکن وجود آسیب‌پذیری‌هایی درونی Linode است که تنها می‌توانسته از درون خود آن مورد بهره‌برداری قرار گیرد. در پست وبلاگ Linode تیم امنیتی آن می‌گوید که یک آسیب‌پذیری را در درگاه SSH Lish پیدا کرده است (Lish یک پوسته‌ی Linode است و نرم‌افزاری است که به وسیله‌ی Linode راه‌اندازی شده است) که به صورت بالقوه می‌تواند برای به دست آوردن اطلاعاتی که در تصویر ماشین نفوذگر وجود دارد، مورد استفاده قرار گیرد. ماهیت دقیق این آسیب‌پذیری افشاء نشده است، اما بهبود مشخص اولین وبلاگ از سوی Linode به عنوان نتیجه‌ی نفوذ، محدودکردن دسترسی Lish به اطلاعات احراز هویت است:‌ «چندین نرم‌افزار ما (نظیر Linode Manager و Lish) کار احراز هویت را انجام می‌دهند. پیش از این، این نرم‌افزارها این کار را به وسیله‌ی دسترسی به اطلاعات گواهی‌نامه‌ها که مستقیماً از پایگاه داده‌ی ما دریافت می‌شد، انجام می‌دادند.»
با جمع کردن این‌ها، یک توضیح فنی قابل قبول برای نفوذ به Linode/PagerDuty این است که مهاجمان از دسترسی مستقیم به پایگاه داده‌ی Lish سوءاستفاده کردند تا اطلاعات احراز هویت کاربران را که در همان پایگاه داده قرار داشت به دست آورند. (برای مثال با استفاده از تزریق SQL). با این حال برای سوءاستفاده از Lish مهاجمان باید از درون سامانه‌ی Linode وارد عمل می‌شدند، از این رو حمله از داخل کارگزار میزبان Linode انجام شد.

هنگامی که دو به علاوه‌ی دو می‌شود چهار!
همان‌طور که در بسیاری از موارد دیده می‌شود، اعتبارنامه‌های حساب‌های مدیران ضعیف‌ترین حلقه در نفوذ به Linode/PagerDuty بوده است. احراز هویت دوعامله Linode تنها برای سمت مشتری مناسب بوده است، چرا که نیاز داشته تا مشتری چیزی را بداند (گذرواژه) و یا چیزی را داشته باشد (یک نرم‌افزار تلفن همراه با یک کلید مخفی در آن). اما در سمت کارگزار این احراز هویت دوعامله به یک عامل سقوط کرده است، چرا که هر دو، هم رمز عبور و هم کلید مخفی TOTP‌ از سوی یک نرم‌افزار تنها قابل دسترسی بوده‌اند و شاید هم در یک ردیف در اطلاعات مربوط به کاربر در پایگاه داده قرار داشته‌اند.
محیط‌های ابری هم فرصت‌ها و هم خطرات را ارائه می‌کنند. بنابراین ارائه‌دهندگان خدمات ابری باید امنیت را به عنوان اولویت اصلی خود در نظر بگیرند و مشتریان این فضاهای ابری باید امنیت ارائه‌شده به وسیله‌ی ارائه‌دهندگان مختلف فضاهای ابری را به عنوان یک عنصر کلیدی برای تصمیم‌گیری خرید خود، در نظر بگیرند.

منبع: asis

درباره نماد امنیت وب

“نماد امنیت وب” به عنوان یکی از شرکت های پیشتاز در زمینه امنیت نرم افزار و سرویس های تحت وب، با ارائه سرویس های امنیتی برای تمامی کسب و کار ها و دارای نمایندگی شرکت Acunetix (اکوانتیکس) بعنوان محبوب ترین اسکنر امنیتی black box در دنیا، ایمنی وب سایت شما را در مقابل حمله هکر ها تضمین می کند.

[easy-pricing-table id="6835"]