تفکیک پیام نقض داده LastPass • TechCrunch

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

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

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

توبا در یک پست وبلاگ کوتاه گفت که اطلاعات به‌دست‌آمده در حادثه آگوست برای دسترسی به یک سرویس ذخیره‌سازی ابری شخص ثالث استفاده شده است که LastPass از آن برای ذخیره داده‌های مشتریان و همچنین داده‌های مشتری برای شرکت مادرش GoTo استفاده می‌کند که مالک LogMeIn و نیز است. GoToMyPC.

اما از آن زمان، ما هیچ چیز جدیدی از LastPass یا GoTo نشنیدیم، که مدیر عامل آن، Paddy Srinivasan بیانیه ای حتی مبهم منتشر کرد و گفت که در حال بررسی این حادثه است اما مشخص نکرد که آیا مشتریانش نیز تحت تأثیر قرار گرفته اند یا خیر.

نیکولت باسو-آلبوم، سخنگوی GoTo از اظهار نظر خودداری کرد.

طی سال‌ها، TechCrunch در مورد نقض‌های بی‌شماری داده‌ها و مواردی که هنگام افشای حوادث امنیتی شرکت‌ها باید به دنبال آن باشیم، گزارش داده است. با آن، TechCrunch اشاره کرد و اعلان نقض اطلاعات LastPass با حاشیه 🖍️ با تجزیه و تحلیل ما از معنای LastPass و آنچه که از دست داده است – درست همانطور که در اوایل امسال با نقض هنوز حل نشده سامسونگ انجام دادیم.

آنچه LastPass در اعلامیه نقض داده خود می گوید

LastPass و GoTo فضای ذخیره سازی ابری خود را به اشتراک می گذارند

بخش مهمی از اینکه چرا LastPass و GoTo به مشتریان مربوطه خود اطلاع می دهند به این دلیل است که این دو شرکت هستند همان فضای ذخیره سازی ابری را به اشتراک بگذارید 🖍️.

هیچ یک از شرکت‌ها سرویس ذخیره‌سازی ابری شخص ثالث را مشخص نکرده‌اند، اما احتمالاً این سرویس خدمات وب آمازون، بخش محاسبات ابری آمازون خواهد بود، با توجه به اینکه یک پست وبلاگ آمازون در سال 2020 توضیح می‌دهد که چگونه GoTo، که در آن زمان به نام LogMeIn شناخته می‌شد، بیش از یک میلیارد رکورد را از ابر اوراکل به AWS.

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

اگر حساب ذخیره سازی ابری به اشتراک گذاشته شده توسط LastPass و GoTo به خطر بیفتد، ممکن است طرف غیرمجاز کلیدهایی را به دست آورده باشد که امکان دسترسی گسترده، اگر نامحدود، به داده های ابری شرکت، رمزگذاری شده یا موارد دیگر را فراهم می کند.

LastPass هنوز نمی‌داند چه کاری انجام شده یا داده‌ای گرفته شده است

LastPass در پست وبلاگ خود گفت که “با پشتکار” برای کشف این موضوع تلاش می کند چه اطلاعات خاصی 🖍️ توسط یک شخص غیرمجاز دسترسی پیدا کرد. به عبارت دیگر، در زمان پست وبلاگ خود، LastPass هنوز نمی‌دانست به چه داده‌های مشتری دسترسی داشته است یا اینکه آیا داده‌ها از فضای ذخیره‌سازی ابری آن استخراج شده است.

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

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

احتمالاً یک بازیکن بدخواه پشت این نفوذ است

عبارت پست وبلاگ LastPass در آگوست این احتمال را باز می گذارد که “طرف غیرمجاز” بد نیت عمل نکرده است.

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

در این مرحله، کاملاً مطمئن است که این را فرض کنیم مهمانی غیر مجاز 🖍️ یک بازیگر مخرب پشت این نفوذ است، حتی اگر انگیزه هکر – یا هکرها – هنوز مشخص نباشد.

