Облачная халатность: как появляются утечки без вмешательства хакеров
Главные новости этой недели — массовые утечки персональных данных: до 60 млн клиентов Сбербанка (сам банк пока признает только 200) и 20 млн российских налогоплательщиков. И если в случае со Сбербанком пока много неясного, то данные о налоговых платежах россиян пролежали в облаке минимум в течение года из-за халатности владельца базы. И это далеко не единичный случай.
The Bell рассказывает об утечках, причиной которых становится не злой умысел хакеров, а беспечность владельцев массивов данных, хранящихся в облаках.
Эта статья изначально была написана для еженедельной технологической email-рассылки The Bell. Подписаться на нее можно здесь.
Краткий ответ: 20 млн налоговых записей с номерами паспортов, ИНН, информацией о работодателях и суммах уплаченных налогов.
Базы, об источнике которых известно лишь то, что их хозяин проживает на Украине, содержали свыше 20 млн налоговых записей (14 млн в одной базе, 6 млн в другой).
Хранившаяся информация охватывала период с 2009 по 2016 год и была доступна как минимум с мая 2018 года, когда ее впервые проиндексировали поисковики. Владелец не ответил на письма, отправленные 17 сентября 2019 года, но через три дня закрыл доступ.
В ФНС утечку назвали «провокацией», так как часть данных не собирается и не хранится российскими налоговиками. Кроме того, структура данных отличается от принятой в налоговой службе.
Собранные данные могут быть компиляцией из украденных баз госорганов.
Краткий ответ: независимый исследователь киберугроз Боб Дьяченко, специализирующийся на облачных утечках, совместно с британской компанией Comparitech.
Если кому-то нужно выложить в интернете большую базу данных, для этого обычно разворачивается поисковый кластер в популярном облачном сервисе — например, Amazon.
Владельцы баз данных часто не считают, что их база данных кому-то нужна, и не думают, что хранимые там пользовательские данные имеют какую-то ценность.
Метод Дьяченко заключается в сканировании облака Amazon и других сервисов и поиске баз данных. Он обнаруживает базы, которые забыли, не подумали или даже не сумели защитить паролем.
Краткий ответ: очень часто.
В блоге Дьяченко сообщения об обнаруженных утечках появляются 1–2 раза в неделю. В целом обнаруженные базы данных можно разделить на следующие виды:
- принадлежащие госорганам;
- информация о клиентах компаний;
- компиляции из неизвестных источников (например, результаты конкурентной разведки или скупки персональных данных для маркетинговых целей);
- базы, используемые троянами и мошенниками для автоматического хранения украденной информации.
Что хуже всего, далеко не со всеми владельцами баз данных удается связаться. А иногда они не понимают проблемы, возникающие из-за доступности информации.
Например, базы часто становятся добычей кибервымогателей. Те стирают данные и требуют выкуп за резервную копию. Одну такую уже взломанную базу обнаружил Дьяченко. Но беспечность владельцев дошла до того, что даже после двух месяцев предупреждений хозяева не закрыли доступ на запись и продолжают собирать в уже взломанную базу важную информацию.
https://twitter.com/MayhemDayOne/status/1179837283102593026
Среди множества недавних случаев выделяются два.
Утечка СОРМ, Россия. В сентябре компания UpGuard обнаружила общедоступный сервер с 1,7 терабайта данных об устройстве телекоммуникаций МТС и установке СОРМ — системы досмотра трафика и сбора информации российскими спецслужбами.
Причиной оказался сотрудник Nokia, грубо нарушивший протокол безопасности и работавший с секретными данными со своего домашнего компьютера.
Утечка данных избирателей, Казахстан. В июле 2019 года данные 11 млн граждан Казахстана (это все взрослое население страны) оказались доступны через поиск Google и «Яндекс».
Позднее выяснилось, что ИНН, паспортные данные и адреса проживания утекли через Центризбирком — его подрядчики забыли защитить от внешнего доступа сервер разработки.
Здесь было допущено сразу две ошибки. Во-первых, доступ к таким важным данным не был закрыт паролем. Во-вторых, поисковику не дано даже элементарной, хотя и недостаточной рекомендации не индексировать содержимое сервера.
- Не забывайте, что халатность — только одна из причин возможных утечек. Например, данные 60 млн клиентов Сбербанка, недавно выставленные на продажу, вряд ли результат глупости. Скорее всего, информацию о кредитных картах слил один из сотрудников.
- Первая утечка — не последняя. Если ваши данные или данные ваших клиентов утекли, они попадут в десятки других баз данных, и некоторые из них могут оказаться незащищенными, даже если вы приняли необходимые меры защиты.
- Не считайте сервер разработки или временный сервис чем-то, что нужно защищать хуже, чем основную систему. Утечки чаще всего происходят через самые слабые звенья цепи — или ковавшиеся в спешке.
- Отличайте рекомендацию от ограничения доступа. Например, «запрет» поисковым роботам индексировать те или иные уголки сервера — лишь совет, к которому злоумышленник может и не прислушаться.