Неизвестные взламывают и сбрасывают WD My Book Live с полной потерей данных / forpes.ru

Главная
Неизвестные взламывают и сбрасывают WD My Book Live с полной потерей данных

Неизвестные взламывают и сбрасывают WD My Book Live с полной потерей данных +11

25.06.2021 10:55

denis-19 23 8000 Источник

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

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

WD просит всех пользователей My Book Live и My Book Live Duo срочно отключить сетевые хранилища от внешней сети.

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

Данные из файла user.log, обнаруженные пользователем на своем диске после инцидента:
Jun 23 15:14:05 My BookLive factoryRestore.sh: begin script:
Jun 23 15:14:05 My BookLive shutdown[24582]: shutting down for system reboot
Jun 23 16:02:26 My BookLive S15mountDataVolume.sh: begin script: start
Jun 23 16:02:29 My BookLive _: pkg: wd-nas
Jun 23 16:02:30 My BookLive _: pkg: networking-general
Jun 23 16:02:30 My BookLive _: pkg: apache-php-webdav
Jun 23 16:02:31 My BookLive _: pkg: date-time
Jun 23 16:02:31 My BookLive _: pkg: alerts
Jun 23 16:02:31 My BookLive logger: hostname=My BookLive
Jun 23 16:02:32 My BookLive _: pkg: admin-rest-api

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

Специалисты компании WD пояснили изданию Bleeping Computer, что в курсе проблемы и начали проводить собственное расследование инцидента. Они заявили, что атака на устройства пользователей была не через взлом серверов WD My Book Live, а из-за компрометации учетных данных самих пользователей.

Заявление производителя NAS: «Western Digital определила, что некоторые устройства My Book Live были скомпрометированы неизвестным вредоносным программным обеспечением. В некоторых случаях эта компрометация приводила к сбросу настроек до заводских, который, по всей видимости, стирает все данные на устройстве. Устройство My Book Live получило последнее обновление прошивки в 2015 году. Мы понимаем, что данные наших клиентов очень важны. В настоящее время мы рекомендуем вам отключить My Book Live от Интернета, чтобы защитить свои данные на устройстве".

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

Пострадавший от проблемы пользователь на Хабре предполагает, что это вина WD, которая продолжает рассылать некорректное обновление на сетевые хранилища пользователей, после установки которого NAS ведут себя по-разному — «у кого-то остается интерфейс и исчезают данные, у кого-то полное окирпичивание, кто-то может зайти по SSH, кто-то нет».

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы столкнулись с этой проблемой?

1,6%Да.2
24,8%Нет.32
5,4%Успел отключить от сети до инцидента.7
68,2%Никогда не подключаю NAS во внешнюю сеть.88

Комментарии (23)

