Минулого року Dell пережили одну з найбільших в історії компанії кібератак. Дані 49 мільйонів користувачів викрали через критичні вразливості в системі. Запобігти проблемі можна було досить легко, як мінімум, налаштувавши роботу Security Operations Center. Які уроки з цього кейсу може винесли бізнес та як побудувати ефективну систему захисту персональних даних — розглянемо детальніше у статті.
Що сталося в Dell
Наприкінці весни 2024 року американський виробник електроніки Dell розіслав 49 мільйонам клієнтів повідомлення про витік їхніх персональних даних. Мова йшла про імена, адреси та замовлення техніки впродовж 2017–2024 років. Представники Dell заявили, що ні фінансова чи платіжна інформація, ні електронні пошти та номери телефонів клієнтів під час атаки зловмисник не дістав, але ризики все одно суттєві. На той момент база з викраденими даними вже продавалася на одному із «чорних» форумів. Цієї інформації вистачить для персоналізованого спаму на адреси користувачів Dell.
Здійснив кібератаку хакер Menelik. Він скористався вразливістю в API партнерського порталу компанії, призначеного для співпраці з торговими представниками виробника. На сайті можна відстежувати інформацію про замовлення товарів, гарантію тощо. Menelik створив на порталі фейкові акаунти та отримав доступ до великої кількості чужих даних. І хоча сам хакер повідомив Dell про свою «діяльність» мейлом, від компанії він так і не отримав жодної реакції.
Які прогалини в безпеці призвели до кібератаки
Інцидент виявив низку вразливостей у кіберзахисті компанії. Та як показує практика, ці проблеми не поодинокі для багатьох ІТ-команд. Пропоную на прикладі Dell розглянути кожну «дірку» в системі безпеки та способи їх вирішення.
Відсутність верифікації користувачів
Що не так?
Для створення акаунту на партнерському порталі Dell достатньо було вказати назву компанії та емейл. Ба більше: ці дані ніяк не перевірялися, тому їх можна легко підробити. Наприклад, вказати вигадану компанію й одразу отримати доступ до порталу. Завдяки цьому хакер зміг швидко та без перешкод створити безліч акаунтів у системі Dell.
Як правильно?
Найпростіше зробити «живу» верифікацію користувача. Тоді новий підрядник не зможе автоматично створити акаунт на партнерському порталі. Для цього треба надіслати компанії запит, а далі працівник фірми-виробника перевіряє вказану інформацію: чи це дійсно реальний підрядник, чи взагалі він існує. І тільки після цього Dell самостійно створював би акаунт партнера та надавав би заявнику відповідні креди (доступи до персональної сторінки).
Але цей спосіб є не універсальним й іноді буває неможливим. Якщо компанія має тисячі партнерів, вручну обробити значну кількість запитів важко. Тоді має сенс застосувати автоматизацію. Наприклад, створити бази даних із переліком партнерів, з яким система звірятиметься самостійно. Також при підписанні партнерської угоди виробник може передавати спеціальний код для створення акаунту на порталі.
Неправильні налаштування ролей доступу до даних
Що не так?
В роботі партнерів із порталом Dell використовувались унікальні семизначні сервісні теги — ідентифікатори, які надсилаються в API-запиті для отримання даних юзера. Як виявилось, у Dell не налаштували обмеження ролей. Тобто залогінившись, можна перебирати теги за принципом брутфорсу, відправляти їх через API та отримувати дані чужих замовлень. Menelik для генерації тегів навіть створив окрему програму.
Як правильно?
Це типова проблема в побудові будь-якої закритої бази даних. Після успішної ідентифікації та автентифікації користувача має відбуватися авторизація — керування доступами до тих чи інших ресурсів відповідно до ролі юзера. Адже пів біди, що хакер зміг створити акаунт фіктивної компанії. Куди гірше, що завдяки цьому він отримав дані з акаунтів реальних партнерів Dell.
Користувачам завжди слід налаштовувати доступи, щоби вони могли дивитися тільки свої дані. Раптом через помилку хтось надішле чужий тег, йому надійде повідомлення про відсутність доступу до цієї інформації. Можна навіть не ускладнювати створення тегів — вони можуть йти підряд як простий ID. Зловмисник, надсилаючи запит із цими ключами, все одно нічого не отримає через обмеження ролі.
Некоректні ліміти на запити
Що не так?
Зазвичай розробники обмежують кількість запитів на API від юзера за певний проміжок часу, скажімо, за за хвилину чи секунду. Але на порталі Dell ліміти були або високі, або їх не було в принципі. Врешті хакер виконував до 5000 запитів на хвилину. Сам по собі показник для цієї системи, можливо, й не є критичним, але зловмисник працював на цій частоті досить довго, що фахівцям компанії могло би здатися підозрілим.
Як правильно?
Ліміти API мають бути завжди, і це слід пам'ятати всім — розробникам, security-інженерам, SOC-командам. Обмеження діють на одного юзера або на IP-адресу в залежності від бізнес-логіки застосунку. Ліміти щонайменше допомагають збалансувати навантаження на застосунок, коли всі користувачі мають рівні можливості доступу. Водночас ці обмеження підвищують безпеку, бо скорочують можливі втрати при витоку даних.
Я би не радив встановлювати конкретні ліміти API, все залежить від специфіки проєкту. Для одних програм 5000 запитів забагато, для інших — норма. А може бути і так: десь користувачі зазвичай створюють 100 запитів на хвилину, але раз на рік за певних обставин показник підвищується до 1000. Тож треба аналізувати бізнес-логіку сервісу або окремого ендпойнту та вираховувати адекватні для цієї системи показники.
Відсутній моніторинг
Що не так?
Menelik не просто мав змогу збирати дані на високій швидкості, він створив кілька фіктивних акаунтів, кожен з яких на максимальній «потужності» працював тривалий час. Атака на партнерський портал Dell відбувалась три тижні поспіль, ніхто не помічав підозрілої активності користувачів. Саме цей чинник дозволив хакеру отримати велику кількість персональних даних.
Як правильно?
Для зменшення наслідків зламу потрібно створити моніторинг з алертами на аномальні події. Аномалії можуть бути різними: юзер задає декілька API-запитів або десятки користувачів одночасно запитують одні й ті самі дані, або ж з IP-адресу надходять запити із заданою регулярністю. Суть моніторингу полягає в тому, щоб при появі будь-якої підозрілої активності ви отримували повідомлення на пошту або в месенджер.
Важливо грамотно налаштувати моніторинг, адже не кожна аномалія свідчить про злам. Можна орієнтуватися не на кількість запитів, а на якість відповідей. Наприклад, у разі брутфорсу тегів або ID періодично надходитимуть відповіді з кодами 404 (не знайдено) або 500 (Internal Server Error). Хоч все залежить від проєкту, помилки можуть бути і в реального юзера, та якщо таких відповідей 90%, краще все перевірити.
Повільне реагування на вже вчинений злам
Що не так?
Dell проігнорували лист хакера, коли той написав їм про успішну атаку на компанію. Спеціалісти побачили повідомлення лише за кілька тижнів, коли базу даних їхніх клієнтів уже виставили на продаж. Ця затримка є критичною, адже відсутність негайної реакції призвело до зливу вкраденої інформації. В іншому випадку, можливо, цього вдалося б уникнути та зменшити втрати для бізнесу.
Як правильно?
Створити систему швидкого реагування на наявність вразливості та власне зламу — задача не стільки фахівців із безпеки, скільки самого бізнесу. Але Security-спеціалісти можуть бути на крок попереду та запропонувати шляхи убезпечення компанії. Наприклад, підключити до електронної пошти інструменти сортування листів. Таких тулзів зараз безліч, зокрема на базі штучного інтелекту. Вони можуть аналізувати вміст повідомлень та надсилати алерти про знайдені задані стоп-слова.
Та замало прочитати листа, потрібно ще й оперативно переконатися, що хакер говорить правду. І тут доможуть фахівці з безпеки: перевірять вразливість системи та протестують рівень її безпеки. Це займе певний час, бо ендпойнтів може бути багато, і не всі матимуть документацію. Якщо хакер детально описує механізм зламу, це дозволить швидко все перевірити.
Як побудувати систему захисту даних
Описані проблеми могли би бути не критичними, але всі разом вони призвели до масштабного й водночас простого на рівні технологій зламу.
До питання безпеки слід підходити комплексно та системно. Врахуйте наступні кроки:
- Сформуйте Security Operations Center
Команда не обов’язково має бути великою, іноді достатньо двох фахівців. Але це мають бути досвідчені спеціалісти, задіяні в проєкті, щоб активно взаємодіяти з командою розробників, тестувальників, власників бізнесу тощо. SOC в режимі реального часу моніторить активність користувачів, реагує на інциденти та в особливих випадках самостійно розв'язує проблеми. Фахівці повинні мати можливість швидко заблокувати підозрілих юзерів та IP-адреси.
- Проводьте комплексні перевірки безпеки
На етапі розробки за сек’юрність відповідають девелопери і тестувальники. SOC-команда долучається до пошуку вразливостей після запуску проєкту, зокрема під час penetration-тестів (тестування на проникнення). Фахівці не обмежуються моніторингом та реакцією на алерти. Девелоперам вони можуть створювати тікети для виправлення помилок. Перевірки системи можуть бути складними й довгими, все залежить від проєкту, ролей у команді, бюджету. За бажанням замовника це бути додаткова послуга.
- Створіть сценарії взаємодії з користувачами
Задача бізнесу серед іншого — вести коректну та регулярну комунікацію з клієнтами. В компаній мають бути чіткі стратегії оперативного інформування юзерів про потенційні ризики. Потрібно розділяти, кому надіслати повідомлення — всім користувачам чи лише «жертвам» витоку даних, якщо вони відомі. Продумайте поради для своїх користувачів.
Інколи достатньо змінити пароль, але в деяких ситуаціях, щоб убезпечити аккаунт, зміни потрібні суттєвіші. Наприклад:
- Увімкнути двофакторну аутентифікацію для додаткового рівня захисту.
- Перевірити список пристроїв, підключених до облікового запису, та вийти з непізнаних сесій.
- Оновити контактну інформацію для відновлення доступу, в тому числі email та номер телефону.
- Відкликати доступ сторонніх застосунків та перевірити дозволи API.
- Сканувати пристрій на наявність шкідливого ПЗ та оновити антивірусне програмне забезпечення.
- Змінити паролі на всіх сервісах, де використовувався скомпроментований пароль.
Кейс Dell багато чого може навчити як власників бізнесу, так і технічних фахівців. Та головний висновок, як на мене, в іншому: вразливості можуть виявитися в кожній, навіть потужній на перший погляд IT-системі. Тому складно переоцінити важливість моніторингу та оперативного реагування на подібні проблеми. Звісно, робота фахівців із безпеки потребує чималих коштів, але в разі зламу фінансові та репутаційні втрати можуть бути куди вищими.
Владислав Безродний, Application Security Engineer в NIX
Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
