Western Digital надо срочно бэкапить: пользователи жалуются на удаленное форматирование данных с NAS-устройств

Богдан Мирченко

29.06.2021 13:29

Сетевые хранилища Western Digital (WD) атаковал неизвестный вирус, который удаляет пользовательские данные, сбрасывая настройки хранилища до заводских. Представители WD попросили всех пользователей My Book Live и My Book Live Duo отключить сетевые хранилища от внешней сети.

Многие пользователи WD My Book Live получили 23 июня 2021 году внешнюю команду сброса настроек до заводских. Другие устройства, по мере того, как становятся доступными, продолжают получать команду.

Вот как выглядят данные из файла user.log, обнаруженные одним из пользователей после атаки:

Jun 23 15:14:05 MyBookLive factoryRestore.sh: begin script:
Jun 23 15:14:05 MyBookLive shutdown[24582]: shutting down for system reboot
Jun 23 16:02:26 MyBookLive S15mountDataVolume.sh: begin script: start
Jun 23 16:02:29 MyBookLive _: pkg: wd-nas
Jun 23 16:02:30 MyBookLive _: pkg: networking-general
Jun 23 16:02:30 MyBookLive _: pkg: apache-php-webdav
Jun 23 16:02:31 MyBookLive _: pkg: date-time
Jun 23 16:02:31 MyBookLive _: pkg: alerts
Jun 23 16:02:31 MyBookLive logger: hostname=MyBookLive
Jun 23 16:02:32 MyBookLive _: pkg: admin-rest-api

В компании считают, что устройства подверглись атаке неизвестных хакеров, потому что последнее обновление прошивки для My Book Live вышло в 2015 и происходящее не может быть связано с ней. По мнению пользователей, была скомпрометирована облачная система WD, которая отвечает за диагностику и доступ к открытым и зарегистрированным в ней устройствам WD My Book Live.

Как исправить ошибку

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

Инструкции для исправления уязвимости безопасности CVE-2018-18472 опубликовал пользователь под ником dracenmarx. Вот что нужно сделать:

Зайти по SSH и отредактировать файл (например с nano);
/var/www/Admin/webapp/includes/languageConfiguration.php.
Находим первое изменение:

exec("sudo bash -c '(echo \"language {$changes["language"]}\">/etc/language.conf)'", $output, $retVal);

Заменяем на:

if (!preg_match('/^[a-z]{2}_[A-Z]{2}$/', $changes["language"], $dummy)) return 'BAD_REQUEST';
exec("sudo bash -c '(echo '\"'\"".escapeshellarg("language {$changes["language"]}")."\"'\"'>/etc/language.conf)'", $output, $retVal);

Находим второе изменение:

exec("sudo bash -c '(echo \"language {$lang["language"]}\">/etc/language.conf)'", $output, $retVal);

Заменяем на:

if (!preg_match('/^[a-z]{2}_[A-Z]{2}$/', $lang["language"], $dummy)) return 'BAD_REQUEST';
exec("sudo bash -c '(echo '\"'\"".escapeshellarg("language {$lang["language"]}")."\"'\"'>/etc/language.conf)'", $output, $retVal);

По словам dracenmarx, в WD якобы знали об ошибке в 2018 году. Также разработчик обнаружил, что компания было известно об эксплойте с марта 2014 года, но она ничего не сделала.

В качестве дополнительных действий для безопасности dracenmarx советует:

Отключить «удаленный доступ» в UI;
Изменить «параметры подключения» с «автоматически» на «вручную», это отключит UPnP;
Отключить UPnP в роутере;
Если считаете, что заводское восстановление никогда не понадобится, отключите его. Отредактируйте /usr/local/sbin/factoryRestore.sh» и «wipeFactoryRestore.sh и измените строку №2 для exit.