Эксперты нашли способ избавиться от неудаляемого Android-вредоноса

Эксперты нашли способ избавиться от неудаляемого Android-вредоноса

Эксперты нашли способ избавиться от неудаляемого Android-вредоноса

Исследователям в области кибербезопасности спустя десять месяцев всё же удалось найти надёжный способ, помогающий избавиться от сложной вредоносной программы для Android — xHelper. Напомним, что ранее зловред считался неудаляемым.

xHelper терроризировал пользователей Android на протяжении десяти месяцев. Впервые его обнаружили в марте 2019 года.

Согласно многочисленным жалобам, наводнившим форумы в прошлом году, xHelper нельзя удалить даже через сброс смартфона к заводским настройкам.

Спустя несколько часов после подобного сброса xHelper переустанавливал себя в системе без всякого взаимодействия с жертвой.

При этом нельзя было сказать, что xHelper является именно вредоносной программой, скорее — раздражающей. Приложение докучало пользователям показом всплывающих рекламных окон или спамерских уведомлений.

Как установили эксперты, xHelper попадал на устройства пользователей с помощью приложений, установленных из сторонних источников.

К счастью, специалист из Malwarebytes Нэйтан Коллиер опубликовал пошаговую инструкцию, с помощью которой можно избавиться от xHelper.

Обратите внимание, что инструкция требует установить приложение Malwarebytes для Android, но оно абсолютно бесплатное, так что переживать не стоит. Итак:

  1. Установите из Google Play Store файловый менеджер с возможностью поиска файлов в директориях.
  2. Временно отключите Google Play Store, чтобы пресечь переустановку зловреда: Настройки > Приложения > Google Play Store > кнопка «Отключить».
  3. Запустите сканирование системы Android в приложении Malwarebytes — оно поможет вычислить имя процесса, за которым скрывается xHelper (как правило, это следующие имена: fireway, xhelper и дублирующее — Settings).
  4. Откройте файловый менеджер и найдите в хранилище любой объект, имя которого начинается на com.mufc.
  5. Отметьте или запишите для себя дату последней модификации всего, что начинается на com.mufc.
  6. Удалите всё, что начинается на com.mufc и все объекты с такой же датой модификации (за исключением папок вроде «Загрузки»).
  7. Активируйте Google Play Store — Настройки > Приложения > Google Play Store > кнопка «Включить».

34% систем управления ЦОД работает на устаревших прошивках

Треть систем управления инженерной инфраструктурой ЦОД работает на устаревших прошивках. Специалисты «Информзащиты» изучили 66 395 BMS и выяснили, что неактуальное программное обеспечение установлено на 34% устройств. Но старая версия — лишь начало: 84% систем обмениваются данными по небезопасным протоколам, а 800 содержат известные эксплуатируемые уязвимости из каталога KEV.

Хуже всего обстоят дела с системами мониторинга электропитания: устаревшие прошивки обнаружены на 59% устройств. У OT-систем показатель составляет 48%, у BMS — 40%, у IoT-оборудования и интеллектуальных датчиков — 37%, у источников бесперебойного питания — 23%.

Обновлять такие системы сложнее, чем офисные компьютеры. Новую прошивку необходимо проверить на совместимость с контроллерами, датчиками, шлюзами и диспетчерским ПО.

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

Свежая прошивка тоже не волшебная таблетка. Около 84% BMS используют протоколы без достаточной аутентификации и шифрования, включая BACnet и MODBUS. Устройство может одновременно иметь старое ПО, известную уязвимость и принимать команды, толком не проверяя отправителя.

Напрямую из интернета доступны лишь 369 исследованных BMS — менее 1%. Однако закрытый внешний периметр не спасает: 14% систем в инфраструктуре ЦОД находились всего в одном сетевом переходе от связанного с интернетом узла. У PDU эта доля достигает 41%. Злоумышленнику достаточно взломать соседнюю ИТ-, IoT- или сетевую систему, а затем переместиться в технологический сегмент.

Эксперты рекомендуют провести инвентаризацию инженерных устройств, закрыть уязвимости KEV, изолировать BMS, контролировать подрядчиков и следить за командами в технологических протоколах. Потому что резервный контроллер с той же дырявой прошивкой — это не киберзащита, а второй шанс наступить на те же грабли.

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