Из-за чего были стерты данные в NAS Western Digital

Недавно мы обсуждали историю с тем, как у пользователей NAS Western Digital после обновления были стерты все хранящиеся в NAS данные. В Engaget появилась статья, в которой вроде бы объясняется, что именно там произошло - "Hackers exploited two flaws in event that remotely wiped Western Digital devices".

То есть это результат действий хакеров, которые воспользовались найденной уязвимостью, однако что самое странное в этой истории - хакеры запускали сброс устройства, при этом такое действие должно было запрашивать пароль, и в программном обеспечении WD запрос пароля был. Но с какого-то обновления этот запрос был закомментарен (то есть это сделал кто-то внутри компании), и хакеры могли выполнить сброс устройства без запроса пароля. То есть у WD была (или есть) "крыса" внутри компании.

И это очень нехорошая история.

Upd: И еще по этому поводу интересное на Хабре. Уязвимость была известна аж с 2014 года. Но в WD по этому поводу жопу никто так и не приподнял. Упаси меня бог покупать NAS от WD.

Примечательно, что два других пользователя создали себе форки этого кода. 11 июня 2014-го и 29-го августа 2015-го. Утверждать, что о нём никто не знал... ну PR и не на такое способны :)

Получается, "неофициально", но вполне находимо (→ https://gist.github.com/phikshun) эксплоит был публично доступен 7 лет, самое позднее, когда WD получили официальный пинок репорт - 2018-ый. Но когда код пишется на тяп-ляп (или матерную форму сего выражения, иначе бы уязвимости не было), а задача поддержки — не ведение базы данных и введение причастных лиц в курс дела, то и получаем отписки

Комментарии 45

WD "решил" проблему.
Заплатки не будет.

Hello My Book™ Live/My Book Live Duo Customer,
If you are a My Book Live or My Book Live Duo customer, we are offering the following limited time offer:
Trade-In Offer:
Western Digital is offering current registered My Book Live or My Book Live Duo customers a trade-in discount of 40% off a select new My Cloud™ Home personal cloud storage or My Cloud EX2 Ultra 2-bay network attached storage device. For more information regarding the trade-in offer for eligible devices, please visit My Book Live and My Book Live Duo: Trade-In Offer.

Additionally, if you are a My Book Live or My Book Live Duo customer that has lost data as result of the recent security incident, we are here to help you by offering the following service.
Data Recovery Service (“DRS”) Offer:
Western Digital will help to recover your data using the data recovery services provided by a Western Digital-selected vendor. Western Digital will cover all the costs of shipment of the qualifying product to the DRS vendor and for the DRS. Recovered data, if any, will then be sent to you on one or more My Passport™ portable hard drives. For a list of qualifying products and eligibility requirements, please visit My Book Live and My Book Live Duo: Data Recovery Offer.
At Western Digital, we strive to continually improve our products and customer experiences. To take advantage of either of these services, or if you have any questions, please contact our Western Digital Support Team.
Sincerely,
Western Digital
12.07.21 09:33
0 0

Немножко теории заговора с Хабра:
01.07.21 19:32
0 0

Теперь NAS от WD как раз стоит покупать
30.06.21 16:55
0 1

На Ars Technica статья с подробностями
Hackers exploited 0-day, not 2018 bug, to mass-wipe My Book Live devices

We have determined that the unauthenticated factory reset vulnerability was introduced to the My Book Live in April of 2011 as part of a refactor of authentication logic in the device firmware. The refactor centralized the authentication logic into a single file, which is present on the device as includes/component_config.php and contains the authentication type required by each endpoint. In this refactor, the authentication logic in system_factory_restore.php was correctly disabled, but the appropriate authentication type of ADMIN_AUTH_LAN_ALL was not added to component_config.php, resulting in the vulnerability. The same refactor removed authentication logic from other files and correctly added the appropriate authentication type to the component_config.php file.
Про "крысу" и пр - вот мне интересно - почему на просторах xSU всегда ищут сложные объяснения простым вещам?
30.06.21 15:30
0 3

Кстати, эти слоупоки из WD мне только сегодня прислали письмо - мол, отключите устройство и ждите дальнейших инструкций.
Но у меня в WD Live диск несколько лет назад накрылся, так что уже не актуально...
30.06.21 15:02
0 0

01.07.21 10:36
1 0

Использую шестидисковый QNAP NAS T-653A. Полтора-два года назад почти сразу после обновления прошивки стали появляться фейковые сбои дисков. Уведомление в логе о сбое и пометка диска неработоспособным. То один диск, то другой. Для восстановления работоспособности NAS надо было вынуть-вставить диск (симитировать замену) и запустить многочасовую процедуру восстановления данных, после завершения которой через некоторое время вылетал новый диск. Мучался так почти две недели, в течении которых NAS пользоваться было невозможно. Раз десять так было, через все диски прошло. Сразу было понятно, что дело не в физических проблемах с дисками, а что-то с самим NAS. Обращался в поддержку QNAP. Максимум, что они мне смогли посоветовать - откатиться на старую прошивку. После отката проблема исчезла. Позже в новых прошивках стал искать в описании что-нибудь про исправление подобного бага. Ничего не было. Ни в каких новостях или репортах от QNAP тоже ничего подобного не встретил. Тем не менее, через пару прошивок снова рискнул обновиться. И, на этот раз, все прошло беспроблемно и ни разу с тех пор подобных сбоев не было.
Вывод. В QNAP в ходе доработки прошивки внесли какой-то очень серьезный баг, а потом втихую исправили. Так как шума не было, могу предположить, что условия для возникновения бага были специфичными и проявлялся он у немногих. Однако, это свидетельствует о том, что в QNAP тоже криворукие работают и неприятно, что даже в описании новых прошивок они решили не уведомлять никого об устранении подобного бага.
30.06.21 13:52
1 0

Единственно, что мне не очень понятно - какая выгода для хакеров запускать сброс устройства / стирание данных. Или это были не хакеры а малолетние кулхацкеры?
aag
30.06.21 13:24
0 0

Для хакеров выгоды никакой, а для конкурентов очень даже.

Можно было втихаря тырить инфу и дальше, а так ... Аларм!! Тревога!! Облава!!

Написано, что накопители My Book Live получали обновления ПО с 2010 вплоть до 2015 гг. Похоже, что на них разработчики просто забили болт, и не факт, что вообще знают об их существовании. 😄

Надо сказать, что многие пользователи наверняка активно пользуются накопителями 15-летней давности, которые не обновлялись уже лет 10, и какие там уязвимости сидят и ждут своего часа - никто не знает.
30.06.21 13:12
0 0

Но в WD по этому поводу жопу никто так и не приподнял.
Они просто очень заняты были - песеты меняли на евро.
30.06.21 13:02
0 2

Или "крыса", или, что более вероятно, кто-то отлаживал кусок кода, и этот запрос на пароль каждый раз его достал, так он его и закомментил. А потом забыл разкомментить на релиз, а теста на это у них не было.
30.06.21 13:00
0 3

Закомментил, а потом ещё и залил в стрим.
А тот, кто проводил ревью изменений, это дело пропустил.
А потом при мерже в продакшн-стрим снова никто не заметил (ведь не может же такого быть, чтобы можно было сабмитить напрямую в продакшн?)
А среди квалификационных тестов не оказалось соответствующего теста на проверку секьюрности.
Короче, WD - это целая система раздолбайства, от которой надо держаться подальше.

Надо просто переставать пользоваться устройствами с истекшим сроком поддержки. Ну хотя бы в критичных местах
30.06.21 12:28
6 3

Вы просто "не читатель"?
Если чукча, то простительно. (простите, Чукчи)

Взлом связан с обновлением прошивки!
30.06.21 12:34
7 0

Вот поторопились Вы. Сами не прочитали.

The My Book Live series was introduced to the market in 2010 and these devices received their final firmware update in 2015. [1]
Перевод нужен?
30.06.21 12:42
0 3

Взлом связан с обновлением прошивки!
Имхо, вы тоже. Последнее обновление прошивки в 2015 году.
30.06.21 13:48
0 1

Замечательно. Оличный выход. Сами-то хоть раз пытались соблюдать?
Да и потом, как написано, в паблике эта дыра с 2014 года, т.е. если бы кто-то додумался до этой атаки ещё тогда, то вся поддержка WD (закончилась в 2015) вам бы не помогла...
30.06.21 14:05
0 2

ИМХО это попытка WD отмазаться, типа нашли дыру CVE-2021-35941 только в этом году. Судя по статье дыре этой больше 7 лет. Пинали WD по этому поводу и в 2014 и в 2018 году. И ни с каким паролем она не связана, а тупо забыли заэкранировать параметр в запросе из за чего хакеры смогли выполнять любые команды на устройстве.
30.06.21 11:43
2 1

ИИ ни с каким паролем она не связана, а тупо забыли заэкранировать параметр в запросе из за чего хакеры смогли выполнять любые команды на устройстве.
Вы немного не поняли уязвимости - ДВЕ. И без дюбой из них атака бы не состоялась.
О Первой - удаленный доступ - стало известно в 2014г.
Вторая - отмена запроса пароля - была ещё раньше.
И WD знала об этом как минимум с 2018 но не желала выпускать обновление для таких старых устройств, т.к. денег же не приносит - устройства уже проданы...
30.06.21 14:02
0 0

Если какая-то крыса смогла внести изменения в продакшн-код, то всё гораздо хуже чем просто крыса - у WD серьёзные проблемы с организацией процессов разработки. Гораздо хуже потому, что на одну крысу всегда найдётся сотня обычных идиотов.

Да найти эту крысу плевое дело, все пользуются git системами контроля версий, и узнать аккаунт того кто закоментил такую строку это дело 5 минут.
Хотя уверен, что это было сделано для упрощения тестов, а потом просто забыли убрать при релизе.
30.06.21 11:22
0 5

Я где-то краем уха слышал, что для таких вещей как упрощение тестов существует conditional compiling.

Зачем такие сложности, закоментил строку и делов. Избавил себя от введения имени и пароля при каждом тесте. А вот что забыл раскоментить тут уже другая беда, думаю выводы будут сделаны нехилые.

Читал всякие истории с диска "штурман хакера", там было, что в 80-х из-за ошибки в ПО был масштабный сбой в электросистеме каких-то штатов США, как потом оказалось, что программисты поставили лишнюю фигурную скобку в цикле с семью вложенными подциклами.
30.06.21 11:21
0 0

Тогда вопрос, как хакеры добрались до устройств за файрволлом в приватной сети при условии, что никакие порты c них наружу не опубликованы? А проблема вроде бы возникла после обновления прошивки.
Или все же касается только устройств с открытыми портами, тем более ранее инфицированных?
Или же распространялась инфицированная прошивка с бэкдором?
Или же девайс облачный, с аккаунтом в облаке WD, постоянно держит коннект с ним, а накосорезили уже из облака? (Облака производителей зло.)
30.06.21 11:15
0 0

Тогда вопрос, как хакеры добрались до устройств за файрволлом в приватной сети
В прошлом году ИТ-аудит нашего клиента просканировал рабочие станции, серверы и сетевое оборудование с помощью MaxPatrol. 37 серверов - 34к уязвимостей, 117 рабочих станций на винде - 62к выявленных уязвимостей, 1 маршрутизатор - 18 уязвимостей.

И не сказать, что админы криворукие. Просто им каждый год так согласовывают бюджет на ИТ-безопасность, что часть серверов работает до сих пор на Windows Server 2003 и 2008.

И по итогам аудита было принято решение... закрыть это всё процедурами, а не обновлением хотя бы критично устаревшего ПО.
30.06.21 11:30
1 0

А проблема вроде бы возникла после обновления прошивки.
Нет.
Последние прошивки на WD Live были аж в 2015 году.
Что ж вы никак читать-то не научитесь, и вините всегда "обновления прошивки".
30.06.21 11:31
2 0

Тогда вопрос, как хакеры добрались до устройств
Тут детали m.habr.com
Вкратце, любой браузер в локалке загружает вредоносную страницу в инете, внутри код, который обращается к локальному NAS по имени и исполняет код
30.06.21 11:37
0 2

Я где-то винил обновление прошивки? Предположил вероятные причины. Если не оно, то хорошо.
30.06.21 13:10
0 0

Спасибо. Теперь вопрос еще, как он обращается по имени, это верно только для дефолтового имени или адреса, да еще наткнуться на injection.
У длинк DSL, кстати, давно была дыра, он по URL на устройство с определенным параметром светил админский пароль.
30.06.21 13:16
0 0

Мне вот тоже кажется, имело место быть банальное головотяпство (да ,банально, dev-ветку в мастер залили и весь фокус), чем злой умысел.
Да и смысл так крысятничать, если в репозитории все ходы записаны.
30.06.21 11:11
0 1

Бритва Хэнлона
«Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью»
30.06.21 11:30
0 13

Но как и упоминалось в комментах к прошлой записи, речь идет только о My Book Live линейке, а не о всех накопителях WD.
30.06.21 11:08
0 1

Но как и упоминалось в комментах к прошлой записи, речь идет только о My Book Live линейке, а не о всех накопителях WD.
Я не был бы ТАК в этом уверен.
30.06.21 12:57
0 0

Фотка какая удачная, мне даже показалось, что у мужика есть черты лица, как у Экслера. Дядя Лёша, признавайся, твоих рук дело в WD??? >=)))
30.06.21 11:06
2 0

Да, я - секретный физик. Закон Кулона знаешь? Моя работа!
30.06.21 11:07
0 3

Обидели какого-то джуна. А синьор не откодревьюил ) автотесты не оттестили (хотя врядли сброс устройства покрыт автотестами)
30.06.21 10:58
2 0

Была крыса, есть и кто именно WD из информации по контролю версии уже безусловно знает. Ну или как минимум с компа какого разработчика было сделано изменение.
30.06.21 10:52
0 0

Ну да, это должно быть известно.
30.06.21 10:57
0 0

Скорее закомментарили при разработке/тестировании прошивки, а потом просто забыли снять.
30.06.21 10:52
0 9

Да, но это ещё предстоит проверить уже внутри компании.
30.06.21 11:07
1 1

Скорее закомментарили при разработке/тестировании прошивки, а потом просто забыли снять.
Согласен. Может и саботаж, конечно, но вероятность раздолбайства больше. При тестировании пароли часто байпассят, а при компиляции под релиз не включили обратно. У нас коллеги из Индии лет цать назад тоже как-то кусок кода закомментарили и так в релиз и пустили. Город без связи был несколько ночей подряд: накат-не работает-траблшутинг-откат, следующую ночь по новой, поняли, в чем дело, R&D прислало коррекцию и в третью ночь таки поставили. Впрочем, и у наших полностью отрицать возможность саботажа не могу 😄
30.06.21 11:22
1 1

Да, но это ещё предстоит проверить уже внутри компании.
почему в будущем времени? если уже известно что "этот запрос был закомментарен", то значит известно под чьими креденшенами этот комит был сделан, когда сделан, с какого компа сделан. это если у них по-простому организована работа с версионным контролем. если же все комиты, как в больших конторах делается, интегрируются в ветки отдельным работником, то уже известно, кто одобрил это изменение на код-ревью и кто потом не оттестировал версию.

в любом случае, что-то не очень у них хорошие альтернативы в этой проблеме.
30.06.21 11:33
0 3

Скорее закомментарили при разработке/тестировании прошивки, а потом просто забыли снять.
«Никогда не приписывай злонамеренности то, что вполне объясняется глупостью; но не исключай злонамеренности».
Или же кратко:
"Миром правит не тайная ложа, а явная лажа"
;)
30.06.21 13:35
0 5
Теги
Сортировать по алфавиту или записям
BLM 18
Calella 113
exler.ru 138
авто 358
видео 2874
вино 299
еда 384
игры 107
кино 1341
ПГМ 1
попы 148
РКН 2
РФ 1
РЩД 709
СМИ 1640
софт 777
США 22
тип 2
тмп 11
шоу 6