В УСПД СЕ805М устранили три опасных уязвимости

В УСПД СЕ805М устранили три опасных уязвимости

В УСПД СЕ805М устранили три опасных уязвимости

Эксперт Positive Technologies обнаружил три уязвимости в УСПД СЕ805М производства компании «Энергомера»; одна из проблем была признана критической. Обновление с патчами для встроенного софта уже доступно и предоставляется по запросу.

УСПД СЕ805М предназначено для использования на энергообъектах ЖКХ и розничного рынка. Устройство осуществляет сбор данных с умных счетчиков электроэнергии и передает их на верхний уровень автоматизированной системы коммерческого учета электроэнергии (АСКУЭ); с помощью УСПД также можно удаленно управлять нагрузкой.

Найденные уязвимости характеризуются следующим образом:

  • BDU:2023-04841 (9,8 балла CVSS) — возможность несанкционированного изменения настроек на уровне SUPERVISOR (причина — вшитые в код учетки и использование хеша вместо пароля для аутентификации);
  • BDU:2023-04842 (8,1 балла) — возможность нарушения целостности базы данных и отказа в обслуживании (DoS) через SQL-инъекцию;
  • BDU:2023-04843 (8,8 балла) — возможность инъекции команд, выполняемых при запуске автообновления прикладной программы.

«К одному такому устройству могут быть подключены сотни счетчиков, — комментирует Антон Бояркин, автор опасных находок и сотрудник отдела PT по безопасности промышленных систем управления. — Используя уязвимый УСПД как шлюз, атакующий мог не только получить к ним доступ и нарушить работу системы учета на этом участке, но и отключить подачу электроэнергии. Устройство широко применяется в составе систем АСКУЭ электросетевыми компаниями и представлено у нас на полигоне Standoff 365».

По данным экспертов, большинство потенциально уязвимых устройств находятся в России и Азербайджане (51 и 28% соответственно). В небольшом количестве они также присутствуют в Белоруссии (2%), Германии (2%) и Казахстане (1%).

Пользователям советуют (PDF) обновить встроенный софт до сборки 4.13. Для надежности можно также ограничить или запретить доступ к порту, который используется для удаленной настройки УСПД.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

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

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

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

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