VPNFilter теперь может заражать устройства от ASUS, D-Link, Huawei, ZTE

VPNFilter теперь может заражать устройства от ASUS, D-Link, Huawei, ZTE

VPNFilter теперь может заражать устройства от ASUS, D-Link, Huawei, ZTE

Вредоносная программа VPNFilter не так давно всколыхнула ИБ-сообщество, заразив 500 000 маршрутизаторов и NAS-устройств в 54 странах. Оказалось, что этого вредоноса недооценили — согласно опубликованному Cisco Talos отчету, VPNFilter может также заражать маршрутизаторы от ASUS, D-Link, Huawei, Ubiquiti, UPVEL и ZTE.

Напомним, первоначально считалось, что данный зловред предназначен для атак роутеров Linksys, MikroTik, Netgear, TP-Link и QNAP.

Таким образом, количество заражаемых VPNFilter моделей маршрутизаторов выросло с 16 до 71 (16 моделей упоминались в первом отчете Cisco).

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

Специалисты отметили два новых плагина:

  • ssler — перехватывает и модифицирует трафик на 80 порту, реализуя атаку «Человек посередине». Также этот плагин поддерживает даунгрейд с HTTPS на HTTP.
  • dstr — плагин, перезаписывающий файлы прошивки устройства.

Это только дополнительные плагины к тем, которые уже были известны компании:

  • ps — плагин, сканирующий сетевые пакеты, способен обнаруживать определенные типы сетевого трафика.
  • tor — плагин, используемый ботами VPNFilter для связи с командным сервером (C&C) через сеть Tor.

Технический разбор плагинов ssler, dstr и ps доступен в опубликованном Cisco отчете.

Приводим список устройств, атакуемых VPNFilter:

Asus:

  • RT-AC66U (new)
  • RT-N10 (new)
  • RT-N10E (new)
  • RT-N10U (new)
  • RT-N56U (new)
  • RT-N66U (new)

D-Link:

  • DES-1210-08P (new)
  • DIR-300 (new)
  • DIR-300A (new)
  • DSR-250N (new)
  • DSR-500N (new)
  • DSR-1000 (new)
  • DSR-1000N (new)

Huawei:

  • HG8245 (new)

Linksys:

  • E1200
  • E2500
  • E3000 (new)
  • E3200 (new)
  • E4200 (new)
  • RV082 (new)
  • WRVS4400N

Mikrotik: (устранено в RouterOS версии 6.38.5)

  • CCR1009 (new)
  • CCR1016
  • CCR1036
  • CCR1072
  • CRS109 (new)
  • CRS112 (new)
  • CRS125 (new)
  • RB411 (new)
  • RB450 (new)
  • RB750 (new)
  • RB911 (new)
  • RB921 (new)
  • RB941 (new)
  • RB951 (new)
  • RB952 (new)
  • RB960 (new)
  • RB962 (new)
  • RB1100 (new)
  • RB1200 (new)
  • RB2011 (new)
  • RB3011 (new)
  • RB Groove (new)
  • RB Omnitik (new)
  • STX5 (new)

Netgear:

  • DG834 (new)
  • DGN1000 (new)
  • DGN2200
  • DGN3500 (new)
  • FVS318N (new)
  • MBRN3000 (new)
  • R6400
  • R7000
  • R8000
  • WNR1000
  • WNR2000
  • WNR2200 (new)
  • WNR4000 (new)
  • WNDR3700 (new)
  • WNDR4000 (new)
  • WNDR4300 (new)
  • WNDR4300-TN (new)
  • UTM50 (new)

QNAP:

  • TS251
  • TS439 Pro
  • Другие NAS-устройства QNAP с QTS

TP-Link:

  • R600VPN
  • TL-WR741ND (new)
  • TL-WR841N (new)

Ubiquiti:

  • NSM2 (new)
  • PBE M5 (new)

UPVEL:

  • Список моделей неизвестен (new)

ZTE:

  • ZXHN H108N (new)

Напомним, ФБР рассказало пользователям, что нужно предпринять в случае заражения маршрутизаторов вредносом VPNFilter. Оказывается, нужно всего лишь перезагрузить затронутые роутеры. VPNFilter связывают с группировкой Fancy Bear, которая, как многие предполагают, спонсируется Кремлем.

Проводник Windows падал не из-за Microsoft, виноват оказался деинсталлятор

Инженер Microsoft Рэймонд Чен рассказал любопытную историю отладки загадочных падений Проводника. Сначала всё выглядело так, будто в Windows внезапно появился неприятный баг. Но виновником оказалась вовсе не Microsoft, а сторонний деинсталлятор.

Проблема проявилась как резкий всплеск сбоев Проводника. Инженеры начали изучать дампы и заметили странную деталь: падала 32-битная версия программы, запущенная на 64-битных системах Windows.

Такая версия Проводника всё ещё есть в Windows ради совместимости со старыми приложениями. Обычно современные системы почти не используют этот путь. Но в данном случае сторонний деинсталлятор каким-то образом заставлял систему обращаться именно к этому устаревшему компоненту.

Дальше выяснилось, что деинсталлятор некорректно работал с системными API: использовал неправильное соглашение о вызовах функций и неверно обрабатывал параметры стека. Из-за этого при каждой неудачной операции данные из стека удалялись неправильно.

Поскольку процесс повторялся в цикле, повреждение памяти постепенно накапливалось. В какой-то момент указатель стека уезжал в область активного кода, и Проводник падал.

Со стороны всё выглядело как типичная системная ошибка: софт снова и снова аварийно завершал работу, создавая ощущение, что проблема в самой Windows. На деле операционная система лишь показывала последствия ошибки в стороннем ПО.

Чен напомнил важную вещь: в экосистеме Windows с миллиардами устройств и огромным количеством приложений далеко не каждый сбой компонента Microsoft означает баг в Windows. Сторонние программы тоже могут ломать системные процессы, особенно если неправильно используют низкоуровневые API.

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