Ростелеком-Солар помог устранить бреши в промышленном оборудовании МОХА

Ростелеком-Солар помог устранить бреши в промышленном оборудовании МОХА

Ростелеком-Солар помог устранить бреши в промышленном оборудовании МОХА

Илья Карпов и Евгений Дружинин, эксперты «Лаборатории кибербезопасности АСУ ТП» компании «Ростелеком-Солар», провели исследование защищенности промышленного Ethernet-оборудования мирового вендора МОХА. В ходе исследования была обнаружена 31 уязвимость, в том числе ряд критических. Обнаруженные уязвимости могли позволить злоумышленнику получить доступ к управлению оборудованием, а также учетным записям пользователей, конфигурации сети и другой чувствительной информации. Данные об уязвимостях были направлены вендору, который выпустил соответствующие обновления безопасности.

MOXA Inc. — мировой лидер в производстве и разработке оборудования связи для систем промышленной автоматики с представительствами в 70 странах мира, в том числе в России. Корпорация занимает 3 место в мире в сегменте Industrial Ethernet – оборудования, которое позволяет объединить системы управления технологическими процессами в единую сеть и централизованно управлять ими с помощью MES-/SCADA-систем. Промышленные Ethernet-устройства МОХА широко распространены в нефтегазовом и электроэнергетическом комплексах, применяются в ряде транспортных инфраструктур, в том числе в России.

«Лаборатория кибербезопасности АСУ ТП «Ростелеком-Солар» занимается исследованиями защищенности промышленных протоколов, программных и программно-аппаратных решений, широко применяемых при создании и эксплуатации технологических сегментов российских предприятий. Это направление деятельности сегодня приобретает стратегическое значение для целого ряда отраслей, поскольку в последнее время наблюдается выраженный тренд к росту числа кибератак на промышленные предприятия, в том числе относящиеся к объектам КИИ», – рассказал Владимир Карантаев, руководитель направления Защиты критических инфраструктур и АСУ ТП компании «Ростелеком-Солар».

Большинство уязвимостей, обнаруженных экспертами «Лаборатории кибербезопасности АСУ ТП» «Ростелеком-Солар», относятся к реализации веб-сервиса оборудования MOXA. Эти уязвимости позволяют злоумышленнику осуществить так называемые атаки на отказ в обслуживании и временно вывести оборудование из строя (CWE-120, CWE-121, CWE-400, CWE-680, CWE-941), а также получить доступ к управлению оборудованием благодаря небезопасным механизмам аутентификации (CWE-200, CWE-352, CWE-521).

Большое число обнаруженных потенциальных киберрисков были связаны с тем, что чувствительная информация, в том числе логины и пароли пользователей, хранилась и передавалась в открытом, то есть незашифрованном виде (CWE-310, CWE-312, CWE-319).

Эксперты «Ростелеком-Солар» также сообщили о небезопасной реализации криптографического протокола в ряде Ethernet-устройств MOXA (CWE-327). Нестойкие алгоритмы шифрования могли позволить злоумышленнику получить информацию о конфигурации сети и скомпрометировать весь трафик. При этом в некоторых устройствах закрытый ключ шифрования, от которого зависит конфиденциальность зашифрованных данных, был записан прямо в коде программного обеспечения. В случае его компрометации весь трафик был бы открыт злоумышленнику, при этом смена ключа была бы невозможна для пользователя (CWE-321). Кроме того, в коде ПО некоторых устройств был записан пароль, предоставляющий доступ к управлению оборудованием (CWE-321), что несет аналогичные киберриски.

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

Эксперты «Лаборатории кибербезопасности АСУ ТП» «Ростелеком-Солар» немедленно сообщили о найденных уязвимостях вендору, а также передали информацию во ФСТЭК России для публикации в «Банке данных угроз безопасности информации» (BDU:2019-03252 – BDU:2019-03282). Это обеспечивает скоординированное единовременное раскрытие информации для различных CERT, SOC и сторонних баз данных уязвимостей. На данный момент уязвимости закрыты.

Windows 11 после обновления может отрезать вас от проводного интернета

Похоже, у сисадминов снова «праздник»: в сообществе r/sysadmin на площадке Reddit обсуждают баг апгрейдов Windows 11, из-за которого рабочие станции после обновления внезапно теряют проводную 802.1X-аутентификацию и остаются без Сети.

Сценарий звучит неприятно: обновляете машину «поверх» (например, с 23H2 на 25H2; люди пишут, что это повторяется и на ежегодных переходах), перезагружаетесь — и всё, Ethernet молчит.

Причина, согласно описанию участников обсуждения, в том, что после апгрейда папка dot3svc оказывается очищенной, а вместе с ней пропадают политики / профили, которые нужны Wired AutoConfig для 802.1X.

Wired AutoConfig (dot3svc) — это тот самый компонент Windows, который держит проводной 802.1X в рабочем состоянии. А его политики лежат как раз в директории C:\Windows\dot3svc\Policies (плюс есть папки для миграции во время апгрейда). И вот когда эти файлы исчезают / не мигрируют корректно, машина не может пройти 802.1X на коммутаторе и получить доступ к корпоративной сети.

Самое злое тут — эффект «замкнутого круга». Без сети устройство не может дотянуться до контроллеров домена, чтобы подтянуть Group Policy и восстановить настройки автоматически. Поэтому в полях лечат по старинке: подключают устройство в «открытый» порт без 802.1X, делают gpupdate /force (часто именно /target:computer), и только потом возвращают на защищённый порт.

Есть и ещё один баг: в отдельных кейсах при апгрейде люди жаловались на проблемы с машинными сертификатами, что особенно больно организациям на EAP-TLS (когда 802.1X завязан на PKI).

При этом самое обидное — на официальных страницах Windows Release Health для 24H2 и 25H2 упоминаний про 802.1X/dot3svc в списке известных проблем сейчас не видно.

Что с этим делать прямо сейчас, если вы планируете массовые апгрейды: многие админы советуют хотя бы заложить «страховку» в процесс — например, заранее сохранить содержимое C:\Windows\dot3svc\Policies и вернуть его после обновления, либо обеспечить доступ к сети через временно открытый порт, чтобы успеть прогнать gpupdate.

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