Вымогатели-шифровальщики переключились на незащищённые СУБД MongoDB

Вымогатели-шифровальщики переключились на незащищённые СУБД MongoDB

Вымогатели-шифровальщики переключились на незащищённые СУБД MongoDB

В Сети зафиксирована новая атака на серверы с СУБД MongoDB, доступные без аутентификации. Выявлено около 2000 поражённых систем, на которых имеющиеся данные были удалены, а в БД добавлена таблица "WARNING_ALERT", содержащая запись с требованием выплатить 0.2 или 0.5 Bitcoin ($200 или $550) за восстановление информации.

В сообщении утверждается, что данные зашифрованы, но на деле они просто удалены. При этом, в некоторых случаях в логе зафиксирован экспорт данных перед удалением.

 

 

Среди поражённых оказались конфигурации MongoDB, доступные для сетевых соединений извне и не использующие аутентификацию доступа. Подобная особенность связана с тем, что до версии 3.0 в MongoDB по умолчанию предлагались настройки, подразумевающие присоединение ко всем сетевым интерфейсам без включения аутентификации. В MongoDB 3.0 по умолчанию была осуществлена привязка к localhost, но многие системы, обновившиеся с MongoDB 2.x, сохранили прежние настройки в конфигурации, а привязка к внешним сетевым интерфейсам осталась незамеченной. Например, до сих пор остаётся открыта база одного из крупных операторов сотовой связи c данными о звонках абонентов, содержащая более 853 миллиардов записей, пишет opennet.ru.

Если раньше подобная беспечность приводила к утечке данных, например данный способ использовался для захвата учётных записей 13 миллионов пользователей программы MacKeeper, то теперь злоумышленники перешли к применению шантажа, надеясь заработать на серверных системах с ненадлежащим резервным копированием (расчёт сделан на то, что проблема будет выявлена администраторами после праздников, а за выходные резервные копии с реальными данными могут быть вытеснены новыми резервными копиями).

С проблемой уже столкнулось одно из учреждений здравоохранения США, у которого оказался блокирован доступ к 200 тысячам записям пациентов. Всем администраторам MongoDB рекомендуется проверить привязку к сетевым интерфейсам, заблокировать внешний доступ к сетевому порту 27017 и включить доступ с применением аутентификации (запуск с "--auth" или добавление в настройки "security.authorization"), который не активирован по умолчанию. 

MAX массово сбоит с самого утра: пользователи жалуются на сообщения

Утро 30 марта у многих пользователей MAX начал сбоить мессенджер. Примерно в 09:28 по московскому времени резко выросло число жалоб на работу сервиса: тысячи людей одновременно сообщили о технических неполадках. Судя по отзывам пользователей, сбой затронул сразу несколько ключевых функций платформы.

Как пишет detector404.ru, у одних не загружается основной интерфейс приложения, у других сервис вообще отказывается работать. Также поступают жалобы на проблемы с отправкой и получением сообщений, сбои при отправке медиафайлов и ошибки при загрузке медиаконтента.

О проблемах сообщают пользователи из разных регионов России. Больше всего обращений зафиксировано из Самарской области — на неё пришлось 10% всех жалоб.

На втором месте оказалась Ульяновская область с показателем 7%. Далее идут Москва, Санкт-Петербург и Республика Татарстан — по 5% обращений на каждый из этих регионов.

 

Если смотреть на распределение по устройствам, сильнее всего, похоже, пострадали владельцы Android-устройств: на них приходится 42,4% всех жалоб. Далее идут пользователи Windows с долей 29,3%, затем iOS — 23,9%. Значительно меньше сообщений о неполадках поступило от пользователей Linux (3,3%) и macOS (1,1%).

Особенно много недовольства вызвало то, что сбой произошёл именно утром, когда многие только начинают рабочий день и активно пользуются MAX для общения и решения рабочих задач. В комментариях пользователи пишут, что из-за неполадок не могут нормально вести переписку и пользоваться сервисом в привычном режиме.

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