پست وبلاگ LastPass می گوید که حزب غیر مجاز از اطلاعات دریافتی استفاده می کند 🖍️ در طول نقض اوت برای به خطر انداختن LastPass برای بار دوم. LastPass نمی گوید که این اطلاعات چیست. این می تواند به معنای کلیدهای دسترسی یا اعتبارنامه هایی باشد که توسط طرف غیرمجاز در جریان حمله آنها به محیط توسعه LastPass در ماه آگوست به دست آمده بود، اما LasPass هرگز آنها را لغو نکرد.

آنچه LastPass در مورد نقض داده ها نگفته است

ما نمی دانیم که نقض واقعاً چه زمانی رخ داده است

LastPass نگفت که چه زمانی رخنه دوم اتفاق افتاد، فقط این اتفاق افتاد “به تازگی کشف شده” 🖍️که به کشف نقض توسط شرکت اشاره دارد، نه لزوما خود نقض.

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

اما شرکت‌ها در عوض گاهی اوقات از اصطلاحات مبهمی مانند «به تازگی» (یا «بهبود یافته») استفاده می‌کنند که واقعاً هیچ معنایی بدون زمینه لازم ندارند. این امکان وجود دارد که LastPass نفوذ دوم خود را تا زمانی که مهاجم دسترسی پیدا کرده است، کشف نکرده باشد.

LastPass نمی گوید چه اطلاعات مشتری ممکن است به خطر افتاده باشد

یک سوال واضح این است که LastPass و GoTo چه اطلاعات مشتری را در فضای ذخیره سازی ابری مشترک خود ذخیره می کنند؟ LastPass فقط این را می گوید “عناصر خاصی” از داده های مشتری 🖍️ در دسترس بودند. این می تواند به اندازه اطلاعات شخصی که مشتریان هنگام ثبت نام به LastPass داده اند، مانند نام و آدرس ایمیل آنها، تا اطلاعات حساس مالی یا پرداخت و فروشگاه های رمزگذاری شده مشتری، گسترده باشد.

LastPass به دلیل روشی که این شرکت معماری دانش صفر خود را طراحی کرده است، قاطعانه معتقد است که رمزهای عبور مشتریان ایمن هستند. Zero-Knowledge یک اصل امنیتی است که به شرکت ها اجازه می دهد تا داده های مشتریان خود را به صورت رمزگذاری شده ذخیره کنند تا فقط مشتری بتواند به آن دسترسی داشته باشد. در این مورد، LastPass فروشگاه رمز هر مشتری را در فضای ذخیره سازی ابری خود ذخیره می کند، اما فقط مشتری رمز اصلی را برای باز کردن قفل داده ها دارد، حتی LastPass.

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

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

LastPass نگفته است که چه تعداد مشتری تحت تأثیر قرار گرفته اند

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

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

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

با فرض بدترین حالت، LastPass حدود 33 میلیون مشتری دارد. GoTo طبق آخرین درآمد خود در ماه ژوئن 66 میلیون مشتری داشت.

چرا GoTo اعلامیه نقض اطلاعات خود را پنهان کرد؟

اگر فکر می‌کردید که پست وبلاگ LastPass از نظر جزئیات ساده است، بیانیه شرکت مادر GoTo حتی سبک‌تر بود. کنجکاوتر این بود که چرا اگر عبارت GoTo را جستجو کنید در ابتدا آن را پیدا نمی کنید. این به این دلیل است که GoTo از یک کد “noindex” در پست وبلاگ استفاده می کند تا به ربات های موتور جستجو، مانند Google، بگوید که آن را رد کنند و صفحه را به عنوان بخشی از نتایج جستجو فهرست نویسی نکنند، تا اطمینان حاصل شود که هیچ کس نمی تواند آن را پیدا کند. آدرس وب خاص آن را بدانید.

لیدیا تسویی، مدیر شرکت ارتباطات بحران Brunswick Group که نماینده GoTo است، به TechCrunch گفت که GoTo کد “noindex” را که اعلان نقض داده را مسدود می کند از موتورهای جستجو حذف کرده است، اما از بیان دلیل مسدود شدن پست در ابتدا خودداری کرد.

برخی از اسرار که ممکن است هرگز آنها را حل نکنیم.