Zyxel закрыла критические уязвимости в устаревших NAS326 и NAS542

Zyxel закрыла критические уязвимости в устаревших NAS326 и NAS542

Zyxel закрыла критические уязвимости в устаревших NAS326 и NAS542

Компания Zyxel Networks выпустила обновления прошивки для отслуживших свое NAS-устройств, в которых объявились три критические уязвимости. Патчи доступны корпоративным пользователям в рамках расширенной поддержки.

Угроза эксплойта актуальна для NAS326 с прошивкой версий 5.21(AAZF.16)C0 и ниже, а также NAS542 с прошивкой v5.21(ABAG.13)C0 и ниже. В обоих случаях гарантийный срок службы (с латанием дыр) истек 31 декабря 2023 года.

Краткая характеристика уязвимостей, согласно бюллетеню вендора:

  • CVE-2024-29972 — возможность внедрения команд при выполнении сценария remote_help-cgi; эксплойт не требует аутентификации и проводится с помощью вредоносного запроса HTTP POST;
  • CVE-2024-29973 — возможность инъекции команд с использованием параметра setCookie; эксплойт не требует аутентификации и осуществляется подачей запроса HTTP POST;
  • CVE-2024-29974 — возможность удаленного исполнения стороннего кода при отработке скрипта file_upload-cgi; эксплойт не требует аутентификации и проводится через загрузку специально созданного конфигурационного файла.

Исследователи из шведской ИБ-компании Outpost24 обнаружили в NAS-устройствах указанных моделей еще две уязвимости. Обе позволяют повысить привилегии в системе и, по мнению Zyxel, менее опасны, поэтому патчить их не стали.

Проблема CVE-2024-29975 возникла из-за небрежно написанного SUID-сценария. В результате возникла возможность локально повысить админ-привилегии до root.

Уязвимость CVE-2024-29976 проявляется при выполнении команды show_allsessions и позволяет после аутентификации получить сессионные куки совершившего вход админа.

В прошлом году Zyxel тоже латала NAS326 и NAS542. Продукты на тот момент не были сняты с довольствия, и в них в плановом порядке закрыли еще одну возможность инъекции команд — CVE-2023-27992.

Подпишитесь на новости

1,8 ТБ и вагон ошибок: как выгрузка с Яндекс Диска превратилась в квест

Пользователь «Яндекс Диска» решил сделать резервную копию 1,8 ТБ файлов, а также примерно 160 ГБ фотографий и получил приключение с ошибками API, зависшими загрузками и собственными скриптами.

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

Подробности инженер Сергей Терёхин, известный как KenGuru66, описал  в собственном разборе на Хабре.

План был такой: rclone, сервер в Нидерландах, копия в Google Drive. Но стандартная аутентификация позволяла получить сведения о диске, а обращения к файлам возвращали ошибку 410. Доступ удалось наладить с другим OAuth-токеном.

Фотографии из безлимитной автозагрузки добавили веселья: для копирования через выбранный API их пришлось переместить в обычную папку. После этого они начали занимать место в тарифе. Более 30 тысяч снимков переносились около шести часов.

В выборке из 300 случайных файлов автор смог получить начало только 146. По важной папке с документами он скопировал и проверил по MD5 2315 файлов; ещё 3079 на момент публикации оставались недоступны.

Потерю данных автор не утверждает, он продолжает повторные загрузки. Скрипты опубликованы на GitHub.

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