XogN
25.06.2021 14:05
#23189150
+1
Использую чистый Debian на своем WD My Book Live уже несколько лет, благо заменить им родную прошивку достаточно простая задача.
1. isden
  25.06.2021 17:32
  #23190298
  А можете рассказать, как накатывали?
  У меня есть пара идей, но обе подразумевают всякие интересные развлечения на несколько часов :(
  1. XogN
    25.06.2021 19:11
    #23190654
    +1
    В моем случае тоже на час примерно. Просто мне это в удовольствие.
    Если вкратце:
    1) Бекапим:
    
    dd if=/dev/sda bs=15728640 count=1 | bzip2 >/DataVolume/shares/Public/SDA_MBR_FREESPACE.bz2 dd if=/dev/sda1 | bzip2 > /DataVolume/shares/Public/SDA1_IMAGE.bz2 dd if=/dev/sda2 | bzip2 > /DataVolume/shares/Public/SDA2_IMAGE.bz2
    
    Скидываем бекапы в надежное место.
    
    2)После:
    
    mdadm --manage /dev/md0 --fail /dev/sda1 mdadm --manage /dev/md0 --remove /dev/sda1 mkfs.ext3 /dev/sda1 mkdir /newroot mount /dev/sda1 /newroot/ dpkg -i debootstrap_1.0.67_all.deb gpg --no-default-keyring --keyring /usr/share/keyrings/debian-archive-keyring.gpg --keyserver keyserver.ubuntu.com --recv-keys 6FB2A1C265FFB764 debootstrap --arch powerpc wheezy /newroot http://archive.debian.org/debian cp /etc/network/interfaces /newroot/etc/network/ cp /etc/resolv.conf /newroot/etc/ cp /etc/hosts /newroot/etc/hosts nano /newroot/etc/apt/sources.list пишем в него: deb http://archive.debian.org/debian wheezy main contrib non-free сохраняем. mount -o bind /proc /newroot/proc/ mount -o bind /dev /newsys/dev/ chroot /newroot apt-get update apt-get install openssh-server mc --no-install-recommends passwd задаем пасс mcedit /etc/ssh/sshd_config настраиваем как нам нужно mcedit /etc/fstab должно быть так: proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 tmpfs /tmp tmpfs rw,size=100M 0 0 /dev/sda1 / ext3 defaults,noatime,nodiratime 0 0 /dev/sda3 swap swap defaults 0 0 /dev/sda4 /storage ext4 defaults,auto,noatime,nodiratime 0 0 apt-get install ca-certificates build-essential uboot-mkimage unzip mcedit boot.cmd echo Boot from U-boot configuration setenv md0_args 'setenv bootargs root=/dev/sda1 rw rootfstype=ext3 rootflags=data=ordered' setenv load_sata 'sata init; ext2load sata 1:1 ${kernel_addr_r} /boot/uImage; ext2load sata 1:1 ${fdt_addr_r} /boot/apollo3g.dtb' setenv boot_sata 'run load_sata; run md0_args addtty; bootm ${kernel_addr_r} - ${fdt_addr_r}' echo ==== Loading Linux kernel, Device tree, Root filesystem ==== run boot_sata mkimage -A powerpc -O linux -T script -C none -a 0 -e 0 -n 'Execute uImage' -d boot.cmd boot.scr cp boot.scr /boot/
    
    Инструкция не полная!!! Это примерная последовательность действий!!! Не несу ответственности в случае любых проблем!
    
    Помню что не собирал ядро из исходников, так как зеркала на важные патчи многие давали 404 уже. А с сервера одного из энтузиастов использования Debian на этом устройстве скачал уже собранное и проверенное ядро, которое поддерживает ext4 с размером блока 16384 на PowerPC архитектуре.
    
    Вроде были еще твики в виде установки и настройки утилиты для автоустановки часового пояса и времени при загрузке (в этом устройстве нет батарейки, время при выключении сбивается)
    Сама установка производилась наживую, у этой модели идет soft-raid1 видимо для удобства обновления прошивки.
    
    Прошу прощения, точнее информацию не смогу предоставить, за давностью лет уже смутно помню. Чудом нашел свою старую шпаргалку :) Но в инете еще встречаются мануалы.
    
    isden
    25.06.2021 19:15
    #23190672
    Ага, спасибо. Что-то подобное с разваливанием рейда и предполагал.
    Я еще думал на тему попробовать завернуть новую систему в апдейт-пак и накатить штатными средствами, но тут уже с разбивкой диска особо не поиграть.
    
    XogN
    25.06.2021 19:27
    #23190696
    +1
    В целом, рекомендую поискать более детальную оригинальную инструкцию. Моя — по сути личная шпаргалка, для себя, на память. Могу что-то упускать.

AntonioXXX
25.06.2021 14:35
#23189396
+1
У меня древний WD My Book Live еще первого поколения со старой прошивкой. Проблем нет, но отключил на всякий случай.

namikiri
25.06.2021 14:40
#23189422
Удаленный доступ к данным системам хранения напрямую невозможен, только через облачные серверы системы WD My Book Live.

Ага, типа это безопаснее. Я снова повторю свой комментарий: пользуйтесь облаками, это ведь так безопасно!
1. ialexander
  25.06.2021 19:38
  #23190734
  Ну вот в данном конкретном случае люди держали данные локально, не в облаке, и все равно потеряли их. Команда на удаление правда пришла из интернета, но к облакам вся эта история не имеет никакого отношения.
  1. namikiri
    26.06.2021 03:51
    #23191928
    Несмотря на то, что хранилище сетевое, ему нечего делать на серверах WD, за исключением обновления ПО. Здесь же сказано что была использована инфраструктура WD, при этом не сказано «при попытке обновления». Следовательно, NAS зачем-то шляется на серверы производителя и получает оттуда команды. Так быть не должно.
    
    Ark1774
    26.06.2021 10:49
    #23192354
    Может это бэкдор для любопытных госструктур?

