Порушення вихідного коду LastPass – опубліковано звіт про реагування на інцидент

Якщо здається, що велика історія цього місяця відбудеться Порушення даних Uber, де хакер нібито міг широко проникати в мережу компанії спільного використання поїздок…

..велика історія минулого місяця була Порушення LastPass, в якому зловмисник, очевидно, отримав доступ лише до однієї частини мережі LastPass, але зміг втекти за допомогою власного вихідного коду компанії.

На щастя для Uber, їхній зловмисник, схоже, був налаштований зробити великий, швидкий PR-сплеск, схопивши скріншоти, щедро розповсюджуючи їх в Інтернеті та глузуючи з компанії крикливими повідомленнями, такими як UBER ЗЛАМАЛИ, безпосередньо на власних форумах Slack і bug bounty:

Проте зловмисник або зловмисники з LastPass, схоже, діяли більш приховано, вочевидь, обманом змусили розробника LastPass встановити зловмисне програмне забезпечення, яке потім використали кіберзлочинці, щоб пробратися в сховище вихідного коду компанії:

LastPass тепер опублікував офіційний звіт про подальші дії про інцидент, виходячи з того, що вдалося з’ясувати про атаку та нападників після вторгнення.

Ми вважаємо, що статтю LastPass варто прочитати, навіть якщо ви не є користувачем LastPass, тому що ми вважаємо, що це нагадування про те, що хороший звіт про реагування на інцидент так само корисний для того, що ви визнаєте, що ви не змогли зрозуміти, як і для того, що ви були.

Що ми тепер знаємо

Речення, виділені жирним шрифтом нижче, надають схему того, що говорить LastPass:

• Зловмисник «отримав доступ до середовища розробки, використовуючи скомпрометовану кінцеву точку розробника». Ми припускаємо, що це пов’язано з тим, що зловмисник імплантував на комп’ютер програміста зловмисне програмне забезпечення, що стежить за системою.
• Трюк, використаний для впровадження зловмисного програмного забезпечення, визначити не вдалося. Це розчаровує, оскільки знання того, як насправді була здійснена ваша остання атака, полегшує переконання клієнтів, що ваші переглянуті процедури запобігання, виявлення та реагування, ймовірно, заблокують її наступного разу. Спадає на думку багато потенційних векторів атак, зокрема: невиправлене локальне програмне забезпечення, «тіньові ІТ», що призводять до незахищеної локальної конфігурації, помилка під час фішингу, небезпечні звички завантаження, зрада в ланцюжку постачання вихідного коду, на яку покладається відповідний кодер, або мінований вкладений електронний лист, відкритий помилково. Знімаю капелюха перед LastPass за визнання того, що є «відомим невідомим».
• Зловмисник «використовував свій постійний доступ, щоб видати себе за розробника, коли розробник успішно пройшов автентифікацію за допомогою багатофакторної автентифікації». Ми припускаємо, що це означає, що хакеру ніколи не потрібно було отримати пароль жертви чи код 2FA, а просто використав a атака крадіжки файлів cookie, або витягнув маркер автентифікації розробника зі справжнього мережевого трафіку (або з оперативної пам’яті комп’ютера жертви), щоб використати звичайний доступ програміста:

• LastPass не помітив вторгнення відразу, але виявив і вигнав зловмисника протягом чотирьох днів. Як ми зазначали в нещодавній статті про ризики неоднозначність позначки часу у системних журналах можливість визначити точний порядок, у якому відбувалися події під час атаки, є важливою частиною реагування на інцидент:

• LastPass зберігає свої мережі розробки та виробництва фізично розділеними. Це хороша практика кібербезпеки, оскільки вона запобігає перетворенню атаки на мережу розробки (де все неминуче перебуває в стані постійних змін і експериментів) у негайну компрометацію офіційного програмного забезпечення, яке є безпосередньо доступним для клієнтів та решти бізнесу. .
• LastPass не зберігає жодних даних клієнтів у своєму середовищі розробки. Знову ж таки, це хороша практика, враховуючи, що розробники, як випливає з назви роботи, зазвичай працюють над програмним забезпеченням, яке ще має пройти повну перевірку безпеки та процес забезпечення якості. Це розділення також робить правдоподібним твердження LastPass про те, що дані сховища паролів (які все одно були б зашифровані закритими ключами користувачів) не могли бути розкриті, що є вагомішим твердженням, ніж просто твердження «ми не змогли знайти жодних доказів того, що це було викрито». Зберігання реальних даних у вашій мережі розробників також запобігає випадковому захопленню програмістами з добрих намірів даних, які мають бути під нормативним захистом, і використанню їх для неофіційних тестових цілей.
• Хоча вихідний код було вкрадено, зловмисник не залишив жодних неавторизованих змін коду. Звичайно, у нас є лише власна претензія LastPass, але враховуючи стиль і тон решти звіту про інцидент, ми не бачимо причин не вірити компанії на слово.
• Вихідний код переміщується з мережі розробки у виробництво «може відбутися лише після завершення ретельних процесів перевірки коду, тестування та перевірки». Це робить правдоподібними заяви LastPass про те, що жоден модифікований або отруєний вихідний код не досяг би клієнтів чи решти бізнесу, навіть якщо зловмиснику вдалося імплантувати фальшивий код в системі контролю версій..
• LastPass ніколи не зберігає та навіть не знає особистих ключів дешифрування своїх користувачів. Іншими словами, навіть якщо зловмисник втік із даними пароля, він би закінчився як стільки подрібненої цифрової капусти. (LastPass також надає a публічне пояснення про те, як він захищає дані сховища паролів від злому в автономному режимі, включно з використанням PBKDF2-HMAC-SHA256 на стороні клієнта для хешування та розтягування вашого пароля в автономному режимі за допомогою 100,100 XNUMX ітерацій, таким чином спроби злому пароля набагато складніше, навіть якщо зловмисники вдасться отримати локально збережені копії вашого сховища паролів.)

Що ж робити?

Ми вважаємо розумним сказати, що наш перші припущення були правильними, і хоча це незручний інцидент для LastPass і може розкрити комерційні таємниці, які компанія вважала частиною своєї акціонерної вартості…

…цей хак можна розглядати як власну проблему LastPass, оскільки під час цієї атаки жодні паролі клієнтів не були досягнуті, не кажучи вже про зламане:

Ця атака та власний звіт LastPass про інцидент також є хорошим нагадуванням про те, що «розділяй і володарюй», також відомий як жаргонний термін Нульова довіра, є важливою частиною сучасного кіберзахисту.

Як пояснює експерт Sophos Честер Вишневскі у своєму аналізі останній злом Uber, на карту поставлено набагато більше, якщо шахраї отримають доступ до деякі вашої мережі можуть бродити, де завгодно, в надії отримати доступ всі з нього: