Почти 75% утечек пользовательских данных совершаются умышленно

Почти 75% утечек пользовательских данных совершаются умышленно

Почти 75% утечек пользовательских данных совершаются умышленно

Эксперты ГК InfoWatch представили интересный отчёт об утечках информации, зафиксированных в 2020 году. Аналитики привели долю умышленных сливов данных и рассказали об общей ситуации с подобными инцидентами, отмеченными за прошлые двенадцать месяцев.

Ковидный год, по данным ГК InfoWatch, привёл к росту числа менее явных утечек, поэтому из государственных организаций и коммерческих компаний стало сливаться на 4,5% реже, чем годом ранее (статистика по миру). А вот доли умышленных утечек и сливов по вине внешней стороны резко выросли.

Экспертно-аналитический центр InfoWatch за 2020 год зафиксировал 2395 утечек конфиденциальных данных из государственных органов, коммерческих компаний и прочих организаций. Эта цифра оказалась на 4,5% меньше, чем аналогичная в 2019 году, однако на 5,8% превысила показатели 2018 года.

Как отметили исследователи, США сыграли главную роль в снижении числа утечек в мире, поскольку показатель Запада упал на 20% за год. Тем не менее 11 миллиардов записей персональных данных всё равно оказались в общем доступе в период ковидного года. Утекали имена, фамилии, адреса электронной почты, телефонные номера, пароли, физические адреса, номера социального страхования, данные банковских карт и т. п.

Но в то же время общее число таких инцидентов снизилось на 25,5% в сравнении с 2019 годом. Также эксперты отметили меньший объём утечек: 4,6 млн записей в 2020 году против 5,9 млн в 2019-м. А вот крупных утечек стало больше (213 против 169 — на 26%).

Доля персональных данных в утечках 2020 также выросла с 76,6% до 80,6%, а платёжная информация стала сливаться реже (с 9,8% до 4,8%). В InfoWatch отметили, что причина кроется в усилении защиты платёжной инфраструктуры и усложнившейся процедуре использования данных скомпрометированных банковских карт.

Основной вектор утечек в 2020 году смещался в сторону внешнего нарушителя. Действия сторонних лиц стали причиной 55,9% подобных киберинцидентов. Общая доля умышленных сливов информации составила 72,5%, а в 2019 году — 60,2%.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Опубликованные ключи ASP.NET используются для развертывания вредоносов

В конце прошлого года специалисты Microsoft зафиксировали серию атак инъекцией кода, проведенных с использованием статических ключей ASP. NET. В одном из случаев злоумышленникам удалось внедрить в IIS-сервер инструмент постэксплуатации Godzilla.

Примечательно, что validationKey и decryptionKey, предназначенные для защиты данных ViewState от подмены и утечки, не были украдены или куплены в даркнете. Их можно найти онлайн, исследователи обнаружили более 3 тыс. таких сливов.

Обычно ключи ASP. NET генерируются по месту и сохраняются в реестре либо задаются вручную в конфигурационных файлах. К сожалению, некоторые разработчики веб-приложений используют готовые, отыскав их в паблике (документация на код, репозитории), притом без изменений.

Злоумышленникам такие находки тоже облегчают жизнь. При наличии верительных грамот для ViewState отправленный на сайт вредоносный POST-запрос будет с успехом обработан, пейлоад загрузится в память рабочего процесса и запустится на исполнение.

Подобная тактика позволяет автору атаки удаленно выполнить вредоносный код на сервере IIS и развернуть дополнительную полезную нагрузку — к примеру, фреймворк Godzilla с плагинами.

 

«Человеческий фактор нередко приводит к печальным результатам, разработчикам следует понимать, что статические ключи должны быть уникальными и защищёнными, — комментирует эксперт компании «Газинформсервис» Михаил Спицын. — Размещение таких данных в открытых репозиториях или документах эквивалентно предоставлению злоумышленникам несанкционированного доступа к системе».

Похожие атаки были проведены лет пять назад на серверы Microsoft Exchange. Злоумышленники пытались использовать ошибку разработчика, которую тот устранил двумя неделями ранее: все экземпляры Exchange Server использовали одни и те же значения validationKey и decryptionKey, прописанные в web.config.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru