Инцидентът, променил облачната сигурност
Актуализирано за 2026 г.
Пробивът на LastPass от 2022 г. не е преди всичко за мениджъри на пароли. Той е за доверие. Фирмите са доверили данните си на облачен доставчик. Това доверие се е счупило. Причината е скрити дефекти, а не безразсъдство.
LastPass е продавал дизайн с нулево знание. На практика той не е бил нулево знание. 25 милиона потребители са имали своите криптирани трезори откраднати. Атаката е разкрита за първи път през август 2022 г. LastPass е ревизирал своите разкривания няколко пъти. Пълният мащаб е станал ясен в края на 2022 г.
За фирми в здравеопазването, финансите и правото това не е бил далечен новинарски разказ. Тези сектори носят реална отговорност при изтичане на данни. Случаят с LastPass е бил ранен знак за по-широк проблем.
Два дефекта, позволили атаката
Преразглеждането след инцидента е установило две ключови слабости.
Слабо извеждане на ключ. LastPass е използвал PBKDF2 за извеждане на ключ. По-новите акаунти са имали 100 100 итерации. OWASP препоръчва 600 000. Някои стари акаунти са имали едва 1 итерация. По-малко итерации правят атаките с груба сила бързи и евтини. Нападателите с файловете на трезорите биха могли да тестват главни пароли с висока скорост.
Некриптирани метаданни. Съдържанието на трезора е криптирано. Но метаданните -- не. URL адреси, потребителски имена и имена на услуги са всички видими в откраднатите данни. Нападателите са могли да видят кои услуги има акаунти за всеки потребител. Това е позволило целенасочен фишинг и пълнене с идентификационни данни. Не е бил необходим пробив на трезора.
Този случай показва защо два въпроса трябва да бъдат задавани отделно. "Дали дизайнът е с нулево знание?" е един въпрос. "Дали изпълнението е правилно?" е различен въпрос.
Okta през 2023 г.: Различна атака, същият резултат
През октомври 2023 г. Okta е съобщил за инцидент в сигурността. Откраднати идентификационни данни са дали на нападател достъп до системата му за клиентска поддръжка. Атаката е изложила 600 000+ записа за поддръжка. Те включват файлове, качени от клиентите по време на сесии за поддръжка.
Okta е платформа за самоличностна сигурност. Проблемът не е бил дефект в дизайна. Той е бил провал при контрол на достъпа. Входът на инженер по поддръжката е бил откраднат. Нападателят го е използвал за достъп до чувствителни данни.
LastPass и Okta показват двата основни пътя към компромис с доставчика:
- Дефекти в дизайна -- твърдения за нулево знание, неизградени правилно
- Провали при контрол на достъпа -- валидни идентификационни данни, използвани за достъп до данни, до които не трябва да достигат
Дизайнът с нулево знание предотвратява първия тип. Той не спира нападател с валидни идентификационни данни за поддръжка. Но блокира този нападател от четенето на клиентски данни. Доставчикът никога не съхранява дешифруемо съдържание. Вижте нашия преглед на сигурността и съответствието за това как това се отнася за инструменти за лични данни.
SaaS инцидентите в сигурността са нараснали с 300% за две години
Obsidian Security е установил 300% ръст в инцидентите в сигурността на SaaS платформите от 2022 до 2024 г.
Това не е ръст от 300% в уменията на нападателите. Две сили го са движили. Употребата на SaaS е нараснала бързо. Нападателите са последвали данните. Един компромис с доставчик може да изложи данните на десетки клиенти наведнъж. Тази изплата е в полза на атаките срещу доставчици, а не срещу отделни фирми.
Предприятия, приемали, че облачните платформи са безопасни, трябва да актуализират тази гледна точка. SaaS доставчиците вече са основни цели.
Въпроси, които да зададете на всеки облачен доставчик
За екипите по закупуване и сигурност, този контролен списък покрива основните области.
Настройка на криптиране:
- Поискайте алгоритъма за извеждане на ключ, броя на итерациите и настройките за памет.
- Потвърдете, че броят на итерациите отговаря на минималните изисквания на OWASP. Това е 600 000 PBKDF2-SHA256 или еквивалентен Argon2id.
- Проверете, че извеждането на ключ се изпълнява на вашето устройство, а не на сървърите на доставчика.
Излагане на метаданни:
- Попитайте какви метаданни се съхраняват в некриптиран текст до криптираното съдържание.
- Поискайте модел на данните. Той трябва да показва кои полета са криптирани и кои са видими при атака.
Достъп за поддръжка:
- Попитайте дали персоналът по поддръжката има достъп до клиентски данни.
- Потвърдете, че системите за поддръжка не могат да достигат до некриптиран клиентски текст.
История на инцидентите:
- Поискайте всички предишни инциденти в сигурността, включително тези под прага за публично разкриване.
- Оценете колко пълни и честни са били предишните разкривания.
Инцидентът с LastPass е бил провал при изпълнението и провал в доверието. Доставчици с конкретни отговори позволяват реален преглед на риска. Доставчици с неясни твърдения оставят риска скрит. Този риск често се проявява едва след атака. Вижте нашия преглед на съответствието за насоки при оценка на доставчици.
anonym.legal използва архитектура с нулево знание за анонимизация на лични данни. Извеждането на ключ се извършва чрез Argon2id във вашия браузър или настолно приложение. Криптирането се случва, преди данните да напуснат вашето устройство. Сървърите съхраняват само шифрован текст, който не могат да декриптират. Научете повече.