Инцидентот кој го измени обезбедувањето во облак
Ажурирано за 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 ги покажуваат двата главни патишта до компромитирање на добавувачот:
- Неуспеси во дизајнот — тврдења за нула-знаење кои не биле правилно изградени
- Неуспеси во контролата на пристап — важечки акредитиви користени за достигнување на податоци до кои не треба да стигнат
Дизајнот со нула-знаење го спречува prvиот тип. Не го запира напаѓач со важечки акредитиви за поддршка. Но го блокира тој напаѓач да ги чита податоците на клиентите. Добавувачот никогаш не чува дешифрирачка содржина. Погледнете го нашиот преглед на безбедност и усогласеност за тоа како ова се применува на алатките за PII.
Безбедносните настани на SaaS пораснаа за 300% за две години
Obsidian Security утврди пораст од 300% во безбедносните настани на SaaS платформите од 2022 до 2024 година.
Ова не е пораст на вештините на напаѓачите за 300%. Две сили го движеле. Употребата на SaaS брзо пораснала. Напаѓачите ги следеле податоците. Еден компромис на добавувачот може да изложи податоци од десетици клиенти одеднаш. Таа исплата фаворизира напади на добавувачи наспроти напади на поединечни фирми.
Претпријатијата кои претпоставувале дека облак платформите се безбедни треба да го ажурираат тој поглед. SaaS добавувачите се сега примарни цели.
Прашања за да ги поставите на кој било облак добавувач
За тимовите за набавки и безбедност, оваа контролна листа ги покрива основните области.
Поставка за шифрирање:
- Прашајте за алгоритмот за изведување на клучот, бројот на итерации и поставките за меморија.
- Потврдете дека броевите на итерации ги исполнуваат минимумите на OWASP. Тоа е 600.000 PBKDF2-SHA256 или еквивалент Argon2id.
- Проверете дека изведувањето на клучот се извршува на вашиот уред, не на серверите на добавувачот.
Изложеност на метаподатоци:
- Прашајте кои метаподатоци се складирани во обичен текст покрај шифрирана содржина.
- Барајте модел на податоци. Треба да покаже кои полиња се шифрирани и кои се видливи при напад.
Пристап за поддршка:
- Прашајте дали персоналот за поддршка може да пристапи до податоците на клиентите.
- Потврдете дека системите за поддршка не можат да достигнат обичен текст на клиентите.
Историја на инциденти:
- Прашајте за сите претходни безбедносни настани, вклучувајќи ги оние под прагот на јавно обелоденување.
- Проценете колку комплетни и чесни биле претходните обелоденувања.
Инцидентот на LastPass беше неуспех во изградбата и неуспех во довербата. Добавувачите со специфични одговори дозволуваат вистински преглед на ризик. Добавувачите со нејасни тврдења оставаат ризикот скриен. Тој ризик честопати излегува на виделина само по нападот. Погледнете го нашиот преглед на усогласеност за насоки за евалуација на добавувачи.
anonym.legal користи архитектура со нула-знаење за PII анонимизација. Изведувањето на клучот се извршува преку Argon2id во вашиот прелистувач или десктоп апликација. Шифрирањето се случува пред податоците да го напуштат вашиот уред. Серверите складираат само шифриран текст кој не можат да го дешифрираат. Дознајте повеќе.