Ark1774
25.06.2021 14:58
#23189536
А такой диск можно обнулить из личного кабинета?
Функционал мягко говоря сомнительной необходимости.
Если же нельзя, то это точно wd свой косяк(двойной, кривая ошибка и не остановили процесс) с прошивкой прикрыть пытается скрыть.

MoonInHell
25.06.2021 16:19
#23189944
Похоже на чью-то месть.

corvair
25.06.2021 16:32
#23190028
Команда на хард резет должна подаваться только локально, скрытой кнопкой, которую можно нажать предметом не толще зубочистки. Сброс, причём столь радикальный, никак не должен делаться удалённо.
1. Anterenoire
  25.06.2021 17:03
  #23190182
  Видимо, фича для всяких «деловых людей», у которых если стырили ЖД и подключили к компу с интернетом, чтобы могли удаленно все свои черные бухгалтерии поудалять. Другого объяснения столь сомнительному функционалу не нахожу.
  1. Layan
    25.06.2021 17:13
    #23190216
    В таком случае, как мне кажется, должен быть пароль/ключ, который производит сброс.
    
    ferosod
    25.06.2021 17:17
    #23190234
    Вероятно, он был :)
    
    Ark1774
    25.06.2021 18:55
    #23190608
    Всм отдельный пароль чисто под сброс. Если сброс массово происходит, то проблема на стороне производителя, т.к. слить его сложнее.
  1. Ark1774
    25.06.2021 18:32
    #23190536
    Даже такой функционал весьма сомнительный, т.к. диск может писать ip в личный кабинет или иметь скрипт который сканирует локалку и отправляет собранные данные куда нибудь. Так что если будут подключать, то только оффлайн с оффлайн же перепрошивкой для сброса паролей и прочего функционала который может помешать новому владельцу.
    
    Metotron0
    25.06.2021 21:20
    #23191038
    Это уже не просто случайный вор, а подготовленный вор, знающий, что он ворует.
  1. corvair
    26.06.2021 02:05
    #23191830
    Те, кто по долгу службы охотятся за "черными бухгалтериями", наверняка понимают правила обращения с вещдоками, а кто ведёт такую, вряд ли держат её на устройстве с внешним доступом.

5-55
25.06.2021 19:05
#23190636
Сколько не спрашивал на обучении, конференциях представителей Microsoft и др. компаний организующих облака и стремящихся как можно больше пользователей перетянуть в свои облака — Кто будет отвечать за незаконный доступ к моим данным?
В ответ только недолгое «мычание» и ответ что у нас все безопасно, отвечать будут только сами пользователи/организации.
А то что минимум у их администраторов есть доступ к хранилищам (в т.ч. физический) не афишируется.
По моему личному мнению облака можно использовать только для тех данных, с которыми можно совершенно безболезненно «попрощаться» навсегда и которые в принципе не содержат конфиденциальных данных, то есть то — что организация/человек готовы и так выложить всем в общий доступ.
1. vsantonov
  25.06.2021 19:28
  #23190698
  Так тут данные как раз лежат у вас локально, а диск в облако только торчит встроенным OpenVPN. А управляющий софт поверх этого VPN регистрируется в их системе и качает обновления, разрешая параллельно, как выяснилось, управлять собой. Я даже в конфигах нашел email сотрудника который это конфигурировал. Лечится просто, меняем конфиг OpenVPN на свой и WD теряет любой доступ к вашим данным.
1. Fahrain
  25.06.2021 19:40
  #23190742
  С облаками мне больше всего нравится то, что если локально хотя бы видно, что кто-то там пытается пароли брутфорсить, то с облаками это все в лучшем случае видят их админы, но учитывая размеры облаков мс/гугла — явно там уже давно на это пофиг.
  Прибежит очередной ботнет, начнет тыкаться в эти облака (это не сложно, у всех поголовно логин==email, который давно в соотв. базах лежит), просто по теории вероятности к нескольким процентам пароли таки подойдут, вопрос времени просто. И ответственности — никакой, ты же "сам" зашел.
  И это я еще не говорю про явные уязвимости. В прошлом месяце у меня в аккаунт apple внезапно добавился какой-то макбук и страна проживания сменилась на ЮАР. При этом, замечу, что пароль там был заведомо уникальный и не использовавшийся мною больше нигде ни разу, введенный в заведомо-безопасном браузере (и только там!) Edge без единого расширения. Уверен, если задать вопрос Эпплу, то ответ будет "это оно само, мы ни при чем".